- This topic has 14 replies, 2 voices, and was last updated 5 years, 2 months ago by
.
-
Posts
-
I am facing a problem in importing the demo content while importing the site from Site Library.
I thought it is due to an insufficient upload limit, so I increased that also but still not working.
Any help.Thanks
Customer Support
Hi there,
The 400 error is usually a server error regarding AJAX in your Dashboard. When you try the import and get the error, right click the page and click “Inspect”. Are there any red errors in the “Console” area?
On right-click the page and click “Inspect”. I see a red error in the “Console” area.
Now it does not solve the problem.
What should I ask the server admins to do to solve the issue?
Thanks
AshishCustomer Support
Hi there,
can you tell us what the error says ?
I see there are a lot of posts regarding this issue that I’m experiencing now. I’ve never had this problem on my hosting that uses shared hosting that uses CloudLinux with a LiteSpeed server. BUT! I’m also hosting a WP Multisite install on WPMU DEV hosting that uses NGINX. After doing what the docs suggest for this issue, I got this from the log file:
[31-May-2020 18:46:10 UTC] PHP Notice: Only variables should be passed by reference in /var/web/site/public_html/wp-content/object-cache.php on line 317 [31-May-2020 18:46:10 UTC] PHP Notice: wp_cache_flush() used, this is broadly not recommended. Called in /var/web/site/public_html/wp-content/plugins/gp-premium/sites/libs/wxr-importer/WXRImporter.php line 541 in /var/web/site/public_html/wp-content/object-cache.php on line 322WPMU DEV’s plugin Hummingbird is installed and I deactivated it by changing the folder name in the plugins directory but I got the same error.
So I contacted WPMU DEV support and this is what they said,
EasyEngine – we’re not using it, that’s for sure. Actually, I just learned that it exists as well.
If disabling Hummingbird by renaming the folder didn’t help in this case, then Hummingbird isn’t part of the issue here. I’d say that it shouldn’t have any influence here as it does page caching and that shouldn’t affect the import process in any way.
The notices in debug.log actually mention something completely different. wp_cache_flush is a function from WordPress core that handles internal WP caching. You can find out more about it here: https://developer.wordpress.org/reference/functions/wp_cache_flush/
We do have another cache on our host however, Object Cache. It’s server side and you can clear it from the Tools tab on your hosting admin page (Tools >> Object Cache >> Flush).
Clearing Object Cache may be needed especially in cases when the database was changed without using standard WordPress functions.
I think this is the case with the importer here, if it’s using a custom method to insert data into the database (that’s the most probable cause of the issue here). It’s generally highly discouraged to make edits to the database skipping the functionalities provided by WordPress, because oftentimes it causes issues like this one. The functions provided by WordPress for changing the contents of the database take server-side caches into account and thus won’t cause that kind of issue.
By the way, the object-cache.php file can’t be renamed or deleted on our hosting as it’s an important system file that’s required for the site to work.
That said, I’d talk with GeneratePress support about possible issues with Object Caching and request them to check that route further.
I did Cleared the Object Cache as he suggested and still received the 400 error.
Any insight on the WPMU DEV support person’s comments would be great! Thanks!
Hi there,
Tom covers the two main issues for why this may occur:
https://generatepress.com/forums/topic/400-error-when-importing-from-site-library/#post-1130813
As you can see Caching is one of them.
Lead Developer
Just to chime in – WPMU Dev seems to be making some assumptions here.
The importer uses 100% core WordPress functions to process the import. We don’t use a single out-of-core function. Even the content importer is a fork of the core WordPress importer.
I believe the 400 error is a security error. We have various security checks in place throughout the importer to make sure no unauthorized users can make changes to your website.
When using a caching plugin (or something like object cache), these security checks don’t validate, as the request is cached.
I could look into forcing the cache not to take effect during import, which might be a possibility.
For now, the best thing to do is completely disable any caching plugins or server caching just while you do the import. Once the import is done, you can re-enable any caching without issue.
Hey Tom, thanks for the comment. I figured WPMU Dev was making assumptions when he said that as I know you do things the WordPress way.
I can’t comment on the security issues but what I can tell you now is, I attempted to install some sites on my Multi-User Reselling hosting and ran into problems there as well. I received a 500 error as well as a 503 error when trying different sites.
The one thing I did notice which may shed some light is that I installed version 1.9 of GP (that was saved to my computer) then noticed that certain sites could not be installed without version 1.10. I installed v1.10, was able to install but then ran into errors again. I tried an older site and that worked. So maybe it’s just sites that require version 1.10 of GP Pro?
I could be barking up the wrong tree but thought I’d mention it.
I definitely has to do with server settings as I can install any site fast and easy on my Mac running MAMP. It just doesn’t work (certain sites anyway) on any server I’ve tried anymore.
So far, the 400 error seems to be 100% related to caching plugins/server caching. If caching is present, the security checks simply don’t check out, and the importer won’t work (for good reason).
The 500 errors are different and typically point to insufficient server resources (https://docs.generatepress.com/article/error-codes-importing/).
Any sort of import (especially content) is inevitably going to run into some issues on some servers, unfortunately.
The version number thing is just a simple check to make sure you’re using a version that has the necessary features to display the site you want to import as it looks in the demo.
Okay… I hate to admit this but… I’ve been using Brave Browsers lately (testing it out) and for those that have never heard of it, it’s touted as a really safe browser blocking all kinds of stuff.
It’s got a feature where, if a site is acting up or not working, you can go “Shields Down” and allow all that the browser is blocking.
I went “Shields Down” and blammo! The site installed flawlessly!
This is not the first time this browser has had me thinking something was wrong so I should have tried this sooner but it didn’t occur to me until after I wrote the above response.
Sorry for wasting anyone’s time. For anyone else having this issue, if you’re using Brave Browser, you know what to do!
That’s good to know! Thanks for reporting back 🙂
UPDATE: Disabling the Brave browser sheild worked with my Multi-User Reseller hosting with FullHost but did not do the trick with WPMU DEV.
I’ve passed on Tom’s comments to the support folks there.
Thanks for the update – appreciate it!
We’re good! They WPMU DEV support fella gave me the following line for my wp-config file:
define( 'WPMUDEV_HOSTING_OBJECT_CACHE_ENABLED', false );And that did the trick! I’ve commented it out as I don’t want to keep Object Cache disabled all the time it’s good to have since this is a multisite that I’ll need to install a GP site from time to time on.
Thanks for helping me get to the bottom of this!
Lawrence
Awesome, really appreciate you reporting back with this. It will definitely help other users in the future 🙂
- You must be logged in to reply to this topic.
