[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 celloexpressions):

 Replying to [comment:36 azaozz]:
 > > The Theme Editor represents an important part of WordPress' mission to
 democratizing publishing
 >
 > No, it doesn't. It has nothing to do with democratizing publishing. All
 it does is making it a bit easier for users to "shoot themselves in the
 foot".
 >
 > I'm actually thinking we should be discussing shipping WordPress with
 `define( 'DISALLOW_FILE_EDIT', true );` in wp-config. The explanation in
 the codex makes a lot of sense:

 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 in core, and serve an important purpose similar to what I've described
 here. Is this opinion shared by other lead developers or solely yours? Or
 am I recalling that incorrectly, and if so, why are these editors still on
 by default in core?

 In the future, this type of feedback from a lead developer should come
 sooner than nine months into a project if at all possible. I would also
 hope that this project could eventually lead to a compromise where the
 more dangerous, less user-friendly way to start customizing a site with
 code can be moved to a plugin. 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.

 > In my opinion adding "theme hacks" through the customizer is plugin
 material, and the plugin should be able to provide adequate support to
 users that break their sites.

 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.

 As I mentioned above, there are easily enough plugin-based solutions (and
 even many in themes) to justify a core solution. I would also anticipate
 there being less of a support burden throughout the ecosystem with
 something like this, as support volunteers already using CSS as needed
 would no longer need to get the user set up with a plugin to add it, and
 those that previously suggested edits in the theme editor where the could
 have taken the site down may be able to suggest this feature instead.

 > Apart from the above there are several other things that are pretty bad:
 > - 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.

 > - "Deceiving" preview. CSS hacks affect the whole site but the user can
 see only one template in the preview. For example it is pretty easy to
 make a change that "looks good" on the front page but breaks the archive
 pages, etc.

 Users can navigate to different pages on their site within the preview,
 and even preview different sized screens as they customize the CSS.
 Perhaps the help text associated with this feature should explicitly
 suggest doing that? By leveraging the customizer framework, we can provide
 a much better and less-likely-to-break-things environment for the user
 than other solutions.

 > In addition there is no good way to make the user entered CSS "secure".
 CSSTidy and similar tools can check/fix the syntax but cannot sanitize the
 CSS for security purposes. I'm not sure such tools exist. New versions of
 the browsers introduce support for new CSS features pretty much every
 month. Don't think it is feasible even trying to sanitize all of them. The
 only way would be to severely limit what is supported then parse the CSS
 and remove everything else.

 I can't provide much input here, but 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.

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