[wp-trac] [WordPress Trac] #35395: Provide a better gateway for code-based theme customizations with the Customizer

WordPress Trac noreply at wordpress.org
Sat Sep 24 02:59:00 UTC 2016


#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 joyously):

 Replying to [comment:36 azaozz]:
 > I am pretty firmly against introducing another way for adding "hacks" to
 WordPress.
 My sentiments exactly. I spent 2 years as a moderator of a popular theme
 forum, and most of those users had no clue what CSS is or what to type in
 this new editor. Having yet another place to look for CSS will make it
 that much harder for support.

 >
 > 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.
 The editor space needs to be adjustable. And at the point of editing, it's
 best to be able to see the HTML of a page, not the rendering. How else
 will you know what selectors to use?
 > - "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.
 And how do you preview/test the responsiveness of your CSS (desktop,
 mobile)?
 >
 > In addition there is no good way to make the user entered CSS "secure".
 I addressed this issue earlier, but I don't know if anyone "got" it. If
 the CSS lives in a file, then anything not CSS in there is a CSS error
 instead of treated as HTML.
 >>If it has to be theme specific, have you considered that the post type
 is like an attachment and the CSS is actually stored in a file? This way
 the storage is easier (CSS can be difficult to get into the database
 correctly), and the inclusion in the header is better (using the src
 attribute), and the browser can cache the file and it can be served
 zipped.

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


More information about the wp-trac mailing list