If you inherit a WordPress codebase, regardless of the age of the project, there may be a lot of context that you don’t have as to why certain decisions were made or how things were implemented.

This may include the server, infrastructure used to help power the site or the app, and other contextual information about the environment in which it was running.

This type of information can be server-related information, PHP version, database type, information that’s actually stored in the database especially if you do a database import, and so on.

This image has an empty alt attribute; its file name is table-plus.png

Ideally, all of this is handed over but that’s not always the case. Anyway, say you attempt to start it up and then when you attempt to start up the application, not only does it not work but it either shows a white screen or displays a message about technical problems with your installation.

Deactivating WordPress Plugins

Though I recommend making sure your debug settings are always defined on your local machine, I also recommend making sure that all plugins are deactivated before spinning up the installation of WordPress.

Native WordPress Debugging Tools: Error Logs

But plugin activation status is set at the database level, so what can we do? Once the installation is set up, connect to the database using your favorite database front-end (I’m a fan of TablePlus) and then run the following queries:

First, if you’re interested in seeing all of the active plugins that are present, run the following:

View the code on Gist.

After that, you can update the active plugins by essentially setting the option value equal to an empty, serialized array:

View the code on Gist.

This secondary query is responsible for deactivating WordPress plugin such that you can load WordPress as close to as vanilla as possible. It should still have the same theme and assets and the plugins will be installed, but deactivated.

Share:

Leave a Reply