Ioannis Anifantakis

Hi, I am having a very strange problem too.

I get SERVER ERROR 500 only at the backend of wordpress.
When I get that error, I have to “service httpd restart” and the backend is active again for “one click”. Then it gets SRV 500 error again.

So to make this short, while in the backend I have before any mouse click to restart apache. I never get errors on the front end. I also have the latest paid memberships pro version.

If I disable the plugin the backend works fine!

Now I also had another observation that made me pulling my hair. On the same domain, on a subfolder, I tried to make a fresh wordpress installation. I got also SRV 500 error on that subfolder during the wordpress installer.

By deactivating the plugin on the main website,
1) I stopped having srv 500 errors on main site
2) I was able to complete fresh wordpress installation on the subfolder of the main site.

I repeat I have installed the latest version of paid memberships pro.

My setup is on CentOS 6.8, with MySQL 5.1.73, Apache 2.2.15 and PHP 5.3.3

Same problem here.
Thank god I tried to check my backups before I did something. My backups stopped working since 29-Feb-2016. Thats the last date of my automated backups.

Version 3.5 doesn’t provide some kind of fix

Its more like a “hack” than a “fix”, but it will do the job.

I would like to make a quick question please.

What does the “filter” stand for in this code? We bypass it when in hhvm and everything “seems” to work fine, but its defenintelly there for a reason.

By removing it, what do we miss from the plugin functionality?

Thank you

I would like to make a very easy and super fast fix suggestion to the wp-all-import team.

To offer some kind of compatibility to your HHVM users, without compromising the filters functionality you have for the standard PHP users, I suggest the following check to see if hhvm is managing the content.

if (defined('HHVM_VERSION')) ....

This will return true if there is some hhvm installation active. It returns true only when hhvm is up, not just when installed! So if we stop hhvm and have php take over, it will return false, so you know exactly WHEN hhvm is taking over or php is taking over!!!

With that, in the 3 separate locations (was 2, now its 3) of the path in the chunk.php, you can do the following….

CHANGE THIS

if (function_exists('stream_filter_register') and $this->options['filter']){
    stream_filter_register('preprocessxml', 'preprocessXml_filter');
    $path = 'php://filter/read=preprocessxml/resource=' . $this->file;
}
else $path = $this->file;

TO THIS

if (function_exists('stream_filter_register') and $this->options['filter']){
    stream_filter_register('preprocessxml', 'preprocessXml_filter');
    if (defined('HHVM_VERSION'))
       $path = $this->file;
    else
       $path = 'php://filter/read=preprocessxml/resource=' . $this->file;
}
else $path = $this->file;

So, if there is a defined version of hhvm actively managing the php content, do the quickfix ($path=$this->file), otherwise keep the standard filtered action.

This is a WIN-WIN situaton.
1) You will keep the filter functionality
2) while at the same time (for those who know the fix), you will help the hhvm users not to change the code every time there is a plugin update.
3) (for those who don’t know the fix), will stop pulling their hair

After some deeper check, the above file may not be the problem after all, however your plugin causes “wp-load.php” to output bytes, and this is how to replicate it….

REPLICATION EXAMPLE
say you have a file testpdf.php

define('WP_USE_THEMES', false);
require_once('../wp-load.php');

header("Content-type: application/pdf");
readfile(get_site_url().'/wp-content/uploads/publications/test.pdf');

The above will serve the specified pdf normally without your plugin installed.

If you install your plugin the the above code does not return the pdf, because it adds bytes to the pdf, aka corrupting it…

so with your plugin installed, the only way to make it work is to ob_end_clean() whatever after the “required wp-load.php”.

That is your plugin adds some output to the wp-load.php….

So the only way for the above code to work while your plugin is installed is to do the following….

ob_start();
define('WP_USE_THEMES', false);
require_once('../wp-load.php');
ob_end_clean();

header("Content-type: application/pdf");
readfile(get_site_url().'/wp-content/uploads/publications/test.pdf');

CONCLUSION:
Without your plugin, including the wp-load.php doesn’t add any bytes to the output, with your plugin it does….

I noticed when I simply opened and resaved this file that it decreased by 2 bytes, and then my readfile returned correct binary file.