Op zaterdag 07 januari 2006 11:01, schreef Piotr Krukowiecki:

Maybe leave that to theme? Let theme decide if it wants to use drupal.css or not. A hook_theme_css() or something. This way, if site is configured to allow users to change themes, some themes can use drupal.css and some can choose not to use it.

This is already possible. A theme can override any CSS file that was added with the correct Drupal APIs. In core all css is added this way. Bèr

Karoly Negyesi wrote:

-- (Voice of Neil Drumm) What's under admin/ is admin.

And if you don't like what is under /admin, change it with menus and/or paths. -- Neil Drumm http://delocalizedham.com/

On Sat, 07 Jan 2006 14:27:52 +0100, Bèr Kessels <ber@webschuur.com> wrote:

Op zaterdag 07 januari 2006 11:22, schreef Karoly Negyesi:

...

Let me sum up this topic, in form of a conversation:

-- We do not need drupal.css, let's move most of it to core themes. -- But then other themes need to theme admin which is pretty hard. -- Then let's make a separate admin theme. -- We do not really know what's admin and what's not. -- (Voice of Neil Drumm) What's under admin/ is admin.

That's my memory of this chat from all last year. We stopped here. Let's   try to continue from here and not re-debate the former parts.

Very well put, Karoly!

Starting from there, I will add my (voice): what is admin will very much depend on your site. We cannot find any good default. We will probably not even be able to find good defaults to

Yes, but Drumm's solution is to simply move under admin what's admin on your site, if I understood it correctly.

On 7-Jan-06, at 5:43 AM, Bèr Kessels wrote:

Op zaterdag 07 januari 2006 14:39, schreef Karoly Negyesi:

...

Yes, but Drumm's solution is to simply move under admin what's admin on your site, if I understood it correctly.

out of the tom of my head, a few links to prove this is not always true: /node/xxx/edit is admin when i'm maintaining a personal blog, but its not when editing my forum post. /user/xxx/edit is admiin when I'm moderator and decide to block some users, its not when I want to change my avatar. /node/add/blog is admin when I am running my personal blog. It is not when I add my blog to this huge community blog. /handbook/howto_add_a_user is admin for a corporate site that I wrote, where they have some dedicated online docs.

I am sure, that we can come up with a hundred more of these, if we start searching. Not all of these can be moved under /admin.

Nothing that you mentioned would I consider "admin" -- none of those are areas where you are working with "administrating" the site in any way (node editing is editing content). And if you want to have different themes, then go for it. For an out of the box Drupal site, what is admin is what is under the admin/ menu hierarchy. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com

The problem I have isn't really with what is admin or not, or making admin sections look special... The problem I'm normally confronted with is pages in the admin/* that nearly unusable due to a theme. So I'm not really concerned with what is or isn't the admin section... I just want my log section/access control page to be readable/usable. Is there any particular reason you client thinks he needs a different theme for when he's editing a node... seems pretty silly to me, especially considering its the same form that is used to add a node. On Sun, 2006-01-08 at 11:39 +0100, Bèr Kessels wrote:

Op zaterdag 07 januari 2006 22:40, schreef Boris Mann:

...

Nothing that you mentioned would I consider "admin" -- none of those are areas where you are working with "administrating" the site in any way (node editing is editing content). And if you want to have different themes, then go for it.

My client considers adding or editing his content as administrating his site. Wordpress considers editing "nodes" as administrating. So, maybe Drupal does not consider this as administration, but /that/ is the whole point of this thing: Drupal cannot say for sure what is considered an administration page and what not. It depends on how a users uses his site. Its a per site thing to define what is considered "administrating that site".

Ber

On Monday 09 January 2006 02:28 pm, Bèr Kessels wrote:

...

seems pretty silly to me, especially considering its the same form that is used to add a node.

Not silly. just look at wordpress! There are hundreds of potential sites where editing, adding, moderating content is considered *administration*. And believe it or not, the node forms are often even harder to theme right, then the admin/ pages, esp on fancy layouts.

The problem is that in current Drupal, editing a node is part of the "node realm", which is centered around the node's URL. (node/5/view, node/5/edit, node/5/blah, etc.) Having the theme change just when you click a tab like that, and only for one of those tabs, is horrid from a UI perspective. Now, if there were an option to disable the edit local task on nodes and then an improved admin/content page to track down and edit all nodes that way, now you're cooking. Admin-themed stuff should be under /admin/. If something should be admin-themed but isn't under /admin/, the solution is to move it under admin, not have the admin theme pop up all kinds of weird places. :-) And that will vary site by site. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

On 1/9/06, Bèr Kessels <ber@webschuur.com> wrote:

Not silly. just look at wordpress! There are hundreds of potential sites where editing, adding, moderating content is considered *administration*. And believe it or not, the node forms are often even harder to theme right, then the admin/ pages, esp on fancy layouts.

Actually, this is one of Drupal's biggest strengths. I have a client that had Wordpress but to manage content you had to go into admin, find the article, then edit it. But it is *far* easier to traverse your site logged in, goto the page you want and edit it. 10 to 1, it is far easier for your client to find the page they want to edit on the website visually then it is to search for it. Now, however, should it be themed differently? Entirely different, but I do agree, admin/ is really the admin area. When you edit a node, I think it can be more visually appealing and have some sort of 'admin border' or whatever you may have it, to make things stand out a bit more. As to what, well as we all say, code is gold, so I'll have something soon. ted

On Saturday 07 January 2006 07:27 am, Bèr Kessels wrote:

Starting from there, I will add my (voice): what is admin will very much depend on your site. We cannot find any good default. We will probably not even be able to find good defaults to define "profiles". So I am preparing sections.module for 4.7. Sections.module, allows you to define sections that get another theme. I also posted before, that I am still struggling with the admin part: whether to ship it by default with sections.module or whether to document how to get an admin theme defined with it.

Ship with admin/* defined as a section, its theme set to empty or Bluemarine or <default>, and disabled. That way it does nothing when you just install it, but once you go look at the config page you see "Oh, so THAT'S how I make an admin theme, cool!" -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

Karoly Negyesi wrote:

Let me sum up this topic, in form of a conversation:

-- We do not need drupal.css, let's move most of it to core themes. -- But then other themes need to theme admin which is pretty hard. -- Then let's make a separate admin theme. -- We do not really know what's admin and what's not. -- (Voice of Neil Drumm) What's under admin/ is admin.

That's my memory of this chat from all last year. We stopped here. Let's try to continue from here and not re-debate the former parts. I know we love debate. But there is a Drupal 4.7 which needs love. No, you do not need to code. It's enough if you review a patch a day. Not more! If every subscriber of this list would just do a good review http://drupal.org/patch/review of just one patch each day then we would have Drupal 4.7 by now.

Here's a semi-related idea. Would we lose anything by creating a .CSS file dynamically? Instead of adding @import drupal.css/ @import theme/style.css; @import module/that.css What if we did this: First, as mentioned, break drupal.css up as said. There seems to be a lot of reason to do this. Second, add a CSS registry. Not just a function to add it to the header, but instead, register every CSS file we want to give to the user. Themes could, if they like, tell the registry that they completely override any of the core Drupal files, or heck, even module files. Third, when a request for drupal.css comes in, Drupal handles it. First, it looks in the cache. If it finds a cache, it sends it. It should skip as much of the Drupal load as possible in order to be as fast an efficient as we can make it; be very early in the Drupal run system. Fourth, under the themes admin, we could put a list of all registered .css files, and checkboxes as to whether to include them. That way if a user modifies his or her theme to override global .css files that the theme didn't know about it, just check a box and that global .css theme is no longer included. It should also included a button to clear and/or disable the .CSS cache so that users doing development don't get screwed by it. What problems does this address? 1) You can, if you like, get rid of drupal.css and anything it imports with the UI. 2) You eliminate having large numbers of .CSS files @imported. From the user perspective, there is just one. 3) Modifying this scheme could allow .JS libraries to be created and registered. I'll leave how that would work as an exercise for the reader, since I haven't thought it out at all. 4) It's very easy to break everything up into logical groupings. What problems does this cause? 1) More resources used when getting the .CSS; I think this is only true if using the non-cached .CSS file. If the .CSS file is cached, this call should be caught very early, with the absolute minimum of code loaded. 2) A more complex scheme could offer more ways for the system to malfunction. 3) Someone would actually have to write the system. 4) Lag in cacheing could cause CSS changes not to appear until something invalidated the cache. I don't see this as a huge issue; with a toggle for development, that puts the onus on the developer for remembering to clear the cache. When modules or themes are saved, the cache can automatically be invalidated (and renewed!) right there.