We have a nice new default theme, but our maintenance pages and installer still look quite simplistic. The attached patch changes two things:

  • Use Minnelli (fixed width) for the installer and update.php.
  • Show a list of tasks for install.php and update.php in the sidebar. This makes the process a little clearer. Note that the install tasks "Choose profile" and "Choose language" only show up if you have more than one profile resp. locale to avoid confusion.
  • Tweaked the styling of numbered lists in Garland for the maintenance pages.

Because Garland's page.tpl.php is quite complicated and relies on template.php, I created a cut-down maintenance.tpl.php which is used by theme_installer_page() and theme_maintenance_page().

See:
http://acko.net/dumpx/garland-maintenance.png

I also added a tiny extra image for the arrow, as Garland's own arrows were too light for indicating the active item.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Steven’s picture

FileSize
128 bytes

Image (goes into themes/garland/images).

Steven’s picture

FileSize
19.47 KB

Forgot to cvs add the maintenance.tpl.php file... now included.

dopry’s picture

+1... I like the maintenance template. Everyone wants their site to still look like their site when its down.
Didn't actually test patch, my dev installs are totally broken at the moment.

merlinofchaos’s picture

+1 on this! Need to do some testing, but have no time tonight.

Dries’s picture

Yes! Obvious +1. :)

Dries’s picture

I look at this patch in more detail. It looks great but there are two things that are somewhat awkward: it uses regex to clean up some HTML (yuck) and it relies on PHPTemplate. So even if you use Smarty as your template engine, you'll have to learn PHPTemplate to theme your maintenance page ...

I might be able to live with both, but it is probably worth pointing out.

webchick’s picture

Status: Needs review » Needs work
FileSize
55.22 KB

Fan-freaking-tastic! Here's a screenshot of the new installer for the more "visually-oriented" among us.

Some review, functionality-wise:
1. This broke localized installs...

+function install_find_locales() {
+  $locales = file_scan_directory('./profiles/' . $profilename, '\.po$', array('.', '..', 'CVS'), 0, FALSE);
+  array_unshift($locales, (object) array('name' => 'en'));
+  return $locales;
+}

$profilename is not in scope.

2. It was confusing that "Verify requirements" just magically showed up as a green checkbox without me having to do anything -- like the installer "skipped" a step, as opposed to the other screens which required manual intervention. Then again, I love the fact that our installer doesn't throw stupid screens at that you just have to click "Next" on. Maybe a drupal_set_message() (or like a little green box with the checkmark in it at the top of the DB page) when things check out ok just to let people know: "Requirements successfully verified."

3. When I got a "Drupal is already installed" message from having an existing database, suddenly those little things on the side vanished completely. That was a bit jarring. It would be better if they still all showed up, just as completed.

4. If it's easy to do, I'm wondering if the installer improvements and the theme improvements should be split into two separate patches.. they both get into their own issues (which theme engine to use vs. which steps to have along the side).

Steven’s picture

2. It was confusing that "Verify requirements" just magically showed up as a green checkbox without me having to do anything -- like the installer "skipped" a step, as opposed to the other screens which required manual intervention. Then again, I love the fact that our installer doesn't throw stupid screens at that you just have to click "Next" on. Maybe a drupal_set_message() (or like a little green box with the checkmark in it at the top of the DB page) when things check out ok just to let people know: "Requirements successfully verified."

Well this is the same as the "choose profile" stuff... is it more confusing to show all installation steps always, or only those you use? I'm not sure either. If I implement requirements the same way as the profile/locale select, then you'd only see "Verify requirements" if there were requirement problems that prevent you from installing Drupal.

3. When I got a "Drupal is already installed" message from having an existing database, suddenly those little things on the side vanished completely. That was a bit jarring. It would be better if they still all showed up, just as completed.

This makes more sense this way, as this screen can pop up at various stages in the installation process (including the very first hit to install.php). It does not belong in any particular stage of the installation. It is really just another maintenance page, like "db is down".

4. If it's easy to do, I'm wondering if the installer improvements and the theme improvements should be split into two separate patches.. they both get into their own issues (which theme engine to use vs. which steps to have along the side).

The installer usability improvements require a more complicated layout to work. I'm not going to waste time working on a CSS layout to match the old theme_maintenance_page() when we already have a 100% working theme sitting there, sorry.

Besides, nobody has complained about the way I themed that page. I think hardcoding the PHPTemplate here gives us the best of both worlds and makes perfect sense given that our maintenance theme is based on a PHPTemplate theme.

Steven’s picture

Dries: by the way, the maintenance theme is not themable at all, just like before. It is impossible to use Smarty or any other theme.

As for that regexp comment, sorry, but I'm really getting tired of this. Every single piece of code that uses a regular expression gets stamped with "ugly" lately. Get over it, please, or send complaints to /dev/null. I'm tired of hearing about this. $partial was part of the original code, and you could argue that my implementation of it is better than the hardcoded one before.

If anyone wants pretty maintenance pages, have a blast and work on the patch. I've lost my appetite for coding.

webchick’s picture

Sorry about re-posting the screenshot. Didn't see the one in the original post. Doh. :P

If I implement requirements the same way as the profile/locale select, then you'd only see "Verify requirements" if there were requirement problems that prevent you from installing Drupal.

Actually, that sounds like a great plan.

This makes more sense this way, as this screen can pop up at various stages in the installation process (including the very first hit to install.php). It does not belong in any particular stage of the installation. It is really just another maintenance page, like "db is down".

Fair enough.

The installer usability improvements require a more complicated layout to work. I'm not going to waste time working on a CSS layout to match the old theme_maintenance_page() when we already have a 100% working theme sitting there, sorry.

Hm. I only meant maybe get the "re-theme the installer/maintenance page" in first, then the step 1, step 2 stuff in the installer. Just cos the comments in the thread seemed to be about two completely different things about the same patch. If they're tied together too much, it's no big deal, I was just trying to help. :(

Still leaving code needs work because of the locale issue.

Steven’s picture

FileSize
17.33 KB

This issue is a perfect example of not many people actually willing to work on design-related patches :P.

Anyway. I fixed the locale bug and changed it so that the "select locale" only shows up if you have a profile with locales (because we don't know which profile a user is going to pick).

I've thought about the visibility of the "verify requirements" item, and I'm still not 100% sure. I think a message at the top would be a little too intrusive, especially because it would have to appear on every page after the check. This is a side effect of how the installer works: every request runs through the entire code until it hits a point where it requires user interaction. On the other hand, we still need to communicate to the user that requirements were met, so I think that's a good reason to keep the item on the left.

Also, if the user has a problem with requirements, he'd end up on that step in the install. If the requirement problem is fixed, then the next step should logically also show the requirement item on the left, with a check mark. But again, we have no way of remembering if the install was broken before or not, and I'd like to avoid setting up some complicated state choreography just for visibility. Let's keep it simple.

Tested and ready for core IMO. Don't forget the image from http://drupal.org/node/117018#comment-193067 .

Steven’s picture

Status: Needs work » Needs review
Steven’s picture

FileSize
19.53 KB

Argh, forgot to cvs add again. *grmbl*

Dries’s picture

I reviewed this patch, and discussed a couple of minor points with Steven in private. +1 to be committed. :-)

Steven’s picture

Status: Needs review » Fixed

Committed to HEAD.

Anonymous’s picture

Status: Fixed » Closed (fixed)