I'm using latest version of CI for my project. I've a list of companies shown to the admin at backend, which show their information. The companies register from frontend and then show in the list for approval/disapproval from admin.
Now coming to the question. If I approve or disapprove any particular company, it updates the record in database, but as soon as redirects back to the list page, it shows the previous status of the company i.e it doesn't display the new updated status.
But as soon as I refresh the page, the new status is displayed. It comes to my mind that it may be fetching values from cache.
I'm using CI native function to update such as $this->db->update('companyTable', $data)
Can any one point me in the right direction, as to what I'm doing wrong here.
NOTE: Updation occurs in db, but when redirected back it shows old status. Upon refresh it shows new updated status.
NOTE2: It only happens on live server. On localhost it is working perfect.
you may use refresh during redirect
like redirect('controller/function','refresh');
Related
A very annoying just surfaced. I did some database tweaking, migrated it and manually imported the user table together with some other tables.
Suddenly the home page of my laravel spark won't display properly. It automatically goes to the settings#/subscription page.
The routes are still intact but are the HomeController is not used at all. I've cleared all caches but still the same. No errors in the log.
And even more annoying as I just found out, it only affects existing users that I imported. New users are not affected. So it definitely has something to do with the MySQL import.
I already compared the users values of a new user and an old one and tried to mimick the new one as much as possible. Doesn't work.
Anyone have an idea how to solve this?
It's been a while so you probably got to the bottom of this, but I just ran into the same issue.
In my case, I installed Spark without the team flag and signed up. Later, I added the necessary code to add teams back in without migrating and seeding. In a few places in my code I'm running the teamSubscribed middleware, and that was the crux of my problem. The redirect started looking at the team subscription status instead of the user subscription status.
Since I didn't sign up as a team, those fields were null, and it redirected pages with the middleware.
For others that come across this:
Search your codebase for the middleware (likely either in a constructor or your routes).
Double check your database for the corresponding user or team active trial status.
For some reason, after debugging i've noticed that form_keys are valid only after i clear the cache by doing a manual rm -rf * in the var folder, clearing my browser cache and retrying the site.
I have made no changes to the core code, I've diffed it to the original 1.8.1 installation, and they are exactly the same.
The original problem I had was that customers couldn't login because I had been using a customer/persistent/login.phtml file from the 1.7.0.2 version, and had to change it to add the form_key as a hidden input element using the method shown in all other posts about the new addition of form keys in magento 1.8.1.
I had captcha enabled, and for some reason when I went to the customer login, captcha isn't displayed.
Randomly, I don't know what I did, the page refreshed, and the captcha displayed and I was able to login to the dashboard and it worked. Then I logged out, and the same problem happened, the customer logs in with the correct username/password, but is redirected to the same customer login page.
I have debugged the loginPostAction in AccountController.php from app/code/core/mage/customer/controllers, and it appears that when the form key is valid, after refreshing cache, clearing cache, in mage and the browser, it reaches if( getIsJustConfirmed == true){ go to __welcomedashboard(..) } however getIsJustConfirmed returns null or false.
I did a check to see where getIsJustConfirmed is set, and it appears in setCustomer of the Session.php inside app/code/core/mage/customer/Session.php:
public function setCustomer(Mage_Customer_Model_Customer $customer)
{
// check if customer is not confirmed
if ($customer->isConfirmationRequired()) {
if ($customer->getConfirmation()) {
return $this->_logout();
}
}
$this->_customer = $customer;
$this->setId($customer->getId());
// save customer as confirmed, if it is not
if ((!$customer->isConfirmationRequired()) && $customer->getConfirmation()) {
$customer->setConfirmation(null)->save();
$customer->setIsJustConfirmed(true);
}
return $this;
}
the first part of !$customer->isConfirmationRequired() always returns true, however $customer-->getConfirmation() returns null, so it doesn't setIsJustConfirmed(true).
As you've noticed, Magento 1.8 adds form keys to a whole lot of forms. The form key in the hidden input field needs to match the form key in your user's session. This plays havoc with any form of caching, as the form key stored in the block or full page cache is unlikely to match the user's session key.
Firstly, I'll assume you've already compared the templates you've copied into a custom theme against the base/default versions and added form keys wherever they're missing.
Then, the next suggestion is to turn all caching in Magento off (and any full page caches such as Varnish) and see if that resolves the problem. This will confirm that you're caching form keys somewhere and this is the cause of your problem.
Next, use a tool like Fabrizio's Advanced Template Hints to see if any of the templates containing a form key are being cached, either explicitly or implicitly via a parent block. If so, this is the cause of your problem, and you'll need to investigate what is causing these blocks to be cached. A stock Magento system won't cache these blocks, but a 3rd party extension might be causing it.
Finally, once the block cache is resolved, you'll need to think about full pace caching (if used). There's no easy answers here, you'll need to either not cache the affected pages in a FPC, or find a way to put the correct form key into the page after it's served.
Step-by-step, I was having the same issue. I started logging the session key output by Mage::log(Mage::getSingleton('core/session')->getFormKey()); on each page load.
Until attempting to login as a customer, the session remained consistent.
However, after attempting to log-in, I determined that the session was getting invalidated on each page load (i.e. the aforementioned logging method echoed a different form key on each page load).
This led me to the cookie. I noticed that after attempting to log in as a customer, there were two frontend cookies stored by the browser: one with .my_domain.com and another with just my_domain.com, thereby causing the invalidation.
Setting the cookie Domain under System -> Configuration -> General -> Web to my_domain.com addressed the duplicate cookie problem and the forms behaved as expected.
I currently have my online store set up using Magento and i’m adding my products, I’ve tried to implement the PayPal Website Payments Standard but there is an error. When the user has passed through to the checkout section, after entering all their details, they fail to submit the order. The button is pressed to confirm order and redirect to the PayPal payment stage, the button will load saying that it's submitting the information, but nothing happens, it starts processing, then never goes through to the page. I've checked that the extension for Mage_paypal is enabled and it is.
If you would like try purchasing one of the test products on www.scarletkisses.com at the moment, you’ll be able to see what I mean.
Thanks.
2 things ..
Make sure that you have index management and cache management done
Try disabling and then enabling Mage_PayPal Module[Reindex the magento database after that]
Here's a quick step by step of what's been happening.
The user adds a product to their basket/cart and proceeds to the checkout. They may choose to Register, Checkout as Guest or Login with an existing account.
Customer Logs in with existing account.
They get taken to a page informing them that their shopping cart is now empty. Yet in the top right the link for My Cart still reads (1 item) next to it. Clicking this link just loads the same 'Shopping Cart is Empty' page.
Some other tests I did showed the following:
User logs in, adds 3 items to his cart, but logs out before going to checkout.
He comes back to the site at a later date and starts a fresh order for just 1 product, choosing to login at checkout.
Upon doing so his cart cart displays the 3 items from his previous session (his new product missing), yet the My Cart link reads (4 items) next to it.
Does anyone know what might be causing the items to vanish from the cart during this transition from not being logged in to being logged in?
I have seen this problem before on servers that are uhosin.session.encryptrunning the suhosin patch. I'm assuming that you are running a secure cart (if not you should) what is most likely happening here is that your session is being lost each time you change between http and https.
When you switch between the HTTP and HTTPS, your HTTP session is not being passed to the HTTPS session. This can be resolved by placing the following in your .htaccess or php.ini file:
php_value suhosin.session.encrypt Off
Let me know if it works or if you are still having the same problem, remember to restart your server once you have made the changes.
I solved it.
Turns out the ZetaPrints OrderApproval module was installed and was overriding part of the checkout page.
Apparantly it was something that had been added, decided it was no longer needed and then forgotten about.
I disabled it and flushed the cache and got my old checkout page back.
All working again.
For me, it was a matter of Cooke Session Control and setting my 'Cookie domain' value as such:
.mydomain.com
Yes, with a period in front.
I'm on Magento 1.4.1 and get regular calls (2-3 per week) from customers that they are unable to add products to their cart. The symptoms are the same for customers: All use IE (7 or 8, most commonly). When they attempt to add to cart, they are taken to an empty cart page. Repeated attempts do not resolve the issue. I have not been able to verify, and the only version of IE I have access to is 9. I would dismiss this as user error except for:
Generally lower-than expected conversion rate on my site (explainable if large % of IE customers are unable to transact).
Consistency of symptoms: Browser and version, action that is failing
I assume this is an issue with setting the session or cookie (but could totally be wrong and am open to other suggested causes). If it is a cookie issue, I've found this post and this post from Stack Overflow which give a little information, but not a solid idea of how to go about confirming it is a cookie or session issue.
Can someone suggest the best way to get started with diagnosis?
setting cookie lifetime to 86400 as recomended here did the trick for me.
IE9 bundles development tools (from settings menu) and this allow you to emulate ie7 - ie9 versions in all compatibility modes.
If you are getting blank pages then there is always a php error behind this and you can see those errors from your server php error log.
We had a similar issue with items disappearing from the cart, it only happened in a store that was using a subdirectory of the main domain, and only with ie9 and older ie's. We also had varnish running on the frontend, and magento 1.4.1.1
e.g.
www.example.com = main store
www.example.com/sub/ = secondary store
After adding items to the secondary store basket in ie9, you could then go to the main store and add more items, return to the basket page and all was well then if you went to another secondary store product and added another item to the basket, then visited the basket page all previous items had gone, but the one just added was there.
We found we could consistently reproduce this by visiting a secondary store product page, adding to the basket, visit the basket - item is there, return to the product page, return to the basket, item has gone. It turned out to be a bad background image url in the stylesheet, and the rule was only used by the product page template, this 404 error was enough to cause ie9 and older ie's to lose the session and start a new one.
ie10 and 11, chrome, firefox and safari didn't have this problem at all, so if you're getting intermittent customer reports of baskets suddenly being empty, check the whole site for 404's, all it can take is one missing image to lose the session for ie9 and older ie's.