› Forums › SNAP – WordPress Plugin Forums › Parse errors testing posts to self-hosted WP sites
- This topic has 5 replies, 1 voice, and was last updated 1 month, 4 weeks ago by felixandrea.
- AuthorPosts
- November 15, 2016 at 10:21 pm #519992Anna SParticipant
I’ve logged a ticket for this issue and have yet to receive a response. Turning to community to see if anybody’s experience is similar to mine…
SNAP pro has been throwing parse errors whenever I try to post to self-hosted WP sites. I’ve tried auto-posting to a couple of sites hosted on different servers, and always the same error.
– -=ERROR=- Array ( [pgID] => [isPosted] => 0 [pDate] => 2016-11-16 03:06:56 [Error] => -=ERROR=- parse error. not well formed ) | PostID: 0 –
I have a WordPress.Com site and it seems to test post successfully. Only the self-hosted sites are not working. Other accounts such as Instagram, Tumblr, and Blogger appear to work just fine.
Things I’ve tried…
-Rolling back to older WordPress version WP 4.5.4 on both host and client sites
-Rolling back to older SNAP Plugin 3.6.6
-In the intervening time, the API has updated from 2.24.7 to 2.24.16November 16, 2016 at 6:38 am #520082AlexGParticipant-=ERROR=- parse error. not well formed
This error can occur because of wrong character encoding of the blog.
Please make sure the encoding are the same on both blogs (source and target).November 16, 2016 at 2:55 pm #520184Anna SParticipantCould you specify where I should look for this info?
wp-config.php has charset defaulted to utf8 for as long as i can remember.
I took a quick look at the databases and tables, and they all seem to be utf8mb4 on both source and target.
Also, I attempted to send a test post from target to source…and it worked with no errors.
As a result of digging around in the back end, I noticed some subtle differences between source and target hosts:
Source server:
PHP Version 5.5.36
MySQL Version 10.0.27-MariaDB-cll-lveTarget server:
PHP version: 5.6.23
MySQL version: 5.6.30November 28, 2016 at 1:37 pm #522521Anna SParticipantAny more help please? My ticket has gone unanswered, and I’m not sure where else to dig up clues or answers. This problem has been ongoing since Nov 1.
I now have WP Plugin Version: 3.7.7 API Version: 2.24.16.
PHP is at 5.6 on my source site.
Database collation is at utf8_general_ci…and tables are at utf8mb4, consistent with the WP version.I still get the same parse error when trying to submit test posts to target self-hosted WP sites on different servers.
Array ( [pgID] => [isPosted] => 0 [pDate] => 2016-11-28 18:10:26 [Error] => -=ERROR=- parse error. not well formed )
December 15, 2016 at 12:43 pm #526717Anna SParticipantWell after much hand wringing and zero response to my ticket, it turns out the issue lay in the hosted environment and not with my local installs. Since I deal with various setups, it was a challenge to find a workaround. For half of my WP blogs, I had to move off Nginx servers, since the hosting companies effectively blocked calls to xmlrpc at the server level.
For the other hosts running Apache, I was able to implement user-level .htaccess filters which allowed me to use the following lines on the target sites:
<Files xmlrpc.php>
SecFilterInheritance Off
</Files>OR:
<FilesMatch “xmlrpc\.php$”>
Satisfy Any
Allow from yourdomain.com
Allow from yourdomainip
Deny from all
</FilesMatch>So if you’ve already troubleshot these areas in your WP install and/or, then give the above a try.
-Checked your wp-config.php for debug mode, charset
-Modify Security Plugins that disable xmlrpc
-Rewrite over your WP core files in case of hacked/corrupted files
-Checked WP database for correct collation/encoding (via phpMyAdmin)
-Updated PHP to take care of broken/disabled PHP xmlrpc extensions (within cPanel)
-If running Varnish cache, disable within cPanelOctober 22, 2024 at 10:04 pm #596098I have a few new solutions to suggest:
– Check the xmlrpc.php File: Reload it from the original WordPress installation.
– Clear the cache from cache plugins (W3 Total Cache, WP Super Cache). Sometimes, old cache files can cause problems.
– Try switching to the REST API instead of xmlrpc.php.
– If you have a web application firewall (WAF) or other security rules, check if they are blocking requests to xmlrpc.php.
If these solutions don’t work, try rice purity test io- This reply was modified 1 month, 4 weeks ago by felixandrea.
- AuthorPosts
- You must be logged in to reply to this topic.