PDO extension is required for this adapter - Magento Connect [duplicate]

Question

This question already has answers here:

PDO loads fine in Magento but not in external CMS (3 answers)

Closed 4 years ago.

I just did a new magento install of V 1.9.2.2 and when I go to magento connect I get the...

"The PDO extension is required for this adapter but the extension is not loaded" error. BUT IT IS!

I have root access to the WHM apache server its running on and it is installed through easyapache, and I did a phpinfo.php file check and the PDO is seen as working on the info sheet. I looked in the php.ini file in the main directory and the PDO extension calls are present. What else would be causing this? The Cpanel its running on has just this install and the single database nothing else to interfere with it?

Answer 1

@MagenX's comment is important because you DO appear to have the same error message that the potential duplicate reports.

BUT the MOST important thing for you is to read the accepted answer from Alan Storm as well as the comments from the OP. Alan's "answer" was more a series of ways to troubleshoot the issue because his gut told him that the problem was a rogue php.ini file SOMEWHERE besides the site's web root that had a directive overriding the expected behavior.

Note The Comment Provded:

The fundamental issue is that you've got conflicting php.ini directives in at least two places:

1. The main Apache php.ini located in your Apache configuration root.
2. 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.

Based on the official PHP docs, the Example Bellow assumes something like this:

/apache/config/path/php.ini

/site/docroot/public_html/php.ini

/site/docroot/public_html/emplyees/php.ini

Let's say you have a php.ini file in your public_html folder. That php.ini file has the PHP memory_limit set to 256M. Only scripts that run directly in your public_html folder will have the memory_limit set to 256M. If you have a folder named public_html/employees, that "employees" folder will not be affected by the public_html/php.ini file, it would only be affected by a php.ini file located in its own folder, public_html/employees

If you have many folders, creating a php.ini file for each folder would be quite tedious. What you can do is update your .htaccess file to tell the server that the public_html/php.ini file should apply not only to public_html, but to any folders within that folder (gsuch as public_html/employees or public_html/about-us).

The SYMPTOM is definitely the same as the related post, but the root cause is probably not the same and the ultimate fix may not be the same either.

The answer on the other post was basically "here's some steps go figure it out because it could be anywhere."

Since I found that post over a year ago, I see 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:

1. I don't agree that is really a duplicate and wanted to offer up all the reports I've found of this affecting Magento installs but having different root causes and fixes.

2. 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.

Then OP can spend some time doing it the long way by 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, he 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.