WordPress.org

Make WordPress Core

#48568 closed defect (bug) (wontfix)

$ not defined on edit screen anymore

Reported by: david.binda Owned by:
Milestone: Priority: normal
Severity: normal Version: 5.3
Component: Script Loader Keywords: close
Focuses: Cc:

Description

While the no-conflict mode of jQuery has been a standard for a while already, the mediaelement script has been leaking jQuery to $ variable, so prior 5.3, the plugin authors (eg.: for tinyMCE plugins) were able to use $ w/o penalties.

However, with the upgrade of mediaelement, this has changed, and jQuery is no longer available via $ in window.

How to test:

In 5.2: open a new post screen and type $ in console. It should be defined. In 5.3 it is not.

It's likely due to the change in https://build.trac.wordpress.org/changeset/46234/trunk/wp-includes/js/mediaelement/mediaelement-and-player.js at line 5778.

Change History (12)

#1 @SergeyBiryukov
11 months ago

  • Component changed from General to Script Loader
  • Milestone changed from Awaiting Review to 5.3.1
  • Summary changed from $ not defied on edit screen anymore to $ not defined on edit screen anymore

#2 @johnbillion
11 months ago

When was this leak from mediaelement first introduced?

#3 @david.binda
11 months ago

When was this leak from mediaelement first introduced?

Looks like it has been 2 years ago, in https://build.trac.wordpress.org/changeset/41038

#4 @azaozz
11 months ago

  • Keywords close added

The "best practice" in WP has always been to not make $ an instance of jQuery. That's been around since jQuery was introduced 13 years ago in WordPress 2.2! The fact that Mediaelement was "leaking" it was a bug upstream that is now fixed.

Thinking we shouldn't be reverting that bugfix upstream. That "leak" was very inconsistent. It seems to have affected mostly the old Edit Post screen and scripts that are "doing-it-wrong".

#5 @joemcgill
11 months ago

I would say that the leak was unintended behavior and anyone relying on it was relying on unsupported behavior. It's possible that the fix for #44484 is what changed this behavior.

#6 @joemcgill
11 months ago

No seems loading order isn't to blame here. Was likely the fix to #46681 where this got changed, as was pointed out in the initial issue description.

This ticket was mentioned in Slack in #core by clorith. View the logs.


11 months ago

This ticket was mentioned in Slack in #forums by diddledan. View the logs.


11 months ago

#9 @afercia
11 months ago

Noting the upstream change was mentioned in the mediaelement 4.2.12 and 4.2.11-rc3 release notes under the (maybe a bit cryptic) item:

No longer modify any objects under the global window objects to prevent side effect. (PR #2123 Fixed #2598)

See https://github.com/mediaelement/mediaelement/issues/2123 and https://github.com/mediaelement/mediaelement/pull/2598/files

This ticket was mentioned in Slack in #forums by wido. View the logs.


11 months ago

#11 @Otto42
11 months ago

Agreed, plugins or other code that were using it should be modified to not rely on the unintended behavior. Suggest this is a wontfix.

#12 @johnbillion
11 months ago

  • Milestone 5.3.1 deleted
  • Resolution set to wontfix
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.