[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:
     Type:  feature request   |     Status:  new
 Priority:  normal            |  Milestone:  4.5
Component:  Customize         |    Version:
 Severity:  normal            |   Keywords:  has-patch
  Focuses:                    |
------------------------------+-----------------------
 The Theme Editor represents an important part of WordPress' mission to
 democratizing publishing, acting as a gateway for introducing users to
 their ability to create literally anything with WordPress by editing and
 writing code. Many developers of all abilities (including myself) got
 their start with PHP or other related technologies by editing themes with
 the theme editor in the WordPress admin.

 At this point in the development of the WordPress ecosystem, we can do a
 much better job of introducing users to code-based customization for their
 sites. This ticket proposes leveraging the Customizer to offer instant
 live previews of code-based changes for improved user experience. Rather
 than blindly making edits that can completely take down a site where the
 user potentially has no idea what FTP even is, every change is instantly
 previewed and no changes are published until the user is ready to push
 them live.

 ------

 == Proposed solution: Custom CSS + Links to resources outside of core ==

 WordPress can't reasonably teach users much about code within the software
 (although a plugin that does so would be very interesting to see).
 Additionally, when bridging the gap between advanced user and beginning
 developer, desired changes are likely to be limited to visual tweaks that
 are primarily theme-related. Therefore, I'm proposing to limit the scope
 of this new feature to a custom CSS editor.

 The CSS editor would take inspiration from the many plugins (including
 Jetpack) offering similar solutions, but with an updated solution that
 offers instant previewing in the Customizer via `postMessage` setting
 transport. This is core territory rather than plugin territory because it
 is designed as the next generation of the existing theme editor in core,
 with a more refined feature set and more user-oriented focus. The theme
 editor is not proposed to be removed at this time, although that could be
 a future possibility depending on a variety of factors. Plugins could
 continue expanding this feature to incorporate additional uses.

 Storing the CSS as a `theme_mod` facilitates custom CSS being theme-
 specific. However, the editor would be used to override theme styles
 rather than editing them directly to avoid the awkward experience of
 telling users that they can make changes but they may get overwritten
 during updates, which the theme editor does. Instead, custom CSS safely
 stays available on a per-theme basis after updating and switching themes.
 Other solutions such as a custom post type make the notion of having
 different sets of CSS styles for different themes difficult to implement.
 Projects such as Customizer Transactions (#30937, which would actually use
 post objects) and revisions for Customizer settings (#31089) would bring
 benefits offered by the custom post type approach to this feature, while
 storing the data in a more logical theme-related way.

 To improve the user experience further, it is critical that a link to
 documentation and resources for learning CSS be included with useful help
 text inline alongside the CSS editor. This could initially be a codex page
 but would ideally live on a user or developer handbook of some sort
 eventually. Inline text must be much more succinct than the help tab on
 the existing theme editor, conveying what CSS is, where to learn about
 specific rules, and explaining that it's specific to each theme in only a
 few lines. My initial proposal is in the screenshots below.

 Considering next steps when users begin moving beyond the basics of what
 can be done within a custom CSS editor like this, I also suggest providing
 an additional piece of help text underneath the editor (potentially only
 once a certain threshold of content is reached - the exact measure could
 be rough). Such a friendly tip could convey that if they're making a lot
 of progress with CSS, they should consider learning more about themes,
 child themes, storing CSS in files, etc. via an external link to a
 resource on WordPress.org. On multisite installations we would likely
 never show this message since the user probably can't make code changes
 there outside of this CSS editor. As with any customizer feature, custom
 CSS could be disabled with `remove_section()` on sites where
 administrative access is to be limited.

 Technical Considerations with the initial patch:
 - Should we sanitize & validate user-input CSS? I believe the current
 theme editor doesn't do anything, and worst case scenario we could set up
 similar capability restrictions.
 - Should we include syntax highlighting? There are libraries available, if
 we want it it would require a compatible license or we could also roll our
 own. May be a future enhancement for later.
 - The patch leverages the existing textarea control for simplicity, as
 well as introducing a new core control type for help text. If we want to
 add syntax highlighting or other usability improvements such as vertical
 auto-resizing for the editor to avoid double scrollbars (since this is the
 only option in the section), we can do a custom control instead.
 - While we could bump the editor out of the standard Customizer sidebar to
 provide more horizontal space, the short line lengths typical in CSS lend
 themselves nicely to the amount of space provided by default.
 - I included help links within the translatable string as they would need
 to be localized; we may need to break these out separately though?
 - We should probably create a new page introducing CSS for the first link
 - nothing on the codex or handbook currently fits this purpose. There's a
 decent explanation on WordPress.com that could potentially be adapted and
 expanded in the theme developer handbook:
 .https://en.support.wordpress.com/custom-design/css-basics/
 - Live preview is not working when previewing a theme, I'm not sure why.
 It does work if the theme previously had custom CSS in it.

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