[wp-trac] [WordPress Trac] #21055: Interface for wpdb compatibility

[WordPress Trac]

#21055: Interface for wpdb compatibility
-----------------------------+------------------------------
 Reporter:  santec           |       Owner:
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Database         |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |
-----------------------------+------------------------------

Comment (by 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
 [http://www.techbeast.net/2012/06/13/wordpress-3-4-fatal-error-upgrading-
 database/ 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().

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/21055#comment:2>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software