Make WordPress Core

Opened 10 years ago

Closed 8 years ago

#28509 closed enhancement (wontfix)

Allow themes specifically meant to be parent themes to prevent activation

Reported by: nathanrice's profile nathanrice Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.9.1
Component: Themes Keywords: close
Focuses: Cc:

Description

Sometimes, you build a theme that is meant specifically to be a parent theme, and doesn't work very well when activated itself.

It would be nice if there were a way (in the style.css header) to indicate this, and WordPress would take this directive as an instruction to not allow the theme to be activated on a site, but rather serve only as a template for child themes.

Not sure if this would be better accomplished as hiding the theme on the themes page completely, or showing it, but not offering the ability to activate, or displaying it specifically in a "Parent themes" section or something.

Change History (32)

#1 @ryanduff
10 years ago

I'd vote for leaving them on the themes page, marked as a parent theme and no activation.

Along with that, perhaps show the applicable child themes as a sub-set of the parent theme. i.e. "This is a modification of x theme"

#2 @nathanrice
10 years ago

I like that a lot.

#3 @grapplerulrich
10 years ago

Why would such a parent theme not work when activated?

#4 follow-up: @Otto42
10 years ago

Sounds like a badly made theme to me. Parent themes aren't meant as "frameworks", they should be working themes.

#5 follow-up: @knutsp
10 years ago

-1
Themes should work.

#6 in reply to: ↑ 5 @ryanduff
10 years ago

Replying to knutsp:

-1
Themes should work.

Constructive criticism is always better when trying to encourage new contributors, FWIW...

#7 @nathanrice
10 years ago

Why would such a parent theme not work when activated?

Because it's not meant to be activated. It provides features that only work when a child theme supports them. It has minimal (if any) CSS, or CSS that styles particular features that are activated by a child theme. It's a parent theme that shouldn't be modified, and allowing it to be activated provides a de facto blessing on doing exactly that.

Sounds like a badly made theme to me. Parent themes aren't meant as "frameworks", they should be working themes.

Yes, I understand you're not a fan. That doesn't, in the slightest, negate the reality of their existence and popularity. Notice the title isn't "Prevent all parent themes from being activated". It's an option for themes that meet this specific criteria.

Themes should work.

Different themes work differently. It would be nice to recognize that not every theme is meant to be activated, and have a mechanism in place to accommodate for that.

#8 in reply to: ↑ 4 @ryanduff
10 years ago

Replying to Otto42:

Sounds like a badly made theme to me. Parent themes aren't meant as "frameworks", they should be working themes.

Perhaps in a past sense of the word, but who's to say we don't remake the concept some? They *should* work as stand-alone, but that's not always the intended use case. Lets remember nathanrice comes from Genesis where it is meant to be a parent theme and not directly modified.

#9 follow-up: @poena
10 years ago

I don't see the point when you can just create a plugin.

#10 in reply to: ↑ 9 @nathanrice
10 years ago

Replying to poena:

I don't see the point when you can just create a plugin.

A plugin that does what?

#11 @greenshady
10 years ago

I'm not in favor of this idea. It did cross my mind in the past as a method of keeping users editing just their child theme. However, I think this is a bad path to go down. Whether we like it or not, users should have the freedom to activate and edit their themes, even those meant specifically for use as a parent theme and parent theme only.

If the theme isn't meant to be activated, maybe the structure of it should be rethought. Is this something that should be a theme? Maybe it's better as a plugin?

#12 @nacin
10 years ago

I think "Themes should work." is a perfectly valid response here, and my initial reaction as well. greenshady explains that thought more in depth, and I tend to agree with him.

#13 follow-up: @nathanrice
10 years ago

Whether we like it or not, users should have the freedom to activate and edit their themes, even those meant specifically for use as a parent theme and parent theme only.

They still do. Remove 1 line from style.css and they can edit it again. The point is to allow theme developers to affect the UX in a way that helps reinforce the intended usage. If I, as a theme developer, don't believe the theme is best used as the active theme, why not allow me to at least try and enforce that a little?

#14 @mindctrl
10 years ago

Aside from the UX difference, is there something preventing you from addressing your needs on one of the hooks that runs on theme activation?

#15 in reply to: ↑ 13 ; follow-ups: @Otto42
10 years ago

Replying to nathanrice:

The point is to allow theme developers to affect the UX in a way that helps reinforce the intended usage. If I, as a theme developer, don't believe the theme is best used as the active theme, why not allow me to at least try and enforce that a little?

But is that intended usage best for the user? It seems to me that making a "theme" that doesn't actually work as a theme doesn't make a whole lot of sense. A theme that is really just a framework for some other code shouldn't be actually called a "theme". It creates user confusion because it's using the wrong system to accomplish its goals.

If the goal is to provide a base for some other code to build a theme upon, then that base is not a theme in and of itself, and should not be a theme. It should be a plugin, or a framework, or maybe something else entirely.

Expanding the definition of "theme" to allow things that are not actually themes to live there too is probably not the right answer. It would make more sense to allow for some other kind of core "framework" support, but realistically I think that could exist as a plugin instead. If it was popular enough, then a special type of plugin could be devised for it, but I don't really think it is that popular of a methodology. I know a couple of "themes" that do this, but only a couple.

#16 @nathanrice
10 years ago

Aside from the UX difference, is there something preventing you from addressing your needs on one of the hooks that runs on theme activation?

Obviously, as the developer of Genesis, I can probably push in code to make WP work pretty much however I would like it to. But yes, the UX is the key, and I personally believed it would benefit more than just Genesis users, so I wanted to see if there was interest in it for core.

#17 in reply to: ↑ 15 ; follow-up: @ryanduff
10 years ago

Replying to Otto42:

Replying to nathanrice:

The point is to allow theme developers to affect the UX in a way that helps reinforce the intended usage. If I, as a theme developer, don't believe the theme is best used as the active theme, why not allow me to at least try and enforce that a little?

But is that intended usage best for the user? It seems to me that making a "theme" that doesn't actually work as a theme doesn't make a whole lot of sense. A theme that is really just a framework for some other code shouldn't be actually called a "theme". It creates user confusion because it's using the wrong system to accomplish its goals.

If the goal is to provide a base for some other code to build a theme upon, then that base is not a theme in and of itself, and should not be a theme. It should be a plugin, or a framework, or maybe something else entirely.

Expanding the definition of "theme" to allow things that are not actually themes to live there too is probably not the right answer. It would make more sense to allow for some other kind of core "framework" support, but realistically I think that could exist as a plugin instead. If it was popular enough, then a special type of plugin could be devised for it, but I don't really think it is that popular of a methodology. I know a couple of "themes" that do this, but only a couple.

I've worked on enough sites where we need to install parent/child theme and can't tell you how many times I've accidentally activated the wrong theme and had to go back and activate the child theme instead. Perhaps it's just me in haste that causes the issue. Maybe users take more time to look at what they're clicking on...

In either case there's gotta be a way to make that UX clearer.

#18 in reply to: ↑ 17 @peterdog
10 years ago

Replying to ryanduff:

I've worked on enough sites where we need to install parent/child theme and can't tell you how many times I've accidentally activated the wrong theme and had to go back and activate the child theme instead. Perhaps it's just me in haste that causes the issue. Maybe users take more time to look at what they're clicking on...

In either case there's gotta be a way to make that UX clearer.

How about a CSS overlay in the corner that designates a framework parent theme as a parent theme and let the user be smart enough to not activate it but serve as a visual cue? That way you don't prevent activation but provide a cue... as a UX should.

#19 in reply to: ↑ 15 ; follow-up: @nathanrice
10 years ago

Replying to Otto42:

Expanding the definition of "theme" to allow things that are not actually themes to live there too is probably not the right answer.

It's not that they're not themes, it's that they aren't meant to be used without a child theme ... they're meant to be extended. Do we not call a PHP class a "class" just because we intend it to be extended? No, we use the "abstract" keyword to prevent it from being used without being extended. That's all I'm suggesting here.

But I see I'm swimming upstream here. I don't want to force the issue, I just wanted to give some input based on the perspective of someone who does build themes with this relationship. <strike>Very successfully.</strike> Edit: Sorry, that was unnecessary and petty. Didn't mean for it to come across that way.

Last edited 10 years ago by nathanrice (previous) (diff)

#20 @nacin
10 years ago

For what it's worth: I don't find the use case invalid. I just don't think WordPress needs to always account for all valid use cases.

#21 follow-up: @nathanrice
10 years ago

For what it's worth: I don't find the use case invalid. I just don't think WordPress needs to always account for all valid use cases.

Fair enough. You're the boss :-)

#22 in reply to: ↑ 19 ; follow-up: @Otto42
10 years ago

Replying to nathanrice:

It's not that they're not themes, it's that they aren't meant to be used without a child theme ... they're meant to be extended. Do we not call a PHP class a "class" just because we intend it to be extended? No, we use the "abstract" keyword to prevent it from being used without being extended. That's all I'm suggesting here.

I do understand what you're saying here, really. But a theme that you're not supposed to actually activate and use isn't really a theme, in my view. If you're not supposed to activate it and use it to make your site look a certain way, then it should not be in the themes list at all. Or in the themes directory.

What you're describing is half-a-theme. Some set of code and functions that somebody can use to build a working theme from. Now, the way you're doing it happens to fit the parent/child model, but maybe another model would fit better.

