Opened 10 years ago
Closed 10 years ago
#29214 closed defect (bug) (wontfix)
Extension and backwards compatibility in the Media Library
Reported by: | danielbachhuber | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Media | Keywords: | dev-feedback |
Focuses: | Cc: |
Description
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
I see no action items here.