[wp-trac] [WordPress Trac] #42189: MediaElement.js 4.2 is not backward compatible with 2.2

[WordPress Trac]

#42189: MediaElement.js 4.2 is not backward compatible with 2.2
--------------------------+-----------------------
 Reporter:  bradyvercher  |       Owner:  rafa8626
     Type:  defect (bug)  |      Status:  assigned
 Priority:  normal        |   Milestone:  4.9
Component:  Media         |     Version:  trunk
 Severity:  major         |  Resolution:
 Keywords:                |     Focuses:
--------------------------+-----------------------

Comment (by bradyvercher):

 Replying to [comment:6 ocean90]:
 > We could try something similar to https://github.com/jquery/jquery-
 migrate.

 A migration shim would be perfect.

 Replying to [comment:7 rafa8626]:
 > The <mediaelement> wrapper is needed since it's the fake node that
 allows all the other renderers to mimic the API, so that cannot be changed
 on my side; to access the original tag, you have to use
 media.originalNode. The other variable that I cannot change is
 player.container, given that is being used in lots of places.

 I would have to do some more testing around related to the fake node to
 know what kind of issues that poses, but `player.container` was widely
 used as a jQuery object in previous versions, so if we can't update that,
 the other changes won't help much.

 What about updating MediaElement.js to use a method for retrieving those
 properties. That way if they've been converted to a jQuery object, they
 can be dereferenced before being used? I don't know how you'd structure
 it, but some sort of utility method like this:

 {{{
 MediaElementPlayer.prototype.get = function( el ) {
         return jQuery !== undefined && el instanceof jQuery ? el[0] : el;
 };
 }}}

 Then anywhere you reference `t.container` or `t.controls`, change them to:
 `t.get(t.container)` and `t.get(t.controls)`. Or create specific wrappers:

 {{{
 MediaElementPlayer.prototype.getControls = function() {
         return this.get(this.controls);
 }
 }}}

 I think there were a couple of other places where elements might need to
 be dereferenced, too, so a generic utility method might be useful.

 Replying to [comment:8 rafa8626]:
 > please check the PR I listed above; it has been updated with more notes
 and some of the missing variables. Let me know if there's anything else I
 can do to assist you

 That PR looks like a good start. I'll leave some comments on that
 regarding a couple of issues I noticed.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/42189#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform