Trying PL5 on a new WP Engine hosted installation (using a child theme for PL framework) with SSL cert and style is "gone."
We are using pagelines in an WPEngine environment that is cached by a varnish.
Whenever an editor makes a change eg on the home page the less will be re-compiled, which takes up to a few seconds.
What we witness then nearly every time is that the page references css that point to a 404, which makes the entire page unusable of course.
This lasts until the cache-age expires which is in our case 10 looong minutes
If we re-publish the page the problem is gone (most times or it re-happens).
Just trying to understand, maybe this is what happens:
I didn't find a pattern of how compiles-css files are stored or deleted. e.g. yesterday we published a couple of changes and there is no css file in the uploads directory from yesterday but many from last month etc.
I think the process might be like so:
1. I publish a page
2. the old css is deleted
3. in the meantime the page is broken and will be cached with 404 css references
4. then new css is re-compiled and saved to the uploads dir
5. the reference to the new css is saved to the database
6. after 10 minutes (cache-age expired) the new css is available
If this is the case pagelines doesn't support varnish - am I right?
Pls. let us know how to proceed. We have a large print campaing leading traffic to our site and it's broken as soon as we edit a thing.
Thanks in advance
OK, so I've been having some issues with WP Engine, mutlisite, and Pagelines DMS2. I searched the forums, and the closest thing (that didn't exactly work) was this: http://forum.pagelines.com/topic/38307-wp-engine-server-migration-copy-installation-problem/?hl=database
To make a long story short, when I created my staging site, the Site and Home URL were messed up (it was adding "www." to the beginning). After fixing that issue in the DB with a find and replace (using the same interconnectit tool in the above forum post), all the sections are suddenly blank. I can't figure out why... All I did was replace www.[stagingsite].wpengine.com with [stagingsite].wpengine.com. The first one was wrong, so if anything I would have expected to have problems with that one...
Any ideas? Here's the staging site:
Here's the live site:
Backstory: We had a marketing person who has a license to use Pagelines setup our website last year. Since then we have had a large increase in traffic and over the last few days the site became unusable. We do not have the license for Pagelines so we went back to the person who set it up but they were non-responsive. We host with WPEngine who provide great support. We asked them to look into it and they ran some diagnostics.
This is the response from tech support over at WPEngine - http://clicky.strapr.com/image/2N030q143Y1p
Here is the webpagetest.org results from running Pagelines - http://www.webpagetest.org/result/150117_JP_B7D/
We picked a different theme today from Themeforest to relaunch on while we determine our next steps.
Here is the webpagetest.org results from that new theme - http://www.webpagetest.org/result/150118_7A_5MC/
We went from an over 8 second page load time with freezing to a just under three second page load time. We are following WPEngine's advice and using a plugin called Smush to compress the images on the site so we can increase the performance even more. That plugin estimates we have a day and a half left before the compression is done.
In any case I thought this would be of interest to the Pagelines community so you can investigate what is causing the issue.
Here is a pastebin of the WPEngine text - http://pastebin.com/bxw6JEF6
Our website www.rootstock.com has been running on WPEngine for months without any problems.
Within the past 3 weeks, they have crashed it 5 times.
After much back and forth with their support staff, they came back to us with the following explanation and insist that our theme developer needs to fix this problem (snippet from them is below) -
There's an autoloaded row that's used by your theme ( pl-settings ) that is storing just past 1MB of data, that is going to be cleared out when our nightly processes are run within the environment. This would explain the header and footer being mangled, but the rest of the page being intact.
To remedy this, you will want to contact your site's developer and review the information being stored within that row and keep it as far under one megabyte as possible. If you would like to see the amount of data stored within rows on your end (in bytes), feel free to use the following command within PHPMyAdmin. You'll need to select your desired database (wp_ for production and snapshot_ for staging), then click on the SQL tab near the top:
max-width: 100%">SELECT option_name, LENGTH(option_value), autoload FROM `wp_options` WHERE autoload = 'yes';
Arrange the rows in descending order by "LENGTH(option_value)" and you'll get the rows holding onto the largest amount of data within your "wp_options" table. Also, to help speed things up, it's best to keep the total amount of autoloaded data as low as possible. Ideally, being under 300KB is best. Here's a query to show the total amount of autoloaded data:
max-width: 100%">SELECT SUM( LENGTH( option_value ) ) FROM `wp_options` WHERE autoload = 'yes';
Let me know if this helps to move things forward on your end. If there are any other questions that I can answer, please feel free to ask!
Is this a DMS-centric issue or is WPEngine able to remedy this? Is this an issue that every website hosting company will have with DMS?
Thank you for your help.