Remove Garland from Core

I'm not sure if anyone actually themes their site based on Garland. Might not be a bad idea to drop it. I'm also not sure if Seven will be applicable to D8 either, but that's mostly a version thing.

You've got my vote! Garlend is not a very flexible (or well designed) theme in comparison to Bartik and therefore I don't see any reason it should be in core, nor does it have any value as a parent theme.

Lets kill it!

Subscribe

I agree with this...although we'll have to make sure to create (at least) one theme to replace it.

@EvanDonovan in #5

See: #1087784: Add new theme to Drupal 8.1.x or another minor version

Subscribe

I know we likely will want to debate this some more. But I'm feeling patch happy tonight and wanted to move the discussion along by talking about an actual patch.

In addition to removing the garland theme from the themes directory, this patch removes garland references from the default settings.php and a test from the color module.

I don't mean to stop the discussion but can someone let me know if I've packaged up this patch correctly?

Oops missed some code that I need to remove from the comment.test

I don't see what I did wrong here. I'l retest

#12: remove-garland-2.patch queued for re-testing.

"Detect a non-applicable patch
Ensure the patch applies to the tip of the chosen the code-base."

Looks as if this patch needs a lot of work. I'll find some time near the end of my day to correct whatever the test bot has deemed wrong.

try patching local on your own machine before you submit them. it should be easier to figure out what exactly went wrong, see drupal 8.x git instructions. (and you don't have to wait for the testbot)

:)

With this patch only changelog.txt has a notice about Garland

+1

OMG!!! NO!! GARLAND!!!
Please, please, do not let them do it.

We will also need an upgrade routine that makes sure D7 sites using Garland don't break when upgraded to D8. Garland configuration settings need to be removed from the DB and an alternative theme needs to be enabled that copies Garland's block layout as much as possible.

@Xano Great! Suppose, upgrade path been needed when we change default theme to Bartik and now I see no reason for upgrade path. Anyway a theme would live in contrib so upgrade.txt or changelog should just point where it can be found

Probably we need just contrib project like been done for
http://drupal.org/project/pushbutton
http://drupal.org/project/bluemarine
http://drupal.org/project/chameleon

so it's time :) for Garland

EDIT: announce could be copy-pasted from #315533: Remove all themes but Garland and Stark from core

How was this done when Bluemarine etc were removed from core? Will core upgrade without their contrib D7 versions? If so, how gracefully does it upgrade? I'm fine with either option, as long as we don't cause WTFs and broken sites.

What logic would you use to do an upgrade? How do you know if the garland in the source themes directory is unmodified? If it is used as a base theme? Renamed? Or worse, moved/copied from /themes to /sites/.. A text note would be more straightforward.

d.ru

:-)

I don't think this can happen until Bartik supports fluid width -- it's not usable yet as an admin theme because of that.

We have 7 as an admin theme? Why should we have another fluid admin theme?

7 is no good as an admin theme if you're not using overlay, because it has no sidebars.

You can always install garland again (contrib). I don't think we should keep this in core because some use it as an admin theme o_O. I think there must be better admin themes out there with side bars.

+1

Make a new theme before killing an old theme.

I agreed to add a new theme but.... come on, old doesn't means it outdated. I don't see the design of Bartik is better than Garland.

> Plenty of themes out there with sidebars to use as admin themes, can't see this being a valid blocker

Core should be usable with overlay turned off.
This shouldn't be a huge deal -- Bartik is due to get fluid width, there's an issue open for that already.

No. I don't try to maintain it because both are bad IMO. I was hurt by designers. I shared it to many designers when D7 released. But all of them told me D7 UI are really bad. At the same time all drupaler told me D7 is really nice.

I agreed with #41, it won't be a problem and don't forget we are going to create a new one ? It can be with anything.

In order to keep Garland going, I've created http://drupal.org/project/garland . Ran into a problem where Color module's tests used Garland to test it's stuff. Gotta figure out another way to test color.module.

Use Bartik :)

#patchfail... Here it is. Good idea with using Bartik. Hmmmm.

Let's Garland die! :-)

We should have time for an adaptive layout of Bartik with media queries and maybe a new core theme. But Garland already can't evolve in that direction.

Trigger bot

1. Fix the Color tests.
2. Provide upgrade path to switch users with Garland to Bartik, or the contrib Garland if it exists.

Hopefully this fixes the issues I stated above. During the update, it switches from Garland to Bartik for the admin theme, maintenance mode and default theme. We might want to check if the contrib Garland is available though and use that.

Apparently the test bot doesn't like git diff with deletes, so hopefully git format-patch works.

Looks like the test bot likes it, but I am not sure dries or webchick will like that format (with all the binaries). :-)

That patch was made using the Creating patches via feature branch, so they'll have to like it. The bot doesn't like it any other way when deleting binaries.

When one is doing Database Updates, one does see Garland in D7 (at least I do on an upgraded site that came from D6).
Just to mention - maybe there is still an Dependency there somewehre that has to be taken care of.

Garland ships with Drupal 7.
This patch's target is to remove Garland from Drupal 8. :-)

@eigentor: No more dependencies anywhere. This patch removes all dependencies on Garland from all tests, themes, modules, etc. It even puts in an upgrade path that switches the site away from Garland if they were using Garland.

What this issue does need though, is a Issue summary. Someone mind helping out in putting it together? :-)

Issue summary as requested in comment #56

Problem/Motivation

There is wide consensus around the need for garland to be removed. It is inflexible and quite dated looking. Removing garland from core would create a much better overall 1st impression for newcomers to Drupal. And a much better face for Drupal moving forward with the Drupal 8 release cycle and beyond.

Comments on this issue showing this consensus:
http://drupal.org/node/911054#comment-3445384
http://drupal.org/node/911054#comment-4191146
http://drupal.org/node/911054#comment-4193110
http://drupal.org/node/911054#comment-4247770
http://drupal.org/node/911054#comment-4852450

Proposed resolution

-Create a patch to remove the Garland theme and all it's dependencies from tests, themes, modules, etc. (http://drupal.org/user/61114).

-Talk to JohnAlbin(Current Garland maintainer) about moving Garland to contrib (http://drupal.org/node/911054#comment-4248398)

-If needed: Make sure that Seven meets full requirements for use as an admin theme & add sidebars if needed. (http://drupal.org/node/911054#comment-4852394, http://drupal.org/node/911054#comment-4852686).

-Build out a proper upgrade path. In documentation - pointing existing 7.x garland users to the garland theme in contrib. And making the actual upgrade path that removes any conflicts and copies the block layout as close as possible. (http://drupal.org/node/911054#comment-4837652) EDIT: Part of this has been done. The patch in #51 switches the site away from garland if they are using it.

Remaining tasks

This issue still needs a bit of review of from core maintainers (eg Dries, Webchick)<-?. It would be good to hear from them as to how they want to the upgrade path to work, and whether Seven meets the needs for a core admin theme. After then we can decide how we want to make add garland to contrib. We have a working patch to remove the theme. We just need guidance on how they want to proceed with these other steps.

User interface changes

The only change in interface or functionality will be removing the Garland theme from core.

API changes

No API are included in this patch or are being proposed in this issue

Original report by Jeff Burnz

Posted by Jeff Burnz on September 14, 2010 at 12:52pm
"Garland has lived through 3 major versions of Drupal and was first debuted in Jan 2007. By the time D8 ships Garland will be at least 5 years old (if not more). I think the time has come for Garland to step aside quietly into the abyss of contrib and make way for some new exciting themes in D8.

from Russia with love"

Re tagging based on Sun's tag in #57. I accidentally changed it back when creating the issue summary.

Copy of the revision from August 8, 2011 - 01:40.

Updated issue summary.

Thanks a lot, @tlattimore. I've copied it into the issue summary at the top and touched up the HTML a bit.

#51: 911054-removegarland.patch queued for re-testing.

Subscribing. It would be great to know what's going to happen with this sooner rather than later.

Changing status to get maintainer feedback.

@Everett Zufelt: You've modified this issue to reviewed and tested by the community (RTBC). Did you want to set this to postponed (maintainer needs more info)?

I'm comfortable removing Garland from 8.x. For now, in terms of upgrade path, we could just set Seven or Bartik as the admin theme. I plan to commit this patch later today or tomorrow.

#51: 911054-removegarland.patch queued for re-testing.

Blast! I'll try and re-roll if that patch this afternoon if no one else gets to it first.

Here's a re-roll.

Got today's d8 distro
applied patch
installed drupal using standard web-based installer
observed that Garland was not an available theme.

RTBC

This needs a CHANGELOG.txt entry, could be done in a followup though.

Sorry, lets not rush this. Why do we remove Garland if we have no valid replacement? I am all for removing it, but seems like we are rushing this. Also we don't remove themes from core with no maintainer ( I am pretty sure more people use Garland, than any other theme (not base theme) on d.o)

But we will have a replacement via the Design Initiative.

It's not a matter of rushing it, it's a matter of having a clear plan and not wasting people's time. I don't want to have to a team of people wasting cycles on applying fixes and or updates to a theme that is going to end up being removed. If it stays that opens up discussion in every single issue we do as to whether or not X markup or CSS change should be applied to Garland. It also means we spend hours on end across patches cross browser testing the theme for every single CSS change we apply to core modules.

Simply put, it's a burden that may or may not be justified. If the theme is going to stay, then it's justified. If not, then it's just a complete and utter waste of everyones time and that is truly frustrating, so it should be avoided.

Just a note that Garland does have a maintainer (Rob Loach) in contrib: http://drupal.org/project/garland Not that this means it'll chase HEAD constantly, and probably will in fact wither and die like everything else we move into contrib, but hey. :)

I see Jacine's point here that converting Bartik to HTML 5 is going to be challenging enough. Converting Bartik *and* a non-default front-end theme that very few of those people use is going to be even more challenging. So I'd support its removal.

Because even in the worst case, where we remove this theme *and* the D8 design initiative fails to produce anything (which could happen), I don't actually think we're that bad off. We'd ship core with three themes: a front-end theme (Bartik), a back-end theme (Seven), and a developer theme (Stark). It makes it really obvious that "if you don't like what's here, you should go to http://drupal.org/project/Themes and go find something else." (though hopefully http://drupal.org/project/project_browser will make it in and this will become a moot point)

Since Garland does have a valid replacement (an update function switches it to Bartik), and it does have a maintainer for the contrib project (Rob Loach), moving back to RTBC. I don't see a compelling reason to halt this; this is one of those things for the D8 maintainers to make a call on, IMO, and it looks like Dries already has.

As much as I love Garland, I think it's going to hinder the html5 effort, big time. So even though I'd like it to stay, I think it should be removed, now.

The last remaining issue to prevent it's elimination appears to be a minor update to the changelog. As mentioned above that change should not block this commit. Who has the authority to commit this patch?

This is awesome!!! Tiny change:

+++ b/modules/color/color.testundefined
@@ -27,18 +27,13 @@ class ColorTestCase extends DrupalWebTestCase {
-    // This tests the color module in both Bartik and Garland.
+    // This tests the color module in both Bartik.

Remove the word 'both'

Let's add that CHANGELOG.txt entry while we're at it, then.

Done, rerolled. Tested patch before submitting, worked.

Sorry didn't add the line to CHANGELOG. Here's a new patch with that change included.

Looks like my patches are of the old style. Can anyone point to the documentation where the proper patch making process is explained?

git diff > foo.patch should take care of it. See http://drupal.org/node/707484

@Jacine I think that everyone agrees with a direction that avoids people wasting time. I wish that was a stronger argument for a lot of UI's that I spend time fixing even though I know they are utterly wrong :) . I guess its only when a lot of people waste a lot of time, things like these become an argument.

@webchick I do think we are very bad off, if we end up with no new theme in core. The idea of showing another theme, is showing that you can extend and make your site more beautifull. By offering no alternative, we miss out on that opportunity and dump them into the horrible d.o experience (20 base themes first). I guess part of my comment, came from my worry that the design iniative wont produce a new theme because its still stalled.

Anyways, seems like a lot more useful arguments to push this in now :) so lets do it!

webchick: git diff > foo.patch should take care of it. See http://drupal.org/node/707484

Unfortunately git diff will only get you part of the way there. You'll need git format-patch for complicated stuff like removing binaries, like this patch does. @cosmicdreams, you can find the steps to do it over at the advanced patch contributor guide.

Bojhan: I guess part of my comment, came from my worry that the design iniative wont produce a new theme because its still stalled.

I'm completely with you, Bojhan. It would be great to launch a new theme with Drupal 8, but the amount of amazing themes that pop up in contrib completely blow what's suggested for Drupal core (6.0 or 7.0) out of the water. I love Garland, and plan to continue to use and support it in the Drupal 8 lifecycle.... But, seriously, there are way better systems out there. Let's consider those alternatives in a year when Omega takes over the world, responsive design is the norm, and the HTML5 Initialive has pwned Drupal in the face.

In the mean time, let's re-roll this patch with #79, the CHANGELOG.txt addition, and say hi to Garland in contrib :-) .

Unless someone beats me to it, I'll format the last patch appropriately tonight. The patch in #83 includes the changes requested in #79 and #80. It's just not formatted right.

@Bojhan I share your concerns about having to work around UI metaphors that don't work and think that we should have a new theme for Drupal 8. I'm not worried about the new theme part though. The design initiative, I'm sure, will produce something of high quality. I also am grateful that I work with a bunch of UX / IA rock stars and am looking forward to getting their input about various UI concepts that are put forward during the D8 development cycle.

With everything on D8's plate, I think we're going to end up with something exponentially awesome.

@Bojhan I'm sorry to hear that, because the work you are doing is just as important as any of these initiatives. Just because there might be less people working on it, doesn't mean the time spent is any less valuable, so IMO the argument should be just as strong.

@cosmicdreams The video in this post might help you. You can stage the files as if you were going to commit them and then just do git diff --staged > patchname.patch.

Anyway, I decided to re-roll this real quick and make a change to the changelog entry. Unless another theme is removed, it seems to makes more sense to have it be a one line entry.

But, hmm, this seems way smaller than Rob's patch. Sigh. Hopefully it works just as well?

EDIT: Or not. Sigh. I guess I need to figure out git format patch and make yet another update to that post.

Another try (using git format patch)

I think I have the patch right, given how it's file size compares with the files size of the patch that is attached to #70. Can anyone kick the bot's butt into gear so we can see if the patch applies?

@cosmicdreams I tested it out and it works for me. Give the bot a little bit. I'll go green and we'll RTBC it for you. Thanks!

Dries already posted in here, so I'll let him do the honours, but just to confirm I agree with the decision to move Garland to contrib.

Subscribe.

Committed to 8.x. Thanks all!

Yay! :D

Awesome! Now all we have to optimize is Seven, Stark, and Bartik? Well, and the new theme we make for Drupal 8.

Should we drop "Seven" and make a new administrative theme called "Eight"?

Should this have a change node? I suspect in the least that it should advise those with Garland sub-themes (custom most likely) that they need to download the contrib module, as Garland is no longer part of Core.

Yeah, it should.

Unassigned it from my TODO list.

I've been making some noise about the problem of having an admin theme named Seven in D8. It's confusing.

@cosmicdreams - glad you agree.

So, perhaps we need a new issue to look at creating either an Eight theme or just renaming it to something generic like CoreAdmin so that we don't have to go through and do this every few years (I do wonder how many references there are to the theme name in core & associated documentation).

Might be useful to have a bit of a brainstorm about what we'd want from an admin theme & what other admin themes are offering that a CoreAdmin doesn't.

Would be good to have SVG files for all themes in core in a repository too so that people could more easily tweak the designs. Inkscape files can nicely be stored in git too.

Let's file another issue about name of Admin theme for D8 and later - I prefer to use Admin & probably Omega is a good candidate for main D8 theme

I would love to see a version of omega as the replacement.

Media queries in core? Yum.

I agree with #111

#110 #112 Please keep the issue clean. Lets start another issue 4 that.

BTW: #110, Please NO subtheme solutions in core!

http://drupal.org/node/1297864

@Jeff - Good call. I should have just started this new issue rather than bringing up a tangent here.

Those who are interested in discussing the admin theme I set up 2 new issues:
#1297428: Rename Seven in D8
#1297962: Brainstorming for D8 Admin Theme features

@Andy - definitely interested in your thoughts about the Admin theme on these new issues.

Fixed up the HTML