WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 2 years 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 2 years ago.
24787.1.diff (8.5 KB) - added by obenland 2 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 2 years ago.
24787.3.diff (7.2 KB) - added by nacin 2 years ago.

Download all attachments as: .zip

Change History (13)

@nacin2 years ago

@obenland2 years ago

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

comment:1 @nacin2 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.

comment:2 @nacin2 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.

comment:3 @lancewillett2 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.

comment:4 follow-up: @lancewillett2 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.

comment:5 in reply to: ↑ 4 @nacin2 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.

@nacin2 years ago

comment:6 @nacin2 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.

comment:7 @lancewillett2 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).

@nacin2 years ago

comment:8 @ryan2 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

comment:9 @nacin2 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.