Problems getting WordFence to work with my site on SiteGround

Hi @onty,

Does the warning persists if you exclude from caching the file /home/username/public_html_domains/art-of-software-testing.com/wp-includes/load.php?

All the caching is completely off (as far as I can control it)
I have also disabled all plugins related to caching.

• This reply was modified 7 years, 7 months ago by onty.

If I just rename “php.ini” to “php.ini_” (effectively removing the part of WordFence which loads before the WordPress code), then the site loads completely fine, and everything works, but WordFence says it’s not been fully setup.

The moment I renamed it back, everything stops working.

Please note that WordFence has been installed on this site previously, and DB has WordFence tables. Is there a process for removing these old settings? Is it safe to just delete existing WordFence tables before trying WordFence again?

I can provide you with the URL to the site so you can take a look for yourself, but I would prefer not to put it into a public forum.

Hi @onty,

Could you make sure the SG Optimizer plugin or the Dynamic Cache are disabled?

If you wish to delete all Wordfence related tables in order to carry out an install from scratch, please see below the steps to follow.
However, keep in mind that this will remove all previous Wordfence related data (scan results, live traffic data, etc.) as well as any specific configuration you might have implemented (Firewall rules, scan options, etc.).

• Go to the Wordfence Options page
• Tick the box Delete Wordfence tables and data on deactivation (located near the bottom of the Other Options section)
• From the WordPress plugins page, deactivate and then delete Wordfence plugin
• Re-install Wordfence plugin

Initial: “php.ini” was renamed “php.ini_” to ensure I can work with the backend

1. I have made sure all caching and optimization are turned off.
2. I have put checkmark in the option “Delete Wordfence tables and data on deactivation” and saved saved options
3. I have deactivated and deleted Wordfence
4. I have reinstalled Wordfence
5. I have renamed “php.ini_” back to “php.ini”

Now when I try to load the main page of the site, I get error:

Warning: array_merge(): Argument #2 is not an array in /home/username/public_html_domains/art-of-software-testing.com/wp-includes/load.php on line 63

Warning: Cannot modify header information - headers already sent by (output started at /home/username/public_html_domains/art-of-software-testing.com/wp-includes/load.php:63) in /home/username/public_html_domains/art-of-software-testing.com/wp-includes/pluggable.php on line 1179

And nothing else is displayed on the page. Only the errors.

I am open to ideas. What should I try next?

• This reply was modified 7 years, 7 months ago by onty.
• This reply was modified 7 years, 7 months ago by onty.
• This reply was modified 7 years, 7 months ago by onty.

Hi @onty,

I’ve done some more research and it turns out the issue could actually be caused by the presence of unexpected whitespace characters on line 63 of the load.php file.

Please see this guide for more info.

Thank you for the info. I have studied the document. I am not able to detect any extra spaces outside of <?php blocks.

• I did not find any files whose opening <?php block would have extra spaces beforehand
• I did not find any files which have a closing ?> block… except wordfence-waf.php.
  I have removed the closing ?> in wordfence-waf.php but the error persists.

I have looked at all files which wordfence-waf.php invokes. None of them seems to have extra spaces outside of the code block.

I have reviewed wp-config.php and it does not seem to have any extra spaces.
Same for wp-load.php — no extra spaces found before PHP code block, and the code block is never closed so there cannot be spaces afterwards.

I have checked like 63 of wp-load.php. It contains:

