Top Posts

Changes should happen in Code, not in UI

If you are deploying your WordPress site, it generally doesn’t make much sense to have to go in and setup changes when you push the newest version live. When you push to production, production should have all your changes.

One more benefit of this method is that you never need to be signed in with a user who can change settings, change plugins, or change themes. Being signed in as a user with as few capabilities as possible is a one part of limiting your vulnerability in case of attack

This is what I use to stop the majority of activities from happening in the UI.

6 thoughts on “Changes should happen in Code, not in UI”

I like update_option since it allows the DB to be the definitive record of which values are what. Filtering the option is really nice for development and for conditional changes, but if the option is going to be one value and the plan is for it to stay that value, updates seem to me to be the way to go.

I don’t think you should move the plugin update routines into your code. This is for the site update routines. Some of the common functions that go in here are activate_plugin and deactivate_plugins. After a site has been in development and right before going live, I’ll include an update routine that resets everyone password (since people use bad passwords when a site isn’t active and forget to update them). Also useful are things like updating specific plugin options.