Admin skins

Bloke · 2008-11-08 21:25:06

wet wrote:

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

Ooh, nice, thank you very much. I’ll roll those changes into my install and then adjust the default theme to suit.

It means there are far less files to worry about in the patch itself. In fact, just txplib_head.php (minus the changes you just made), plus the small mod to txplib_html.php, the reference to txp_img (the carver) and the two references to the txp_img slugs in setup/txpsql.php are left. Marvellous work all round!

On a theme note, I’m happy to announce that Stuart has ported his “A Bit Blue” over this morning and it is truly a work of art. It’s now my new best friend and default theme. Nice one Stuart, thank you. I have a little bit more work to do on the plugin to test a few more corner cases and check that things definitely fall back to the default theme when required, then I’ll make a patch against r2992 and post the link here. And cross my fingers :-)

In the meantime if anybody wants to play with the plugin, the offer of a login is still open so just let me know via e-mail.

Last edited by Bloke (2008-11-08 21:25:18)

wet · 2008-11-08 21:37:02

Bloke wrote:

It means there are far less files to worry about in the patch itself. In fact, just txplib_head.php (minus the changes you just made),

I think this is a matter of where to aim. Your approach is to have even the default skin as a part of the themeing system. If you’d only override with alternate styles, e.g. by hooking into admin_side.head_end event, I would expect that the core could be used unaltered. I’d love to learn what change is required in txplib_head.php which wouldn’t be sufficiently captured by the admin_side.head_end event?

the reference to txp_img (the carver)

Same here: Overriding should be easy easy, why move the file?

and the two references to the txp_img slugs in setup/txpsql.php are left.

These are part of the public side default theme and not related to the admin side. By changing this you deprive people from using the default pages whenever they switch their admin side theme off the default admin skin, aren’t you?

Bloke · 2008-11-08 22:54:52

wet wrote:

Your approach is to have even the default skin as a part of the themeing system.

Yes, the same as Mary did in crockery. Figured that was the path of least resistance since that patch had already been subject to code/peer review.

If you’d only override with alternate styles, e.g. by hooking into admin_side.head_end event, I would expect that the core could be used unaltered.

True, except that plugins cannot run on the login or Admin->plugin pages so they would always be unstyled without a core mod to read a global pref. As far as I can tell, $prefs is the only thing I can influence that occurs above doAuth() / plugin loading; and the head_end callback, while awesome for injection, never gets handed to a plugin on these two pages. Rightly so.

Overriding should be easy easy, why move the file?

Perhaps I’m way off base then. I was copying the idea Mary started and it seemed logical to pull the HTML that txplib_head/txplib_html produces and make it part of the theme so they could be altered by people who knew what they’re doing. If certain designers are happy with site-wide CSS-only themes, this is not required and will always use the output as it is today, without them or the core doing anything exceptional.

txpsql.php: These are part of the public side default theme and not related to the admin side.

Yes. If the txp_img directory remains where it is, you are absolutely right: that does not need to be changed.

By changing this you deprive people from using the default pages whenever they switch their admin side theme off the default admin skin, aren’t you?

Not quite. The patch (as Mary did) moves txp_img to theme/default/img and moves textpattern.css to theme/default/css. So anywhere there was a hard-coded reference to txp_img (now far fewer, thanks to r2992) I changed it to theme/default/img. Since those references are hard-coded anyway, it doesn’t matter what theme you pick on the admin side, it was just the fact that the physical .gif had moved that required the alteration.

If the ‘default’ theme stays where it is (i.e. textpattern.css and txp_img left untouched and no core modification to txplib_head/html), this is what we are left with:

CSS-only modifications
No theme shows up on login or Admin->Plugin pages. Admin->Plugin probably isn’t critical since (I guess) most clients won’t see that page — though it is nice for consistency — but the login page would be great to welcome a client to “their” content management system
To bypass the above, you have to ‘hack’ the core (replace textpattern.css) and remember to hack it again when upgrading
No ability to move things about the page except with jQuery after the DOM has loaded, thus seeing a flash of semi-styled theme on every page, which is ugly

