[wp-trac] [WordPress Trac] #28509: Allow themes specifically meant to be parent themes to prevent activation

[WordPress Trac]

#28509: Allow themes specifically meant to be parent themes to prevent activation
-------------------------+------------------------------
 Reporter:  nathanrice   |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Themes       |     Version:  3.9.1
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+------------------------------

Comment (by F J Kaiser):

 Replying to [comment:27 Otto42]:
 > But still "wrong", from a UX perspective.

 I'm not totally sold on "wrong UX" on this one. "Parent theme" still is a
 very loose definition. Genesis and others have proven that we did ''not''
 care enough to lock that system down and force a strong user expectation.
 Else those themes would not have such a large user base. In my opinion
 this is more about ''marketing'' what "parent theme" really means. Maybe
 we are at a good point and should discuss the potentials further?

 > I'm just uncomfortable with defining a condition where a theme can be
 "not-a-theme". If we need a third category, then let's invent it.

 So far we have "plugins", "themes" ["parent themes", "child themes"], "mu-
 plugins" and "drop-ins". Out of those five categories of user defined
 stuff, most people only have heard of two. When they've used WP for quite
 some time, they may get into the "parent/child" theme thing. Are you sure
 that they will be able to wrap their heads around "app parent" - or
 however we will then name it? To clarify myself: It's a (maybe) steeper
 learning curve [for people starting with WordPress] that gives me some
 headaches when bringing a new ''category'' to the table. But maybe I'm
 just expecting too less from users.

 > Or one "plugin" for creating an "App" and a theme to define how it
 looks. Themes should be about how the site looks, **and nothing else**. If
 we need extra ways to hook in, then let's define them appropriately, and
 create a better way.

 I understand that point of view. Still I don't think that this could be
 done by just adding even more hooks and filters. This would need a larger
 (and well planned) change. Maybe it's a ''make.wp.org'' article that is
 needed to discuss this (a) in public and (b) sketch out what should get
 done to and where we should put "Theme Frameworks" and "WebApp cores". I
 can't post on make, but if someone else does, I will join the discussion.

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