So I was talking with our hosting provider's support team (Flywheel) about a recurring problem with our sites. According to the support rep, it appears that an uncacheable PHPSESSID cookie is being placed onto every visitor's browser, effectively breaking cache for 100% of people going to our sites. This can be seen by looking in the "waterfall" section of a GTmetrix report at the slow server response time and looking inside of the "headers" within it. He mocked up a screenshot of the report to illustrate his point:
hidden link
He's able to make a server-level "band-aid" fix, but this implies that this is a temporary solution, and should be investigated further. The support rep then went out of his way to discover which plugin was causing this issue and determined, via process of elimination, that Toolset Layouts was the origin of this cookie.
Is there something we can do, either via our configuration methods, or elsewhere, that would allow us to disable the integration of this uncacheable cookie, or is it something more technical within the plugin's code?
Any help in the matter would be greatly appreciated.
Hello and thank you for contacting Toolset support.
From what I can gather so far, I can't be sure if it is only triggered by Toolset Layouts. In fact, it is being used in https://toolset.com and it does not generate a similar cookie. Check this screenshot hidden link
And this other one hidden link
Too many factors may be contributing to this issue. I suggest that we migrate your website into our platform and we check it there, so we don't impact your live users, and we will also have more control over the hosting server to enable/disable features.
Please follow the instructions in my private reply(June 19, 2021 at 9:46 am) to migrate your website. Once the migration finishes, reply to this thread so I can see it on my threads queue.
Please create an Administrator user for us before the migration and share its credentials in your next reply, which will be private.
Attached to my first message is a Duplicator package for you to bring over to your hosting environment, but if this is the way you prefer to migrate sites, I can go right ahead and attend to this.
The migration to your server has finished.
My apologies, I missed the Duplicator copy link, otherwise, I would have tested it before asking for migrating the website.
It turns out that the cookie is created when both "Toolset Layouts" and "Toolset Divi Integration" plugins are active.
I was not aware of the existence of this plugin "Toolset Divi Integration". It is from a couple of years before I join the Toolset team.
My teammates confirm that it was created when Toolset Layouts was used to design the entire page, including the header and footer. If you don't need that, I'll suggest disabling it.
Keep in mind that the current Integration with Divi 4 consists of a Toolset View module that can be used inside Divi designs. We still recommend not mix Toolset and Divi on the same pages for Divi 4 users. Check these articles:
- https://toolset.com/2019/10/toolset-and-divi-4-issues/
- https://toolset.com/2020/01/how-to-build-advanced-sites-with-toolset-and-divi/
Please try disabling that plugin in a staging site, then assess if it does not break anything. In that case, disable it on the live site too.
I hope this helps. Let me know if you have any questions.
I suspected that it might've had something to do with the Divi Integration Plugin, as a couple of my fellow associates had suggested that it was possible the cookie was linked to that particular plugin.
Thing is, we use the Divi Integration plugin to allow us to use Layouts to establish a global header and footer parent layout. This is a legacy practice that we have been using with Toolset since we adopted it several years ago. We would otherwise be unable to customize the header and footer areas to our liking if we weren't using the Divi Integration plugin.
And this has largely worked for us, with minimal issues. We don't use the Divi Builder within Toolset cells, but rather relegate Divi usage within post bodies, so we don't mix integration in this manner. The most we do is incorporate Toolset post meta data shortcodes and views within Divi code modules, but that's as far as "mixed integration" goes for us.
Our customized layouts are built strictly with Toolset cells within Layouts and traditional HTML markup with Toolset shortcodes for dynamic data.
We have tried to use Divi's own Theme Builder to structure our global header and footer areas without the Divi Integration plugin, but that has proven problematic on multiple levels, especially in regards to WooCommerce integration, so we've opted to continue in the same manner that we've been using Toolset since we adopted it prior to the shift to Toolset Blocks.
We have hesitated to move away from Toolset Layouts and Views into Toolset Blocks, because we still want to use Divi as a building tool for pages and certain post types, and Toolset Blocks does not give us the same level of control as these two "legacy" plugins do when it comes to layout and view structure for post types, archives, and beyond. We have even been encouraged by Toolset support reps to continue use of these plugins until Blocks receives all of the same features (if it ever does).
We were also told that we would continue to receive support with the Divi Integration Plugin, so I'm wondering if there is a change that can be made to it that would prevent it from dropping this uncacheable PHPSESSID cookie into user's browsers.
Honestly, I can't tell if we will provide further support for the Toolset Divi Integration plugin or not. I'll ask our 2nd Tier about it and get back to you.
The "Toolset Blocks" plugin and the "Toolset Views" plugin are virtually the same plugins with different names. In fact, it is not possible to activate both plugins at the same time. Once you activate one of them, it will automatically deactivate the other.
The only difference is the loading order. The Toolset Blocks plugin is always loaded first. While Toolset Views will be loaded after Toolset Layouts. This has, previously, created some issues that were addressed.
Let me check with our 2nd Tier about this special case and get back to you.
We're not actually using Toolset Blocks on any of our sites. We were told that we could continue use of the Views and Layouts plugins because Blocks didn't (at least at the time) offer the same level of features we've come to rely on from those two legacy plugins.
In fact, Toolset Blocks does not offer all the features that Toolset Views offers. That will come in the future. We still offer support for Toolset Views and Toolset Layouts. And we will fix any bug that may arise. However, the Toolset Layouts Integration plugin is not supported anymore.
Our 2nd Tier has analyzed this issue further, and he was able to sport the issue. We are not sure if that will create any side effects, and we would like your help with that.
As of now, please comment the line 7 in plugins/layouts-divi/application/theme/view/header.php
It will fix the cookie issue. However, we are afraid, it may have some side effects, please test this on your staging site before implementing it on the production site. Let us know what you will get.
Removing
<?php if ( ! isset( $_SESSION ) ) session_start(); ?>
from the header.php file of the integration plugin certainly addresses the PHPSESSID cookie, but I don't see any visible breakages in the staging environments that I tested this in.
What kind of "side effects" should we expect to see if we move this kind of change onto any production sites?
Our developers think that it would not have any side effects, but they have still recommended testing it in a staging site and assessing it to make sure everything works as expected.
Oh, awesome. Glad to hear it. Shall we close out this ticket, or are other solutions being considered?
Let's close this ticket unless you want to discuss something further. Feel free to open a new ticket anytime you have a question or you need assistance with something.
Sounds good. Thanks for your help, Jamal!
