Hey there, I spent a few hours working through this issue today since I've seen it on other Magento versions in the past and have run across it all over the web. In every case there are similar symptoms and in most cases the solution that gets rid of the symptom is a somewhat blind stab at changing whatever php.ini files are easiest to locate in the system until Magento behaves the way you think it should. Because I first found this question over on the Magento Stack Exchange AND I first ran across this issue and discovered a related answer from Alan Storm on SE, I put all the gory details in that post and won't duplicate it in its entirety there.
I will link to it since you should have the option of going through my process of identifying the issue first over a year ago and all of the research I've discovered as I've seen it posted and reposted over the last 15 months or so.
Here's the key points:
The fundamental issue is that you've got conflicting php.ini directives in at least two places:
- The main Apache php.ini located in your Apache configuration root.
- At least one additional file somewhere in your site's document root.
This recent related issue post explains how the multiple copies of php.ini that have conflicting config directives interact when placed in a folder structure where they will conflict. Keep in mind, much like apache's .htaccess file if AllowOverrides is set to TRUE, you can litter your web site document root folder structure with as many different copies of that file as you like.
That article isn't QUITE as clear as it could be. It's late so you can read my rather lengthy answer on Magento SE, but the abbreviated version is that
1. BY DEFAULT, apache will first read the main root php.ini for config directives
2. BY DEFAULT, if ANY other php.ini files are found in a directory, apache will override the settings in the master file with what it finds in a php.ini file in the same folder as a PHP script it executes.
3. By default, if it later finds another php.ini file in a directory lower in the tree than the one it just executed it will use THAT settings when executing php files in that sub-folder.
4 BY DEFAULT, apache DOES NOT keep using the files it finds in each higher folder in other sub-folder beneath that. It BY DEFAULT will always use the master php.ini UNLESS it finds a php.ini file in the same folder that the php scripts it executes is located.
The above article is correct that by definition this is NOT a recursive pattern of configuration. The author states it awkwardly but is correct. It is an ok example of a way to recursively traverse through the directory structure of the file system, but it doesn't use the same recursive logic to apply the configuration of php.ini files it finds.
The semantic distinction is explained in great detail at the above Magento SE answer and leverage the many references I included to the core PHP docs, apache config docs, other blogs etc...
I will include the following to bring this to a quick resolution for the OP and anyone else who sees this problem in the future:
Since I found a post from Alan Storm over a year ago, I have seen that this has cropped up all over, on Magento SE, also over on Stack Overflow, and other sites and it's always something different as the root cause.
I just wanted to write this up or two reasons:
I don't agree that is the post I answered is a duplicate of Alan's original post from 2014 and wanted to offer up all the reports I've found of this affecting Magento installs but having different root causes and fixes.
When I last saw the issue, I saw Alan's "poor man's debugger" comment and. laughed. And I want to repay Alan back for what I learned on that day and share with this poster and whoever finds this answer later.
Anyone reading this can can spend some time doing it the long way by starting over at Magento SE and thern going the same route as the other post or even as I started by adding
php_ini_loaded_file()
calls before the function throwing the exception IF he knows where that's happening and he could fix that php.ini directive when he finds that file. And then he might have to repeat that process if there are other exceptions being thrown because of other php.ini files that may be scattered about.
At some point in the next few hours or days he might be find all of them and figure out all the plugins and hack that led to those php.ini files cropping up.
Or, you can read this answer and head over to Alan's blog to see his post on PHP exception handling in Magento's Developer Mode and see the comments where a different PDO error pops up then do what I'd did and pick up a copy of CommerceBug for $50 and install it and sort it out pretty quickly.
Then when he sees that issue crop up AGAIN, because he will (and so will most anyone who spends enough time here) they'll have a tool to figure it all out quickly.
To any other reviewer who makes it this far - it's not a Magento-specific root cause, but I've seen it a few times in the last few years and it's occurring regularly on Magento deployments so I think it's relevant.
Finally, just to be 100% clear - Alan has never promoted his commerce bug as an answer to any question here that I am aware of. He may remember interacting with me so very long ago, though I rather doubt it.
He has no idea (yet) that I even wrote this. Magento SE is not a forum to promote your own products even if it MIGHT help someone asking a question and I've never see Alan do this. I am quite happy to suggest his CommerceBug as a solution. If you're as experienced as him and a few other awesome members of of the SE community, you never even search for this post you just know what to do. I did and instantly realized my time is more valuably spent using his product to get to the bottom of it.
He saved me more than $50 when I found the original post and bought CommerceBug and helped me solve lots of other problems with that tool later. If you work through the long part of this post you will know more about your system and will understand more about how all the internals of apache, PHP and Magento work.
That's great.
Or go solve some other problem that hasn't been figured out yet with the extra time. Enjoy this answer either way.