Because, to me, the parent/child model was intended to make adjustments, large or small scale, to already working themes. Re-defining it to make parents that are not actually working themes doesn't make any sense to me. Instead, I think a new model might be more appropriate. A plugin can do everything a theme can, just not as easily. Maybe making it easier on that level would provide a better approach overall.

Or something else, I don't know everything. I just think that if we want to support a mechanism for some chunk-o-code to replace large parts of what is traditionally done by the theme, so the theme doesn't have to, then having that appear in the existing Theme UI at all is ugly and kinda hacky.

#23 in reply to: ↑ 21 ; follow-up: @nacin
10 years ago

If a theme needs to prevent itself from deactivating, there are ways of doing so. (It was admittedly much easier when the theme_action_links* filters worked, which have been bypassed since 3.8.) It's not an invalid pattern what you're doing and obviously it's been the Genesis pattern for some time. But it's not ideal for a multitude of reasons and angles, and I don't think we should be providing a tool that can be easily employed for things like this that are not ideal.

Replying to nathanrice:

Fair enough. You're the boss :-)

On the scale of ‘one man’s opinion’ to ‘mandate’, I'd put this no further than ‘strong suggestion’.

#24 in reply to: ↑ 22 @nathanrice
10 years ago

Replying to Otto42:

What you're describing is half-a-theme. Some set of code and functions that somebody can use to build a working theme from. Now, the way you're doing it happens to fit the parent/child model, but maybe another model would fit better.

I don't necessarily disagree. If theme frameworks were officially a thing, I could get behind that. But what we have is Themes and Plugins. And from some preliminary work I did while considering moving to a plugin, it sure seemed like a lot of unnecessary work to do the conversion, not to mention making years of instruction null, and running the risk of the "plugin + theme" idea not being as intuitive as the current Parent + Child paradigm, which users seem to "get" without us having to do much in the way of explaining.

#25 in reply to: ↑ 23 @nathanrice
10 years ago

Replying to nacin:
That scale should be expanded and adopted as the official feedback mechanism. Seriously. Would help greatly to just KNOW if something has legs and should be pursued with proof of concept code, or if it's DOA.

  1. DOA because of X.
  2. Keep talking if you must, but probably ain't gonna happen.
  3. I need some convincing.
  4. You had my curiosity, now you have my attention.
  5. That's a cool idea, a proof of concept would be even better.
  6. Bad ass. Build it, and I'll commit it.

#26 follow-up: @F J Kaiser
10 years ago

25 comments without anyone throwing stones. I guess that's a new record.

Parent themes that are not intended to be used as stand alone themes are fact. If you still feel uncomfortable with the idea of parent/child themes not both being fully functional themes, try to see it like this: Sender & Receiver Themes. This is something we simply need when we want to start building "WebApps on the WordPress platform". One theme for setting up the App and defining routes and another one to have stylesheets and actual templates which return JSON (built by template tags).

I'm totally sold on that ticket. It's a needed step and we should turn our heads towards it.

#27 in reply to: ↑ 26 ; follow-up: @Otto42
10 years ago

Replying to F J Kaiser:

Parent themes that are not intended to be used as stand alone themes are fact.

But still "wrong", from a UX perspective.

If you still feel uncomfortable with the idea of parent/child themes not both being fully functional themes, try to see it like this: Sender & Receiver Themes. This is something we simply need when we want to start building "WebApps on the WordPress platform". One theme for setting up the App and defining routes and another one to have stylesheets and actual templates which return JSON (built by template tags).

Or one "plugin" for creating an "App" and a theme to define how it looks.

I'm not discounting the idea completely. Really. 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.

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.

#28 in reply to: ↑ 27 @F J Kaiser
10 years ago

Replying to 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.

#29 @travisnorthcutt
10 years ago

One thing I didn't see mentioned here (apologies if I missed it) is this: @nathanrice, how many times have you dealt with or seen support requests from users who modified Genesis (the parent theme), then updated it and wiped out their changes? Everyone else: how many times have you heard of that happening with other themes?

To me, that's the real argument in favor of this.

#30 @greenshady
10 years ago

Replying to travisnorthcutt:

One thing I didn't see mentioned here (apologies if I missed it) is this: @nathanrice, how many times have you dealt with or seen support requests from users who modified Genesis (the parent theme), then updated it and wiped out their changes? Everyone else: how many times have you heard of that happening with other themes?

I've been building parent/child themes for six years. In that time, I've maybe seen this happen 10 times. Most of them were in my first couple of years when no one knew what a child theme was.

#31 @knutsp
9 years ago

  • Keywords close added

#32 @johnbillion
8 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

The consensus in the discussion above is that while there is a valid use case for preventing a theme from being activated, it's really very narrow and can be implemented in the theme itself.

Note: See TracTickets for help on using tickets.