[drupal-devel] Admin theme?
http://www.nascencetech.com/newvillageboy/2005/05/28/the-mumbo-jumbo- of-blogging/ "I’m using Drupal for a couple of community sites I run and it’s not really by choice. It is by far the most feature-laden OpenSource content management engine there is. It’s also a BITCH to use and customize. A couple of really weird user interface issues bug me to hell too. What in the name of HADES made them decide that a theme just had to affect the editing interface too? You got any idea how fuckin’ troublesome it is to create a CSS file for all the editing widgets and forms that nobody except me sees? I’m still stuck using the downloaded themes for all my Drupal sites ‘cos I simply can’t be bothered with creating a whole new theme for it." -- Dries Buytaert :: http://www.buytaert.net/
On 28/05/05, Dries Buytaert <dries@buytaert.net> wrote:
http://www.nascencetech.com/newvillageboy/2005/05/28/the-mumbo-jumbo- of-blogging/
Has anyone contacted him asking him to be more specific about any of the problems he's found? If he's had so much trouble using it, perhaps he can explain what parts were causing that trouble. -- David Carrington
Op 28-mei-2005, om 16:53 heeft David Carrington het volgende geschreven:
On 28/05/05, Dries Buytaert <dries@buytaert.net> wrote:
http://www.nascencetech.com/newvillageboy/2005/05/28/the-mumbo-jumbo- of-blogging/
Has anyone contacted him asking him to be more specific about any of the problems he's found? If he's had so much trouble using it, perhaps he can explain what parts were causing that trouble.
-- David Carrington
I don't think that would be very hard to guess.. - Theming drupal withouth knowledge of PHP has been improved since a little while and is available in HEAD now after PHPTemplate hit the trunk; - I do think that without any knowledge of PHP, you can't theme drupal. I tried to convince *some* people to use wrapper functions inside theme_* functions so they are easier to customize, but that had a negative aura around itself.. I'm still not convinced that this would be a bad thing todo; And, afterwards I'm not very curious about what he thinks about drupal anymore after the words he already spread here. If the guy needs help, he can always ask but in a gentle way of talking. Which is imo not like this! So if he can talk without words/sentences as 'bitch', 'fuckin' and the populair way of writing I am always willing to help someone. But this get's me in the wrong mood.. The community does good things andn keep improving drupal, which is really nice. This kind of e-mails are humiliating for all the people who do their best to keep improving drupal and work on it a lot. The way of writing makes me angry, and sick.. For my final words I'm lowering myself to the level of the original writer: "The e-mail is full of shit, without any real solutions of what could be improved. I don't know who the hell this guy may be, but he probebly think he's God or something. I truly ask myself why people are writing such e-mails.. I cannot see what the thinking behind it is, or could be. IMO these kind of e-mail could/should be ignored..." As said above, this is it.. PERIOD When the e-mail is rewritten on a normal way, and does have some improvements which we should work on it will be a whole other story.. But this is not normal.. Just my 0.02 cents.. (I don't expect you guys to feel the same, but I just want to point this out) Your sincerely, Stefan
Dries Buytaert schreef:
http://www.nascencetech.com/newvillageboy/2005/05/28/the-mumbo-jumbo- of-blogging/
"I’m using Drupal for a couple of community sites I run and it’s not really by choice. It is by far the most feature-laden OpenSource content management engine there is. It’s also a BITCH to use and customize. A couple of really weird user interface issues bug me to hell too. What in the name of HADES made them decide that a theme just had to affect the editing interface too? You got any idea how fuckin’ troublesome it is to create a CSS file for all the editing widgets and forms that nobody except me sees? I’m still stuck using the downloaded themes for all my Drupal sites ‘cos I simply can’t be bothered with creating a whole new theme for it."
I'm still in the "no admin theme" camp. Consider this: how popular would Wikipedia be if their edit interface worked and looked completely different from the regular site? People who look for a blogging tool automatically want a separate admin interface, but this is only a small part of our audience. Steven Wittens
On 5/28/05, Steven Wittens <steven@acko.net> wrote:
I'm still in the "no admin theme" camp. Consider this: how popular would Wikipedia be if their edit interface worked and looked completely different from the regular site?
People who look for a blogging tool automatically want a separate admin interface, but this is only a small part of our audience.
It's not secret that I'm in the separate admin UI camp. But I can also see how the integrated option makes sense in some cases. And so I've suggested many times that we *enable* the option of theming the admin section more easily -- and that Drupal develop some guidelines as to what belongs in the admin section of a web CMS and what doesn't. The delineation I've suggested is to consider what features should be community facing and which shouldn't. For example, throttle is not something the community should care about, but an admin obviously needs to use that tool. The editing UI is *not* an admin function, it's a community maintenance feature; the UI should be the same as the rest of the site. In my adminbar, I precisely mapped out which features belong to the admins and which don't. It's far from complete, but could serve as the basis of discussion on what is admin and what is not. The blogger's argument about theming is well understood. That WordPress has hundreds of high quality themes illustrates that there is something intrinsically easier about theming WordPress. I would venture that it's not only a less complicated application, but it also removes the difficulty of theming the admin forms; and with the same stone, knocks out the documentation bird making it easier to document WP's many admin interfaces. Dries, there is a split in the community about this topic and none of us are wrong. But we need to know whether we should expend effort on this and if it's something that you would support. I'm of course in favor of it, but we need to stop debating it and make a decision one way or the other. Chris
Dries, there is a split in the community about this topic and none of us are wrong. But we need to know whether we should expend effort on this and if it's something that you would support. I'm of course in favor of it, but we need to stop debating it and make a decision one way or the other.
There is nothing to decide between. Until someone actually *makes* an alternative theme to what we have today, this is all talk. Using sections.module, you could easily swap in a theme for the q=admin path. I suggest someone implement such a theme, and then we can see how valuable it might be. my .02
On Mon, 2005-05-30 at 21:23 -0400, Moshe Weitzman wrote:
Dries, there is a split in the community about this topic and none of us are wrong. But we need to know whether we should expend effort on this and if it's something that you would support. I'm of course in favor of it, but we need to stop debating it and make a decision one way or the other.
There is nothing to decide between. Until someone actually *makes* an alternative theme to what we have today, this is all talk.
Using sections.module, you could easily swap in a theme for the q=admin path. I suggest someone implement such a theme, and then we can see how valuable it might be. my .02
Why not just start with the bluemarine theme. It works well and will work on most basic browsers. My .02 cents worth. At this rate we even get a whole dollar ;-) Gordon.
On 5/30/05, Moshe Weitzman <weitzman@tejasa.com> wrote:
There is nothing to decide between. Until someone actually *makes* an alternative theme to what we have today, this is all talk.
Well, we're all right, more or less. And that's the ironic split I'm talking about. I do, however, think that there are *absolute* admin features -- like throttle or user administration that deserve a separate, consistent theme. However, across Drupal it's unclear why any given menu item or screen should or should not be put into the admin section. In so ways I grudgingly agree with Ber. Different sites have different needs and for some, edit is admin, for others, it is not. So, to brute force this to a conclusion, and to answer Moshe's challenge, all the CivicSpace themes in the next release will have the same admin UI. This will include: * Groundswell * Democratica * SpreadSpread (was SpreadFirefox) * Lincoln's Revenge I spend 90% of my time theming the admin sections of sites and it's a waste of my time when 2% of users actually see it. We can greatly improve the overall user experience with Drupal if we focus on consistency and simplicity and while maintaining flexibility. So that's that. We'll see how this goes. ;-] Chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01 Jun 2005, at 1:31 AM, Chris Messina wrote:
So, to brute force this to a conclusion, and to answer Moshe's challenge, all the CivicSpace themes in the next release will have the same admin UI. This will include: I am really looking forward to seeing your work, as i trust you have put a lot of thought into this. When can we expect code ?
I spend 90% of my time theming the admin sections of sites and it's a waste of my time when 2% of users actually see it. That is exactly what i want to stop from happening. We need to lower the barriers to themeing drupal.
I was one of the people who spearheaded the effort to get the themes consistent between the admin section and the site originally, But my interest in that was primarily to standardise on the (then new) menu system which was only being used for admin pages. I personally like the themes integrated, but the proliferation of simple, elegant fixed width themes, with utterly broken admin sections has led me to believe that the integrated admin sections should be the exception rather than the rule. Now we can argue about the semantics of this for days, but I would like to see what Chris has put together, and then we can tear that apart like a pack of rabid wolves.. i mean.. give constructive criticism, and work from there. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCnQmWgegMqdGlkasRAtV6AJ9hIkIBasZwAeSliYEfq5TpxRM1iACg1yIQ wHga/jiC8OgELZfLQVGpL+M= =G04E -----END PGP SIGNATURE-----
Adrian Rossouw wrote:
proliferation of simple, elegant fixed width themes 'proliferation' is a bit strong. A handful of themes have been ported over from blog tools, only the fact that we had so few themes before (which had relatively few graphics and weren't quite as pretty) makes it seem like 'proliferation'.
But Drupal isn't fundamentally for blogs, it's for community sites (although it can be adapted).
with utterly broken admin sections Which means that they were badly ported to Drupal, or badly constructed - not usually for lack of skill but because it is hard to theme a large piece of software like Drupal consistently.
It seems to me that people are suggesting fitting Drupal around a certain type of theme, rather than having the themes fit to Drupal as it should be.
I would like to see what Chris has put together Indeed, but I'm betting it will introduce a truck load of UI problems and increase admin/editor confusion. Also it will allow people to create very pretty front ends whilst ignoring the admin/editing UI, inevitably that will begin to suffer.
There are things it be good to (optionally) have happen on admin, editing and for that matter any page with wide content - blocks with irrelevant content out of the way, irrelevant menu options collapsing - anything which allows people to focus on the task they are doing. What we need IMNSHO are adaptable themes, not a separate admin theme. -- adrinux (aka Adrian Simmons) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@gmail.com> AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com
Adrian Simmons wrote:
What we need IMNSHO are adaptable themes, not a separate admin theme.
Adaptable to what? Lost in this discussion is a notion of what is a minimum acceptable screen size for using Drupal. Statistics I've collected over the past month say that 800x600 screen size amounts to 11% of my traffic. Other recent surveys (Google on "screen resolution statistics") put the 8x6 crowd at as much as 29%. Several of my elderly friends have computers that are *capable* of displaying higher resolutions. What they don't have are *eyes* that can read fine print, so they choose to use 800x600. One of these elderly friends is actually a chief editor and contributor for one of the Drupal sites that I've created (www.mn-leon.org). So rendering on small screens --even in the "admin" sections-- is actually a significant issue for me. If Drupal fails to render properly on this screen size, then I suggest it is not the theme that is failing to be adaptable, but Drupal itself. Worth noting: The front page of drupal.org renders passably on 8x6 (Firefox/Mac), but has some unintended artifacts. Most pages render OK, but the project pages are pretty bad. Chris Messina wrote:
I spend 90% of my time theming the admin sections of sites and it's a waste of my time when 2% of users actually see it. We can greatly improve the overall user experience with Drupal if we focus on consistency and simplicity and while maintaining flexibility. ...
Amen to that... As the author of one of the themes that is broken in this way (greenthing), I made a conscious choice to focus my efforts on the end-user visible portions of my site and live with some bad rendering in the "admin" sections (which, on most of my sites, at least, aren't visible to anyone but me). I can control the *content* of my site so that it displays nicely in a given width. I can't control the admin section of the site so easily. If you continue down Adrian's road of insisting that themes be "adaptable" to arbitrarily wide content, then I predict you will continue to (a) continue to make choices that make Drupal unappealing to the small-screen crowd, and (b) severly limit the number of people willing to make the effort to create new themes for Drupal. -Eric -- Eric Scouten Photography | www.ericscouten.com (Drupal powered!) Fine art prints from the world of nature
Worth noting: The front page of drupal.org renders passably on 8x6 (Firefox/Mac), but has some unintended artifacts. Most pages render OK, but the project pages are pretty bad.
Unfortunately HTML and CSS does not really offer much in the way of adapting to multiple resolutions... save for using Javascript to switch stylesheets. But if you are referring to the way that on Drupal.org the green download box covers the 3 screenshots in the orange box at 800x600, that is intentional. Resolutions in between 800x600 and 1024x768 are very, very rare, and this solution keeps the (important) download box visible even at 800x600. Steven Wittens
On Thu, 02 Jun 2005 06:19:20 +0200, Steven Wittens <steven@acko.net> wrote:
Worth noting: The front page of drupal.org renders passably on 8x6 (Firefox/Mac), but has some unintended artifacts. Most pages render OK, but the project pages are pretty bad.
Unfortunately HTML and CSS does not really offer much in the way of adapting to multiple resolutions... save for using Javascript to switch stylesheets.
The CSS 3 Media Queries specification[1] should help here. Browser support at this point is sparse, though. [1] http://www.w3.org/TR/css3-mediaqueries/ -- Tim Altman
On 6/1/05, Adrian Simmons <adrinux@gmail.com> wrote:
I would like to see what Chris has put together Indeed, but I'm betting it will introduce a truck load of UI problems and increase admin/editor confusion. Also it will allow people to create very pretty front ends whilst ignoring the admin/editing UI, inevitably that will begin to suffer.
<rant class="vehement"> With due deference, Adrian, I am fed up with this argument being used. It's simply a falicy and a defensive way to look at the problem (as opposed to a proactive, solution-seeking approach). I've been given this line since before DrupalCon and I've seen very little real progress on improvements to the Hummer-sized admin UI that comes with Drupal even though it *is* currently integrated. If you really believe this, please substantiate it, for I've only seen evidence to the contrary. For one, I would be much more interested in improving the Drupal admin UI if more variables in the admin section were set in stone and I knew what I had to accommodate. That we don't have consistent human interface guidelines for how admin settings and pages are designed, created, located and referenced is a core aspect of this problem. Any given themer should not have to resort to redesigning user interfaces in Drupal just to make them usable. Themeable functions should be exploited as a last resort or when you require a degree of customization that most sites don't need out of the box. Themeable functions should not have to be used to fix usability issues (and yes, I will be submitting patches against core for the many problems I've unearthed -- you might consider my latest theme work one giant patch). Whatever the case, the admin UI will simply not be neglected if we separate out the front-facing styles. In fact, I believe that more people will appropriate skillsets will flock to both opportunities since designing backend UI vs frontend UI require wholly different ways of approaching the design problems. So long as the admin UI stays integrated with the rest of the site, the quality of Drupal themes will continue to suffer and usability will improve at a less-than-optimal rate. </rant>
What we need IMNSHO are adaptable themes, not a separate admin theme.
Provide good defaults and exploit the cascade model of overriding those defaults if you so desire or have the time/money/effort/energy to do so. That is the model that I'm adopting as it seems to have worked well in other areas of Drupal. As a point of clarification: I'm not angry, but I am decidedly in favor of moving Drupal forward, as we all are. This is one issue that I feel very strongly about and one that I am backing up with code. I also just gave up coffee and switched to green tea so I might be a little imbalanced today. ;) Chris
Let us please end this endless debate, and *do* something please. Who volunteers for a working (does not have to be perfect, the first shot) admin theme? I will then modify the sections module to work with that theme> We will then have an example and can look onward from there. I know there are loads of pros and cons for a non-core solution, but at least it IS a solution, while endless debates are not. ;) Debates are good, yet they must clearly be goal driven, i see this debate leading no-where at all, which is a pity, because that woul be a missed chance to at least try to improve Drupal. Ber
On Saturday 04 June 2005 09:40, Bèr Kessels wrote:
Let us please end this endless debate, and *do* something please.
Who volunteers for a working (does not have to be perfect, the first shot) admin theme? I will then modify the sections module to work with that theme> We will then have an example and can look onward from there.
The occy theme already has an admin section. Occy has themed it and I created a very crude check in page.tpl.php whether we are in admin. Regards NK
On Jun 4, 2005, at 12:40 AM, Bèr Kessels wrote:
Let us please end this endless debate, and *do* something please.
http://demo.civicspacelabs.org/home It's a testing site in the middle of upgrading with 60 modules. I'll take advice gladly, but you've been warned it's a testing site. Send me a link to your user profile and I'll upgrade you to admin privileges so you can see Chris's admin theme. Cheers, Kieran
I just put Chris's latest theme, with separate administration theming, and four styles to accompany his template up on: http://demo.civicspacelabs.org Create an account and mail me your user profile, so that I can give you admin access. Cheers, Kieran
On 28-May-05, at 2:03 PM, Chris Messina wrote:
On 5/28/05, Steven Wittens <steven@acko.net> wrote:
I'm still in the "no admin theme" camp. Consider this: how popular would Wikipedia be if their edit interface worked and looked completely different from the regular site?
People who look for a blogging tool automatically want a separate admin interface, but this is only a small part of our audience.
It's not secret that I'm in the separate admin UI camp. But I can also see how the integrated option makes sense in some cases. And so I've suggested many times that we *enable* the option of theming the admin section more easily -- and that Drupal develop some guidelines as to what belongs in the admin section of a web CMS and what doesn't.
Err...have you looked at the "occy" theme? He just does some regex inside his phptemplate and spits out a different theme if it's anything in "admin". There is nothing stopping you from doing this with any theme.... And reading the rest of this thread, there is also sections.module. Chris, unless there is something really difficult that we're missing, I don't think there *is* a split -- anyone can make a separate admin theme right now, with no hacks. Just a thought: I think the logical extension of no context switching for admin sections is in-page AJAX to do direct editing of title/ content/etc. (except for the actual configuration sections of admin). -- Boris Mann http://www.bmannconsulting.com
On 31 May 2005, at 05:39, Boris Mann wrote:
Chris, unless there is something really difficult that we're missing, I don't think there *is* a split -- anyone can make a separate admin theme right now, with no hacks.
Can we update one core theme so that it differentiates between admin and non-admin pages (based on the URL scheme)? I think that should be this discussion's action point. -- Dries Buytaert :: http://www.buytaert.net/
Op dinsdag 31 mei 2005 06:54, schreef Dries Buytaert:
On 31 May 2005, at 05:39, Boris Mann wrote:
Chris, unless there is something really difficult that we're missing, I don't think there *is* a split -- anyone can make a separate admin theme right now, with no hacks.
Can we update one core theme so that it differentiates between admin and non-admin pages (based on the URL scheme)? I think that should be this discussion's action point.
please no! that is exactly the non-flexibility we do not not want. Hardoded regexpes etc are not an option IMO. Here is my plan * someone needs to update sections module to work with the HEAD blocks path API * someone needs to code a style or theme for our admin areas * we need to put copy-pastable sets of regexpes that a user can paste in the sections config. Note the "someone". I have no time for this ;) But this is an easy route, yet it will provide the flexibility. for as Gerhard pointed out /my/ admin may not be /yours/. Think of /node/add/forum vs node/add/blog, admin/taxonomy, etc. a lot of paths that we will never agree upon, simply because every drupal site will use them different. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On 31-May-05, at 12:07 AM, Bèr Kessels wrote:
Op dinsdag 31 mei 2005 06:54, schreef Dries Buytaert:
On 31 May 2005, at 05:39, Boris Mann wrote:
Chris, unless there is something really difficult that we're missing, I don't think there *is* a split -- anyone can make a separate admin theme right now, with no hacks.
Can we update one core theme so that it differentiates between admin and non-admin pages (based on the URL scheme)? I think that should be this discussion's action point.
please no!
that is exactly the non-flexibility we do not not want. Hardoded regexpes etc are not an option IMO.
Ber -- 1) sections is not core 2) this can be accomplished today, by any themer (including choosing the regexes), at the layer of the template This is a theme layer issue, and as such is up to individual theme designers whether or not to provide separate admin styling. If there are things that can be done to make this easier (which might very well include documentation in the theme guide to download and use sections.module) then great. I think the discussion point stands -- Chris, we'd love for you (or anyone else) to have a go at this with one of the core themes. Look at the occy theme to see how it's done there. -- Boris Mann http://www.bmannconsulting.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31 May 2005, at 9:24 AM, Boris Mann wrote:
This is a theme layer issue, and as such is up to individual theme designers whether or not to provide separate admin styling. If there are things that can be done to make this easier (which might very well include documentation in the theme guide to download and use sections.module) then great. I don't believe it should be. I believe we need sensible defaults, that can be changed to suit the designer / site owner.
The simple fact of the matter is a large amount of the themes we have currently are UNUSABLE, and the simple fact of the matter is that these themes can not all be changed to work correctly. Would we rather have more themes, and lower the barrier of entry for new themers, or would we rather argue about semantics and personal feelings regarding seperately styled admin sections. What I would like to see, is we have a 'admin' => true added to the menu entries, and an 'is admin screen' checkbox in the menu.module that allows people to modify it if absolutely neccesary ( for individual pages ). The admin setting will then use themes/drupaldefault/admin, IF NO themes/mytheme/admin style is found. This means the designer can style it however he wants. Themes that want to theme the admin section, can do so .. and can even have differently styled admin sections. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCnEgcgegMqdGlkasRAg7XAJ40yhJANNVmqxc7JQOsuXEskI81wQCgtlFi lOsdxUhFQF9lh7NP5lL3tls= =CJoz -----END PGP SIGNATURE-----
Adrian Rossouw wrote:
The simple fact of the matter is a large amount of the themes we have currently are UNUSABLE, and the simple fact of the matter is that these themes can not all be changed to work correctly. Would we rather have more themes, and lower the barrier of entry for new themers, or would we rather argue about semantics and personal feelings regarding seperately styled admin sections.
I am in agreement with Adrian. I don't really care if the admin areas are themed differently or the same as the rest of the site. I just want the admin areas to be usuable. In most themes, they are difficult or impossible to use -- tables regularly blow up the page, admin links are behind menus where they cannot be clicked, etc. I already have to have an "admin" theme: That is, I have to install, enable and configure 2 themes for my site. The first is the styled theme I want all visitors to see. The second is the one where the admins can actually do something because they cannot in the first theme which is unusable in the admin sections. -- Chris Johnson
I am in agreement with Adrian. I don't really care if the admin areas are themed differently or the same as the rest of the site. I just want the admin areas to be usuable. In most themes, they are difficult or impossible to use -- tables regularly blow up the page, admin links are behind menus where they cannot be clicked, etc.
But this has nothing to do with whether a page is an admin page, but whether it has wide content. What about the "recent posts" page, it can have a wide table too. Is "Edit my account" an admin page? Etc etc. If you need to solve the problem of accomodating special content, why not preg for "<fieldset" and "<table" in the content, and use an alternate stylesheet then? Steven
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31 May 2005, at 5:03 PM, Steven Wittens wrote:
I am in agreement with Adrian. I don't really care if the admin areas are themed differently or the same as the rest of the site. I just want the admin areas to be usuable. In most themes, they are difficult or impossible to use -- tables regularly blow up the page, admin links are behind menus where they cannot be clicked, etc. If you need to solve the problem of accomodating special content, why not preg for "<fieldset" and "<table" in the content, and use an alternate stylesheet then?
Do we really need to have the average themer learn how regex works to be able to theme drupal properly ? What other pages do you think cause the same problem ? - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCnMjcgegMqdGlkasRAqvdAKCkg4o6hsLvf9mWZWXqdZ7jXJkbbgCfR2pC uUn0v8xXRcZKKt3IzOLP168= =Y/CY -----END PGP SIGNATURE-----
I fully agree with all of you when you say "sections module is not core, thus wont solve the problem" I know that any non-core module should never be put forward as "the" solution, but in this case i a confident it /is/ the solution. Why? We really (as in : no doubt about it) have a problem in definning what is admin and what is not. A quick investigation on my 8 public drupal sites gave me the figures: * 4 use anything below /admin as admin * 4 use one or more pages below /admin as public pages * 6 use */edit pages as admin * 2 use */edit as admin only those are just eight. I am 100% confident that we will never find a good set of of *default* regexps for a n admin theme to be able to act as admin theme. Thus i tried to find a way to * help users for certain sorts of sited to degfine an admin theme for their case * still have flexibility. I simply do not believe we will ever get to an agreement on what is admin and what is not. And i think we should actually never reach that agreement, because then we will have to cut on flexibility. Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On Wed, 1 Jun 2005, Karoly Negyesi wrote:
those are just eight. I am 100% confident that we will never find a good set of of *default* regexps for a n admin theme to be able to act as admin theme.
My solution: store a flag in the menu structure stating whether the page is admin or not.
-- This will only increase the size of the menu structure that we need to cache. Cheers, Gerhard
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01 Jun 2005, at 12:30 PM, Gerhard Killesreiter wrote:
This will only increase the size of the menu structure that we need to cache. I see that as a worthwhile trade-off.
- -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCnak3gegMqdGlkasRAgljAJ9eb6RN2PQYU5k1vm1x1UWzVARqugCfQ4zd zS0EbQ1U5sQkbb48a8MRIfA= =v1Rr -----END PGP SIGNATURE-----
On Wed, 1 Jun 2005, Adrian Rossouw wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01 Jun 2005, at 12:30 PM, Gerhard Killesreiter wrote:
This will only increase the size of the menu structure that we need to cache.
I see that as a worthwhile trade-off.
We'd need to investigate how much the cache would grow. Since the menu cache is per user and the admin theme path setting would be per site, it does not make any sense to store this setting in the menu cache from a systematic point of view. You should rather store it in a variable on its own. Cheers, Gerhard
Gerhard Killesreiter wrote:
You should rather store it in a variable on its own. Wouldn't this then be a variable that all modules and themes could use to adapt to the task the user is performing? That would seem like a good thing.
-- adrinux (aka Adrian Simmons) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@gmail.com> AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com
On 5/31/05, Bèr Kessels <berdrupal@tiscali.be> wrote:
I know that any non-core module should never be put forward as "the" solution, but in this case i a confident it /is/ the solution.
I have to agree with Ber here. It just needs to be stabilised and improved. There's nothing preventing it from becoming a core module, right? Grtz, Breyten :)
Op woensdag 01 juni 2005 11:11, schreef Breyten Ernsting:
On 5/31/05, Bèr Kessels <berdrupal@tiscali.be> wrote:
I know that any non-core module should never be put forward as "the" solution, but in this case i a confident it /is/ the solution.
I have to agree with Ber here. It just needs to be stabilised and improved. There's nothing preventing it from becoming a core module, right?
In theory not, but i guess the module in itself is a bit OTT for core. I would think that if using it for admin themes is a success, we can think about incoroporating it in the theme.inc. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On 31 May 2005, at 09:07, Bèr Kessels wrote:
Can we update one core theme so that it differentiates between admin and non-admin pages (based on the URL scheme)? I think that should be this discussion's action point.
please no!
that is exactly the non-flexibility we do not not want. Hardoded regexpes etc are not an option IMO.
Here is my plan * someone needs to update sections module to work with the HEAD blocks path API * someone needs to code a style or theme for our admin areas * we need to put copy-pastable sets of regexpes that a user can paste in the sections config.
Ber, you are trying to fix a different problem; i.e. the lack of flexibility. We are trying to improve the out-of-the-box experience with this. The section module is a "power tool", although I reckon that it could involve into something fancy and easy to use. -- Dries Buytaert :: http://www.buytaert.net/
On 5/31/05, Bèr Kessels <berdrupal@tiscali.be> wrote:
that is exactly the non-flexibility we do not not want. Hardoded regexpes etc are not an option IMO.
Here is my plan * someone needs to update sections module to work with the HEAD blocks path API
I will put some time into updating sections later this week or over the weekend.
* someone needs to code a style or theme for our admin areas * we need to put copy-pastable sets of regexpes that a user can paste in the sections config.
Note the "someone". I have no time for this ;) But this is an easy route, yet it will provide the flexibility. for as Gerhard pointed out /my/ admin may not be /yours/. Think of /node/add/forum vs node/add/blog, admin/taxonomy, etc. a lot of paths that we will never agree upon, simply because every drupal site will use them different.
I completely agree with this. The idea of some themer deciding what pages should and should not be considered "admin" based upon his/her own whim really bothers me. I want to be able to define which pages are admin on my site. A blogger's site may only render "edit" pages for the admin, so using an admin theme for those pages might be appropriate. However, this is terribly inappropriate for a community site with blogs and a forum. Whether or not to use an admin theme and on which pages the admin theme should be used should be a decision made by the site admin and absolutely no one else. Sane defaults could be provided on a global or per-theme basis, but should ALWAYS be overridable easily. Sorry to be so wordy, but I feel very strongly about this. :-) Tom
On Saturday 28 May 2005 09:44, Dries Buytaert wrote:
"I’m using Drupal for a couple of community sites I run and it’s not really by choice.
[SNARK MODE ON] (and aimed at the commentor, not at Dries...) Yes it is. You downloaded it. You installed it. You could have either downloaded or purchased one of the other countless content managers that are out there just waiting to recruit you as a loyal user. [SNARK MODE OFF]
It is by far the most feature-laden OpenSource content management engine there is. It’s also a BITCH to use and customize.
A nuclear-powered submarine is more complex to operate than a rowboat, too. Do you need to cross a pond, or win a naval battle in open waters? Right tool, right job.
A couple of really weird user interface issues bug me to hell too. What in the name of HADES made them decide that a theme just had to affect the editing interface too?
Couldn't one achieve the desired result by simply installing and enabling one of the [several] very minimalistic themes on the site, then making that the default theme for the administrative account? Good security practice says the site admin should have a regular account anyway, for testing the site's features from the perspective of a regular user -- so set the admin account to the minimalist theme, and the regular account to the site default theme. Problem solved, and in the process, you give your users who need assistive technology (or who prefer Lynx or Charlotte browsers) a nice low-overhead way to access the site. [SNARK MODE ON] Don't get me wrong, I appreciate candid and frank feedback on my code. I just got a bug report today, in fact, for one of my modules, and I am glad of this because it means people are helping me to improve. But the report I got was very politely worded. If I got one like this, I think instead of thanking the person for helping the code get better, I'd be inclined to bluntly offer him a refund of the money he paid me for the module. >-( Or I might give him a one-word reply: "Patch?" [SNARK MODE OFF] Flies....honey....vinegar.... Apparently this person missed that lesson. ;-) Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
Guys Whether we like it or not, perception is everything. The original article gives Drupal high marks as the most feature laden CMS. His style and language are vulgar for sure, but as I pointed elsewhere, some people never get over high school style talk. Many don't differentiate between chat, email, blogs, and use the same trash talk everywhere. The rest of the comments do not stem from a vacuum though. Let us deal with the real issues (not the style) he raises (somehow) rather than be in denial, and go in ad hominem mode. (For the record: I love Drupal, and have been using it for almost two years. I initially wanted something to run my semi-abandoned web sites, and now it has become a passion on its own.) __________________ http://www.nascencetech.com/newvillageboy/2005/05/28/the-mumbo-jumbo-of-blog... "I'm using Drupal for a couple of community sites I run and it's not really by choice. It is by far the most feature-laden OpenSource content management engine there is. It's also a BITCH to use and customize. A couple of really weird user interface issues bug me to hell too. What in the name of HADES made them decide that a theme just had to affect the editing interface too? You got any idea how fuckin' troublesome it is to create a CSS file for all the editing widgets and forms that nobody except me sees? I'm still stuck using the downloaded themes for all my Drupal sites 'cos I simply can't be bothered with creating a whole new theme for it."
Being new to Drupal there are a lot of suggestions that I have on the admin interface. If anyone cares to listen.
On Sun, 29 May 2005, Peter Apockotos wrote:
Being new to Drupal there are a lot of suggestions that I have on the admin interface. If anyone cares to listen.
Besides that there is not actual admin interface, I guess we'd like to hear your opinion as well as other's. Please make nice graphics mockups to go with them (if applicable). Cheers, Gerhard
On May 30, 2005, at 1:34 AM, Gerhard Killesreiter wrote:
On Sun, 29 May 2005, Peter Apockotos wrote:
Being new to Drupal there are a lot of suggestions that I have on the admin interface. If anyone cares to listen.
Besides that there is not actual admin interface, I guess we'd like to hear your opinion as well as other's. Please make nice graphics mockups to go with them (if applicable).
Cheers, Gerhard
I will try to work on this as much as possible this week. I have back surgery on the 2nd. I will setup a website with my suggestions and post the address soon.
Yes! Op maandag 30 mei 2005 05:17, schreef Peter Apockotos:
Being new to Drupal there are a lot of suggestions that I have on the admin interface. If anyone cares to listen.
We are always listening. Even to shouting and ranting people so it seems :). But keep in mind that only suggestions dont really get us anywhere. It is one thing t /know/ what must be improved, but its another thing to /improve/ it. we are very aware of flaws in usability of our software, that is right, but few have the time or resources to sit down and come with actual solution in terms of code, documentation, or hired specialists. So feel free to commit your ideas, please! But do keep in mind that mockup, a screenshot, a html page etc with that will help us far more then: "i think you should organise the admin area better" Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On Sun, 29 May 2005, K B wrote:
Whether we like it or not, perception is everything. The original article gives Drupal high marks as the most feature laden CMS.
This actually worried me more than the rest of his article. First, I don't think "feature laden" is actually positive, second he does not seem to have a wide overview over the CMS world.
His style and language are vulgar for sure, but as I pointed elsewhere, some people never get over high school style talk. Many don't differentiate between chat, email, blogs, and use the same trash talk everywhere.
Right, we should not worry over such people. We should not even work them with the clue bat. Waste of time.
The rest of the comments do not stem from a vacuum though. Let us deal with the real issues (not the style) he raises (somehow) rather than be in denial, and go in ad hominem mode.
There is no issue, only perception. The "problem" with Drupal is that it is very modular and flexible. /Your/ admin function can be /my/ user feature. Thus, it is very hard to determine which pages are "admin" pages. There are a few pages which are more admin like than others of course. I would not mind if we'd modify Drupal to add "admin" CSS tags for such pages if it would stop the constant whining and bitching. One point to consider is: If you cannot use your regular theme for admin pages (because it is too graphics laden?) then what good is it for your usual pages? I am a site administrator at drupal.org and never found it a problem that bluebeach is used for both types of pages. I've recently set up a site using occy.theme and was rather surprised that it has some sort of an admin theme for URLs starting with "admin". I guess I can work with both. The suggestion by Scott to add an "admin" theme for the actual admin account and use a user acoount for everyday's work is also worth to consider. I am doing that at drupal.org. If you can add subdomains at will, you can also make admin.doma.in an alias to doma.in and have both accounts open in the same browser (Killes' Drupal Secrets #22). Cheers, Gerhard
On Monday 30 May 2005 01:33, Gerhard Killesreiter wrote:
If you can add subdomains at will, you can also make admin.doma.in an alias to doma.in and have both accounts open in the same browser (Killes' Drupal Secrets #22).
Ooooh, *that's* cool! Thanks for the tip! P.S. -- My post about the profane ranter was meant as dry humor, not to seriously suggest anyone working him over with a verbal baseball bat. I'm sorry if the humor didn't come through in the post. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
participants (22)
-
Adrian Rossouw -
Adrian Simmons -
Boris Mann -
Breyten Ernsting -
Bèr Kessels -
Chris Johnson -
Chris Messina -
David Carrington -
Dries Buytaert -
Eric Scouten -
Gerhard Killesreiter -
Gordon Heydon -
K B -
Karoly Negyesi -
Kieran Lal -
Moshe Weitzman -
Peter Apockotos -
Stefan Nagtegaal -
Steven Wittens -
Syscrusher -
Tim Altman -
Tom Dobes