Make WordPress Core

Opened 22 months ago

Last modified 20 months ago

#21055 new feature request

Interface for wpdb compatibility

Reported by: santec Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Database Keywords:
Focuses: Cc:



From the wp-includes/wp-db.php file:

It is possible to replace this class with your own
by setting the $wpdb global variable in wp-content/db.php
file to your class. The wpdb class will still be included,
so you can extend it or simply use your own.

When one implements a db class that does not extend wpdb, it would be safer that the new class implements an interface. This interface may be called wpdb_compat and would assure that the class has all necessary methods/properties. Of course, wpdb_compat should be supported by wpdb too.

Design Strategies

My patch adds:

  • wp-includes/interfaces/wpdb-compat.php

Very small edits to:

  • wp-includes/wp-db.php
  • wp-includes/load.php
  • wp-admin/install.php

At the moment, WordPress does not include any interface; this means that there is not a directory for interfaces.
In my first draft, I put it in wp-includes/interfaces so that - if more interfaces will be added in the future - they will have a logical place.

Attachments (1)

wpdb_compat_v1.zip (22.7 KB) - added by santec 22 months ago.
First draft of the feature i'm asking for

Download all attachments as: .zip

Change History (8)

santec22 months ago

First draft of the feature i'm asking for

comment:1 kurtpayne22 months ago

  • Cc kpayne@… added

HI santec,

Can you submit this as a patch?

Further reading:

comment:2 nacin22 months ago

In 3.3, we added a delete() method. If we had altered the interface to include that method, then PHP would have issued a fatal error. This error occurs on class definition and is not catchable, which means there is literally nothing that we could do to wrap a proper user experience around this without causing a fatal error.

If the wpdb class was extended, and assuming that MySQL was the storage mechanism in use, things at least would have worked without a delete().

We need to emphasize that the "proper" way is to extend the wpdb class. "or simply use your own" needs to be stricken from the document block. And we need to come up with some kind of versioning systems for our drop-ins (db.php and object-cache.php could both use this treatment).

Perhaps we should consider allowing the registration via wp-config.php a specific location for db.php or object-cache.php. GlotPress, bbPress, and other applications derived from WordPress/BackPress architecture allow for this. This could allow someone to keep a database or object-caching plugin in a drop-in that can be updated. Combined with versioning and integration with the update checks, this could prevent issues like this one in the future.

A plugin in the directory could specifically say that they include one of these drop-ins, which means we could automatically make sure that an active drop-in is compatible and updated when a user wants to update core.

Doing all of this also makes sense for advanced-cache.php. Rather than define( 'WP_CACHE', true ); it could be a file path. Similar things could be employed for most or all drop-ins listed in _get_dropins().

comment:3 scribu22 months ago

  • Cc scribu added

comment:4 kurtpayne22 months ago

What if, instead of an interface, we used an abstract class?

abstract class wp_dao {
 // common properties and methods
class wpdb extends wp_dao {
 // concrete implentation

So things like delete() can be added into wp_dao and wpdb without breaking back compat. Children don't have to implement these methods unless they're explicitly marked abstract. Children can either inherit from wpdb or wp_dao depending on their use case, and the code can still use $whatever instanceof wp_dao?

Anybody currently extending wpdb would be unaffected.

comment:5 santec22 months ago

it's not very clear to me what you would put in wp_dao and what you would put in wpdb, but your idea sounds much better than mine.

I hope that, in your idea:

  • wp_dao contains the logic (which can/must not be changed);
  • wpdb is merely a bridge to mysql.

So it would be possible && easy to implement an "alternative wpdb" which uses mysqli or PDO_MySQL, or whatever.

I would be happy to help in doing this - next time I'll use svn and read better your documents, I promise.

comment:6 scribu21 months ago

+1 for allowing drop-in files to remain inside a plugin which can be updated (don't think this is the right ticket for it, though).

Note: See TracTickets for help on using tickets.