WordPress.org

Make WordPress Core

Opened 21 months ago

Closed 21 months ago

Last modified 21 months ago

#24787 closed enhancement (fixed)

Allow absolute URLs in editor styles

Reported by: obenland Owned by: ryan
Milestone: 3.6 Priority: normal
Severity: normal Version:
Component: Editor Keywords: has-patch commit 2nd-opinion
Focuses: Cc:

Description

Let's allow absolute URLs to be used in add_editor_style().

Attachments (4)

24787.diff (7.2 KB) - added by nacin 21 months ago.
24787.1.diff (8.5 KB) - added by obenland 21 months ago.
Based on nacin's patch, adds a callback to 'admin_print_styles' to enqueue fonts in the custom header admin.
24787.2.diff (7.6 KB) - added by nacin 21 months ago.
24787.3.diff (7.2 KB) - added by nacin 21 months ago.

Download all attachments as: .zip

Change History (13)

@nacin21 months ago

@obenland21 months ago

Based on nacin's patch, adds a callback to 'admin_print_styles' to enqueue fonts in the custom header admin.

comment:1 @nacin21 months ago

24787.1.diff was something I suggested to obenland in IRC — basically, there's not a whole lot wrong with duplicating the wp_enqueue_style() calls. It's going to be easier for people to understand.

comment:2 @nacin21 months ago

  • Keywords has-patch commit 2nd-opinion added

I think this is good to go. I don't like adding something this late in general, but I like how well it simplifies 2013.

comment:3 @lancewillett21 months ago

+1 to the simpler changes and better organization in Twenty Thirteen.

Only thing missing from this ticket is the "why" and some use case examples, for future reference as to why this change is important. To give it context.

comment:4 follow-up: @lancewillett21 months ago

Applied patch to test, I'm getting only one of the two Google Fonts on the front-end. Bitter but not Source Sans Pro (all browsers). Could have something to do with the + symbol being URL encoded.

Also, why is it necessary to change the datestamps used for versioning in wp_enqueue_style() and wp_enqueue_script(). If we're using the theme version number (1.0) that won't be good enough to bump after a change to a CSS file or script. And just choosing a number seems arbitrary -- the date seems better, to me.

comment:5 in reply to: ↑ 4 @nacin21 months ago

Replying to lancewillett:

Applied patch to test, I'm getting only one of the two Google Fonts on the front-end. Bitter but not Source Sans Pro (all browsers). Could have something to do with the + symbol being URL encoded.

That's probably it, yes. I'll experiment.

Also, why is it necessary to change the datestamps used for versioning in wp_enqueue_style() and wp_enqueue_script(). If we're using the theme version number (1.0) that won't be good enough to bump after a change to a CSS file or script. And just choosing a number seems arbitrary -- the date seems better, to me.

I was just playing with things. I think this should be released as '1.0', then gets moved back to dates for development. The dates aren't very obvious and a relatable version number might be easier to understand.

@nacin21 months ago

comment:6 @nacin21 months ago

Yes, it's +. See 24787.2.diff. I simply copied obenland's patch, happy to leave version numbers out of any commit. It's something we could/should/would do when we hit 1.0.

comment:7 @lancewillett21 months ago

.2 tests out nicely, theme changes looks good minus the minor versioning thing (I'm not going to worry about it right now, can tweak later).

@nacin21 months ago

comment:8 @ryan21 months ago

  • Owner set to ryan
  • Resolution set to fixed
  • Status changed from new to closed

In 24735:

Allow absolute URLs in editor styles.

Props nacin, obenland
fixes #24787

comment:9 @nacin21 months ago

In 24736:

Twenty Thirteen: Go back to dates for style versions, partially changed in [24735]. see #24787.

Note: See TracTickets for help on using tickets.