[wp-trac] [WordPress Trac] #38672: Custom CSS should work with existing Jetpack custom CSS

WordPress Trac noreply at wordpress.org
Fri Nov 4 21:50:50 UTC 2016


#38672: Custom CSS should work with existing Jetpack custom CSS
--------------------------+------------------
 Reporter:  helen         |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  high          |   Milestone:  4.7
Component:  Customize     |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------

Comment (by helen):

 Jetpack's implementation does clear between theme changes, so while it
 appears to only use one parent post object and indicate in each revision
 for that post object what the theme active at the time was, as far as what
 faces users it's theme-specific and not global. This means I can browse
 revisions to copy back what I had before, but it's not really all that
 intuitive or usable because of the way revisions are displayed (can't make
 a sane selection to copy-paste).

 Because what's in core is a basic textarea in the customizer only, it
 seems to me that from a UI/UX front Jetpack could "enhance" things, such
 as the IDE-esque and preprocessor features. We should then '''work
 together''' to bring those enhancements into core as they make sense, and
 perhaps even work within Jetpack to experiment with other enhancements
 (seeing revisions in the customizer interface, for instance). I also don't
 mind there not being an admin interface for the core one straight off the
 bat or even really ever, as having a separate preview is infuriating.
 Editing in a narrow sidebar is kind of annoying, but at least it's not
 infuriating. Jetpack can keep on with adding its existing admin screen, as
 its users are probably quite used to it, and maybe let users know they can
 now edit that CSS with awesome live previews in the customizer.

 Since we don't really have interface collisions here, I ''think'' the
 technical difference may really boil down to the name of the CPT and
 whether you start a new post for each theme with its own revisions (as
 core is doing) or you use one post with revisions forever with the theme
 info stored for each revision (as Jetpack appears to be doing).

 Core can change what it's doing fairly easily because we're in beta, but I
 want to make sure we are working with the Jetpack team just as we should
 work with anybody behind a plugin with major adoption whose features match
 something that is coming into core. I really hope this was an honest
 oversight and not a case of not-invented-here, "ugh Automattic" syndrome,
 because this is an incredibly annoying thing for myself and many others
 coming awfully late in the development cycle. There is a serious risk of
 dropping this from 4.7 because of this.

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


More information about the wp-trac mailing list