Hi,
I am having some trouble activating Toolset plugins. My site works fine on the dev site but whenever I activate Toolset plugins on the live site, everything breaks.
The destination URL is an installation of WordPress that is on a subdirectory of an existing installation of WordPress.
newsite.devurl.com << Development site. Everything works totally fine.
hidden link << an existing wordpress installation.
hidden link << the destination live URL for the development site.
When I enable the Toolset plugin on the destination URL and visit any /wp-admin/ page, the site gives me a 404 page. However, the 404 page is being served from the PARENT SITE (www.mysite.com) and not the destination site (www.mysite.com/newsite). When I disable all Toolset plugins, the admin pages load as normal.
I installed a completely blank WordPress installation, hidden link. When I activate a Toolset plugin on this site (/newsite-test/), I get the same behavior I described above.
This leads me to believe the issue is with the Toolset plugins. However, I cannot imagine what the issue might be.
Any help would be appreciated.
Is it possible that a server error 500 on the new destination site is being masked as a 404 error? Let's turn on server logs to see if any backend errors are generated. If you're not familiar with server logs I can show you how to activate them temporarily. Go in your wp-config.php file and look for
define('WP_DEBUG', false);
Change it to:
define('WP_DEBUG', true);
Then add these lines, just before it says 'stop editing here':
ini_set('log_errors',TRUE);
ini_set('error_reporting', E_ALL);
ini_set('error_log', dirname(__FILE__) . '/error_log.txt');
Then resave your site permalinks and try to activate Types only. If any backend errors are generated, this will create an error_log.txt file in your site's root directory. Please send me its contents. Once that is done, you can revert the changes you made to wp-config.php and delete the log file.
Thanks for the reply.
I enabled debugging and logging, resaved permalinks, and visited the page -- unfortunately, there were no errors being generated... the file had not yet been created.
The Apache error log threw the following errors when any Toolset plugin is activated and you try to visit the /wp-admin/ (these are from multiple requests to /wp-admin/:):
[Tue May 28 14:55:17.773840 2019] [proxy_fcgi:error] [pid 23446:tid 47062023100160] [client 69.160.38.132:40634] AH01067: Failed to read FastCGI header
[Tue May 28 14:55:17.773997 2019] [proxy_fcgi:error] [pid 23446:tid 47062023100160] (104)Connection reset by peer: [client 69.160.38.132:40634] AH01075: Error dispatching request to :
[Tue May 28 14:55:22.631828 2019] [proxy_fcgi:error] [pid 23446:tid 47062029403904] [client 69.160.38.132:41604] AH01067: Failed to read FastCGI header
[Tue May 28 14:55:22.631952 2019] [proxy_fcgi:error] [pid 23446:tid 47062029403904] (104)Connection reset by peer: [client 69.160.38.132:41604] AH01075: Error dispatching request to :
grep: 184.177.8.150: No such file or directory
grep: 184.177.8.150: No such file or directory
[Tue May 28 14:55:37.503374 2019] [proxy_fcgi:error] [pid 22876:tid 47062023100160] [client 69.160.38.132:43462] AH01067: Failed to read FastCGI header
[Tue May 28 14:55:37.503525 2019] [proxy_fcgi:error] [pid 22876:tid 47062023100160] (104)Connection reset by peer: [client 69.160.38.132:43462] AH01075: Error dispatching request to :
grep: 184.177.8.150: No such file or directory
[Tue May 28 14:55:41.129096 2019] [proxy_fcgi:error] [pid 23230:tid 47062114649856] [client 69.160.38.132:43694] AH01067: Failed to read FastCGI header
[Tue May 28 14:55:41.129181 2019] [proxy_fcgi:error] [pid 23230:tid 47062114649856] (104)Connection reset by peer: [client 69.160.38.132:43694] AH01075: Error dispatching request to :
[Tue May 28 14:55:41.950293 2019] [proxy_fcgi:error] [pid 22951:tid 47062012593920] [client 69.160.38.132:44274] AH01067: Failed to read FastCGI header
[Tue May 28 14:55:41.950358 2019] [proxy_fcgi:error] [pid 22951:tid 47062012593920] (104)Connection reset by peer: [client 69.160.38.132:44274] AH01075: Error dispatching request to :
grep: 184.177.8.150: No such file or directory
[Tue May 28 14:55:45.981740 2019] [proxy_fcgi:error] [pid 23446:tid 47062006290176] [client 69.160.38.132:44564] AH01067: Failed to read FastCGI header
[Tue May 28 14:55:45.981937 2019] [proxy_fcgi:error] [pid 23446:tid 47062006290176] (104)Connection reset by peer: [client 69.160.38.132:44564] AH01075: Error dispatching request to :
grep: 184.177.8.150: No such file or directory
[Tue May 28 14:55:51.579852 2019] [proxy_fcgi:error] [pid 22876:tid 47062106244864] [client 69.160.38.132:45104] AH01067: Failed to read FastCGI header
[Tue May 28 14:55:51.579921 2019] [proxy_fcgi:error] [pid 22876:tid 47062106244864] (104)Connection reset by peer: [client 69.160.38.132:45104] AH01075: Error dispatching request to :
[Tue May 28 14:56:11.273881 2019] [proxy_fcgi:error] [pid 22876:tid 47062116751104] [client 69.160.38.132:47700] AH01067: Failed to read FastCGI header, referer: <em><u>hidden link</u></em>
[Tue May 28 14:56:11.273991 2019] [proxy_fcgi:error] [pid 22876:tid 47062116751104] (104)Connection reset by peer: [client 69.160.38.132:47700] AH01075: Error dispatching request to : , referer: <em><u>hidden link</u></em>
Another bit of data: we are using php 5.6 on the live site while the dev site was running 7.x.
We turned off PHP-FPM and we were able to activate all the Toolset plugins and successfully log into the admin area.
Does your server use APC or any other opcache system? Object caching? Memcached? If so, does disabling the caching system resolve the problem when you reactivate PHP-FPM?
I'll check it out -- we do use Zend OPcache. I'll try disabling OPcache and enabling PHP-FPM and see if that fixes it.
I'll stand by for your update, thanks.
