Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #38672, comment 8


Ignore:
Timestamp:
11/05/2016 01:14:04 PM (8 years ago)
Author:
georgestephanis
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #38672, comment 8

    initial v1  
    1010For 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).
    1111
    12 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.
     12The 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.  (Or, depending on the size of the styles, perhaps enqueueing a link to ... a REST API endpoint that echoes the CSS so it can be cached?  Or at least strip out newlines and tabs when printing it to the page?)
    1313
    1414@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`).