'base theme' property in theme .info.yml files does not need to be wrapped in quotes

Yeah, agreed, this is a problem.

Let's simply rename this to "base_theme".

Ideally, I'd even go one step further and rename it to just "base".

("parent" would be much more accurate, but unfortunately, that would invalidate tons of theme system documentation that currently refers to "base theme")

Changing to "base" looks cleaner in the yml file whilst still being clear to the developer/themer.

An initial crack to moving the property name from 'base theme' to 'base'. Taking in to account the core themes, yml processing and all associated tests.

Giving PHPStorm a go for creating patches. Fingers crossed.

The patch was created with core as base directory, so I simply created it again.

Interesting — this patch somehow triggers the same weird test failures I also got in #2228201: Replace global $theme with global $theme_info

Unfortunately, I wasn't able to figure out why they are happening... Can you debug?

6: Rename_yml_info_file_property_base_theme_to_base-2228125-6.patch queued for re-testing.

@codenator if 'base' appears in the theme info yaml file then it has some context about its purpose.

But 'parent' is an option i like a bit too.

6: Rename_yml_info_file_property_base_theme_to_base-2228125-6.patch queued for re-testing.

It is only replacing 'base theme' property with base and we have test if this come back green then it is RTBC.

And we need change notice for this as well.

Reroll

Tagging for http://drupaltwig.org.

+++ b/core/includes/theme.inc
@@ -124,7 +124,7 @@ function drupal_theme_initialize() {
- *    An optional array of objects that represent the 'base theme' if the
+ *    An optional array of objects that represent the 'base' if the
  *    theme is meant to be derivative of another theme. It requires

Let's re-add "theme" (sans quotes) after 'base' to not break this sentence. :-)

from a theme persepctive using base: instead of base theme: in the yml file makes perfect sense - so no worries there

Changing the comment.

Thanks! :-)

Added a change notice draft. https://drupal.org/node/2234253

Hm. If we're going to break this anyway, it sounded like more people were in favour of "parent" than "base." This also makes a lot more sense to me. Looks like WordPress uses somewhat this same terminology as well: https://codex.wordpress.org/Child_Themes Versus I was not able to find a similar concept in any other system by googling for "base theme."

I think invaliding some documentation is probably the least of our worries, since there's basically nothing from D7 that holds true for D8 anymore anyway. ;)

Knocking back to needs review to see what people think.

If renaming it to 'parent' is an option, then I think I'd be in favor of that, yeah. "Parent" concisely describes the model and algorithm under the hood, and that concept is generally understood.

In that case, I'd suggest we just care for the .info.yml property rename here + perform a whole bunch of API method + variable renames in a separate issue.

Rewrote the issue summary to properly reflect the problem space and proposed solutions.

Just a thought!
Why just not make it base_theme like all other keys.
This preserves the well known term 'base theme' instead of new one 'parent'

just to chime in here (not that i feel strongly about) but a "base theme" / "base" is understood by any drupal themer, introducing new names for known concepts makes little sense to me - else can I wish that we rename blocks, so we can free that name for twig ;)

Ok, fair enough. Let's go with this then. While there are underscores in certain .info.yml properties (notably "ckeditor_stylesheets," which is a bit bizarre in and of itself) the norm is just single words, even if they havetobecrammedtogether (like "stylesheets").

I guess this needs to happen before beta, but I'd like to gather some more feedback first (and just asked in IRC #drupal-themes + #drupal).

I'm also adding "base_theme" as proposal C to the summary, since it has been mentioned a few times by now.

re: @mortendk:

"base theme" / "base" is understood by any drupal themer

Is it possible that Drupal themers only understand what it is, because they once had to learn it the hard way? :-)

I think we should make the shift now to the "parent/child/grandchild" paradigm. It would help clarify a whole lot in documentation, especially when dealing or discussing "base theme/sub-theme/sub-sub-theme".

another vote for "parent_theme", precise and unambiguous.

@SeriousMatters: Was that a vote in favor of proposal B, or are you suggesting a new option D to rename 'base theme' into 'parent_theme'? (same as B, but with additional _theme suffix)

Another +1 for parent (proposed solution B).

Yes, Drupal themers know what a base theme is, but I think the parent/child concept is easy enough to understand and explain, maybe even easier to understand, especially for newcomers to the platform. For example, the concept of inheritance makes more sense in the context of a parent/child relationship than it does in the context of base theme/sub-theme relationship, because everyone understands that a child inherits traits from a parent but also has unique traits of her own. But how do a "base" and a "sub" relate? Subterraineously? See, that's not even a word. Although, I will concede that base theme is a term that should be familiar to Drupal themers already, even if they did learn it "the hard way."

@webchick makes a good point about Wordpress having the concept of child themes already. There are a lot of folks that build sites using both Wordpress and Drupal, so I think it's actually kind of nice to introduce even the tiniest bit of consistency between the two platforms. :)

+1 for _theme suffix

Both base_theme and parent_theme are good, makes sense for existing themers and easy to understand for new ones.

+1 For parent. I would rather have it as parent_theme, but parent is next in line.
I would still keep the _theme suffix, since base or parent without that suffix makes me think about some Drupal component, like theming engine, rather than another theme.

+1 to parent_theme, I agree with alexrayu completely.

+1 for parent. Makes more sense than base when there are more two (or more) levels of inheritance. Adding _theme would be redundant, I think (the parent of a wombat is a wombat).

Looks like all options regarding "base" are off the table now. Updated issue summary accordingly.

Remaining options:

B) "parent"

D) "parent_theme"

Personally, the _theme suffix looks superfluous to me. I don't see how a (top-level) "parent" property could be ambiguous.

FWIW, we also have "engine" (which defaults to 'twig'), which equally does not have a _theme suffix. Likewise, "name" is not "theme_name" either. All of the top-level properties imply the scope of a "theme".

Therefore, just "parent" seems to be sufficient and most accurate.

Agreed parent sounds more appropriate. _theme is extraneous and unnecessary. It's already declared as type: theme and rather apparent in which context this belongs.

Looks like people are generally in favor of "parent". Moving back to CNW for continued work on the patch.

If we change to parent, there's a bunch of other uses of $base_theme, $base_theme_info, $theme_object->base_themes etc that should(maybe) also be changed... not a small task. Otherwise we end up with 'parent' in one place, 'base theme' in another. One or the other please.

Bump. Can we rename the YAML key and do the variable/method/etc. renaming in a followup? Beta is looming.

I think we should fix all the stuff needed for beta sooner than later in order to get it in. We can take care of the rest later.

I will create a patch for this with key 'parent'

Just a general question. Did someone considered that the following code IS a valid YMl, see #2328411-14: Convert all permissions to yml files and permission callbacks

name: 'Breakpoint test theme'
type: theme
description: 'Test theme for breakpoint.'
version: VERSION
core: 8.x
base theme: bartik

Proove: Patch.

Oh! :) Lovely.

So this seems more appropriate then. Added the best link I could find to the top of the issue summary.

Thank you @dawehner!

Adding the link from #2328411-14: Convert all permissions to yml files and permission callbacks also.

Committed and pushed to 8.x. Thanks!

@Codenator - no change was made to the structure of the .info.yml file for themes because the quotes are simply not necessary.

So the patch in #48 simply removes the quotes.