D7UX: use Seven for installation / updates

Not sure if we should fix all visual design issues here or just apply the theme in this patch and fine tune in follow ups?

subscribing

How our sites look to the ultimate end users, that is the registered users or visitors, is what matters finally and most importantly. Not how the site looks to me as administrator.

Installation, imho, should actually present that view so that I know how the site is going to look to the world. So I feel installation should take place in the site's default theme, garland or whatever new theme is designed.

Installation is also the time I come to have the first impression how my site is going to appear on the www. This first impression should not be 'damaged'.

Also, Garland or any other new theme can be used for BOTH default site design and Admin area, while Seven cannot be used as site's default theme as by default it has not blocks etc enabled.
Thus the opening theme (installation is the time of first opening) should have wider perspective.

If Seven shows up as 'site offline' theme it will be odd to the members/visitors and if Garland/Minelli is the site offline theme but Seven the online theme things become NOn-uniform.

-1 from me for the change.

I am going to try to contact Mark once more about this page. For the page that serves as the first impression of users for Drupal. It should be looked after, right now I think there could at least be more separation between the content and the required steps.

Could the "V" icon be implemented correctly?

I disagree with kaakuu. During installation you are installing the Drupal software, not your new Drupal web site so should be using the default admin theme Seven. If there ever was an administrative task then it's actual installation!

tagging

@yoroy - installation is the first chance I get to see how my site will be on web. Drupal software is a live web thing and not a back-end or desktop software that 'spits' out the Drupal website. Basically they are the same. Imho, the first and foremost humane administrative task is to have a look and feel how my site looks to my visitors. Of course, opinions can vary. Its also going to be a bit of shock how drastically things change when I hit "Back to site/front page" from my admin zone as if it lands up things in a very different place.

The proposed installation is going to mimic WP somewhat and this is one place I will opt not for mimicry but Drupal's uniqueness.

Did not mean any tag change or whatever. Please do the needful to make it what is needed. Thanks.

re-tag

@kaakuu I must disagree, would you expect an installation for a game/app to look like the game/app will? I'd expect it to look like an installation wizard.

Installing is an administrative task, so does it not make sense to show it in an administrative environment?

Not to get into a +1 / -1 war here, but this is a big +1 for me. :)

This change is consistent with the very idea of an admin theme - installation is about as "admin" as one can get. At this point why should Garland be the default? I could see Drupal core (or distros like Acquia) shipping with multiple themes to choose from. Using the admin theme opens up the interface to having theme selection as part of the install process without an awkward switch from Garland, to Seven and the to the theme chosen during installation.

I agree with this direction. Installing and upgrading Drupal is an administrative task.

If I were to walk someone who had not used Drupal before, through an installation, I would prefer to do so with Gábor's patch. It looks very professional and polished and gives a warm feeling of competence that evokes "Trust us, we know what we are doing."

Subscribe.

Under no circumstances whatsoever can we include the new wordmark in Drupal itself.

One of the main design goals for the new wordmark was to have a new official logo and branding that was not under the GPL. See: http://www.garfieldtech.com/blog/drupal-org-logo-trademark

Any artwork included in Drupal core must be released under the GPL.

Therefore, the new wordmark cannot be included in in core. Period.

We could potentially put other artwork there (maybe Druplicon?), but not artwork that's part of the drupal.org redesign.

--Larry Garfield
Drupal Association Director of Legal Affairs

Great, we can't use our own logo in our own software! ;) Larry also asked me to take down the new Drupal logo from drupal.com until we figured out the license for the new logo. While I personally think that is a bit unnecessary, he felt very strict about it. While I disagree, I want to respect him (and the law) so I'm trying to come up with a temporary new logo for use on drupal.com as soon as possible, and use that until we sorted out the license issues around the new logo. If it looks nice, we could also temporary use the temporary logo in the installer. I'm comfortable with releasing the temporary logo as GPL.

Er. What?? In remotely what way are images derivative works that must be GPLed?

From a branding perspective, a temporary logo would not be a good thing. We already have the Druplicon, the new Drupal logo, and now a potential other logo - all to represent the same software and organisation. How can this not be a massive potential for confusion?

If it comes down to it, I'd recommend removing the logo from here until this can be ironed out.

This is related to why many Linux distros have created custom builds of the Firefox code and removed all references to "Firefox", because that name and its images are copyrighted so cannot be GPL'ed for their distros. It sucks, but that's life.

The difficulty is that even dual-licensing it with GPL and something else would effectively give up control of the logo, which isn't something Acquia is likely to do.

The wordmark doesn't belong to Acquia, it belongs to the Drupal Association.

webchick: If the wordmark graphic is in CVS and distributed with Drupal, it must be under the GPL. That's *our* rules. If it's released under the GPL to anyone who downloads Drupal, its use as an official logo is severely crippled. See the blog post I linked to.

Surely not every open source project strips all branding from its GPL distribution. The name of "Drupal" itself is of course included in the software package and yet it is protected under trademark law. Why can't this be applied to the image of the wordmark as well?

I came across an interesting research article which addresses this very topic. Here's an excerpt from Trademark and OSS:

