- This topic has 69 replies, 18 voices, and was last updated 3 years ago by
.
-
Posts
-
DigialOcean Ubuntu 18.04.1,
EasyEngine v4.0.11 (NginX), PHP 7.2.16
GeneratePress 2.2.2
GeneratePress Pro 1.8.0-alpha.2
WordPress v5.1.1The GeneratePress child theme I am trying to import is called “Marketer”, but I have also checked some of the others and it happens with all of them.
When I try to import from the Site Library I get an error 400, and the resulting site looks like it doesn’t import the correct sidebar content. However, when I check, it actually did the import the content, but (I assume) it couldn’t check that it was complete, so threw the error.
Eventually, as a test, I hid the @object-cache.php file and it turns out that the importer had imported all the sidebar content/widgets etc., because the site then started working/looking just as it should do.
I have reported this at https://wordpress.org/plugins/wp-redis/ but I thought I should also mention it here.
I end up with…
Search
Recent Posts
Recent Comments
Archives
Categories
MetaInstead of…
Product Highlight
Recent Posts
Follow MeSo disheartening. 🙁
I hid the @object-cache.php again and it turns out that the importer had imported all the sidebar content/widgets etc., because it all started working just as it should do.
So its definitely something in the @object-cache.php file that the importer and the site itself is objecting to.
Tom, I know I am not the only one with this problem. Can you investigate please?
OK, last report for tonight.
I re-enabled WPRedis and NginX Helper then hid the @object-cache.php file and the sidebar and widgets started working again, and the site isn’t running too slowly so, I think I’ll just leave @object-cache.php disconnected until somebody can figure out why its causing this problem.
Night all! 😀
Lead Developer
It just sounds like your site has some aggressive caching that isn’t working nicely with the importer. It’s a good idea to keep caching turned off while developing your site (not only using the importer), or else you will run into issues like this.
It’s not likely something we can “fix” on our end, as server caching isn’t within our control.
Tom,
Thanks for jumping in.
Because this kind of issue sometimes occurs, where one developer can’t or won’t accept responsibility for resolving the problem, this is precisely the reason I run the site/server caching from the get-go.
I don’t want to invest many hours of work only to find there is a fundamental incompatibility somewhere and nobody willing or able to help me fix it.
By the way, the WPRedis caching is the Pantheon implementation you can see here… https://github.com/pantheon-systems/wp-redis/
It works with every other EasyEngine site I have built, and that will be in the region of 40 or 50 using V4.
You say its not “within your control”, and I can understand where you’re coming from, but this is the only site I have ever built where I’ve had this problem, so I thought it might be important to you since it will mean all V4 EasyEngine users will have problems using GeneratePress child themes.
Terence.
I don’t want to invest many hours of work only to find there is a fundamental incompatibility somewhere and nobody willing or able to help me fix it.
I totally get that, and I agree. However, importing a site from the library is a one-time thing you do at the very start of your build. That typically means you’re safe to leave the caching off until the site is imported, then you’re good to activate it.
I’ll see if there’s anything we can do, but usually when something like this happens it means the requests we’re making to import the site are cached/not making it through.
I appreciate the feedback! 🙂
@Tom … no response from either EasyEngine or WP Redis, so now I have to find a new server platform, or change the theme to one that’s compatible.
I’m not sure I fully understand – doesn’t the Site Library work fine if you turn off caching? Once the site is imported you no longer need the library, so you can turn caching back on.
Or is the caching affecting the Customizer settings/overall appearance of the site?
Nope, the theme’s interaction with that file causes a problem which shows up in two ways. If the default caching is active when the child theme is imported it throws an error 400, but it does import everything, it just doesn’t show it when the caching is active. However, if that file is then hidden it shows the correct sidebar setup. This means that the top part of the sidebar configuration will not run when the caching is activated.
That just sounds like the cache is working. Have you tried clearing the cache once you re-activate it after the site is imported? If that’s not working, it sounds like the caching mechanism itself is broken.
Yes I had cleared both my browser’s cache and purged the WP Redis cache so I could see exactly what was being cached and what wasn’t.
Now the strange thing is, I’ve replaced the @object-cache.php file and now, it’s quite the opposite and I can’t get it to fail.
I’m stumped.
It definitely sounds like something is broken. If the widgets appear when that file is removed/renamed, it means the database has been updated correctly. If they disappear once the file is re-added, it means that file is holding on to an old cache when the widgets didn’t exist.
What do you mean by can’t get it to fail? Is it working now?
Yes Tom, that’s what I thought too. But now I come to replace the file and activated the caching plugin, it just seems to work. Something has definitely changed but I can’t see what. Oh well, all’s well that ends well, I guess. 🙂
Glad it’s working now 🙂
- You must be logged in to reply to this topic.