Admin Side Theming! (r3149)

jakob · 2009-03-21 15:27:31

Wet wrote:

I was contemplating about the separation of logged-out (i.e. global) vs. logged-in (i.e. private) themes but didn’t think it would gain much popularity.

The active theme for a certain user can only be determined once she is logged in. On the log-in screen we’d therefore have to show a “global” theme which applies to all users – we don’t see who’s in front of the screen.

Maybe we’re talking at cross-purposes :-) I had assumed the pluggable_ui was a site-wide modification that applies to all users, not that five different users on the same site can have five different looks to their back-end. Your second reply suggests that users can change the settings on a per-user basis.

I can see lots of use case scenarios where an admin would like to adapt the back-end as a whole, e.g. for branding purposes or to remove potentially confusing or unused/irrelevant elements, and I can see use cases where some users should not have access to editing all parts of a site (e.g. only their own articles, only certain tabs, only certain sections, i.e. a per privilige or per role settings – one can then assign these to users), but I’m not sure why different individual users would like to choose their back-end look. I’d be forever switching it off/installing only one theme as it just means more to support and document and more potential for other plugins to break.

Regarding the login screen: if one is going to be able to theme the admin, in my view one should be able to theme the login page with it.

…

Thanks for the register tab example: if I remember rightly, that’s the standard way, so that means all existing plugins that play by the rules can be made the startup tab.

Redbot wrote:

I understand what you are asking for but I wonder if it is really necessary to to this at server-side level (when the html is generated) given that this is quite easily doable (and I do it an a regular basis) with a few lines of Jquery.

It depends how much do you change “with a few lines of jquery”. Changes like ied_hide_in_admin are I agree no problem. Something like this would require wholesale wipeout and rewrite elsewhere repaint jobs (kind of what aro_myadmin does). That’s pretty inefficient when it happens for every single page refresh.
For that screenshot, I have a drop-in replacement for the write tab that is essentially the existing write tab source code in a different order. Basically I just moved around whole chunks of codes and then made sure that all the right ‘div’s and ‘if’s were correctly closed. Robert’s latest changes modularise some of the back end into these chunks which is great. All that’s missing is the ability to reorder them and not limit them to the container div’s they are currently tied to.

Wet wrote:

There are vast herds of dragons (plugins) which rely on the current markup.

Agreed, but if this classic theme is always there, they won’t break. Only where other themes are in use and that risk is already present when a new theme changes elements of the backend. That’s something for the theme author and plugin authors. As plugin users begin to use your new callback hooks more rather than the DOM-node structure, the plugins will work with other themes too.

redbot · 2009-03-21 19:57:31

jakob wrote:

It depends how much do you change “with a few lines of jquery”. Changes like ied_hide_in_admin are I agree no problem. Something like this would require wholesale wipeout and rewrite elsewhere repaint jobs (kind of what aro_myadmin does). That’s pretty inefficient when it happens for every single page refresh.

Hmm… maybe you are right. While the write tab you linked to can certainly be achieved with jquery (not really just a few lines but neither hundreds) it will be probably ‘pretty inefficient when it happens for every single page refresh’. So yes, at the end I agree with your request.

wet · 2009-03-22 07:53:59

jakob wrote:

I had assumed the pluggable_ui was a site-wide modification that applies to all users, not that five different users on the same site can have five different looks to their back-end. Your second reply suggests that users can change the settings on a per-user basis.

pluggable_ui() is an application entry point for plugins, and does what a plugin author intends, may be little or much. This is not an end-user feature. Authors of admin themes can decide to use it in any imaginable extent, or just implement a little custom CSS. That’s also up to the admin theme authors.

Bloke · 2009-03-22 09:25:43

wet

Thanks for the js hint, I missed that. I was looking for a dedicated ‘.js’ loading mechanism in the code. D’oh!

I was contemplating about the separation of logged-out (i.e. global) vs. logged-in (i.e. private) themes but didn’t think it would gain much popularity.

That’s the reason my patch used a cookie to store the current theme. So:

The admin of the site sets the global theme and everyone sees that on login
If there is some mechanism to allow individuals to change their theme, they can do so and a cookie stores their pref
When they logout they still see the theme they chose because the cookie is checked first
If the theme is deleted for some reason by an admin, the cookie theme would not exist next time they try to log in so they would see the global default theme instead

Regarding per-priv/per-user themes I built the plugin to handle these cases:

