I have a Magento store running 1.9.1.0, it appears that user sessions are being stored incorrectly, because:
If user logs out of their account: on the home page, it's fine, but then if they go to a product they've already visited, they're logged back in automatically.
I believe this to be related to caching, and disabling Fishpigs Bolt seems to fix the issue, but this hasn't occurred on other stores I have with Bolt
How can I ensure that Magento sessions are not cached in such a way?
Although it looks like the user is logged in, it's highly likely that they aren't logged in and that it appears that way because incorrect content has been cached. This shouldn't happen and with the latest version of Bolt, does not happen.
My first suggestion would be to upgrade Bolt to the latest version, which is currently 2.2.0.4. After doing this, fully refresh your cache and see whether this fixes the issue.
If this doesn't help, please contact me directly (I'm the creator of Bolt) using this form and I'll help resolve the issue. After that I'll edit this post with the correct solution.
UPDATE/SOLUTION
This issue was caused because of an incorrect Varnish/Turpentine configuration that stripped the 'frontend' cookie from Magento. As a result the FPC was unable to determine whether the user was logged in or had items in their basket. Removing Varnish/Turpentine resolved the problem.
I believe this is issue regarding caching modules like FPC. You need to mention that phtml block inside header in dynamic blocks in backend so that it will not cache the html.
In your case, even when you log out, when you go back to the page, header is coming from caching layer which was cached when customer was logged in. Make this as a dynamic block which will always render this html from server
Related
I am using PHP session to store some variables that have a short lifespan and also get deleted every time the browser is closed. It however does not work if I serve cached version of the page, which is basically a static HTML page.
Is there an alternative that can work the same way AND is compatible with cache in general?
PS: I'm talking about a WordPress site and cache in general (basically applies to every major cache solution out there)
Cookies and caching are the best alternative for session in wordpress.
when it comes to cookies basically there are two types of cookies
1.Session Cookies
2.Persistent cookies.
Now the question is
How WordPress Core Uses Cookies ?
When we refer to WordPress core, we simply mean the files that make up the open source project, before installing any third-party plugins or themes. It’s WordPress in its natural state as we like to call it.
Now that you know the basics of what a cookie is and the different types, let’s take a look at why and how WordPress core uses them to make all that magic happen behind the scenes. Fun fact: Cookie was originally derived from the term “magic cookie.”
WordPress core uses cookies for two different purposes:
1. Login Cookies
Login cookies contain authentication details and are used when a user logs into the WordPress admin dashboard. According to the WordPress Codex, a couple of different session cookies are set:
On login, WordPress uses the wordpress_[hash] cookie to store authentication details (limited to the /wp-admin/ area).
After login, WordPress sets the wordpress_logged_in_[hash] cookie. This indicates when you’re logged in and who you are.
When you try to access the back-end of your WordPress site, a check is done to see if the two cookies above exist and haven’t expired. This is what allows you to magically bypass the wp-login.php screen. 😉
WordPress also sets wp-settings-{time}-[UID] cookies. The ID being your user ID from the WordPress users database table. This stores personal dashboard and admin interface settings.
2. Comment Cookies
By default, there are cookies set when someone comments on a blog post (with an expiration of 347 days). This is so if they come back later they don’t have to fill out all the information all over again. The following three cookies are stored:
comment_author_[hash]
comment_author_email_[hash]
comment_author_url_[hash]
However, with recent privacy policy changes due to GDPR, new tools have been introduced by WordPress core to make sure you let users opt-in to these cookies being set. This setting, if not already set, can be enabled under “Settings → Discussion” in your WordPress admin dashboard. Select the option to “Show comments cookies opt-in checkbox.” The popular Akismet plugin also allows you to display a privacy notice.
Cookies and WordPress Caching
When it comes to WordPress cache, this is where things get tricky. Caching is essentially the process of storing resources from one request and reusing those resources for subsequent requests. Basically, it reduces the amount of work required to generate a page view. While this is great for performance, it causes a problem when it comes to cookies.
Why? Because cookies are there to perform a certain action, such as keeping the shopping cart populated while you browse around a WooCommerce site. However, if a page is served from cache, neither PHP nor the database does anything, the server simply serves up a static copy of the page.
So what can you do?
Use JavaScript
The first option would be to use JavaScript and update content on a page dynamically. Basically, you have HTML placeholders and use JavaScript to pull in info over an API or ajax call.
An example would be loading a list of posts in the WordPress sidebar by using JavaScript to grab a list of posts over the wp-api and then render them in the sidebar. In that scenario you could update the list of posts without clearing the page from cache since the data is generated dynamically.
This isn’t ideal though, it’s always better to cache if possible in terms of performance. But if you must have some bit of content remain dynamic while the page itself can remain static (served from cache), that’s one way to do it – use JavaScript to pull down the content for that part of the page dynamically via an API/ajax call. However, unless you can hire a WordPress developer to build a custom JavaScript solution or extension of a plugin, this option usually isn’t practical.
Use Admin-Ajax Calls
Admin-ajax.php is not able to be cached, therefore you could use admin-ajax calls. A good example of this is the No Cache AJAX Widgets plugin. It makes admin-ajax calls and therefore doesn’t have to worry about conflicting with server-level or third-party caching solutions.
However, just like with JavaScript, going down this route is typically not feasible for the average user. It can also lead to other performance problems such as high admin-ajax usage and lots of uncached requests.
Exclude Pages From Cache (When the Cookie is Present)
TRY A FREE DEMO
Unless you can go down the JavaScript or admin-ajax route, excluding pages from caching when a specific cookie is present is the best way to go. This is typically what we recommend, especially those running highly dynamic sites such as WooCommerce and Easy Digital Downloads.
At Kinsta, certain WooCommerce and Easy Digital Downloads pages like cart, my-account, and checkout, are automatically excluded from caching. There is a server-level rule in place so that users automatically bypass the cache when the woocommerce_items_in_cart cookie or edd_items_in_cart cookie is detected to ensure a smooth and in-sync checkout process.
We also listen for the associated logged-in cookies and set the cache to bypass when we detect that someone has logged into WordPress. The prevents the back-end dashboard from accidentally being cached.
By default, we don’t exclude the wp_woocommerce_session_ cookie from caching. Most WooCommerce sites in our experience don’t have any issues. This also improves performance by increasing your cache HIT ratio, while utilizing fewer PHP workers.
However, due to there being many different WordPress theme and plugin configurations, we can exclude the wp_woocommerce_session_ cookie from cache if needed. Just reach out to our support team. The result is that once a user adds a product to their shopping cart, all subsequent requests won’t be served from cache, increasing the usage of PHP workers.
If you need a custom page excluded from cache, feel free to open up a ticket with our support team. Again, you have to be careful when it comes to exclusions. Too many uncached pages could really deteriorate performance. Check out our do’s and don’ts for hosting WordPress membership sites.
I updated my webshop to 1.9.2.3. When I try to reset my password I do receive the email, but when I click the link to change my password I see a blank page.
I've looked this up on Google and changes customer_account_resetpassword to customer_account_changeforgotten. I changed it in all my customer.xml files just to be sure and I also cleared the cache, but without success.
I also noticed that the URL in the mail is: https://xxx.xx/customer/account/resetpassword/?id=976&token=b13713eb50b22b5a1320adbe08fdf08e but I get redirected to the page https://xxx.xx/customer/account/changeforgotten/
How do I fix this?
This was an issue that was created due to a recent patch that Magento released. They are now enforcing that forms with POST actions must submit the validation token. If you look at the link below, you will find the solution for this problem.
See - https://magentary.com/kb/reset-password-blank-page-after-supee-6788/
I hope this helps! I just recently had this issue myself.
Occasionally I run into a problem logging into the Magento admin panel. The username and password I enter is correct and the url in the browser window tells me that I have logged in correctly (ie: I see domain.com/index.php/admin/areallylongstring), however the login window is displayed again. No error message telling me that the log in details are incorrect is displayed, I am just routed back to the log in window. Has anyone come across this before and can anyone please suggest a solution?
Thanks!
Try start a private browser session and see if you can login, if so clear your cookies for the website and you should be able to login.
I occasionally get this problem, next time I get it I will dig into the code with my debugger to see what is actually going on.
This problem arises due to multiple reasons and the cheapest solution for this will be comment out the following lines in one of core files of magento.
FILE :- app/code/core/Mage/Core/Model/Session/Abstract/Varien.php.
// set session cookie params
session_set_cookie_params(
$this->getCookie()->getLifetime(),
$this->getCookie()->getPath()//,
//dependes which versin of mage you are using, you may comment these as well
//$this->getCookie()->getDomain(),
//$this->getCookie()->isSecure(),
//$this->getCookie()->getHttponly()
);
Find out above code in that file and then comment out those three cookies as shown above.
But as I said it is the cheapest and easiest solution that you can go with. For more information, checkout this link
I recently got Pair Networks to migrate my app to a new pair server. Since then I noticed the following:
Some users with extra permission are no longer able to access those areas they should normally have permission for. They get redirected to the login page which also serves as the Access Denied page.
Some pages with forms now redirect users to login.php on submit of the form. Form data are submitted to the db as expected though.
I have checked the db and the users are configured correctly. Also, user do not lose session when this happens, as they can click Back and navigate to a different area. I have also had a look at the log files but unable to gather much apart from the HTTP 302 code appearing a number or times to login.php probably describing the redirect to the login page.
Can anyone please suggest what could be responsible for this? Could it be a configuration problem and how can I deal with that? Could it be a conflict in those two servers I don't suppose it's pair's server, as I haven't really encountered similar problems in the past.
Any directions will be very much appreciated.
Seams like you are using PHP sessions out of the box, PHP is probably storing temp cookies on a folder that gets cleaned way to often.
If this is the case there is a security risk as the folder is server-shared and your services can be compromised.
A simple way to fix this is to change your session_save_path that can be done in the following fashion:
<?php
session_save_path('/home/example.com/sessions'); // where this a personal directory
ini_set('session.gc_probability', 1);
?>
I have a problem in my dev Magento store in that I can not save a new customer or edit an existing customer. I get the "Please Wait" box forever. The animation in the box moves a frame or two every so often but otherwise doesn't do anything. If I refresh the page it loads successfully but the changes have not been applied. I get no errors in the logs or on the page. All the other questions people have posted about this are either not related to customers or throw errors. This does nothing....it just sits there. I think it's failing on the validation, but I don't understand why. It doesn't even work when I try to hit the "Save" button without making any changes.
I did recently delete some 35000 customers that were imported from our main store, so I figured that might have something to do with it even though it was working since then and only broke recently. To test I imported an older copy of the database but I continue to have the same problem. At this point I have to imagine it's a file and not a database issue, but despite reverting all recent changes, nothing has helped.
Does anyone have any suggestions on debugging this and/or have you run into this before?
Thanks!
This was the first result on Google when searching "save customer account freeze magento" so I figured I'd include my findings here.
Running Magento CE 1.9.1 but this probably applies to most any installation. For my situation, the customer I was trying to modify had an extremely large address book (well over 100 addresses). Due to Magento's mechanism of validating every Form on the "Edit Customer" page, the browser determined that script execution was taking too long and killed the page.
My solution was to delete a bunch of the addresses with the customer's consent.
Add a few breakpoints in the various Form javascript class to see what the hold up is. For me it was a dead giveaway when the validator was attempting to process thousands of elements.