Perhaps in my naivity I’m missing something, but even if the plugin hooks into head_end or pagetop_start, the default layout (i.e. the rest of pagetop) still gets executed after the plugin has finished, right? So I can inject stuff like my_theme.css and my_theme.js no problem. I could even do a search and replace to remove or replace the <link> tag to textpattern.css. I could hook into body_end and do a search/replace for the entire tab table and remove it, replacing it with some fixed HTML that someone included with a theme, but that doesn’t take into account the fact that some tabs may have been hidden by TXP due to privs.

If I was clever enough (hehe, perhaps if I had infinite monkeys coding for me), I could probably write a parser to scan the primary_nav node, see what tabs are there and only inject the ones that are visible. But writing or using an HTML parser to intelligently find and replace this:

<table cellspacing="0" cellpadding="0" align="center">
<tbody>
<tr>
<td valign="middle" style="width: 368px;"></td>
<td class="tabdown">
<a class="plain" href="?event=article">Content</a>
</td>
<td class="tabdown">
<a class="plain" href="?event=page">Presentation</a>
</td>
</tr>
</tbody>
</table>

with:

<ul id="areas">
<li>
<a href="?event=article">Content</a>
</li>
<li>
<a href="?event=page">Presentation</a>
</li>
</ul>

seems a trifle convoluted.

The only way I can see to allow someone to change the current tabs or move the message area is to handle the entire process of rendering the page in the plugin, i.e. pretty much duplicate pagetop, call all relevant callbacks, the cookie check, poweredit, the works, and then call die() to stop the rest of pagetop from executing. That seemed like a lot of work for a plugin to do (and to keep abreast of changes to pagetop), and it still wouldn’t run on login/Plugin pages, hence the modification. But like I say, perhaps I just need educating. I’m all eyes if there’s a better way :-)

Thanks for your interest in this, wet. Much appreciated. It’s certainly making me think!

thebombsite · 2008-11-09 00:38:53

Robert, why don’t you get a login off Stef and go and have at look at it in action? In particular have a look at “A Bit Blue” and see the added functionality in the header. Whether you like the theme or not is neither here nor there but you will see what could be done with this plug-in given the modest changes to the core that Stef is asking for, changes which are backward-compatible and invisible to anyone not using the plug-in.

Whilst this isn’t a total solution to the age-old forum arguments about a complete admin re-design, I think it is a bloody good step in the right direction and would be a boon to those of us who would like a simple method of giving our customers a corporate make-over for their admin.

I’m thinking that a persistence in pursuing a CSS-only route is just a straight-jacket waiting to be ripped off.

wet · 2008-11-09 06:49:26

thebombsite wrote:

Robert, why don’t you get a login off Stef and go and have at look at it in action?

Well, please send it along. Plus, I’d like to see a patch as indicated above.

Bloke · 2008-12-09 00:06:39

Right, I’ve had some time to refine this thing a bit more and it’s now available on the site as before if you wish to login and play with it. Anyone who has requested an account, I have increased your security level to Publisher because the plugin is now only available to that level of user. I trust you all to play nice :-)

New features:

The directory is called ‘skin’ and everything is now referred to as a skin instead of an admin theme
Setup button to handle the plugin prefs (that I can’t bloody well move to the right of the screen… grrr, will fix it one day)
Skins can be sorted with or without case sensitivity (thanks kemie)
Skins can either be set globally (one for all), one per privilege level, or one per user. A cookie tracks the latter two cases
Current skin is highlighted better in the list
The about.txt file is now referred to as a Skinfo file, for no other reason than my personal amusement ;-)
Shortcut back to the Skin List page from the Edit page
If you set the skin system to per-user, a new tab appears under Admin for all non-publishers that allows skins to be switched from your defined shortlist
Plugin help written — please read for the known caveats and gotchas. Most important stuff is highlighted in red

If you want to test out the per-priv or per-user skins, I’ve created three low-level users that you can log in as (each from a different browser / machine or it’ll read the cookie from the last person that used it!). The passwords are the same as the login names: staffwriter, freelancer, or designer.

Feel free to have a play around, port, import/export/clone themes and generally put it through its paces. If anybody else would like a login, just holler.

The patch against r3039 is coming… then we can see if we can hone my hackish system into something a bit more elegant and TXP-like.

Bloke · 2008-12-09 00:47:53

And here’s the patch which looks big and scary but isn’t.

