[wp-trac] [WordPress Trac] #35395: Provide a better gateway for code-based theme customizations with the Customizer

[WordPress Trac]

#35395: Provide a better gateway for code-based theme customizations with the
Customizer
-----------------------------------------+-------------------------
 Reporter:  celloexpressions             |       Owner:  johnregan3
     Type:  feature request              |      Status:  assigned
 Priority:  normal                       |   Milestone:  4.7
Component:  Customize                    |     Version:
 Severity:  normal                       |  Resolution:
 Keywords:  has-screenshots needs-patch  |     Focuses:
-----------------------------------------+-------------------------

Comment (by westonruter):

 @joyously The vast majority of uses for this functionality would surely be
 wanting to tweak the styles of a theme's stylesheet. That is, to override
 and extend the cascade. If a user is experienced enough to know about FOUC
 then they'd just as well add that to their `functions.php` to output at
 the top of `wp_head`. That's my opinion on that.

 I am not familiar with the state of CSSTidy. I just know that it is used
 by Jetpack for their CSS editing module.

 As for storing the CSS in a custom post type as opposed to directly in a
 theme mod, the reason for doing this is for scalability. It is conceivable
 that a lot of CSS could be dumped into such a field and since theme mods
 are just options and also _autoloaded_ options, it is important that
 unbounded blocks of CSS to not be included in the theme mod itself. If the
 Memcached object cache plugin is used, and there are several themes that
 have lots of CSS, then the 1MB limit for a cache bucket could be breached
 and the site could crash since alloptions would no longer be cacheable. As
 for data portability, I don't think that will cause a problem. Consider
 the CSS being stored in a new post type called `theme_css`, where each
 theme has one and only one `theme_css` post created. The `post_name` for
 these posts can exactly correspond to the theme that it is associated
 with. In that way, the `theme_css` posts could be exported via the normal
 XML exporter and imported on another site, and the would then
 automatically be recognized because they'd have the `post_name` wouldn't
 change.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/35395#comment:19>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform