Admin skins

Bloke · 2008-11-07 12:23:50

Changing the skin/theme of the admin-side is something a lot of the community seem to do for their clients. Currently it requires hacks to work across the site – either replacing textpattern.css and/or modifying txplib_head.php.

Back in January, Mary made some changes to crockery to allow themes on the admin-side. Having reviewed the code I’m convinced she was onto something awesome so I took what she had done, tweaked it slightly and merged it into my latest SVN.

I didn’t do everything exactly as Mary has done (I added a couple of convenience functions, and textpattern.js remains where it is, for instance) but through a few small changes to txplib_head.php, txplib_html.php, and moving txp_img to its own directory theme/default/img (changing the few hard-coded references to it in the core), the concept of skins is brought to life.

And the best part? That is all that’s required. It’s transparent to the end user: no new tabs, no visual changes, no new anything whatsoever. Behind the scenes, TXP ships with one skin/theme — default — that is invisible to the user. But by making the modification, plugins can take over and deliver admin side skin management if people require them. Those that don’t want to change the look, remain blissfully unaware anything has changed.

So, I propose something along the lines of this modified code should be brought forward into the 4.0 branch because:

It moves textpattern.css and txp_img from the ‘textpattern’ directory into a dedicated place dealing with the look of the site, thus tidying the file tree
Having a dedicated ‘skin’ directory for all graphics and css is good encapsulation and having a directory per theme is a very neat way of collecting like files together. This includes javascript if people wish to do fancy things with the back-end via jQuery
By splitting a few core pieces (masthead, tabs, footer) into the theme area, people can have more control over the look of the site if they wish. The main window block remains unchanged, thus has no impact on existing code/plugins. If theme authors choose to create a CSS only theme, the core gracefully falls back to the standard functions, i.e. no impact on existing functionality whatsoever
There will be fewer people having to hack the core to offer a customised back-end for clients, thus easing upgrades for these sites. Those people who have been asking for theme support are sated because there’s a mod-free avenue open to them if they choose to take it
Since the bulk of the work was done by Mary, it’s a proven idea that had already been checked into the repository

Now the exciting part (for me). To demonstrate how it could work, over the last couple of days I have put together the start of a plugin that takes advantage of such a modification. It’s totally unofficial and will likely change beyond recognition in the coming months. But you can:

Create and edit all aspects of a theme; from meta info like its name, version, compatibility info, a thumbnail, as well as the CSS, Javascript, images and any mods you may wish to make to the masthead, tabs and footer
Clone existing themes
Export a theme package to distribute to others
Import/Install theme packages; either one you’ve downloaded, one you’ve created yourself, or from a URL
Choose how you work: manage the installed themes either from the Extensions->Admin Skins tab or upload stuff to the skin directory yourself via FTP, or a combination thereof
Switch skins instantly by clicking its name/thumbnail

In addition, theme guru Stuart (thebombsite) has graciously bought into the concept of my proposition and has offered TextGarden as a possible repository for admin-side themes. Perhaps via feeds, I’d like the plugin to be able to ask TextGarden if there are compatible updates available for any installed skins and present them as optional installation links in the back-end itself.

The plugin is fully functional as far as I want (for now) to demonstrate the idea, but it’ll take quite a bit of refinement to make the back-end core-worthy. At the moment it’s a bit hacky. I’m going to invest some low-level resources into the plugin as we move towards a concrete idea and hopefully work with the devs at integrating the necessary changes to allow skinning to become easy for designers, and for plugin authors to offer tools to help.

If anybody would like a login to my test site so they can mess about with some themes, shout here or e-mail me. That of course includes ruud and wet if you have time ;-) Be aware that there’s only one pref in the plugin that controls the currently-displayed theme so you’ll fight over it if more than one person is logged in at once!

Many, many thanks to my beta testers and guiding lights over the past few days (mary, hcgtv, nemoorange, thebombsite, et al). You’re all bloody amazing.

