[drupal-devel] Admin theme.

[Chris Messina]

On Sun, 27 Mar 2005 21:03:10 +0200, Steven Wittens <steven at acko.net> wrote:
> Adrian Rossouw schreef:
> 
> > On 27 Mar 2005, at 2:25 PM, Moshe Weitzman wrote:
> >
> >> perhaps disable all blocks beside navigation while in admin. that
> >> would guarantee that a 3 column site collapse into a 2, thus giving
> >> more breathing room ... i didn't attend that session so perhaps more
> >> sophisticated proposals were made.
> >
> > Certain themes like kubrick and co. are still completely unusable when
> > this happens.
> >
> > The idea is to get a clean consistent admin interface that works for
> > everyone, regardless of theme .. and then allow the designer to
> > override it with his own theme / look.. IF THEY KNOW WHAT THEY ARE DOING.
> 
> I thought we were going to leave this up to the themer, as it's mostly a
> theme issue. Really, CSS positioning issues appear on more than just the
> admin, so it's not an ideal solution.
> 
> I would default it to 'off' for most core themes, as they have a very
> usable admin section.
> 
> Steven Wittens
> 

This is really not the "wording" that I would advocate, although the
result is essentially the same as what you're going after.

Drupal should ship with a default /admin theme, which provides a
consistent backend UI for all Drupal installs. This should be part of
a new default theme, which has yet to be designed (I'm suggesting that
we replace Blue Marine as the default with something totally new and
much improved -- to set the bar for and motivate new themers).

This /admin theme can be overridden in individual themes if there is
an /admin directory provided which contains the appropriate styles,
etc. This means that Kubrick themes would use the default Drupal
/admin theme but other themes, notably ones shipped w/ Drupal could
provide their own /admin themes.

I wrote up a reply to the CiviCRM guys about some questions they had
w/r/t to remotely theming their application, which will eventually
ship with CivicSpace. The general idea is that we can extend the
/admin theme idea to other third-party components, so if your theme
comes with a /civicrm directory, you can override the defaults,
allowing Drupal distros to better customize the complete look and feel
of the package.

My reply:

> For this release it would mean we integrate with
> Drupal's themeing system and provide a user a choice
> between CiviCRM's stylesheet and Drupal's theme.

> If you want a seperate style sheet for the civiCRM output, you *could*
> include a separate sheet in the drupal theme - but you will have to make
> sure that there are no naming collisions with other element's classes or
> IDs.

This is actually a very interesting discussion that I can shed some
light on. It was decided at DrupalCon to rip out the site admin UI
from the community admin UI and make administering your site occur in
a visually isolated environment. There were a number of reasons for
this, but I'll speak more directly to the technical implementation
that CiviCRM can benefit from.

In particular, Drupal will now ship with a default admin theme. This
theme will be used for all pages generated in /admin (i.e.
/admin/block/) so that theme developers need not worry about the look
and feel of the admin area (since more and more themes, like the
ported Kubrick theme, don't deal with the wide tables of the admin
UI).

However, if a theme comes with an /admin directory then those styles
will override the default Drupal admin theme. The purpose of this is
to allow designers to control all the visual aspects of a site if they
desire, but makes it optional so that they can focus on the frontend
without worrying about mucking up the backend.

CiviCRM could follow a similar approach, where a default theme is
provided, but if a theme comes with a /civicrm directory, the selected
theme would override the defaults.

This would make it very easy for CivicSpace or any other CMS to apply
its own styles or themes to CiviCRM while making it possible for
CiviCRM to have its own identity when shipped independently.

Anyway, I thought that this would help move the discussion along. I'd
be interested to hear your thoughts, ideas, opinions or concerns about
this approach.

Chris