Although osCommerce is released under the GNU General Public License, we do enforce our trademark rights concerning the osCommerce name and logo. This means that, while you have considerable freedom to modify and redistribute osCommerce, there are restrictions placed on the usage of the osCommerce name and logo…. The GPL does not provide any license or right to use an osCommerce mark in any form or media. Thus, although a GPL licensee may redistribute the underlying software, a GPL licensee may not use an osCommerce mark in doing so that does not conform to the osCommerce trademark policy without written permission of osCommerce.

I found this at softwarepluralism.org.

Crell: As Aaron points out, why can't there be exceptions, or enforce trademark rights as osCommerce do? Surely this is a little different with graphics, as it could be argued that bitmap graphics are the representations of the vector source. They're not source graphics that are able to be changed, manipulated or violated in the same way that code could potentially be.

If it's released in the this fashion, I don't see how its use as an official logo is 'crippled'. Surely the alternatives - such as additional logo for drupal.com, or more prominent use of the Druplicon - would cause more brand damage and confusion? That would be more crippling, no?

I question the assertion that the logo must be made GPL by being included. That assumes that the logo is dependent upon Drupal to be an image, which is clearly not true. The logo is content. So the issue is not GPL itself, but some notion of policy.

Yet it seems simply including a trademark.txt file with the theme would cover that.

The only real obstacle is that we collectively prevent ourselves from doing it through doublethinking or convincing ourselves of absolutes that need not be. IMHO.

The concern I would have is that if the wordmark is licensed under the GPL, it becomes much more difficult to prevent others from using it in ways that could lead to consumer confusion. If the idea behind the wordmark is to establish drupal.org and other properties as being officially endorsed by the Drupal Association (who holds the copyright on the wordmark), then that could be undermined if folks are able to use it just about anywhere and in any of the ways that they can use the word "Drupal" itself.

Of course, the challenge is that Drupal (the software) is definitely something the DA does want to endorse, and I see Mark's point that fragmenting the branding by using a different mark or Druplicon could be even more confusing. The two possible ways I see around this are either by making an exception to Drupal CVS policy for the wordmark graphic, so that it alone is not distributed under the GPL, like other images are, or that the image is externally hosted outside of CVS, though this would potentially hammer drupal.org's bandwidth because the image would need to be downloaded every time someone installed the software. Also, you'd need a backup for folks who install Drupal while not on an active Internet connection. I don't think we want to be allowing just anyone to use the wordmark under the terms of the GPL, though.

this would potentially hammer drupal.org's bandwidth because the image would need to be downloaded every time someone installed the software.

Just to this point, the D7 core tarball is 1.9MB now. I don't see a few k for a logo as a hammer in any sense.

The png file would not be a derivative work of anything GPLed, no. However, Drupal's standing policy is that anything in CVS is released under the GPL. Period. We've removed themes from CVS before for violating that policy. Granted, the GPL is a lousy license to use for imagery in the first place but a license of "GPL for this, CC for this, public domain for this" in CVS would be extraordinarily messy.

While we could make an exception for just that one file, that would also be quite messy. How do we justify saying that we will make an exception for that file, but not for some other image in a module or theme? Wait, does that mean we can include CC-licensed icons now? (Right now we don't.) Aw, but why? I just want to include my company logo on the theme we're contributing!

Breaking the "It's in CVS => it's GPL" rule complicates things more than I think we want to deal with, politically more than code-wise. And I do not think that's a debate we want to get into.

Hypothetically, perhaps we could work out a "GPL but not really" by layering copyright and trademark on top of each other with special exceptions. However, that would require non-trivial work with an attorney to make sure we get it right, and that runs into both time and money.

Talking to gdemet and farriss offline just now, they suggested an alternate approach where an install profile would separately pull the wordmark from drupal.org, not through CVS, and drop that into the files directory to be cached and used for the admin. Different install profiles (or different admin themes?) could specify a different graphic for alternate branding. That would allow us to keep the wordmark out of CVS, but still display it in the admin theme at least using the default in-core profiles. We could arguably then state that using the wordmark on a Drupal that doesn't come from Drupal.org is not allowed. There's some edge cases to figure out there I suppose, but that's more legal than technical questions.

I'm a little iffy on the idea myself, but it would keep the wordmark out of CVS and therefore out of the GPL.

If we can't use the logo that the Drupal community effectively paid to have designed in our own software, then something is completely and utterly wrong.

If the choice is between GPLing the logo which allows everyone who wants to to draw a fish on it vs. only being able to use it on Drupal.org and other DA-controlled properties, but not in the software that those properties are intended to promote... well then fish away, I say! :P Though this would be a colossal waste, since one of the major reasons behind paying to have said logo designed was so that it could be a strong, protected brand for us. If it was known this was the inevitable conclusion, we might as well have kept the scary alien head and saved ourselves some dough (no offense to Mark :)).

However, I don't think these are our only choices. We make the rules in our own CVS repository, and so we can also just make a rule that our trademarked logos are exempt from the license of the *code*, of which images are not a derivative work in the first place. Done. Yes?

Is it messy when it's Drupal's own wordmark?

Is the logo graphic any more problematic than the word "Drupal" which also is trademarked? If we really want to push it, we could say you can't mention Drupal within Drupal.

Oops. Cross-posted. Larry, I think you are way over-thinking this. I have no idea how it could possibly be confusing to anyone that the Drupal software's repository has an exemption for its own trademarked wordmark and, with that sole exception, all other code/images are GPL.

Given the political issues surrounding changing CVS policy, as well as the fact that making this one exception means that Drupal would no longer be able to make the claim that it's 100% Free Software ("Drupal: 99 and 44/100ths percent pure!"), I'm liking the "download a copy of the logo from Drupal.org when you first install Drupal" option; this should be fairly straightforward to script, and the only concern I would have is bandwidth and/or excessive network traffic if there were a lot of people trying to install the software at once.

@laura s: Yes, the wordmark is a different beast than the word "Drupal" itself; while the word Drupal is primarily a descriptive term that describes the software, the wordmark represents Drupal's brand. The DA won't be able to stop folks from using the wordmark in all situations, but it still enjoys many more protections than the word Drupal itself, even though that word is also trademarked. GPLing the wordmark is a very bad idea, IMO, and pretty much undermines all the time and expense that went into creating the entire identity system in the first place.

Sorry am a bit late to this. (I was in a client workshop all morning.) We can and *must* use the new wordmark in D7 admin theme and we also must preserve our right to use it as a trademark of the Association (i.e. not allow it to become GPLed).

We have options that meet that criteria (all already mentioned in previous posts):
1) link from the theme to the wordmark hosted on a remote server/CDN
2) include a script that downloads the wordmark separately when Drupal is installed.
3) Amend the CVS terms to exclude our png file.

Any of these will suffice and, arguably, there is precedent for options 1 and 2.

There should not be a temporary logo. I do think that Drupal.com should be licensed to use it, even if we end up licensing it to no other party, as a reciprocal acknowledgement of Dries' consent to allowing the Association to use the trademarked word in the first place. No worries, I will work with Crell to get that situation straightened out asap.

To throw a wrench into the download the image when you install drupal issue, what about the times people install drupal and they don't have an internet connection or drupal.org is not responding? I regularly install drupal from a local bzr repo I keep for my head patch workflow. I don't need internet access to roll out test feature installs on a whim. Sure, this is an edge case. But, I imagine we can come up with a lot of those which will bring on many support requests. Sure, we can include a default other image in case we can't get to the image.

We would still be able to claim the software is 100% free software. First, the software is not the images or the css. Second, even it the logo isn't GPL it's still free for them to download.

After talking to gdemet one issue he made clear is that the wordmark, if included, would not be as Free as GPL'ed software. But, Free is really relative. GPL software is not as Free as BSD Licensed Software. This may get RMS followers and/or GPL lovers upset. But, someone will be upset either way. It the wordmark isn't included there are some who will be upset.

So, who are we going to make upset?

1 and 2 seem like they're introducing major WTFs to our users:

1. How come when I installed Drupal in that conference room in front of a bunch of executives trying to show them how nice Drupal looks, the logo was gone?

2. How come on the very first page of the installer it's welcoming me to Drupal by sreaming at me to make some random folder writable?

