Category Archives: WordPress

Exit maintenance mode in WordPress when an update fails

To exit maintenance mode in WordPress when an update fails is as easy as deleting the .maintenance file from the root folder. Fixing the update problem is another history…


Use HTTPS protocol in WordPress 4.4+ for srcset attribute

I’ve started using “Let’s Encrypt” in multiple sites I manage. Just after installing it for this blog I noticed that all images didn’t load because they were originally linked with HTTP.


This was easy to fix with a simple SQL update:

UPDATE wp_posts SET post_content = replace(post_content, '', '');

But I still got the “Mixed Content” error messages. Looking at the generated page source code I found that WordPress 4.4+ adds a responsive image attribute to images img tags: srcset. And the problem was that the links there were using HTTP. Adding this code in functions.php solved the issue:

 * Force URLs in srcset attributes into HTTPS scheme.
 * This is particularly useful when you're running a Flexible SSL frontend like Cloudflare
function ssl_srcset( $sources ) {
  foreach ( $sources as &$source ) {
    $source['url'] = set_url_scheme( $source['url'], 'https' );

  return $sources;
add_filter( 'wp_calculate_image_srcset', 'ssl_srcset' );


Remove a WordPress action in child theme

If you want to remove a WordPress action that was added in the parent theme like this:

function fusion_insert_og_meta() {
add_action( 'wp_head', 'fusion_insert_og_meta', 5 );

It’s VERY important to use the same priority value in the remove action in case a different value from the default (10) was used:

function remove_parent_actions() {
    remove_action( 'wp_head', 'fusion_insert_og_meta', 5 );
add_action( 'init', 'remove_parent_actions' );



Using dbDelta with WordPress to create and alter tables

dbDelta is used in WordPress to create and update tables in the database and you will usually use it in the register_activation_hook with the plugin installation process. Either you want to create or update a table you always have to give dbDelta a CREATE TABLE SQL query. It will automatically detect that the table already exists in case of an update and do the necessary changes.


This function is defined in wp-admin/includes/upgrade.php and you have to import it BEFORE calling dbDeta:

require_once( ABSPATH . 'wp-admin/includes/upgrade.php' );

But this function is a little bit tricky. You can’t just give it any CREATE TABLE query. As pointed out in the documentation:

  • You must put each field on its own line in your SQL statement.
  • You must have two spaces between the words PRIMARY KEY and the definition of your primary key.
  • You must use the key word KEY rather than its synonym INDEX and you must include at least one KEY.
  • You must not use any apostrophes or backticks around field names.

Based on those premises, this SQL wouldn’t work and would SILENTLY do nothing:

global $wpdb;
$sql = "CREATE TABLE table_name(`id` int(10) NOT NULL AUTO_INCREMENT, `extra_id` int(5) NOT NULL,`username` tinytext NOT NULL);";

require_once( ABSPATH . 'wp-admin/includes/upgrade.php' );
dbDelta( $sql );

As you can see all fields are in the same line, there is no PRIMARY KEY defined and field names use backticks. The correct SQL query would be:

global $wpdb;
$sql = "CREATE TABLE table_name (
    extra_id int(5) NOT NULL,
    username tinytext NOT NULL,
    PRIMARY KEY  (id,extra_id)

require_once( ABSPATH . 'wp-admin/includes/upgrade.php' );
dbDelta( $sql );

I used this 2 field PRIMARY KEY example because there is another trick with dbDelta: there can’t be any spaces in the definition of the primary key.

Hope you find this useful. Those silent “errors” are pretty dificult to catch.

Delete WordPress old revisions

WordPress stores revisions of the posts, pages, etc. while you write them. Without even knowing you may have about 5 or more revisions of each entry. And each revisions represents one entry in your posts database table with post_type column as revision.


The first thing I thought was to simply delete those old revisions that had post_type equals revision:

DELETE * FROM wp_posts WHERE post_type='revision';

Then, just in case, I did a search and found out I was not completely right. As Ozh explains here:

Note that the above SQL query just deletes post marked as revisions. If for some reason you associated a revision with a tag or a category that was then removed when the final post was published, you will have extra entries in other tables such as terms.

The query then should look like this:

DELETE p, tr, c
FROM wp_posts p
LEFT JOIN wp_term_relationships tr ON (p.ID = tr.object_id)
LEFT JOIN wp_postmeta pm ON (p.ID = pm.post_id)
WHERE p.post_type = 'revision';

Note: use your table prefix and make a backup first just in case!

You may also disable the revision feature (but I wouldn’t recommend it) in the wp-config.php file:

define('WP_POST_REVISIONS', false);

Or just limit the amount of revisions to a fixed number:

define('WP_POST_REVISIONS', 5);