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! ☕🍺
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!
So glad that worked for you!
Thanks!!!
OMG, you saved my life…
You saved me … I have been fighting with this crap whole day !
Thank you! That solution worked for me. Exact same thing. Migrated a site from Bluehost to SiteGround. This error only showed on mobile, not on desktop.
Worked a treat! Thank you :)
Thank you!! Quick google came up with your solution, saved me HOURS of troubleshooting =)
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 :)
Thank you! and thank you for naming this post very well so it can be found! Much appreciated.
Thank you so much, I fixed the problem in 3 minutes! Much appreciated.
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.
OMG!!! Thank you – I went in and updated the php version and this worked fro me.
Life saver! worked for me also. php.ini was in the wp_admin folder for me.
OH, wow, thanks for pointing that out. I was pulling my hair out, but that is where mine was as well!
Thank you!!!! I panicked when I saw this during a move. I tried a couple of other suggestions I saw elsewhere, but this solution was perfect.
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!
Thank you for posting this! HUGE help!
AMAZING! Thank you SO MUCH for this, Mark! You ROCK!
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.
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!
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?
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.
Great work – saved the day!
Thanks Mark you saved my life!!
great it’s work for me
thanks mark
Ran into the same thing upgrading site to 7.1. And I’ll buy you a coffee or beer at WordCamp
What a man, thank you! Great fix.
OMG, Literally “poof” :) error gone
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!
Thanks for the reply, Mark. You’re totally right that
php.inican be used for legitimate purposes all the time. Changingmax_execution_timeis definitely one of those.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!
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.
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..
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.inifile 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.Hey! This post is a AMAZING. thanks for being so kind to share this, and directly getting to the point!
Will surely buy you a coffee buddy.
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!
Lifesaver!
Could you please tell me where can I find the php.ini file on Siteground? I am having same issue on my site. Thank you
Hi Lobsang. The file should be in the “root” directory of your site. Either the top directory with your site’s files or the one above it. Here is SiteGround’s documentation on php.ini. If you can’t find that file, it suggests it’s a different issue.
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.
Oh you are a life saver. thanks much..
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).
It worked great for me — I was in panic mode for a second there lol. Thanks!
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??
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