An admin-configured site-wide new look. No ability to alter theme by any user. Good for corporate sites or a client with a few users, for strengthening their ‘brand’
An admin-configured list of available themes could be set up (some subset of the entire installed theme list). If this per-user themeing is turned on by the admin, a new tab appears under the Admin tab for lower-priv users to be able to choose between these themes. A cookie stores their pref (equally, the new per-priv txp_prefs could be used, with the caveat that they’d see the global theme on the login page). Good for an extension to the corporate model to allow colour-based changes to suit people, or to offer a hi-vis version for hard-of-sight people in the company, etc
A single admin-configured theme per user role level. Again, a cookie tracks which one was last chosen by a user so they see the one they expect on the login page. If the theme is deleted or altered in any way by an admin, the cookie becomes ‘stale’ (as in case #2) and they would see the global theme instead until they logged in at which time the new theme would show up and the cookie would be repopulated. Good for magazine multi-contributor sites where a copy editor has a different workflow to a freelancer or to a staff writer, thus the themes could reflect their workflow by moving parts of the UI to prominence to suit
A combination of (2) and (3) was planned where an admin could configure a set of themes available to each priv level and mark one as ‘preferred’. This is the one that a user ot that priv level sees upon first logging in, but they are permitted to switch to alternates (e.g. if they need a hi-vis version). I never got round to doing this

Now, I would argue that a plugin is the right place for all this paraphernalia, but in order to work the core would have to check for the existence of a cookie first and try to find that theme — of course, dropping back to global/classic if not found. Once something like this (or an equivalent) is in place, many plugins can be built to allow people to choose how they administer themes to their users and the core gracefully handles such requests.

thebombsite · 2009-03-22 15:39:35

Yes, Textgarden is ready and waiting to accept admin themes. At the moment it only has one. I wonder whose that is? Anyway if people want themes added all it takes is an email containing download and demo page links and a full-page screen-shot. Couldn’t be easier. ;)

mrdale · 2009-03-22 16:29:28

Wow this is fantastic, I use phwiw’s facelift v2 on all my sites, which requires hacking head_lib.php and replacing some images and the css file… Every svn update was a bit of a chore to say the least.

This looks like a great solution but I need an explaination…

So In layman’s (pixel-pusher) terms, I can use a php file to replace the functions that contain markup in the head library? or could I dynamically replace the entire head library non-destructively?

Claps hands!

jstubbs · 2009-03-22 21:26:28

Mmm. Downloaded latest SVN version via Transmit, but I don’t see the theme changer in Admin > Preferences > Advanced? Using MAMP on localhost, don’t know if that has something to do with it..

BTW, what is the preferred SVN URL? I always get problems with the app I use (SCPlugin) and this URL: svn checkout http://textpattern.googlecode.com/svn/development/4.0 dev

Bloke · 2009-03-22 21:35:33

jstubbs wrote:

I don’t see the theme changer in Admin > Preferences > Advanced?

Does this help?

thebombsite · 2009-03-22 23:02:40

Finally managed to get “A Bit Blue” working with this. :)

the_ghost · 2009-03-22 23:22:38

When the community wll select site/portal for sharing admin themes?
I hope, admin-theming will add more txp-lovers to our Planet-of-Txp ♥

wet · 2009-03-23 02:29:30

mrdale wrote:

So In layman’s (pixel-pusher) terms, I can use a php file to replace the functions that contain markup in the head library? or could I dynamically replace the entire head library non-destructively?

Yes, you could. Dig into the Remora theme as an instance of how to change the navigation menu’s markup and include custom JS.

Though, in the most simple case when your custom theme involves only styling and custom images, you don’t even need to write a single line of code:

1. Choose a name for your theme. For illustration purposes, I’ll use foobar.

2. Create a new folder: /textpattern/theme/foobar/

3. Create a new file in this folder named foobar.php:

<?php
if (!defined('txpinterface')) die('txpinterface is undefined.');
theme::based_on('classic');
class foobar_theme extends classic_theme{}
?>

4. Create a file named textpattern.css in this folder and apply all your custom styles. You might choose to build your modifications on the ‘classic’ groundwork CSS, or start with a blank file – whatever seems more appropriate:

/* 
Foobar Theme for Textpattern CMS
*/

@import url("../classic/textpattern.css");

body{font-size: 7px;}

5. Done.

mrdale · 2009-03-23 02:52:11

Thanks wet!

Actually the Facelift changes the navigation to use a more semantic nested unordered list structure, so in the case it’d require markup to change.

I’ll dig in. check it out.

Textpattern CMS

Textpattern CMS support forum

#25 2009-03-21 15:27:31

Re: Admin Side Theming! (r3149)

#26 2009-03-21 19:57:31

Re: Admin Side Theming! (r3149)

#27 2009-03-22 07:53:59

Re: Admin Side Theming! (r3149)

#28 2009-03-22 09:25:43

Re: Admin Side Theming! (r3149)

#29 2009-03-22 15:39:35

Re: Admin Side Theming! (r3149)

#30 2009-03-22 16:29:28

Re: Admin Side Theming! (r3149)

#31 2009-03-22 21:26:28

Re: Admin Side Theming! (r3149)

#32 2009-03-22 21:35:33

Re: Admin Side Theming! (r3149)

#33 2009-03-22 23:02:40

Re: Admin Side Theming! (r3149)

#34 2009-03-22 23:22:38

Re: Admin Side Theming! (r3149)

#35 2009-03-23 02:29:30

Re: Admin Side Theming! (r3149)

#36 2009-03-23 02:52:11

Re: Admin Side Theming! (r3149)

Board footer