I have no idea why TortoiseSVN decided to create some stuff long-hand by essentially deleting every row in both textpattern.css and txplib_html.php, then adding them all back in to new versions of the files, instead of simply marking the minor differences or indicating files as moved?! Perhaps that’s the way it works. Or perhaps I screwed up.

Similarly, the entire txp_img directory has been moved, but for some reason when I dbl clicked the .patch file it only showed me file differences excluding moved/deleted files. The .patch file itself (if read in a text editor) lists all such changes, so maybe there’s some way of getting it to show or apply them that I haven’t figured out yet. This version control lark is all new to me.

If you need anything different from me, just yell. But for now, please take it and feel free to suggest far better ways to help make it into something core-worthy that will unleash skins on the masses. Some sort of callback mechanism for overriding some of the functions like tabber() and areatab() would be awesome instead of my fugly hacks. Either way, look at the PHP files in Stuart’s ‘A Bit Blue’ theme for the way it is currently used and the kind of functionality this opens up.

Thanking you in advance.

P.S. I’m not sure if my use of DS is correct. Perhaps it should be '/'? Haven’t got a Windows environment to test it on.

the_ghost · 2008-12-09 18:33:46

Sorry for some offtopic, but how to merge path file with original txplib_head.php, using TortoiseSVN too

Last edited by the_ghost (2008-12-09 18:34:23)

Bloke · 2008-12-09 19:16:59

the_ghost wrote:

how to merge path file with original txplib_head.php, using TortoiseSVN too

Last time I looked if you dump the patch in a recently-downloaded SVN copy of TXP and right-click the .patch file, there’s a context option TortoiseSVN->Apply Patch...

That showed me a diff, file by file, change by change, and I had to accept or reject the various bits and pieces. It didn’t move the txp_img folder or delete the files that had been moved so maybe there’s some option I missed or I messed up when I made the patch *shrug*

Sorry, I’ve no idea on this SVN lark. Bazaar or Mercurial seem much more intuitive, imo.

On a related note, the patch was really only for the devs to mess about with and kick into shape. By all means try it, but things will change drastically before (hopeful) release so don’t get too comfortable with it the way it is now!

Last edited by Bloke (2008-12-09 19:17:19)

net-carver · 2008-12-09 22:01:13

Bloke wrote:

I have no idea why TortoiseSVN decided to create some stuff long-hand by essentially deleting every row in both textpattern.css and txplib_html.php, then adding them all back in to new versions of the files, instead of simply marking the minor differences or indicating files as moved?! Perhaps that’s the way it works. Or perhaps I screwed up.

Sounds like your editor, diff+merge tool or perhaps tortoise/svn has changed the line endings — presumably from Unix to Windows. You might need to check your prefs to see.

You also need to take care on some diff engines too. I use meld on linux and it took me a long time to figure out it was guilty of adding a line to the end of each file I diff’d and merged changes into using it. Soon sorted in the preferences once noted but not pretty.

Bloke · 2008-12-09 22:25:20

net-carver wrote:

Sounds like your editor, diff+merge tool or perhaps tortoise/svn has changed the line endings

Bingo! Thanks Steve.

txplib_head.php came down as UNIX, my text editor left it that way
txplib_html.php came down as UNIX, my editor changed it to DOS for reasons best known to itself *shrug*
textpattern.css came down from code.google.com as DOS (!), my editor changed it to UNIX — as I expected

I’ll convert the ones that changed to the same format as they came down, then the patch size should shrink dramatically… will repost it later.

Many thanks, sir.

the_ghost · 2008-12-09 22:50:01

Are there some working textpatern skins that can be instaled with this patch?

Textpattern CMS

Textpattern CMS support forum

#13 2008-11-08 21:25:06

Re: Admin skins

#14 2008-11-08 21:37:02

Re: Admin skins

#15 2008-11-08 22:54:52

Re: Admin skins

#16 2008-11-09 00:38:53

Re: Admin skins

#17 2008-11-09 06:49:26

Re: Admin skins

#18 2008-12-09 00:06:39

Re: Admin skins

#19 2008-12-09 00:47:53

Re: Admin skins

#20 2008-12-09 18:33:46

Re: Admin skins

#21 2008-12-09 19:16:59

Re: Admin skins

#22 2008-12-09 22:01:13

Re: Admin skins

#23 2008-12-09 22:25:20

Re: Admin skins

#24 2008-12-09 22:50:01

Re: Admin skins

Board footer