Solving array_merge Argument #2 on load.php line 63 on SiteGround

Occasionally I post technical stuff to the blog if I think I can share a helpful tip for people facing a problem I’ve solved. Pardon the techno-babble :)

The Error Message

Today, a client of mine using my favorite host SiteGround ran into the following issue. They had a error message suddenly showing on their home page that wasn’t there before. It was something like this (though I’ve changed it for their privacy):

Warning: array_merge(): Argument #2 is not an array in /home/anotherfolder/public_html/example.org/wp-includes/load.php on line 63

I found a lot of people on the WordPress forums who seemed to have the same issue—same file and line number—in the past few months.

My Solution

There are almost certainly multiple causes of this error, but here’s what worked for me.

The website had previously been on Bluehost before moving to SiteGround. Whoever moved the site left behind a php.ini file in the “root” website directory with some special server rules regarding server memory and timeouts.

Fix: Rename php.ini to php.ini.BCK

Renaming the php.ini file in the “root” directory of the site fixed the issue.

More specifically, php.iniis a special configuration file for servers. I wanted to test removing it without risking problems I couldn’t undo, so I simply renamed it to php.ini.BCK (short for “backup”). I then refreshed the page, and *poof*, my errors disappeared. Happy client! If that change broke the site, I could have just named the file back to php.ini and looked for a different fix.

Update: Be Aware of What’s In Your php.ini

marklchaves and jonathan both posted comments noting that the directives in php.ini may well be valid and important for your website, even if they’re causing problems with your host.

If there are new problems with your site after applying the “fix” above, then this may be the reason for them. If that’s the case for you, review SiteGround’s information on the two different ways to change PHP settings they provide (via cPanel or a custom php.ini file).


I hope this post solves your hosting issue. If it saves you an hour or a day, please consider buying me a coffee or beer! ☕🍺

Posted on Categories Miscellany

