Admin Side Theming! (r3149)

PascalL · 2009-03-20 20:32:28

Woooot! Quite happy here!
Thank you developers!

wet · 2009-03-21 09:27:07

Bloke wrote:

permit .js files to be included in the theme which (from first glance) the built-in system does not (yet?)

allow forced global, per-user or per-group themes (which I’m not sure will actually work now the per-user txp_prefs are around — need to test it)

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.

Are we to expect an actual demand for such a feature?

jakob · 2009-03-21 09:56:27

allow forced global, per-user or per-group themes (which I’m not sure will actually work now the per-user txp_prefs are around — need to test it)

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. Are we to expect an actual demand for such a feature?

Robert, not quite sure what you mean by logged-out themes for the back-end. Surely when one’s logged out, the only part of the back-end one ever sees is the login box, the rest is the front-end, or have I missed something…

On a per-user-group (privs/roles), it would be useful to have some way of saying if_priv = xyz or if role = abc and show or not show certain information. At the moment, this is only possible for tabs.

I’ve been watching the svn developments with glee. I can see that one can replace certain chunks of the page with a custom display alternative. Would it be possible to do more structural changes such as:

relocate items from one column to another
following on from that, dispensing with the left-hand column altogether
make an alternative display method for lists, e.g. a grid arrangement for images

Last question: you now have a new means of determining the tab that should open on logging in. Can you give a code example for what a plugin needs to include to be added to the pref drop-down, e.g. what one needs to add to the top of a dashboard plugin to be able to select it as the login page?

Last edited by jakob (2009-03-21 09:57:00)

wet · 2009-03-21 10:18:44

jakob wrote:

Robert, not quite sure what you mean by logged-out themes for the back-end. Surely when one’s logged out, the only part of the back-end one ever sees is the login box, the rest is the front-end, or have I missed something…

Frankly, yes. 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.

I’ve been watching the svn developments with glee. I can see that one can replace certain chunks of the page with a custom display alternative. Would it be possible to do more structural changes such as…

Possible: Yes. Planned for the next release: No. There are vast herds of dragons (plugins) which rely on the current markup.

Last question: you now have a new means of determining the tab that should open on logging in. Can you give a code example for what a plugin needs to include to be added to the pref drop-down, e.g. what one needs to add to the top of a dashboard plugin to be able to select it as the login page?

register_tab('admin', 'xyz_foobar', gTxt('xyz_foobar'));

See e.g. wet_haystack for a sample.

redbot · 2009-03-21 11:29:47

jakob wrote:

….more structural changes such as:

relocate items from one column to another
following on from that, dispensing with the left-hand column altogether

In the hope I’m not missing something, which is very likely ;), I’d like to express some thoughts:

Jakob,
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.

In other words I think that we must differentiate between two cases:

Presentational modifications (such as moving interface items around )
Structural modifications (such as including or not a particular item in the actual html)

The difference being in the first case we operate after the html is rendered and in the latter before.

Till now we had to rely on js in either cases (just think at ied_hide_in_admin). From now on, if I understood correctly, a similar plugin could operate when the actual html is rendered (with all the discendig advantages – ie even disabling js and css certain items are not shown).

So, back to your concerns, I think you are right when you outline the usefulness of moving items around but IMHO there is no real need for php-coding it.
On the other side a very welcome change is the possibility to include or not some items in the page.

wet,
excuse the naïve question but I’d like to be reassured in one point: from now on will it be possible to include or not (rather than show or not) interface items?

Hope I’ve not totally missed the point…

wet · 2009-03-21 11:44:05

redbot wrote:

wet,
excuse the naïve question but I’d like to be reassured in one point: from now on will it be possible to include or not (rather than show or not) interface items?

Preamble: pluggable_ui() serves two distinct purposes: Provide a hook for either replacing or extending the current user interface. The choice of one mode vs. the other is based on how we assume plugin authors might gain the most out of it while we still retain a bit of integrity for the core application, and is subjective.

Replaceble UI elements can be identified by their usage as a value for the $default parameter to pluggable_ui(), like here.

Extendable UI elements simply add an empty hook with no $default like so. Basically, this is just a callback_event() invocation in disguise, for the sake of consistency.

In either case, a plugin would provide its own markup as a response to the appropriate event:

if (@txpinterface == 'admin') {
	register_callback('foo_extend_ui', 'section_ui', 'extend_detail_form');
}

function foo_extend_ui($event, $step, $context_data)
{
	return graf('now i am here');
}

The value of $context_data depends on the … context. On the write tab, for instance, $context_data holds the current article array. Play with dmp() if you like to nose around.

redbot · 2009-03-21 12:43:08

Thank you for the explanation wet, very appreciated.
Being not a programmer I have to study it a little though, and then perhaps bother again with further [silly] questions.
Thanks for the patience!

FireFusion · 2009-03-21 12:54:59

Hey I like the new tabs in the classic theme but I have to say that grey shadow around the tabs is bad for my eyes :P

It needs to be a bit strong to stop me squinting when ever I look up there.

phiw13 · 2009-03-21 14:31:19

r3149 + is lovely. With a little bit of playing around, I could recreate my own theme quite easily. Gone are the hacks in txplib_head.php :-).

Thanks a lot Robert.

The latest rev mega-patch where I keep all my mods to txp core suddenly got a lot smaller.

PS – is it intentional that the remora theme doesn’t have any link to the site (view site ?).

Last edited by phiw13 (2009-03-21 14:32:26)

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!

Textpattern CMS

Textpattern CMS support forum

#16 2009-03-20 20:32:28

Re: Admin Side Theming! (r3149)

#17 2009-03-21 09:27:07

Re: Admin Side Theming! (r3149)

#18 2009-03-21 09:56:27

Re: Admin Side Theming! (r3149)

#19 2009-03-21 10:18:44

Re: Admin Side Theming! (r3149)

#20 2009-03-21 11:29:47

Re: Admin Side Theming! (r3149)

#21 2009-03-21 11:44:05

Re: Admin Side Theming! (r3149)

#22 2009-03-21 12:43:08

Re: Admin Side Theming! (r3149)

#23 2009-03-21 12:54:59

Re: Admin Side Theming! (r3149)

#24 2009-03-21 14:31:19

Re: Admin Side Theming! (r3149)

#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)

Board footer