I’m making no bones about the fact I would love to see this in the core 4.0.x. The question is: should it, and do you agree it benefits the community?

Discuss. Play. Enjoy.

Last edited by Bloke (2008-11-10 09:54:41)

redbot · 2008-11-07 15:31:17

Sounds like a great idea. I hope it will be taken into consideration.

nemoorange · 2008-11-07 15:57:46

As Stef mentioned, I’ve already played around with his Admin-side themes plugin. I think everyone has a love/hate relationship with the Txp admin. On one side, it is simple, and user friendly, and easy to navigate. On the other-side, it feels dated, and all those tabs looks a bit too much like an ugly Microsoft diaglog window. Plenty of designers have taken stabs at making their own themes, myself included. Stef has created the tool to easily switch between those themes, and upload them in a standardized fashion. I think its great. I’m really encouraged to keep pushing on with more themes now that there’s an approachable way to get them installed.

Stef – could your plug-in work without a modification to the core? Can the default theme still exist where it is, and additional themes be add to the textpattern/themes folder? I have to admit, I’m not convinced that a mod would be appropriate, since this is an additional feature.

4.0.7 looks to be better suited for admin-side plugins like this one. Maybe that mod will not be necessary.

mrdale · 2008-11-07 16:13:54

fablus. Q: are there going to be sufficient style hooks for CSS?

Bloke · 2008-11-07 16:19:14

Thanks for the encouragement :-)

nemoorange wrote:

Stef – could your plug-in work without a modification to the core?

Of sorts, perhaps. Caveats for the code:

I’d have to handle the exceptional case of what to do with the default theme because everything about it is different (e.g. file locations)
You would not be able to modify the masthead or tabs or footer in any theme ( except by replacing the image files textpattern.gif, carver.gif and so on — which is esentially modding the core) because the PHP code to do that is in the core files. So the PHP/HTML support in the plugin would have to disappear

Caveats for the end user / designer:

Limited scope for modification (CSS/JS only, as noted above)
Theme styling would not apply on the plugin page or login page, since plugins are forbidden from running in those two situations. As you know, the only way you could do that would be to overwrite textpattern.css which brings about the problem that you’ve modded the core and thus you need to remember not to overwrite it when you upgrade

4.0.7 looks to be better suited for admin-side plugins

Yes indeed it is. Much so. That was what first sparked my interest in theming (themeing?? bleurgh!). Sadly, plugins are forbidden from running on the login and plugin pages (well, sadly from a theme perspective; good from a security/site sanity perspective and I don’t think I’d particularly want to see this changed!)

Since the plugin uses a pref (well, a new core global variable) to track the current theme installed and the core already “knows” about one ‘default’ theme which it always uses and can fall back on if the pref isn’t available/plugin not installed, the fact that plugins can’t run on those two pages doesn’t matter. The core reads the theme from whatever directory is currently set in the global variable $theme.

Last edited by Bloke (2008-11-07 16:51:50)

Bloke · 2008-11-07 16:39:03

mrdale wrote:

are there going to be sufficient style hooks for CSS?

The style hooks are whatever are in there at the moment. Nemoorange, thebombsite, jon hicks, etc have shown what can be done within those boundaries. 90% of the time I’d guess a client will want corporate colours, their company logo in place of the Textpattern logo (just replacing the textpattern.gif won’t always work because of its limited size), perhaps the carver removed/moved, some of the junk in the header/footer moved/removed and the tabs jazzed up a bit. That’s what’s covered by the plugin. And don’t forget you can include javascript in the theme; since jQuery is installed as default you can hide, display or move stuff as you see fit — as long as you can get hold of it via a selector!

