Fatal error: Class ‘PDO’ not found is an error seen in websites running PHP applications such as Drupal, Prestashop, WordPress, etc. It’ll look something like this:

Fatal error: Class 'PDO' not found in /home/romrac/public_html/drupal/includes/database/database.inc on line 187

This error reports that the web server was unable to locate a PHP module called “PDO” in the server. Web applications require this PHP module to establish a database connection.

At Bobcares’ web server management services, this error is most commonly reported by website owners who use a VPS or a dedicated server to host their site. Server misconfiguration is the common cause of this error, and is mostly seen on newly setup servers.

For instance, in a support request we received recently, the website was recently migrated to a new VPS. The website used Drupal, and the website owner had personally confirmed that all required modules were installed in the VPS.

To troubleshoot, we took a look at the PHP configuration using the phpinfo function. It showed the below output:

Incorrect extension_dir causing Fatal error: Class ‘PDO’ not found

As you can see, the modules extension directory is mentioned as “/usr/local/lib/php/extensions/no-debug-non-zts-20130716“, whereas the extension directory for this server was “/usr/lib/php5/20121212“. So, PHP was looking for the PDO extension in the wrong directory. This happened because:

• The website was using a custom PHP configuration loaded from “/home/romrac/conf/php.ini” instead of the system default “/etc/php5/apache2/php.ini“.
• The custom PHP configuration was created to match the old server configuration. In the old server had the PHP extensions stored at /usr/local/lib/php/extensions/no-debug-non-zts-20130716. The location was not updated to match the new VPS settings.

To fix this, we could either change the “extension_dir” variable in “/home/romrac/conf/php.ini” to “/usr/local/lib/php/extensions/no-debug-non-zts-20130716“, or we could just disable a custom PHP configuration file. Since this customer used this VPS for just one website, we disabled a custom PHP configuration by removing the entry “PHPINIDir /home/romrac/conf/” from the Apache configuration file.

Other common causes of Fatal error: Class ‘PDO’ not found

As I mentioned earlier, this error is commonly caused by PHP settings mis-configuration. Here are a few scenarios we’ve seen:

The php.ini file missing extension=pdo.so

We’ve seen website owners overwriting fully function php.ini files with default configuration files that came with the Apache package. In such cases, the PHP configuration entry that ENABLES the PDO extension gets over-written.

To detect these issues, we look for the configuration entry “extension=pdo.so” in the active PHP configuration file. For instance, in the above example, we’d look for the “extension=pdo.so” in “/home/romrac/conf/php.ini“.

[ You don’t have to lose your sleep over PHP or MySQL errors in your websites. Get our professional help to fix your site for instantly. ]

PDO module not compiled or missing

In custom configured VPS servers, we’ve seen situations where PHP would not be compiled with a PDO extension, or the modules directory would be the PDO module file. To detect these issues, we look for the file “pdo.so” in the extensions directory, or look at the compiled modules list using the phpinfo() function.

For instance, in the above example, the PHP extensions directory was “/usr/lib/php5/20121212“. So, we’d in that server, we’d look for “pdo.so” in that directory.

[ Never let PHP errors affect your website functioning. Get our professional help to fix your website errors at affordable pricing. ]

Quick resolution of PHP errors

Modern servers use package management systems such as Yum or Apt to efficiently manage PHP configuration. However, customizing these settings for individual websites sometimes can lead to mis-configuration. Our help desk team traces these issues by following what we call “the flow of configuration“.

For example, when troubleshooting an issue in an Apache + mod-PHP server, our team would first check the Apache configuration file to make sure PHP is properly loaded.

Then the primary PHP configuration file (usually located in /etc) is checked to make sure all modules are loaded, the settings are correct, and if it allows user-level over-riding. Then the user’s PHP configuration file is checked to make sure settings are in sync with how the server is configured.

By following a well thought out troubleshooting process, our team is able to resolve such PHP issues within a few minutes, and thereby minimize website downtime.