Interface for wpdb compatibility

[santec]

==Summary==

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.

[santec]

First draft of the feature i'm asking for

[kurtpayne]

HI santec,

Can you submit this as a patch?

Further reading:
​http://codex.wordpress.org/Reporting_Bugs#Patching_Bugs

[nacin]

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().

[kurtpayne]

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.

[santec]

Kurt,
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.

[scribu]

+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).

[kurtpayne]

Related #21663

[wonderboymusic]

No motion in 2 years.