Admin Side Theming! (r3149)

Bloke · 2009-03-20 13:34:20

variaas wrote:

I like the idea of editing themes in the TXP admin interface.

Cool, I notice you never tried out the plugin demo on my site. That might give you an idea of what I did. Interested? Drop me a line.

Last edited by Bloke (2009-03-20 13:35:42)

Bloke · 2009-03-20 15:53:03

I wrote:

per-user or per-group themes (which I’m not sure will actually work now

I can’t find a way of making this work because the init() method of any theme reads the value of the theme_name_TODO in txp_prefs. Thus, as far as I can tell:

if a plugin modifies that value it applies to all users — the same way TXP does out of the box — as it should
if that pref is set in the core to be per user (probably not a good idea), then only an administrator/plugin can set a user’s theme because the prefs page is not available to most users to change their own (besides, we don’t want this feature by default, as it should only be for a plugin to manage if the site design requires it)
per-priv themes are not possible to be read, for the same reason

I may be missing something fundamental here. Please anyone advise if there’s any way a plugin can set up its own theme list (global, per user, per priv) and have the core act on it when someone logs in. Thanks in advance.

FireFusion · 2009-03-20 19:42:48

This is such an awesome announcement. Thanks guys!

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

Hint.

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)

Textpattern CMS

Textpattern CMS support forum

#13 2009-03-20 13:34:20

Re: Admin Side Theming! (r3149)

#14 2009-03-20 15:53:03

Re: Admin Side Theming! (r3149)

#15 2009-03-20 19:42:48

Re: Admin Side Theming! (r3149)

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

Board footer