[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 dev-     |     Focuses:
  feedback                                       |
-------------------------------------------------+-------------------------

Comment (by azaozz):

 Replying to [comment:37 celloexpressions]:
 > I've pretty consistently heard from project leadership over the years
 that there is no chance that the theme/plugin editors will go away or be
 turned off

 I think I said it quite clearly: I would rather discuss turning the file
 editors off instead of adding another way to add theme hacks. Yes, the
 currently standing decision is to leave the file editors be. They are
 useful in cases where a quick fix to a template or plugin is needed in
 order to get a "live" site back on. They are not good for permanently
 adding hacks to themes or plugins.

 The implementation here is to allow permanent changes to the theme's
 styles. These changes may break the site when updating the theme. I don't
 think we need to introduce yet another pain point on updating.

 > The purpose of this project is to make it harder for users to shoot
 themselves in the foot when they need to make code-based customizations.
 > ...
 > There's a big terminology difference between "hack" and customization.
 Being CSS, the focus is on visual adjustments, or customizations, and I
 wouldn't describe those types of changes as hacks, but maybe that's just
 me. This is also not unlike the way child themes are designed to extend
 and customize parent themes.

 I don't agree. Don't think the term "code-based customizations" makes
 sense. Currently most of the popular WordPress themes and plugins are
 produced by several developers/companies, are quite "mature", and usually
 have pretty good support. From development point of view they are at the
 same level as core (if not better). Adding code hacks to them is pretty
 similar to hacking core files. Furthermore a lot of themes are being
 developed by using CSS preprocessors. Overriding the CSS by hand there is
 even harder and more error-prone.

 > > - Inadequate space for editing/writing. Try resizing your coding
 (text) editor to 275px width and edit something for 10-15 min. It's really
 bad.
 >
 > Line lengths are generally pretty short for CSS specifically. The width
 is also variable based on device size (potentially even more so with my
 proposal on #32296). We shouldn't make feature decisions based on the
 current customizer UI, which could always change; we could also bump the
 textarea out to be wider if we feel that that's more important than
 maximizing the size of the preview in this instance.

 Right. Fixing and improving the customizer UI and UX is much more
 important than adding a feature that will benefit only a small amount of
 users. On top of that this feature is already available in plugins so the
 users that need it already have it.

 Even if this finds its way in core, I don't think it needs a preview. As
 far as I see there are two general user cases:
 - The users try to change/override some CSS in the theme to perhaps change
 some colors or hide a component.
 - The users receive a CSS snipped specific to their theme (by the theme
 author or from support) and want to add it to the site.

 In the first case the users will actually need to edit the CSS. However
 doing that without seeing/knowing the current CSS structure and selectors
 is pretty much impossible. Anybody that is even a little familiar with CSS
 would know to open the browser tools and try the changes there. The
 browser tools are also a lot more comfortable when "hacking" any CSS. You
 can see all styles and selectors, there is autocomplete, error
 highlighting, instant preview, etc. We will never be able to match that,
 and don't really need to. There is no point in adding CSS Editor to
 WordPress.

 In this case the users will "compose" their hacks in the browser tools and
 would only need a place to add them to their sites. In the second case the
 users will also only need a place to add the snipped (as they don't know
 how to edit CSS).

 In both cases all of the templates would have to be checked for bad CSS
 interactions. Having a preview increases the chance for the user to
 believe that everything is okay, i.e. the preview can be "deceitful". I'd
 rather avoid that.

 I also think that there are themes that would want to prevent the users
 from (easily) changing their CSS. A child theme

 > ...surely this can't be worse in terms of security than being able to
 edit PHP files directly within the theme and plugin editors? We can decide
 what the appropriate capability is here, such as `edit_files`, if that
 helps.

 Right. The problems here are not bad syntax or foreign content (HTML, JS,
 etc.), the problem is that only users with `unfiltered_html` or
 `edit_files` should have access. There is such thing as "malicious CSS",
 you can easily deface a site with just couple of lines :)

 In that terms changing the theme's CSS should also obey the
 `DISALLOW_FILE_EDIT` constant.

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