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

 I am pretty firmly against introducing another way for adding "hacks" to
 WordPress.

 > 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 "shut 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:

 > Occasionally you may wish to disable the plugin or theme editor to
 prevent overzealous users from being able to edit sensitive files and
 potentially crash the site. Disabling these also provides an additional
 layer of security if a hacker gains access to a well-privileged user
 account.

 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.

 Apart from the above there are several other things that are pretty bad:
 - Inadequate space for editing/writing. Try resizing your text editor to
 275px width and edit something for 10-15 min. It's really bad.
 - "Deceiving" preview. CSS hacks affect the whole site but the user can
 see only one template in the preview. It is pretty easy to make a change
 that "looks good" on the front page but breaks the archive pages, etc.

 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.

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