[wp-trac] [WordPress Trac] #38672: Custom CSS should work with existing Jetpack custom CSS
WordPress Trac
noreply at wordpress.org
Sat Nov 5 13:10:56 UTC 2016
#38672: Custom CSS should work with existing Jetpack custom CSS
-----------------------------+------------------
Reporter: helen | Owner:
Type: defect (bug) | Status: new
Priority: highest omg bbq | Milestone: 4.7
Component: Customize | Version:
Severity: blocker | Resolution:
Keywords: | Focuses:
-----------------------------+------------------
Comment (by georgestephanis):
Replying to [comment:7 westonruter]:
> For what it's worth, I did ping the Jetpack team about the developments
of the Additional CSS feature being worked on in core:
https://github.com/Automattic/jetpack/issues/1621#issuecomment-247155624
Ack! Posting a comment on a year-and-a-half old issue isn't a great way to
get eyes on it, unfortunately. :( That was somewhat compounded by the
fact that it was right at the start of our Grand Meetup, so kinda doubtful
anyone caught it.
I think someone had DM'd me on Slack at it some point in the past, but I
had no idea it was even being considered for merging into 4.7 until I saw
some chatter about it this morning.
For anyone else coming in via this ticket, the Custom CSS ticket was
#35395 and the big commit was [38829]
For a brief technical summary of how the core implementation operates
(because I can't seem to find one anywhere else) -- it works similar to
the Jetpack/WPCOM one, storing it in a Custom Post Type. Core uses
`custom_css` whereas Jetpack and WPCOM use `safecss`. The Core
implementation doesn't attempt at any sort of sanitization or
normalization of the CSS ( :\ ), or any syntax highlighting (I don't blame
you, the JS library we use adds a lot of weight to Jetpack). The Core
Post Type doesn't support revisions either (which I feel is probably a
mistake).
The Core implementation also just echoes the generated CSS on `wp_head` --
personally I'd prefer it if core tweaked `wp_add_inline_style` to allow
adding inline styles without an external stylesheet to attach it to, so it
could be dequeued or the like as needed, just as any other style is
treated.
@beaulebens -- I worry that if we drop Jetpack's Custom CSS entirely in
favor of just prettying up the Core implementation, a lot of users are
going to get left out in the cold. Permissions for each are radically
different. For example, you must be a superadmin on multisite to use the
core implementation, because they don't even make an attempt at sanitizing
it -- treating it akin to the `unfiltered_html` cap (it's actually mapped
to that and named `unfiltered_css`).
I have serious misgivings about how the Core implementation will work for
users in multisite, it doesn't feel very well thought out, merely
defaulting to just taking it away.
I don't know what the ideal solution is /yet/, for how we play nicely with
the Core implementation -- it may be to add Sass/LESS preprocessors,
Syntax highlighting, Revisions, and Sanitization as an enhancement to the
Core implementation -- with some sort of "nag" link at the top asking the
user if they'd like to copy their existing Jetpack CSS into the new modal
to work on further? Whatever it is, we need to do it in a way that either
when activating Jetpack's Custom CSS or deactivating Jetpack's Custom CSS,
no data is lost. Which could be particularly tricky.
I'm not thrilled with how quickly this feature was merged into core after
first being actively discussed, it gives very little time for plugin
authors to react and work to sort out interop between various data
structures.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/38672#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list