#24787 closed enhancement (fixed)
Allow absolute URLs in editor styles
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| 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)
Change History (13)
#1
@
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
@
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
@
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:
↓ 5
@
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
@
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()andwp_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.
#6
@
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
@
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).
Based on nacin's patch, adds a callback to 'admin_print_styles' to enqueue fonts in the custom header admin.