Though it would potentially be fab to be able to include or override most of txplib_head.php in each theme directory so you could rip out its guts and go table-less if you so desire, it may break way too many things. I happen to think tables are a valid choice for the (largely tabular) data in the back-end. OK, the CSS names and IDs aren’t so hot and not everything is accessible easily, but the table itself makes sense for most (not all) pages and the hooks / layout are getting better with each release. The problem with the layout of the pages is not necessarily limited to the CSS hooks, it’s the actual design of the page itself (e.g. Sections tab).

[ Since the back-end changes with each revision of TXP, that’s why I chose to version the themes not only with their own incrementable version, but also with what TXP version they are designed for, to make it easier to target only ones that are guaranteed to work ]

The upshot is the only bits that are extracted for you to tinker with are the masthead, tabs and footer (pretty much exactly as Mary did in the crockery mod). That still gives quite a lot more scope for customisation than right now, within the bounds of the app itself. For everything else, there’s xpattern, right? ;-)

Last edited by Bloke (2008-11-10 09:57:45)

wet · 2008-11-07 19:22:37

I think we would need a patch.

Bloke · 2008-11-07 20:15:07

wet wrote:

I think we would need a patch.

In that case I’d need to find out how to do a diff of the two SVN directories on my hard drive or something. I’ve only ever done diff on a file-by-file basis and that could be a bit tedious to manage. Maybe diffmerge will help me?

Alternatively I could load it onto my github. Maybe if I upload the latest SVN as well, someone smarter than me can figure out how to do a diff that way and/or point me at a resource where I can learn how to be a proper software engineer.

TheEric · 2008-11-07 20:52:33

We’re working on something similiar w/ xPat, but are reshuffling the admin pages adding ID’s / classes, and getting rid of extraneous tables to make it easier to restyle.

The above is the current theme, inspired by Dale. All CSS, no tables in the tabs, all relatively liquid.

Last edited by TheEric (2008-11-07 20:54:18)

Bloke · 2008-11-07 21:03:55

TheEric wrote:

We’re working on something similiar w/ xPat

Wicked! Go xpat go!

For us in TXP-land, this mini mod/plugin is probably as close as we’ll get without a similar major rewrite of the backend.

BTW, I’m kind of out of the loop on xpat stuff (haven’t checked in on IRC for ages and my launchpad account got binned during a reshuffle and I don’t think it got reinstated… could be wrong) so if you want any code for back-end theme management, just let me know and I’ll drop you the plugin source or lend a hand if required. Or mrdale can pilfer it off my site now he has a login ;-)

Would like to get stuck into xpat, but I was kind of a spare part a few months ago among all you real programmers.

Last edited by Bloke (2008-11-07 21:04:24)

thebombsite · 2008-11-07 23:34:28

I’ve been a bit tied up with a site the last couple of days but I’m hoping to put “A Bit Blue” up there tomorrow. As you will know it includes some major changes to the default theme, not just a CSS dress-up, so we will see what we will see. I have really enjoyed playing around with this and see it as something that would be extremely useful to those of us who have to live in the real world and earn a living. Being able to create a dedicated admin theme for clients just has to be a winner. I really hope that Ruud and Robert can get behind this one. It’s one of the best feature ideas I’ve seen for some time.

wet · 2008-11-08 20:59:30

I think r2992 helps to separate skin and bones a little bit more.

Textpattern CMS

Textpattern CMS support forum

#1 2008-11-07 12:23:50

Admin skins

#2 2008-11-07 15:31:17

Re: Admin skins

#3 2008-11-07 15:57:46

Re: Admin skins

#4 2008-11-07 16:13:54

Re: Admin skins

#5 2008-11-07 16:19:14

Re: Admin skins

#6 2008-11-07 16:39:03

Re: Admin skins

#7 2008-11-07 19:22:37

Re: Admin skins

#8 2008-11-07 20:15:07

Re: Admin skins

#9 2008-11-07 20:52:33

Re: Admin skins

#10 2008-11-07 21:03:55

Re: Admin skins

#11 2008-11-07 23:34:28

Re: Admin skins

#12 2008-11-08 20:59:30

Re: Admin skins

Board footer