- This topic has 21 replies, 4 voices, and was last updated 8 months ago by Chris.
November 29, 2019 at 6:16 am #1082907ruzek
Hi there! I am trying to import Merch and am getting 400 errors:
It looks like the error occurs when “importing site options” is reached. Query monitor didn’t show anything unusual:
These are the only PHP (7.3) errors I get:
[29-Nov-2019 12:53:51 UTC] PHP Notice: Undefined index: masonry_width in /srv/htdocs/wp-content/plugins/gp-premium/sites/classes/class-site-helper.php on line 146 [29-Nov-2019 12:53:51 UTC] PHP Notice: Undefined index: masonry_most_recent_width in /srv/htdocs/wp-content/plugins/gp-premium/sites/classes/class-site-helper.phpon line 146
I’m have updated to GP 2.4.1 and Premium to 1.9.1, and disabled all additional plugins (besides the ones the site library installs). Flushed cache as well, to no avail. Hosted on WordPress.com, so any server-side caching cannot be disabled.November 29, 2019 at 6:29 am #1082931DavidStaffCustomer Support
this is generally server related, Tom provides some pointers here that you can ask your Host:November 29, 2019 at 6:41 am #1082959ruzek
Thanks for getting back to me. Can you please provide an XML file so I can use the WP importer instead? Otherwise, is there a guide to manually configure this theme myself? It looks like CSS came through.November 29, 2019 at 10:07 am #1083472ruzek
Just a follow-up: It looks like other GP customers trying to import demo sites from the library are also running into the same errors on WordPress.com. The XML import solution was suggested.
If possible, please reach out to WordPress.com to see if anything can be done for your customers hosted there. I’d really appreciate if you could, though can make do otherwise if there’s a workaround.November 29, 2019 at 4:19 pm #1084855DavidStaffCustomer Support
The file XML can be found here https://gpsites.co/file/merch/content.xml
Problem is that it won’t import site options (plugin options etc..), menus and all that other stuff that’s done in the content import step.
Are you on wordpress . com ? As i know they are restrict access to most normal server controls.November 29, 2019 at 4:30 pm #1084888ruzek
Thanks for sharing that. So without the site library properly importing, I can’t use Merch huh?
SFTP/phpMyAdmin access is about to launch for Business and eCommerce plans on WP.com, so that might be an option for importing. What do you think?November 29, 2019 at 5:00 pm #1084936ruzek
Hey David, the https://gpsites.co/file/merch/content.xml link you shared 404’s when I try to load it.November 29, 2019 at 7:55 pm #1085200TomLead DeveloperLead Developer
Sorry about that – can you try this?: https://gpsites.co/files/merch/content.xml
I’m assuming that WordPress.com has some security measures in place that will prevent the download of external XML files like this. It might be necessary to include a way to manually upload the xml file directly in the importer so it can do all of the other good stuff it does.November 29, 2019 at 8:01 pm #1085206ruzek
Thanks Tom. A manual option would be a nice fall-back.November 30, 2019 at 9:49 am #1086636TomLead DeveloperLead DeveloperNovember 30, 2019 at 9:51 am #1086638ruzek
That’s sincerely appreciated!November 20, 2020 at 7:04 am #1539071ruzek
On WordPress.com, users are still getting 400 errors when trying to import GeneratePress sites.
Has an XML workaround made it to a release yet?
JonathanNovember 20, 2020 at 2:36 pm #1539488TomLead DeveloperLead Developer
Unfortunately, there isn’t much we can do if a host doesn’t allow the plugin to download the XML file.
We’re in the planning stages of a Site Library rebuild that may be able to address this, but we’re talking Q1 or Q2 of 2021 before that’s released.
The best thing to do right now is have your server caching temporarily disabled during the import process. If they aren’t willing to do that, another option would be to import a site on a non-WordPress.com site, and then import that site to WordPress.com using a migration plugin.November 20, 2020 at 5:01 pm #1539563ruzek
Thanks Tom! I’m a Happiness Engineer with WordPress.com and am willing to help figure this out. You’re leaning towards it being a caching issue?November 21, 2020 at 10:47 am #1540323TomLead DeveloperLead Developer
Awesome! Yes, in our experience the 400 error is a caching issue 99% of the time. I believe it has something to do with the admin AJAX failing the nonce check when caching is enabled, but I’m only guessing.
As soon as caching is disabled, the error is resolved 99% of the time.
If there’s anything specific I need to look into I’m happy to! Perhaps I just need to set up an account so I can dig into the code and find where the failure is.
Our plan is to ditch AJAX and use the REST API along with apiFetch in a future update, hoping it will solve issues like this.
- You must be logged in to reply to this topic.