Can someone please explain to me the "political issues" surrounding the GPL policy change (#3)? From what I can see so far in this issue, this approach appears to be the same that other open source projects take when given this exact same issue, and it has not affected their OSI license compliance or created confusion about their repository rules. Which leads me even less put much credence behind the hypothetical situations Crell talks about in #30.

I'm a free software zealot as much as the next person, but I am just not seeing the issue here. Help?

webchick: Most projects don't have an official logo that doesn't get added to their repository thus made available as GPL, the fact that Drupal does makes it different than the norm. That said, it isn't the first to have ran into this:

• Mozilla Firefox vs Gnu Iceweasel (related, not the exact same scenario)
• Pike
• osCommerce
• Joomla

I think the osCommerce and Joomla use cases are the best examples for consideration.

So the "political issues" I was concerned about are the ones described in that Firefox vs. Iceweasel scenario. Debian, like Drupal has historically had a very strict 100% GPL policy, and we're proposing to change that for the wordmark. Personally, I have no problem with this, because it makes sense to me, but I think that it could be a problem for some people. If we went this route, we may need to consider making a version of Drupal without the wordmark available for those folks who refuse to use any software that isn't 100% GPL.

The political issues I was referring to are Drupal internal; Right now we can say "CVS == GPL, period, if you don't like it go away". And we do say that often, especially for themes that want to use non-GPL images. If we instead start saying "CVS == GPL, period, except for images that the DA decides are not", I fully expect that the number of questions and complaints and requests for exceptions that killes and the infra team (and at times me) have to answer to go up. How do we tell Drupal contributors "sorry, you're not cool enough to get an exception to the GPL policy, no not even for a really cool CC-licensed icon pack"?

How do we tell Drupal contributors "sorry, you're not cool enough to get an exception to the GPL policy, no not even for a really cool CC-licensed icon pack"?

Easy: "You are not the Drupal core software itself. Buh-bye, now."

A single exception should be simple to handle. From a larger perspective the exception should be something like: "GPL with the exception of content, media and trademarks owned by the DA required for distribution of Drupal", or something similar to push it back that the DA owns the trademark, it's not just some CC thing someone downloaded that looks cool.

So I did check, and there is a Drupal package that's part of the official Debian distribution, so if we did go with the "exempt the wordmark graphic from the CVS policy" route, they're one example of someone who would need to use an alternate version of Drupal that did not include the wordmark.

Actually, the Iceweasel thing is interesting. We probably will have to have a similar guideline for rebranding Drupal in Drupal distributions, although that is basically covered by the draft trademark policy (hopefully soon to be un-draft policy) that says you can't use the name "Drupal" without permission. Doesn't really make sense to call your distribution "OpenAtrium" but use the "Drupal" wordmark in your installer.

But guidelines around rebranded distributions is a separate issue from including the image in the core download itself.

But you all agree on using the Seven theme for installation, right?
…
I realise this is an important discussion to have, but it's also rather off-topic with regards to the original issue, even if the logo placement was introduced here. Probably too much discussion already right here to just split off another issue? But please, this is a flamingly hot topic that is hijacking an otherwise rather hands-on issue with patch and all. Please advise?

If we instead start saying "CVS == GPL, period, except for images that the DA decides are not"

More like "CVS == GPL, except for the Drupal wordmark itself."

afaik LICENSE.txt isn't in CVS either, but is added by the packaging script - so why not only include it if installing Drupal from a Drupal.org tarball, if you install via CVS you get good old Druplicon instead (which serves as a default for all profiles which don't specify an image) - that gets the logo into the tarball, but not into CVS (it'd have to live on the server somewhere else of course).

To the Drupal Association Members - put the single CVS exception question to a vote - like right now. (Not that I have any business telling you what to do, but I figured that's one way to solve this question before 40 comments turns into 340 comments.)

As for

"How do we tell Drupal contributors 'sorry, you're not cool enough to get an exception to the GPL policy, no not even for a really cool CC-licensed icon pack'?"

That's one perfectly legitimate way of telling people. I would choose different words though.

@yoroy Seven would be great for installation. I would prefer that over Garland and it would show people right up front that something is different about this release.

I actually quite like catch's suggestion in #47. So the package script would add the Drupal wordmark and include it e.g. at misc/installer_logo.png, and then, in code, we'd check if misc/installer_logo.png exists and otherwise take druplicon.png. This would also make it easy for other distributions to add their own installer logo, and Debian can just use the code from CVS and get pure GPL.

And +1 to use Seven for installation. Looks great.

I think catch's proposed solution in #47 is the right way to go. Even with that approach, it should be possible to offer two packaged version of Drupal, one with and one without the logo, so everyone is happy. I don't yet have an understanding of the level of effort this solution would require, but, assuming it is manageable, we should move in that direction.

From a UX perspective, Drupal.org would default to the version with the logo. The important part here is to make completely GPL'ed version, using just Druplicon, available to those who would prefer it, with the understanding that this issue is of concern for only a segment of our audience who would be savvy enough to choose and download the alternate.

+1 to Catch's solution and +1 to using Seven for the installer.

I think that works for me, too, though Dries of course would have the final say. The only argument against it is the inconsistent user experience for "normal" end-users vs. power-users/developers, but the latter audience can take care of themselves, I think. :)

At any rate though, let's get the Seven theme in, since we all agree on that. ;)

I agree with catch in #47, since we already do this for the install.txt file.

Mozilla is taking the same approach. When you build Firefox from the source, there is no Firefox branding included. Even the Firefox name is absent.

So any D7 tarball downloadable from Drupal.org should display and use the new wordmark. But if you do a CVS update, you get the druplicon. :-)

+1 to catch's solution. I'd like to special-case the packager for Drupal anyway to create separate installation and update packages so we can ditch the annoying "copy default.settings.php to settings.php" step.

My +1 goes for catch's idea in #47, for what it's worth. Should this change be handled in a separate issue, given it's.. a different issue than what this one was for?

I wouldn't go as far as making 2 separate packages as proposed in #51, but otherwise, it would be silly to create an identity and then not be able to use it

+1 for Catch's suggestion in #47... though there are plenty of good suggestions in here, and I think its a storm in a teacup. Pleased to see Seven for installation though...

sorry, yoroy, one last thing: we need a separate issue for "when to expose wordmark and when druplicon in core": should druplicon be visible as a default logo in themes, can you see wordmark elsewhere too, not just installer etc.

Re the Seven in installer: looks great in general, it's just:

- #14 : top-align issues with Drupal wordmark and notification box
- I'd unify the proposed green checkbox gfx and our existing ugly checkbox http://cvs.drupal.org/viewvc.py/drupal/drupal/misc/watchdog-ok.png?view=... -- can you give a hand, Yoroy?

Great, we can't use our own logo in our own software! ;) Larry also asked me to take down the new Drupal logo from drupal.com until we figured out the license for the new logo. While I personally think that is a bit unnecessary, he felt very strict about it. While I disagree, I want to respect him (and the law) so I'm trying to come up with a temporary new logo for use on drupal.com as soon as possible, and use that until we sorted out the license issues around the new logo. If it looks nice, we could also temporary use the temporary logo in the installer. I'm comfortable with releasing the temporary logo as GPL.

Use the current logo on drupal.org

I updated this patch.

i suggest creating a gpl wordmark and placing it in /misc/wordmark.png (based on the druplicon),
and then having the packaging script replace that with the registered wordmark.

This means we are always displaying the same image, and all the weird logistics of which image to display is handled at the packaging layer.

Good patch, but needs work. CSS issues. Pictures attached.

What about "Drupal tm" string with decent CSS (font-family: helvetica, arial; weight: bold; color: #color-of-wordmark; size:to-get-the-same-size-as-wordmark) as a fallback, not Druplicon?

kika: the reason i am voting for an image that gets replaced , is that we don't need to use a conditional for wherever we use it.

we can just use misc/branding.png , and it will always work.

tagging for d7ux , we need somebody with design skills (css / graphics)

@63: browser, version and OS please

ups, didn't mean to crosspost :(

Holy crap, the new installer looks slick :) Even with wordmark now...

I got one nitpick: at the second screen, the links "install drupal in english" and "Learn how to install Drupal in other languages" don't really invite for klicking. They should be more centered, have more distance from each other, and maybe have some arrow in front of them to indicate this is an action to take. Sure this would have to be the case for all links that are not buttons during install.

The styling of the progress bar should probably be tweaked to fit with the 7 theme as well, I can take a swing at that.

@BrightLoudNoise I agree that the progress bar should be changed. Now that jQuery UI is in core, we should just adopt it's implementation. However, this might be best as a follow up issue as the change is also needed for file uploads and batch processes.

+1 for #73's suggestion to stick progress bars in a follow up issue.

posted this about the actual wording on very first page - http://drupal.org/node/420358#comment-1982792 -

seems to me relevant here as well. not sure if the two issues should melt into 1 issue about installation look and language

patch worked fine (apart from css issues already mentioned) on Safari 4.0.3 on Leopard (the warm weather one ;-) )

@istos: let me assure you, you don't want to melt issues together :) The trick is to make each issue as specific as possible so that both the goal and what to critique is clear. Downside is you can't really work on the big picture within the issue queue. We definitely need to do that for the installer again soon. Wording changes can be done after code freeze, so don't expect too much attention for it in these last few days before the freeze. Yet, I also responded to #420358: Write clear install profile descriptions :-)

@68: Mac OS X, Firefox 3.5

@63.
1. can't seem to recreate this
3. this is due to a rounding bug in FF: the container is 1.5em, the bar is 1em + 0.5em border-bottom, which adds up, but if u zoom once, it'll appear fixed...
-> http://ejohn.org/blog/sub-pixel-problems-in-css/

should we account for this rounding bug and set the border to 0.6em and overflow:hidden on the container?

FYI: for any noob like me who wants to test this patch:

Images are in #14 http://drupal.org/files/issues/install-update-images.zip above
- Put wordmark image in the misc folder
- and the 2 others, task-check.png and task-item.png in themes/seven/images folder

I made a video of this installation process for those who are curious but cannot apply patches.
http://vimeo.com/6561926

Looks v good to me. It makes sense that you can see "your theme" because it doesn't exist yet, you're only installing. I think it's like a blank slate, looks professional, and the checks are informative and helpful.

This isn't listed as "needs usability review" but I'd like to include this patch for upcoming usability tests. The overall look/feel would be best to be complete from the start.

subscribe

@78, it appears that I cannot reproduce the problem either. Interesting.

@69, tagged for UX review

+1 for Seven as install profile

this looks really nice!

now for D8 we need a theme setting page during the installer ;)

This worked for me, and looked great.

got some fuzz and a bunch of offsets, rerolled to current HEAD

that 1 test will prolly still fail though

attached patch also changes the test so it doesn't look for minelli anymore

What say you testbot?

it seems there is still the wordmark in there, could we get some clarification (possibly in another issue) weither we can use it here under terms of the trademark policy?

the use of the official Drupal logo is covered by this trademark policy, the use of the Drupal icon (druplicon) is not.

http://drupal.com/trademark

- I don't think I can do binary patches, so if someone could attach the images that would be great.

- Does that mean we can delete a few files from Gardens; i.e. the maintenance template?

I reviewed this and it's basically rtbc. It needs lots of CSS, and some copy-writing love but that's postfreezish.

There's one change we need to make on reroll here and that is to *not* add the new wordmark, keep it GPL and make the current css/html output default to druplicon.png, already present in /misc

I tried to add that to the patch but I had problems with this patch format too.

These are the follow-ups:
- #605710: Decide on if and if so, how to implement the Drupal wordmark in core
- #605948: Improve the installer screen sequence's theming

Tagging as something to focus on during UX freeze. Would love to see this patch in!

> Does that mean we can delete a few files from Gardens

Is it Drupal-Dries or Acquia-Dries talking? ;)

What needs to happen for this to get committed? I can spend some time getting it ready to go if I know what to work on.

@cweagans See #91 and some CSS cleanup perhaps.

+1
Yeah! I want this. It drives me nuts that Garland pops up out of nowhere during upgrades. And well, install. And too much.
YES Seven. And or/the active theme (which I believe we can do with overrides.)

(this is just a cheerleading comment.)

kinda waiting on #575294: Add reset.css through drupal_add_css() instead of through the .info file to go in first

attached a simple reroll without the binaries

Tested, it worked - removed the logo, which prevented it from going RTBC. So RTOTHEBC!

+++ themes/seven/maintenance-page.tpl.php
@@ -0,0 +1,46 @@
+        <img id="drupal-wordmark" src="misc/wordmark.png" />

s/drupal-wordmark/branding-logo/

s/wordmark.png/branding-logo.png/

I'm on crack. Are you, too?

I don't understand. Pointing to non-existing images is ok? Rerolled with a src="misc/druplicon.png" and a changed id "branding-logo"

Looks good. Is this still eligible for commit in Drupal 7?

Yes it is!

+1

c'mon DriesChick.

whoah, I just did a simple reroll without the binaries for the images, I didn't change the reference to any of those images. But looks like yoroy got em \o/

+++ themes/seven/maintenance-page.tpl.php
@@ -0,0 +1,46 @@
+        <img id="branding-logo" src="misc/druplicon.png" />

This is not what has been discussed above? We do not want the packaging script to replace druplicon.png...

This review is powered by Dreditor.

Sorry, my fault.

ehh, yup.

So I'm a little confused. Do I basically need to copy misc/druplicon.png to misc/branding-logo.png when I commit this? Otherwise people are going to get 404s in their Apache logs right off the bat...

+++ themes/seven/maintenance-page.tpl.php
@@ -0,0 +1,46 @@
+        <img id="branding-logo" src="misc/wordmark.png" />

@webchick: Yes, if the patch would use that filename (which it should, as discussed above).

I'm on crack. Are you, too?

Ok.

Please change that line according to #102, and then this is good to go.

Oke, fixed it

Since this is the common maintenance mode theme template, we cannot hard-code this logo path.

Instead, we want to massage and use the existing $logo variable.

Fixed that condition.

Additionally, I'm starting to question whether we need that conditional stuff at all.

Seven doesn't contain a logo.png. The packaging script can copy one in. And that will be displayed.

Also, if you want to have a custom branding of the Drupal installer, then I can only guess that you'll want to use a different theme for the installer anyway? Do we approach this whole idea from the right perspective?

Final note: I'd expect this to work in the following way:

; $Id: default.info,v 1.8 2009/11/10 17:27:54 webchick Exp $
name = Drupal
description = Create a Drupal site with the most commonly used features pre-installed.
...
theme = seven

i.e. it is the responsibility of the installation profile to provide a installation theme, and Drupal defaults to Seven, if none was specified.

However, that doesn't really work, because you can choose the installation profile during installation. bleh. :P

Allowing developers to specify per-install profile the theme to use would be a new feature, and would thus be D8 material.

This issue has gone off the rail a few times, but it continues to be about *replacing* Minelli with Seven during maintenance mode, and we should keep it to that.

Removed the conditional override (in favor of themes/seven/logo.png) and fixed the tests.

If sun's approach works, I'd like to use it. Much better to re-use existing theme settings than hard-code stuff.

However, we need to test:

1. Does the normal Seven admin theme get messed up when a logo is used?

2. If you place the wordmark image in... themes/seven/logo.png maybe? (please verify location) does it in fact show up during installation?

tested #121 and after copying misc/druplicon.png over to themes/seven/logo.png it popped up above the task list as expected

using an image wider than 200px would make it stick out of it's container to the right which would cause a horizontal scrollbar for people viewing on a browser with a window width of 770px (800x600 users)

after getting trough the installer and clicking around a bit in the admin sections, I did not encounter the logo again, as it isn't printed in seven's page.tpl.php which, I think, is what we were gunning for, right?

Otherwise people are going to get 404s in their Apache logs right off the bat...

actually no, I don't think people can ever get a 404 during the install as all calls seem to get redirected to install.php, instead they will get a 302 found which will contain the markup that is output by install.php, which can obviously not be rendered as an image, but I don't think this is even remotely related to this issue :)

Did the same as seutje in #123

without logo.png in seven's folder:

with logo.png in seven's folder:

it just looks really nice:

Excellent. :)

COMMITTED TO HEAD!

Note that I did this without copying the Druplicon to Seven's logo.png, so it ends up looking like yoroy's first screenshot (http://img.skitch.com/20091119-mrgsyufrnd397ckau25jgqsjji.png). If we decide we do want Druplicon branding from CVS I can copy that in.

Oh, actually, I think I misunderstood. So I did copy misc/druplicon.png to themes/seven/logo.png and now you see Druplicon there.

So that leaves #605710: Decide on if and if so, how to implement the Drupal wordmark in core for the wordmark swappage issue.

And finally, I had forgotten to commit the checkbox/arrow images, and those are now in CVS too.

WHEW!

Ok, I think that's everything now. :)

Hm, Gábor already mentioned it several times in this issue... there is no reason why this patch should have changed the maintenance theme. The maintenance theme is intended to be displayed to end users, so it needs to still be Minnelli by default.

Also, in the process of making that change:

     // For a regular user, the fact that the site is in maintenance mode means
     // we expect the theme callback system to be bypassed entirely.
     $this->drupalGet('menu-test/theme-callback/use-admin-theme');
-    $this->assertRaw('minnelli/minnelli.css', t("The maintenance theme's CSS appears on the page."));
+    $this->assertRaw('seven/style.css', t("The maintenance theme's CSS appears on the page."));

This "fix" has the effect of making that test entirely pointless and not actually test anything :)

The attached patch reverts those changes so that we go back to using Minnelli as the maintenance theme (but continue to use Seven for installation and updates).

Makes sense. (NIH)

+++ includes/theme.maintenance.inc	19 Nov 2009 04:58:26 -0000
@@ -11,8 +11,8 @@
  * Seven is always used for the initial install and update operations. In
- * other cases, "settings.php" must have a "maintenance_theme" key set for the
- * $conf variable in order to change the maintenance theme.
+ * other cases, Minnelli is used, but this can be overridden by setting a
+ * "maintenance_theme" key in the $conf variable in settings.php.

I really wonder why we cannot expose this setting to the theme administration screen...? @webchick: Could that be still accepted? It's just a new form element; everything else already exists.

I'm on crack. Are you, too?

I agree. It's not a new feature, and it's definitely a UX improvement (try installing http://drupal.org/project/offline if you don't know enough PHP to edit your settings.php).

(Minnelli, btw, is on it's way out the door, so actually it would be Garland that would be used in a patch like the one attached to comment 128 #632030: Merge Garland and Minnelli into one theme )

-1 ,000

I disagree strongly about making Minnelli/Garland the default theme for maintenance. This means that while a site is being upgraded, or is broken, or is otherwise being worked on, a completely new look shows up — a design that most people will be seeing for the first time. I don't want a client's site to be taken over by a whole new look while in maintenance mode.

Gabor wasn't advocating for Garland/Minnelli to show up, he was advocating for the site-specific theme to be used by default:

@kika: I think he meant Garland, since we'd not display maintenance pages with that. But not sure all maintenance pages should use Seven. What happens when you database is down? It's more likely you want your site specific theme to kick in. Not that many sites think about theming that page.

It makes more sense for either the site-specific theme to be used, or for Seven to be used. The sudden appearance of Garland will be an utter mystery to most people, especially users who have accounts to login and are used to seeing Seven while adding/editing content. If that group sees Garland, they will think "What in the world just happened? My site just totally broke!"

I agree with Sun that having a theme settings to switch the maintenance default to the currently active theme (or another theme) makes a lot of sense, and would be used by a lot of people. That sounds like a new issue, needing a new thread.

Thanks for clearing that up jensimmons. Very much agree, too. Using Minelli is a lot more random and unexpected than using either the default front end theme or Seven.

No way. Now you are getting into the "presumptions" area.

1) We want to revert the default maintenance theme to Minnelli, because that is a bug introduced by this issue.

2) We want to add a maintenance theme selector (next to the administration theme selector) to make this configuration easier. That's just a new form element, nothing else. Doable within minutes. In the hope that webchick agrees, please create a separate issue for that and link to it here.

3) Usage of Seven as hard-coded installation/update theme is a very poor limitation, which I really don't like, because I hate Seven theme's poor design and styling. The first experience for new Drupal users is now a ugly theme that really misses everything to make up a compelling user experience. Furthermore, I do not really understand why we are forcing it for update.php - which ultimately means that I cannot even hide and ignore this ugly monster on my sites. That is totally unacceptable for me.

Let's not overcomplicate things. Garland is still Drupal's default theme, therefore Minnelli (or "fixed width Garland" if Minnelli goes away, but that hasn't happened yet) should still be the default theme that users see when the site is in maintenance mode. Both are configurable, and obviously most site administrators who switch away from Garland might also want to switch away from Minnelli, but the default behavior that Drupal provides needs to make sense out of the box.

Having the maintenance theme configurable via the UI seems to make sense, but not only is it a separate issue, it is also complicated by the fact that anything you configure via the UI won't apply when the database is down (the other situation where the maintenance theme is used). So unless you put the variable in settings.php, you'll get a mismatch between those two situations.

So basically, if (a) that issue gets resolved, and (b) Minnelli goes away, I agree the correct code here would be something like this:

    $custom_theme = variable_get('maintenance_theme', variable_get('theme_default', 'garland'));

But neither of those has anything to do with this issue.

Ah, crosspost... but yeah, similar thoughts to what @sun said. See the attached screenshot for what Seven looks like in maintenance mode - you do not want end users of your site seeing that :)

Obviously that screen could be improved a bit, but it really goes against the intention of what Seven was designed for. (Frankly, Seven was designed to mostly only appear in an overlay, as far as I can tell.)

Ok, stand corrected, default front end theme it is. (And the screenshot in #135 looks fabulous, actually :-)

Well, this discussion could become one about which is uglier — Garland or Seven. I like Seven, and think it's is a great improvement. We could improve Seven's maintenance page, and make it more interesting / better looking than it is now, if that would help.

Meanwhile I stand by my above comment #131. I still think making Garland/Minnelli the maintenance theme is a bad idea for UX reasons, as well as any aesthetic ones. It's true that Garland is still the default theme, but once an admin switches away from Garland to something else, then Garland has been un-chosen. I don't see why Garland should "magically" show up when the site goes down. This will confuse people. I disagree that this change was a "bug". I see it as an intentional change that improves UX.

But also, I think the best solution is for each site to use it's own site-specific theme, so any move making that super easy or the default is a good move.

Is there a reason why maintenance mode is not just set to the enabled theme by default? That seems like the best solution — just always make it the theme that is being used for the front-end of the site.

Is there a reason why maintenance mode is not just set to the enabled theme by default?

I think the main reason for this is that sites are often put into maintenance during development or while something's being fixed, and you don't want to see a half-done theme serving up a maintenance page.

I agree with all Sun statements.

This is a bug showing Seven to end user when the site is in maintenance or when there is an error.

The installation and update theme (as well as the administration theme), or simply the Seven theme (install, update, admin) are visible only to the administrators, not the whole world. I don't see why the whole world should see the maintenance page using Seven (ugliness not counting).

As a matter of fact, the maintenance page must use the enabled theme. we want to show the same branding as the web site:

--> maintenance-page.tpl.php

But currently, since database access is not available on error pages, which uses the maintenance page template, we need to modify the settings.php file:

# 'maintenance_theme' => 'minnelli', // Leave the comma here.

This is why we need to move this setting up to the administrative part of Drupal 7, most probably on the Themes page.

So:

1. Let's fix the bug.
2. Let's open a new issue to move up the 'maintenance_theme' to the Themes page.

Ok, for now I've reverted the change to Seven as the maintenance theme (committed #128 to HEAD). While I get what Jen's saying, I think what she's really saying is that "it shouldn't magically change the theme to something else when I'm not looking," and I agree that a simple UI toggle for that is a UX improvement and not an API change, so could go in. I'm concerned though that this might not be as straight-forward as you think with database being down, etc. or we would've done it a long time ago. But anyway, that's for another issue to discuss. ;)

Marking this fixed.

I do agree that the proper thing to do is use the admin-selected default theme when the database is ON. We should fix that. If a theme doesn't have a proper maintenance-page.tpl.php, its a bug with the theme, IMO.

However, when the database is OFF, Drupal has to use whatever is hard-coded in the settings.php file. So what should the hard-coded default be? Garland, Stark, or Seven are our only choices.

• Stark is completely un-styled. It borders on unreadable and cluttered since it has no proper spacing in the form of margins and padding. But that is by design since Stark just uses core's CSS and we don't want all our themes to have to un-do any "proper spacing"; it is up to the design of the theme and not up to core on what is proper spacing.
• Garland/Minnelli has Drupal branding all over it and a mega-blue background. Its a bug to arbitrarily introduce the incorrect branding on a site if its in maintenance mode.

• This is a bug showing Seven to end user when the site is in maintenance or when there is an error.

  [...] the Seven theme (install, update, admin) is visible only to the administrators, not the whole world.

  Yes, but when the database is off, we only have the 3 choices. IMO, the plain-looking Seven maintenance theme is much preferable to Garland and Stark.

  

So let's:

1. make the db-active maintenance page default to use the admin-selected default theme.
2. leave Seven as the default db-offline maintenance page.
3. fix up any problems (like missing logo, site name, etc.) from Seven's maintenance page.

No. Seven was and is not intended to be used as a public-facing theme. The site-under-maintenance page is visible to anyone.

Why so strict? You may not like it, but of the three options available, Seven is the most generic and friendly looking and thus much preferable over either Stark or Garland/Minelli which both will break UX much more severly.

Let's just show this:
http://photos1.blogger.com/x/blogger/2783/325/1600/939474/seehere.blogsp...

Seriously, it's funny and involves a kitten, and probably contains better markup than all the aforementioned options.

#biggerfishtofry.

Can we let this one go? We're talking about the page that shows up when your database server is down. It's not *that* big a deal is it?

-J

Talking about this in IRC, rightsprocket had a good idea. How about if we get rid of the brown-grey stripe that's very Seveny, and let the maintenance page be all white. Something very simple. Let it be driven by Seven, but not look like Seven (easy enough to do with maintenance.tpl.php and some CSS).

Then if/when more complex sites want to use their own theme as the maintenance theme, they can (preferably from a theme setting.) But meanwhile, the default maintenance page is clean and simple. Doesn't look like Garland, or like Seven.

I agree that Seven wasn't intended to be a user-facing theme, but its site-under-maintenance page could also be themed so it looks better.

Do one of the designers advocating for switching this want to try their hand at it in a separate issue? Right now, as far as I'm concerned, this issue is fixed: Seven is now used for installation / updates. Any further changes should be debated elsewhere. This poor issue needs to die. :)

lol @ jacobsingh.

And the issue to clean-up Seven's maintenance page: #637414: Clean up Seven theme's maintenance page for use as db-offline default

I agree with johnAlbin and jennsimmons: Seven is far better than our current maintenance pages and provides a very elegant declaration for the default under site construction pages. a bigger issue is when the db cannot be accessed: when we cannot have any say of what the site-maintenance page should look like because our voice is silenced. defaulting to garland or a blue (and now, branded and well known) interface creates a panic ... esp for clients who don't know anything about their system...

i like Seven :)

Talked with johnvsc in IRC. Moving the discussion to #637414: Clean up Seven theme's maintenance page for use as db-offline default

@128: oops, my bad, guess I should take a better look at how the testing stuff works :x

I've also posted an initial patch at #421062: Maintenance theme is ugly and cannot be altered for providing a UI for selecting the maintenance theme.

@128: oops, my bad, guess I should take a better look at how the testing stuff works :x

No worries, this one was particularly tricky to see - the only reason I noticed the problem is because I am the person who wrote the test :) The issue was that the test was checking that when the site is in maintenance mode, a logged-in administrator and logged-out user see different themes (the site admin sees the theme they would normally see on an admin page, while the logged-out user sees the maintenance theme). So if the same theme is used for both those things, the test doesn't really tell you a gigantic amount. (But I guess it still does tell you a little bit, come to think of it...)

Hm...

Seven can also be put off as admin theme just as garland can be put off as a site theme.
Me and my friends have started putting off Seven not only because the gray slate color is totally mismatch with the Garland blue or any other color but also for other reasons like it clashes with Admin bar module.

Thus if myself or my any user will see Seven out of no where while in db-off mode, they will indeed be surprised. The default that many actual and professional sites do is, under such circumstances, keep on the site logo or big icon and a short statement that they will be back soon, avoiding any theme whatsoever.

Small regression: #641810: "Select installation profile" page looks weird with custom profiles