#58648 closed defect (bug) (fixed)
Error: tinymce is not defined in post-new.php
Reported by: | joemcgill | Owned by: | joemcgill |
---|---|---|---|
Milestone: | 6.3 | Priority: | normal |
Severity: | normal | Version: | 6.3 |
Component: | Script Loader | Keywords: | has-patch has-unit-tests |
Focuses: | performance | Cc: |
Description
The E2E tests began showing a tinymce is not defined
error, which can be replicated in trunk by visiting the post edit screen and checking the developer console.
After some debugging, this looks like it's due to an inline script that is printed after the tinymce scripts in print_tinymce_scripts()
. For some reason, this function is causing the tinymce scripts to be printed with an async
loading strategy, which result in the inline script being loaded before the tinymce scripts have loaded. This is likely related to [56033].
Change History (17)
This ticket was mentioned in PR #4731 on WordPress/wordpress-develop by joemcgill.
18 months ago
#1
- Keywords has-patch has-unit-tests added; needs-patch removed
#2
@
18 months ago
I've opened a PR that demonstrates the broken behavior in order to help with debugging.
#3
@
18 months ago
Figured out what was happening here. print_tinymce_scripts()
calls wp_print_scripts()
to directly print the tinymce
scripts without enqueueing them. When deciding which loading strategy to apply to a script in WP_Scripts::get_eligible_loading_strategy()
, start with all possible strategies and then filter down to the one that should be applied in WP_Scripts::filter_eligible_strategies()
. However, that method intentionally skips evaluating any handles that aren't enqueued to avoid situations where a script's eligible strategy would be affected by a dependent that was not enqueued.
I've updated the PR so that before we start the filtering process, we first take into account the intended strategy of the handle when it is registered.
This ticket was mentioned in Slack in #core by ocean90. View the logs.
18 months ago
#7
follow-up:
↓ 13
@
18 months ago
Leaving the ticket open as there are few (non-blocking) suggestions on the PR that may be added later.
@Bernhard Reiter commented on PR #4731:
18 months ago
#8
Bit of a long shot, but I think @tyxla recently worked on TinyMCE. Marin, is this code something you're familiar with? If so, could you weigh in here? 😊
18 months ago
#9
Bit of a long shot, but I think @tyxla recently worked on TinyMCE. Marin, is this code something you're familiar with? If so, could you weigh in here? 😊
Thanks for the ping!
From what I can see this isn't related to my experimentation on the Gutenberg side; it's rather related to the recent introduction of the async
and defer
loading strategy in https://core.trac.wordpress.org/ticket/12009.
The proposed fix appears to be spot on 👍
18 months ago
#10
Right, the bug was that async
was added to scripts that were "printed" directly without being enqueues first. The fix works well and was committed in https://core.trac.wordpress.org/changeset/56092.
Not closing this PR as there are few suggestions that can be added later.
This ticket was mentioned in Slack in #core by chaion07. View the logs.
17 months ago
This ticket was mentioned in Slack in #core by oglekler. View the logs.
17 months ago
#13
in reply to:
↑ 7
@
17 months ago
- Resolution set to fixed
- Status changed from assigned to closed
Replying to azaozz:
Leaving the ticket open as...
Lets close this for 6.3. Any suggested changes can be added later if they're worth it.
This ticket was mentioned in PR #4852 on WordPress/wordpress-develop by joemcgill.
17 months ago
#14
This applies a couple of suggestions from #4731 that were not resolved before the initial commit.
Trac ticket: https://core.trac.wordpress.org/ticket/58648
joemcgill commented on PR #4731:
17 months ago
#15
Moved followup tasks to a different PR to clarify what would be committed separately.
joemcgill commented on PR #4852:
17 months ago
#17
Committed in https://core.trac.wordpress.org/changeset/56246.
Trac ticket: https://core.trac.wordpress.org/ticket/58648