Make WordPress Core

Opened 14 years ago

Closed 14 years ago

#16694 closed defect (bug) (fixed)

wp_dequeue_script() fails to dequeue when a registered script is dependent

Reported by: nacin's profile nacin Owned by: azaozz's profile azaozz
Milestone: 3.3 Priority: normal
Severity: normal Version: 3.0
Component: General Keywords: reporter-feedback
Focuses: Cc:

Description

I'm trying to dequeue quicktags. It doesn't work.

sivel was able to track down that scripts are not dequeued, when another script is dependent on them.

Only, in this case, quicktag's only dependent (admin-comments), will always be registered, but on this page, it not enqueued. admin-comment's only dependent (dashboard) is also not enqueued, and is only registered.

Two issues:

  1. These functions should have return values for them. If they're going to fail, we need to know.
  1. I should be able to dequeue quicktags in this situation. If admin-comments *is* enqueued, perhaps I should not, unless I dequeue admin-comments first. But at the very least, a registered and unqueued dependent should not prevent dequeueing.

(Extra bug noticed -- the comment reply form is rendered on post-new.php, despite the comments meta box not being supported by this post type.)

Change History (7)

#1 follow-up: @nacin
14 years ago

  • Keywords 2nd-opinion added

Looks like the issue is that quicktags gets spit out by wp_print_scripts(). Enqueueing it doesn't matter, thus dequeueing it doesn't matter.

It should be properly enqueued, instead of printed. (The script should also fire on ready, not direct document.writes on load. Whole thing needs a rewrite.) That's probably for another ticket.

Besides that, the dequeue function should really have a return value. The bug still stands in that wp_dequeue_script() fails to dequeue when an enqueued script is dependent. If that's not a bug, then we need a return false to know that.

#2 in reply to: ↑ 1 @garyc40
14 years ago

Replying to nacin:

It should be properly enqueued, instead of printed.

If we're to go with this direction, the key is automatically detecting when quicktags should be enqueued.

Would requiring quicktags to be enqueued manually break existing themes or plugins that use the_editor() on custom admin pages or on the front-end?

Right now they assume wp_print_scripts() already did the job for them.

#3 @nacin
14 years ago

I think the fix for that would be wp_enqueue_script() plus #9346.

#4 @nacin
14 years ago

  • Version set to 3.0

#5 @azaozz
14 years ago

  • Milestone changed from Awaiting Review to Future Release
  • Owner set to azaozz
  • Status changed from new to reviewing

The problem here is quicktags.js. It hasn't been updated in ages and still uses a lot of "old" JS techniques (document.write, etc.). Once we get it up to standard (hopefully in 3.3) it will be enqueued and dequeued properly.

#6 follow-up: @ocean90
14 years ago

  • Keywords reporter-feedback added; 2nd-opinion removed
  • Milestone changed from Future Release to 3.3

Is this already fixed through [18446] and [18497]?

#7 in reply to: ↑ 6 @azaozz
14 years ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

Replying to ocean90:

Yes, as quicktags is properly enqueued now. Still it is being enqueued mid-page so the dequeue should be done early in a footer action. However I think the underlying problem was fixed too as quicktags is multi-instance by default.

Note: See TracTickets for help on using tickets.