46 thoughts on “Solving array_merge Argument #2 on load.php line 63 on SiteGround”

  1. Mark – I just got this same problem on one of my sites that I just transferred to SiteGround. I renamed that php.ini file just as you recommended and VOILA – fixed. Awesome. Thanks for posting this! Really appreciate it!

  2. Ok, this is the first time in my life that I’ve even left a message in a blog post. Thank you SO much! it worked out perfectly :)

  3. Thanks for this post.

    I’ve got the same issue in my end, a client of mine is having the same error message when trying to purge the SG cache and some functionalities are not working like OptimizePress isn’t loading. I’ve tried copying the website to another Siteground server but the copied website is working perfectly there.

    So I reached out to support and asked to look for the php version and they’ve upgraded the php version to 7.2 and everything works perfect now.

    1. OH, wow, thanks for pointing that out. I was pulling my hair out, but that is where mine was as well!

  4. This also worked for me however I hadn’t recently moved to Sitepress, the website has been on SG since 2016 and has only just started causing this issue. It was pretty serious because it was preventing WP Admin login. Thank you!

  5. An error like this usually kills at-least half a day of your time to figure out a solution. But thank to you. As soon as I Googled the error name your link was the first to pop-up and the solution you offered was an instant fix.

    Thank you so much.

  6. Thank you, Mark. Your solution worked perfectly, exactly as written. Appears to have resolved some other issues and quarks with this install, too. Also using SiteGround. Thank you for posting!

  7. Thank you for the post. What’s odd about this issue is that I’ve had this custom php.ini file in multiple sites for a while now in SiteGround and only this evening did it give me issues. Any idea why?

    1. I’m not quite sure why that would happen. Is it possible you upgraded your version of PHP or turned on a feature that impacts the server like caching just before this happened? I wouldn’t be shocked if this is only a problem on certain configurations, so that would be my guess.

  8. Thanks for posting this, Mark. This issues does seem pretty common, unfortunately. But, your post seems to be the only one that addresses this unique problem and offers a simple solution. Kudos for taking the time to post and saving me and others a lot of stress & hassle.

    The only suggestion I have is that people should be aware of what’s in their php.ini file before chucking it or renaming it. For example, I’m pretty sure that in my case, there were two lines in my php.ini that caused error.

    zend_extension=/usr/local/php56/lib/php/extensions/ioncube.so
    zend_extension=/usr/local/php56/lib/php/extensions/ZendOptimizer.so

    The only other line in my php.ini was

    max_execution_time = 200

    So, my long-term fix was to delete my php.ini and move the max_excecution_time setting to my .htaccess file.

    So, just a word of caution that if your site need settings in your php.ini file and you remove/rename the php.ini to fix the Warning:array_merge() error, you might experience some run-time issues because of this.

    enjoy!

    1. Hey Mark, thanks for your insights, my php.ini contains the following:

      memory_limit = 256M
      upload_max_filesize = 40M
      max_input_vars = 4000
      post_max_size = 25M
      zend_extension=/usr/local/php70/lib/php/extensions/ioncube.so
      zend_extension=/usr/local/php70/lib/php/extensions/ZendOptimizer.so

      I’m not a WordPress pro, but are the above essential for my website? if yes, should I simply copy them to my /.htaccess file?
      (there’s a few of the .htaccess files too, but im guessing you meant just “/.htaccess”)

      Would really appreciate your reply!

      1. Hi Shabazz, I’m glad you found this post so useful. I don’t know for sure, but the likely problem are those two lines starting with “Zend”. Back up your file and then try removing only those two. I suspect you’ll find the site works. If not, you’ll need to specifically review SiteGround’s instructions for increasing memory limit and file size.

        Btw, the maxinputvars is a pretty unusual rule. If you’re not sure why it’s there, I’d see if the site works without it.

    2. First and for all a huge thanks to Mark for this article. It seems to be the only article around addressing this issue and it really helped me! What I was missing though is a solution if you really need to set those values. I am not able to just remove the php.ini file as my users need to be able to upload pretty big zip files..

      I am also hosted on SiteGround and had this exact issue even with just an empty php.ini. After some failed attempts to fix it (switching php versions fixed it for some days), I contacted their support and they actually enabled ionCube and ZendOptimizer for me by adding these two lines:

      zend_extension=/usr/local/php71/lib/php/extensions/ioncube.so
      zend_extension=/usr/local/php71/lib/php/extensions/ZendOptimizer.so

      Maybe you need to make sure you enable them on the right php version? I’m still running wp on PHP v7.1 …

      I have no real clue of what both ionCube and ZendOptimizer should do and how they relate to the issue we are experiencing…

      And other work around would be using .htaccess and defining your php values in there like “php_value upload_max_filesize 64M” but I don’t know yet how reliable that is yet..
      Some more info on this:
      https://www.php.net/manual/en/configuration.changes.php
      https://www.certguidance.com/change-php-settings-using-htaccess-php-ini/

      I’m very tempted to go that route but I’ll first give the ionCube and ZendOptimizer solution a chance to prove itself..

      1. Hi Jonathan. Thanks for such a detailed reply! You’re right that I don’t get too deep into the weeds of when the php.ini file was there in the first place. Just about every person’s file could require a whole separate article to resolve! That said, your experience is a valuable contribution to this post. I’m going to add a link to this and a similar comment so people are aware of these potential complications.

  9. Just like magic! Like everyone else, I moved from Bluehost some time ago, cleared my cookies and then the error message started showing. This was the fix. Thank you!

  10. My issue was on Siteground too. I didn’t have the php.ini file in root. I renamed the htaccess file and rebuild it with a WordPress security plugin.

  11. Worked for us on Siteground. Many thanks. (Not sure how you could figure this one out. Prior to this fix, the array problem was preventing us from accessing our WordPress account).

  12. Hi Mark, thanks for the link, and I just bought you a well-deserved beer through PayPal. We just switched to SiteGround about 3 weeks ago and haven’t had any issues, but then today we were getting these “woocommerce export load array error” while doing a simple WooCommerce order export! I happened to stumble upon your article, and indeed it fixed things. One question: ALL that was in my PHP.ini file was this:
    upload_max_filesize = 256M
    post_max_size = 32M
    How could that possibly be causing a problem??

    1. The php.ini file existing even empty is the cause of the issue. In order to truly fix this issue without deleting the php.ini file is to add the following line to you php.ini

      zend_extension=/usr/local/php71/lib/php/extensions/ioncube.so

      This stops the error and any changes you make using the php.ini will be applied successfully else by deleting the php.ini file you revert back to only the server defaults

Join the Discussion

This site uses Akismet to reduce spam. Learn how your comment data is processed.