[wp-trac] [WordPress Trac] #29214: Extension and backwards compatibility in the Media Library

WordPress Trac noreply at wordpress.org
Thu Aug 14 16:25:07 UTC 2014


#29214: Extension and backwards compatibility in the Media Library
-----------------------------+-----------------------------
 Reporter:  danielbachhuber  |      Owner:
     Type:  defect (bug)     |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  Media            |    Version:
 Severity:  normal           |   Keywords:  dev-feedback
  Focuses:                   |
-----------------------------+-----------------------------
 Modifying the Media Library follows a pattern of extending and overriding,
 which is fundamentally different than WordPress' event-based pattern for
 its PHP internals. The former has inferior support for backwards
 compatibility. We should fix this so developers can reliably extend the
 Media Library

 In PHP land, you modify execution with actions and filters:

 {{{
 class My_Class {

         function init() {
                 do_action( 'my_class_init' );
         }

 }

 add_action( 'my_class_init', function() {
         // do whatever you want when the class is initializing
 });
 }}}

 In Media Library land (and generally with JavaScript), you extend and
 override:

 {{{
 MyApp.originalAttachmentsView = wp.media.view.Attachments;
 wp.media.view.Attachments = MyApp.originalAttachmentsView.extend({

         initialize: function(){
                 MyApp.originalAttachmentsView.prototype.initialize.apply(
 this, arguments );
                 // Do whatever I need to
         },

 });
 }}}

 This approach more or less works, but doesn't accommodate for backwards
 compatibility in the same way actions and filters do. Actions and filters
 implicitly state "you can dependent on this being a reliable way of
 customizing WordPress between releases". Extension allows a developer to,
 in essence, fork a small piece of WordPress for their own needs — without
 any guarantees of future compatibility.

 Very specifically, I'm extending `wp.media.view.Attachments`. Rather than
 calling the original initialize function, I've copy and pasted the
 entirety to my initialize function because I need to actually change what
 the function is doing. Some combination of r29376 and other related
 commits broke the Media Library for me entirely.

 Related #21170

--
Ticket URL: <https://core.trac.wordpress.org/ticket/29214>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list