Provide a better gateway for code-based theme customizations with the Customizer
|Reported by:||celloexpressions||Owned by:||johnregan3|
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.
Change History (114)
8 months ago
7 months ago
- Keywords needs-patch added; has-patch removed
- Milestone changed from Future Release to 4.7
- Owner set to johnregan3
- Status changed from new to assigned