[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:  closed
 Priority:  normal                       |   Milestone:  4.7
Component:  Customize                    |     Version:
 Severity:  normal                       |  Resolution:  fixed
 Keywords:  has-screenshots needs-patch  |     Focuses:
-----------------------------------------+-------------------------

Comment (by pingram3541):

 Whew that was a lot to skim through but I'm liking where all this is going
 and the screens are absolutely beautiful!  I have some input and I
 apologize if any of this is repetitious, again, I skimmed through A LOT of
 this.

 This might eventually replace my own custom live css plugin that
 @westonruter helped me with a while back but I'm concerned like @azaozz
 whether this needs to be in core and something that is always present vs a
 plugin that can be used and then discarded later (it's a developer tool in
 my opinion).  I really never would ask or want my end users to use this
 but I also wouldn't want to hide it from being an accessible tool in the
 wp plugins repo.

 My thoughts, search it up in the repo, install it, use it, disable it and
 then possibly uninstall it after use.

 My idea is very close to what is suggested here but my preference is not
 to use this as a permanent CSS solution that loops through the db on every
 visit but rather a tool to use for development, even post-production too.

 We all know DB calls are much slower than our file system and we want to
 be able to properly enqueue our styles as well.  This will help with post
 processing filters of the css such as minification, uglification (is that
 a word?) etc. and allow for overrides, dequeuing, changing priorities etc.

 I love the idea that I can use a tool to edit live css but then also
 disable that tool when it is not needed and without losing all my work.

 My concept is very similar, use an existing textarea control to apply the
 CodeMirror experience with line numbers, syntax highlighting etc.

 I then set that control to use a custom callback and the rest falls within
 the js api passing post_meta as needed.

 It stores the custom css in the db as follows:

 - master css, shop css (ie. woocommcerce) and archive css (per post_type)
 is stored in wp_options unique to the theme (or child-theme) so that
 switching themes applies the proper and unique css to apprpriate pages
   - a. such as mycss_master_mythemename, mycss_shop_mythemename...

 - post/page/single css is stored in the post_meta also unique to the theme
 /child-theme
   - a. such as mycss_mythemename_postid

 This allows for full freedom or custom css code site wide, across a common
 group of posts/pages or individually and prioritized accordingly.

 The live preview uses inline style elements (with unique ids) for the real
 time "live" previewing when code in the editor is changed but on the front
 end I'm using wp_enqueue_styles with a doctype wrapper to properly use wp
 standard practices.

 Additionally, I added another customizer option to my plugin which
 disables the Front Loading (front end enqueuing of css stored in the db)
 but not when in the customizer.

 My front end development process as a result:

   1. enable the plugin
   2. build to my hearts content all styling that is theme specific and see
 it both on the front-end and in the live customizer
   3. when I'm finished I manually copy all css to processed (minified)
 files into my theme folder (add appropriate wp_enqueue_styles to
 functions.php - future automation of this is an idea I have)
   4. disable the "Front Loading" option and verify static files are
 working on the front end
   5. finally disable the plugin and uninstall if I want

 So what I've done here is use a plugin as a dev tool to build out all my
 css for my theme of which also loads on the front end but must stay
 enabled to be visible and uses css in the db.  Then I optimize and load
 proper external stylesheets as it should be done and the css stored in the
 db is simply my backup copy and referenced only when I activate my css
 plugin again and edit in the customizer.  Each time I do this and after
 verifying the results, I copy the updated css to my static files and
 disable the plugin again.  This is a simple approach to not baking in a
 dependency on my plugin.

 I think a similar approach to page content builders is the next step in
 improving live front-end development beyond just css.

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