Multi-page posts do not render

There are probably two php extensions to verify you have installed, cURL and bcmath. Both are required for the GeoIP code.

Can you explain why non-multi-page posts come up fine, whereas only the multi-page posts are affected by the bug before I worry about installing those two components for the GeoIP system?

Nope, but usually when we see blank pages it’s because there is a missing library. The 5.2 release includes checks for them.

The other place to look is in your PHP error logs. The web server logs aren’t very helpful in these cases usually.

Closing topic.

Hi there.

I’ve had this plugin disabled for some time, but noticed you’d gone up to v6, so turned it back on.

As before, it still throws a blank page (zero bytes, no source) on multi-page posts.

My php error log is empty.

The web server shows:

[20/Jun/2014:17:33:20 -0300] "GET /2013/10/08/home-project-basement-aquaponics-test-system-part-2/ HTTP/1.1" 500 - "https://michelrvaillancourt.com/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36"

… you so can see the error code 500 there, so clearly something is breaking.

Restarting my webserver entirely shows the following in the HTTPD error log:

==> error_log <==
[Fri Jun 20 17:08:55 2014] [warn] mod_fcgid: stderr: WordPress database error Duplicate key name 'location' for query ALTER TABLE wp_statistics_visitor ADD KEY <code>location</code> (<code>location</code>) made by activate_plugin, include_once('/plugins/wp-statistics/wp-statistics.php'), include_once('/plugins/wp-statistics/upgrade.php'), dbDelta
[Fri Jun 20 17:08:55 2014] [warn] mod_fcgid: stderr: WordPress database error Multiple primary key defined for query ALTER TABLE wp_statistics_exclusions ADD PRIMARY KEY (<code>ID</code>) made by activate_plugin, include_once('/plugins/wp-statistics/wp-statistics.php'), include_once('/plugins/wp-statistics/upgrade.php'), dbDelta
[Fri Jun 20 17:08:55 2014] [warn] mod_fcgid: stderr: WordPress database error Duplicate key name 'date' for query ALTER TABLE wp_statistics_exclusions ADD KEY <code>date</code> (<code>date</code>) made by activate_plugin, include_once('/plugins/wp-statistics/wp-statistics.php'), include_once('/plugins/wp-statistics/upgrade.php'), dbDelta
[Fri Jun 20 17:08:55 2014] [warn] mod_fcgid: stderr: WordPress database error Duplicate key name 'reason' for query ALTER TABLE wp_statistics_exclusions ADD KEY <code>reason</code> (<code>reason</code>) made by activate_plugin, include_once('/plugins/wp-statistics/wp-statistics.php'), include_once('/plugins/wp-statistics/upgrade.php'), dbDelta
[Fri Jun 20 17:12:55 2014] [warn] mod_fcgid: stderr: PHP Warning:  parse_url(https://) [<a href='function.parse-url'>function.parse-url</a>]: Unable to parse URL in /home/siteadmin/public_html/wp-content/plugins/wp-statistics/includes/log/log.php on line 259
[Fri Jun 20 17:13:01 2014] [warn] (103)Software caused connection abort: mod_fcgid: ap_pass_brigade failed in handle_request function
[Fri Jun 20 17:13:07 2014] [warn] mod_fcgid: stderr: PHP Warning:  parse_url(https://) [<a href='function.parse-url'>function.parse-url</a>]: Unable to parse URL in /home/siteadmin/public_html/wp-content/plugins/wp-statistics/includes/log/log.php on line 259
[Fri Jun 20 17:13:13 2014] [warn] (103)Software caused connection abort: mod_fcgid: ap_pass_brigade failed in handle_request function
[Fri Jun 20 17:13:19 2014] [warn] mod_fcgid: stderr: PHP Warning:  parse_url(https://) [<a href='function.parse-url'>function.parse-url</a>]: Unable to parse URL in /home/siteadmin/public_html/wp-content/plugins/wp-statistics/includes/log/log.php on line 259
[Fri Jun 20 17:26:01 2014] [warn] (103)Software caused connection abort: mod_fcgid: ap_pass_brigade failed in handle_request function

I’ve got time to hunt this issue down now, so if you can give me some specific instructions about how to hunt this down, I’m willing to do what I can.

The PHP warning about parse_url() can be ignored.

The

(103)Software caused connection abort: mod_fcgid: ap_pass_brigade failed in handle_request function

is because you haven’t configured Apache with enough fastcgi requests.

Stackoverflow says:

https://stackoverflow.com/questions/12477627/mod-fcgid-ap-pass-brigade-failed-in-handle-request-function

And if you scoll down a bit to the “Special PHP considerations” area of the Apache documentation here:

https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#examples

Out of curiosity, what version of PHP are you running?

[root@web01 logs]# which -a php
/usr/bin/php
[root@web01 logs]# php -v
PHP 5.2.17 (cli) (built: Jan 16 2011 22:43:26)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies

It’s what’s bundled with the Virtualmin version 4.08 Pro / Webmin version 1.690 system.

I’ll read up those two articles you linked and get back to you.

Ok, so, I’m actually running

modules/mod_fcgid.so

… and not

mod_fastcgi.c

… which those StackOverflow articles point at. I’m doing some research right now into how to get mod_fcgid.so / Server version: Apache/2.2.3 (Server built: Oct 10 2013 12:56:26) to play nice.

I’m not entirely convinced this is a horrid issue with FastCGI, affecting the plugin, however. I say that, because the only time the problem happens is on multi-page posts … if I remove the page-break from the post, the problem goes away.

Based on those tests I strongly suspect something about the pagebreak logic is causing the plugin a heart-attack.

Let me know what other testing / info you need.

Actually the stackoverflow article talks specifically about mod_fcgid as does the linked Apache document.

I assume what is happening is that the multi-page posts + WP Statistics is tipping the request limit over the allowed value. This will then cause the 500 error.

WP Statistics does not touch the core logic of WordPress on a page load. We execute well after WordPress has completed its work at the very end of the PHP execution just before it exits.

You may also just be running in to an incompatibility with such an old version of PHP.

Both documents you linked specifically reference mod_fcgid.c … however, in my fcgid.conf:

LoadModule fcgid_module modules/mod_fcgid.so

# Use FastCGI to process .fcg .fcgi & .fpl scripts
# Don't do this if mod_fastcgi is present, as it will try to do the same thing
<IfModule !mod_fastcgi.c>
    AddHandler fcgid-script fcg fcgi fpl
</IfModule>

The problem, thus, is that none of the config options mentioned in those two documents seems to apply. :/ The HTTPD stack errors out on restart.

I’m going to roll back to v5.1 and see if the issue persists or not. I know that I used this plugin for a couple months before an update caused the initially reported issue.

I’ll let you know what happens.

An older version may work as we have added code to the plugin that may be pushing it over the limit. Likewise you probably were on an older version of WordPress.

You should have another configuration section to setup fcgid, however I’m not an Apache expert so I can’t help much here. You may not have any other options listed, but they will be set to the defaults in that case.

I think your best option is to find your php wrapper script and make the change as suggested in the Apache documentation.

Ok. So I actually rebuilt the server from scratch:

[root@web01a conf.d]# which -a php
/usr/bin/php
[root@web01a conf.d]# /usr/bin/php -v
PHP 5.3.3 (cli) (built: Dec 11 2013 03:29:57)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
[root@web01a conf.d]# which -a httpd
/usr/sbin/httpd
[root@web01a conf.d]# /usr/sbin/httpd -v
Server version: Apache/2.2.15 (Unix)
Server built:   Aug 25 2013 11:27:22
[root@web01a conf.d]# uname -a
Linux web01a 2.6.32-431.20.3.el6.x86_64 #1 SMP Thu Jun 19 21:14:45 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

WordPress 3.9.1

… it’s still not working. With FCGI enabled or disabled, it does not work. Mod_php, it does not work.

Can you make some suggestions as what to try next?

Are you still seeing the same error in the log?

Have you tried disabling all of your other plugins?

Alright. So after about an hour of experimentation, the issue seems to be an interaction between WordPress Statistics and Antispam Bee (https://antispambee.com) . If I disable ASB with WP-Stats activated, then a multi-page post is visible.

If both are active, then multi-page posts don’t work.

If only one of either are active, then they do.

I’m already using Askimet for spam-fighting, so ASB is a secondary tool. If I have to drop one of the two between ASB and WP-Stat, then I can “afford” to drop ASB.

You’ll likely want to see if you can reproduce the issue and pin it down… having a stat tracker that has an issue with anti-spam software isn’t great news.