if ( false === strpos( $_SERVER['REQUEST_URI'], 'setup-config' ) ) {

which is inside of a code block, and as a result it appears to not be able to contribute spaces. Did I misunderstand anything? To the best of my understanding, anything inside a code block cannot contribute said spaces (unless of course it does a straight up echo or printf… which is not the case).

The site does, however, display the error pointing to line 63 of the said file:

Warning: array_merge(): Argument #2 is not an array in /home/user/public_html_domains/art-of-software-testing.com/wp-includes/load.php on line 63

…….

One thought has occurred to me: I have 2 WordFence installations.

1. First is in a site which uses the default path of my hosting: public_html. This WordFence installation works completely fine.
2. Second WordFence installation is in a site which uses a custom path. And this installation consistently does not work

Is there any chance you could check around and see if your QA team has tested the scenario where both of the below is true:

• (a) .htconfig and php.ini is used to load WordFence, and
• (b) the installation is in a non-default location, such as ~/public_html_other/some-name.com/

Something tells me the non-default path is causing this issue. Just a gut feeling… Could be wrong, but could be worth checking out.

• This reply was modified 7 years, 7 months ago by onty.

Thank you for the info. I have studied the document. I am not able to detect any extra spaces outside of <?php blocks.

• I did not find any files whose opening <?php block would have extra spaces beforehand
• I did not find any files which have a closing ?> block… except wordfence-waf.php. I have removed the closing ?> in wordfence-waf.php but the error persists.

I have looked at all files which wordfence-waf.php invokes. None of them seems to have extra spaces outside of the code block.

I have reviewed wp-config.php and it does not seem to have any extra spaces.
Same for wp-load.php — no extra spaces found before PHP code block, and the code block is never closed so there cannot be spaces afterwards.

I have checked like 63 of wp-load.php. It contains:

if ( false === strpos( $_SERVER['REQUEST_URI'], 'setup-config' ) ) {

which is inside of a code block, and as a result it appears to not be able to contribute spaces. Did I misunderstand anything? To the best of my understanding, anything inside a code block cannot contribute said spaces (unless of course it does a straight up echo or printf… which is not the case).

The site does, however, display the error pointing to line 63 of the said file:

Warning: array_merge(): Argument #2 is not an array in /home/user/public_html_domains/art-of-software-testing.com/wp-includes/load.php on line 63

One thought has occurred to me: I have 2 WordFence installations.

1. First is in a site which uses the default path of my hosting: public_html. This WordFence installation works completely fine.
2. Second WordFence installation is in a site which uses a custom path. And this installation consistently does not work

Is there any chance you could check around and see if your QA team has tested the scenario where both of the below is true:

• (a) .htconfig and php.ini is used to load WordFence, and
• (b) the installation is in a non-default location, such as ~/public_html_other/some-name.com/

Something tells me the non-default path is causing this issue. Just a gut feeling… Could be wrong, but could be worth checking out.

@onty,

The file specified in the error message is /home/user/public_html_domains/art-of-software-testing.com/wp-includes/load.php. It is distinct from the wp-load.php file.

Could you make sure the /home/user/public_html_domains/art-of-software-testing.com/wp-includes/load.php file contains no extra spaces.

My mistake, I was looking at the wrong file.

Checking wp-includes/load.php:

Line 63 contains the following:

$_SERVER = array_merge( $default_server_values, $_SERVER );

The file begins with <?php in first column of the first row, and has no end tag.
Thus I do not believe the file can contribute any spaces.

Any additional ideas?

I would like to note that I somehow managed to make the site run more or less ok.

I was trying to move the site to the default directory, to see if running in the default dir would make WordFence work correctly. For this purpose, I moved my main site into another dir, and then moved art-of-software-testing.com into the default dir. Then I was trying to change DB entries to account for change in the URL. This did not work well. After a while, I gave up, and started moving art-of-software-testing.com back to its original dir. Eventually I was able get things back to [presumably] how they were originally, and lo and behold, the art-of-software-testing.com site is able to load with WordFence active! It still displays PHP warnings about line 63 of wp-includes/load.php. However, I added:
display_errors = off
to php.ini and the errors are no longer displayed. The site appears to function.

So far I’ve been unable to determine why it started working, nor have I yet found any aspect of the site that does not work (aside from the said PHP warning messages). WordFence scan does not show any problems.

Before the attempted move, the site did not load at all. The PHP warnings were displayed, and no page would render. But now the site actually loads. It’s a mystery I would like to understand. ??

• This reply was modified 7 years, 7 months ago by onty.
• This reply was modified 7 years, 7 months ago by onty.

Hi guys,

I encountered a similar kind of error today. I was getting Warning: array_merge(): Argument #2 is not an array in path/wp-includes/load.php on line 63. This was accompanied with the multisite getting stuck in a redirect loop.

Searching for this error led me to suspect that the problem is in PHP. Indeed, when on PHP 7.0.17, I could verify that no cookies are being set by WordPress. However, switching over from PHP 7.0.17 to either PHP 5.6.30 or PHP 7.1.3 solves the problem because cookies are now getting set and the redirect loop is not occurring.

From what I saw, the exact problems people with this error are getting in their sites vary. But all the problems seem similar, in addition to being quite strange and obscure. So my hypothesis is that there’s a problem in PHP itself, or at least a version of it, that is leading to strange behavior.

I am running using PHP 7.1.3 and I am getting these errors.
Indeed, the behavior is quite puzzling. Like I said, I have 2 sites on same hosting: in one I get the errors (non-default dir), in the other I do not (default dir). Aside from dir, configs are almost the same.