Make WordPress Core

Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#24787 closed enhancement (fixed)

Allow absolute URLs in editor styles

Reported by: obenland's profile obenland Owned by: ryan's profile 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 12 years ago.
24787.1.diff (8.5 KB) - added by obenland 12 years 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 12 years ago.
24787.3.diff (7.2 KB) - added by nacin 12 years ago.

Download all attachments as: .zip

Change History (13)

@nacin
12 years ago

@obenland
12 years ago

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

#1 @nacin
12 years 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.

#2 @nacin
12 years 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.

#3 @lancewillett
12 years 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.

#4 follow-up: @lancewillett
12 years 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.

#5 in reply to: ↑ 4 @nacin
12 years 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.

@nacin
12 years ago

#6 @nacin
12 years 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.

#7 @lancewillett
12 years 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).

@nacin
12 years ago

#8 @ryan
12 years 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

#9 @nacin
12 years 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.