[3.0] Redo the theme system for SMF (2.1+ obviously)

[Vekseid]

I don't know how much of this is implemented in RC2, but here goes.

1: Separate imagesets, scriptsets, stylesets, languages, and the themes themselves rather than being forced to use multiple copies of an image, stylesheet or script, just have a single set where this is desired.

Imagesets would function a lot like smiley sets do - being called from smfdir/Images/set/... rather than a subdirectory of themes.

Stylesets and scriptsets would function a bit like MyBB's css loading does. Rather than have the theme call these files directly, the theme instead has a list of available files that it can call, and if a given file should apply to a theme, it is selected directly.

Languages are simply text entries that should be called directly, there should be no need to call them on a per-theme basis, ever.

2: List items should be defined in settings, not in the script or in the theme - for example, BBcode, IMs, profile fields (including the entire postbit), and the menu bar. These items, where they point to and how, should be entries in the database or (better) the settings file that should have been there from the start. I should not have to edit the source code to link to my own YIM and ICQ images to improve load times, for example.

To be clear: BBCode, the postbit, menubar, and IM listings should be completely customizable, along with any similar lists - those are just the ones that strike me at the moment.

3: Use display hooks or rings to allow modifications to attach themselves to places without modifying the theme. A good example of this would probably be Drupal's block system, but ideally would have stricter definitions - here is a footer, here is a header, etc. and so on.

4: Pull theme options out of the theme. Especially things that don't have anything to do with the theme, like whether or not sent pms get saved by default, but even if not - if a theme needs a new option, it should be able to make one and give it a name appropriately.

[青山 素子]

1: Separate imagesets, scriptsets, stylesets, languages, and the themes themselves rather than being forced to use multiple copies of an image, stylesheet or script, just have a single set where this is desired.

SMF currently can't do fallback images or stylesheets, but it has always fallen back to a single set of language files. You can actually use the images from a different theme with the "based-on" property, which moves the images and style paths to point to that theme.

Languages are simply text entries that should be called directly, there should be no need to call them on a per-theme basis, ever.

That's already the way it is, and has been since 1.0. The only exceptions would be if the theme had some extra special settings not in the default theme. In that case, it would need a theme-specific language file to provide text to those settings.

To be clear: BBCode, the postbit, menubar, and IM listings should be completely customizable, along with any similar lists - those are just the ones that strike me at the moment.

There is talk about adjusting some of the profile fields, and the custom profile field functionality should allow you to create whatever field and images you need to. Adding additional IM or other "social" fields should be easy.

Likewise, the main menu in 2.0 is in its own file now. There isn't a fancy editor for that at the moment, but there might be one in a future release.

3: Use display hooks or rings to allow modifications to attach themselves to places without modifying the theme. A good example of this would probably be Drupal's block system, but ideally would have stricter definitions - here is a footer, here is a header, etc. and so on.

That could be somewhat constricting. Our current approach with 2.0 will be to make the theme code as semantic as possible to allow massive style changes with just CSS. This should greatly reduce the need to make custom template files.

[Antechinus]

Not taking anything away from 2.0, but from the digging around I've been doing in it I honestly can't see myself doing any less template editing for 2.0 than I was doing for 1.1.x, simply because the standard templates don't appeal to me much and I prefer to re-design them. This cannot be done with just css, so although 2.0 is an advance in many ways I think the reality of the situation is that template editing will be almost as common under 2.0 as it was under 1.1.x. 

[Vekseid]

SMF currently can't do fallback images or stylesheets, but it has always fallen back to a single set of language files. You can actually use the images from a different theme with the "based-on" property, which moves the images and style paths to point to that theme.

That's already the way it is, and has been since 1.0. The only exceptions would be if the theme had some extra special settings not in the default theme. In that case, it would need a theme-specific language file to provide text to those settings.

These sometimes end up replacing original files rather than just providing new entries, though. Either way, the separation is not as clean as it ought to be.

There is talk about adjusting some of the profile fields, and the custom profile field functionality should allow you to create whatever field and images you need to. Adding additional IM or other "social" fields should be easy.

It currently does not, however. ICQ, YIM, AIM and MSN are hard-coded entries whether or not I want them, and behave a given way unless I edit a .php file. This should not be necessary. In addition, there is no option for adding a profile field to the postbit.

Likewise, the main menu in 2.0 is in its own file now. There isn't a fancy editor for that at the moment, but there might be one in a future release.

Not as of RC 1.1 it isn't, at least, thus the comment.

That could be somewhat constricting. Our current approach with 2.0 will be to make the theme code as semantic as possible to allow massive style changes with just CSS. This should greatly reduce the need to make custom template files.

That gives no ability to add anything, however, which was the point of that item. It's not terribly constraining - I've said this elsewhere, SMF's permissions system is its crown jewel. It handles permissions better than any other solution currently available that I know of. Drupal could not hope to do so well, but it handles this situation extremely well.

[青山 素子]

SMF currently can't do fallback images or stylesheets, but it has always fallen back to a single set of language files. You can actually use the images from a different theme with the "based-on" property, which moves the images and style paths to point to that theme.

That's already the way it is, and has been since 1.0. The only exceptions would be if the theme had some extra special settings not in the default theme. In that case, it would need a theme-specific language file to provide text to those settings.

These sometimes end up replacing original files rather than just providing new entries, though. Either way, the separation is not as clean as it ought to be.

Not sure what you mean by replacing original files instead of providing new. How do you expect SMF to detect what to use where?

Likewise, the main menu in 2.0 is in its own file now. There isn't a fancy editor for that at the moment, but there might be one in a future release.

Not as of RC 1.1 it isn't, at least, thus the comment.

Yep, it is. It has been this way in all the public preview releases. Check the setupMenuContext function in Subs.php. You'll find an array the sets up the menus and all submenu items. If you are writing a modification that makes menu changes, it should go there. If you are working on a theme, it should use this function. Refer to the default theme for how to handle things if you don't know.

That could be somewhat constricting. Our current approach with 2.0 will be to make the theme code as semantic as possible to allow massive style changes with just CSS. This should greatly reduce the need to make custom template files.

That gives no ability to add anything, however, which was the point of that item. It's not terribly constraining - I've said this elsewhere, SMF's permissions system is its crown jewel. It handles permissions better than any other solution currently available that I know of. Drupal could not hope to do so well, but it handles this situation extremely well.

What do you mean by no ability to add things? Edit the default theme files and if you are just using CSS, then the new stuff should show up in all themes.

[Vekseid]

Not sure what you mean by replacing original files instead of providing new. How do you expect SMF to detect what to use where?

Formalize adding a language entry.

Yep, it is. It has been this way in all the public preview releases. Check the setupMenuContext function in Subs.php. You'll find an array the sets up the menus and all submenu items. If you are writing a modification that makes menu changes, it should go there. If you are working on a theme, it should use this function. Refer to the default theme for how to handle things if you don't know.

Subs.php is not 'its own file'. Subs.php is 1) a php file, which is exactly the wrong place for this sort of thing and 2) critical to the functioning of the forum if something refuses to work. The menu does not belong there, at all.

What do you mean by no ability to add things? Edit the default theme files and if you are just using CSS, then the new stuff should show up in all themes.

'edit the default theme' - no. The whole point of the exercise is that adding something like a shoutbox or arcade should require no theme edits. Period. Not via mod edit, not manually. Files may be added, but never edited or replaced.

SMF's theming is its most widely criticized weakness. There's a reason for this, it would be awesome to see it addressed.

[bloc]

SMF's theming is its most widely criticized weakness. There's a reason for this, it would be awesome to see it addressed.

It is? Whats the reason for that, in your opinion?

[Kindred]

Personally, I think SMF's theming system is one of the more powerful ones out there.... The power just doesn't happen to be widely used because it's simpler to make a quick modification to CSS and call it a new theme.

[live627]

I propose sub templates can have two prefixes, template_ and template_custom_ so that custom themes can define only the templates they actually modified. Also I'd like to see multiple sub-templates per page.

[青山 素子]

I propose sub templates can have two prefixes, template_ and template_custom_ so that custom themes can define only the templates they actually modified.

You can already do this. If you don't modify a template file, don't include it in the theme directory. SMF will use the template file from the "default" directory in this case.

Most simple themes will only need to include index.template.php. If they only touch the CSS and images, they won't need to include any template file.

Also I'd like to see multiple sub-templates per page.

Not sure what you mean or how that would work.

[live627]

You can already do this. If you don't modify a template file, don't include it in the theme directory. SMF will use the template file from the "default" directory in this case.

Most simple themes will only need to include index.template.php. If they only touch the CSS and images, they won't need to include any template file.

I know... but I'm not talking about individual files (templates). I'm talking about the specific functions (sub templates).

Not sure what you mean or how that would work.

It's not an entirely new concept, for template layers can do much the same thing. But this... this is like the middle of the sandwich, whilst layers use above and below  like the bread on a sandwich.

Let's go a bit deeper. Currently, you have $context['sub_template'] = 'mst';, which only allows for one sub template at a time. So let's expand on that and get $context['sub_templates'] = array('mst', 'display;');. With an appropriate edit to obExit(), multiple sub templates may be used per page!

[青山 素子]

I know... but I'm not talking about individual files (templates). I'm talking about the specific functions (sub templates).

That would be interesting due to how PHP handles function declarations. You'd need to protect each function using a "function_exists" call to avoid declaring it twice and causing PHP to throw an error. Such a situation could get very messy.

Let's go a bit deeper. Currently, you have $context['sub_template'] = 'mst';, which only allows for one sub template at a time. So let's expand on that and get $context['sub_templates'] = array('mst', 'display;');. With an appropriate edit to obExit(), multiple sub templates may be used per page!

How would that work in practice? I can't think of a practical example of this, but I'm sure you could.

[Oldiesmann]

I know... but I'm not talking about individual files (templates). I'm talking about the specific functions (sub templates).

I really don't see how that could work well, short of splitting every sub-template into its own file (which would be a nightmare). Even if you use "custom_" prefix, there's a possibility of getting errors if the theme that yours is based on has also customized that particular sub-template (not likely, but it could happen).

[DoctorMalboro]

HTML5BP + Template system = Win

I think SMF MUST do a big step foward in the design, is the only thing that has been left behind and now it's a good time to catch up. The main design is not bad, but maybe creating a better templating will make new themes better and more creative.

[bloc]

I don't think its ever been the lack of creative forces? Its just that mods decide what templates we can change(or have up until now anyway) and that the themesystem is maybe too complex at first glance. IMHO thats good thing, the complexity..also, one thing that perhaps is the BIGGEST obstacle in new creative looks for SMF, is that forum owners are *very* traditional. Very few like to change that lovely table/spreadsheet/box layout we have been using for years. Heck, even Curve had a lot of resistance, and that just added a few more rounded headers and containers - its still essentially the same layout as 1.1.

You can already do this. If you don't modify a template file, don't include it in the theme directory. SMF will use the template file from the "default" directory in this case.

Most simple themes will only need to include index.template.php. If they only touch the CSS and images, they won't need to include any template file.

I know... but I'm not talking about individual files (templates). I'm talking about the specific functions (sub templates).

Not sure what you mean or how that would work.

It's not an entirely new concept, for template layers can do much the same thing. But this... this is like the middle of the sandwich, whilst layers use above and below  like the bread on a sandwich.

Let's go a bit deeper. Currently, you have $context['sub_template'] = 'mst';, which only allows for one sub template at a time. So let's expand on that and get $context['sub_templates'] = array('mst', 'display;');. With an appropriate edit to obExit(), multiple sub templates may be used per page!

I think I follow your thoughts..but this doesn't really make it better to theme, it just moves things around. If you cannot change the whole template out of fear it will not work with mods, you have already lost.

[Ricky.]

I agree to bloc, since I am comparatively new in creating SMF themes, I was observing trend of theme acceptance by Forum Admins, they are resistive to new styles and ideas. May be this is because people are used to that spreadsheet style system. Personally.. when I join a new forum and find it on classic layout, I feel comfortable though, it never means I am not open to new ideas but should make things easier to do.

As I have said earlier, I find SMF theme system as one of the most developer friendly system.. I have used many others (if not all ) and I love SMF !

What I see that we can include more AJAX, it may even make SMF lighter if used wisely !

I don't think its ever been the lack of creative forces? Its just that mods decide what templates we can change(or have up until now anyway) and that the themesystem is maybe too complex at first glance. IMHO thats good thing, the complexity..also, one thing that perhaps is the BIGGEST obstacle in new creative looks for SMF, is that forum owners are *very* traditional. Very few like to change that lovely table/spreadsheet/box layout we have been using for years. Heck, even Curve had a lot of resistance, and that just added a few more rounded headers and containers - its still essentially the same layout as 1.1.

You can already do this. If you don't modify a template file, don't include it in the theme directory. SMF will use the template file from the "default" directory in this case.

Most simple themes will only need to include index.template.php. If they only touch the CSS and images, they won't need to include any template file.

I know... but I'm not talking about individual files (templates). I'm talking about the specific functions (sub templates).

Not sure what you mean or how that would work.

It's not an entirely new concept, for template layers can do much the same thing. But this... this is like the middle of the sandwich, whilst layers use above and below  like the bread on a sandwich.

Let's go a bit deeper. Currently, you have $context['sub_template'] = 'mst';, which only allows for one sub template at a time. So let's expand on that and get $context['sub_templates'] = array('mst', 'display;');. With an appropriate edit to obExit(), multiple sub templates may be used per page!

I think I follow your thoughts..but this doesn't really make it better to theme, it just moves things around. If you cannot change the whole template out of fear it will not work with mods, you have already lost.

[青山 素子]

What I see that we can include more AJAX, it may even make SMF lighter if used wisely !

As long as it doesn't prevent functionality when JS is disabled. I hate sites that will not work if you don't allow them to run arbitrary code.

[Antechinus]

Does anybody actually disable js these days? [Unknown] was musing last year that we should really be requiring js these days, because of the obvious benefits (security being one of them).

[Illori]

a lot of people use noscript addon for firefox to do just that, disable js.

[青山 素子]

I use NoScript. It helps with a lot of intrusive JS. If I really need to, I can opt-in to the JS on a site.

[SleePy]

I use NoScript. It helps with a lot of intrusive JS. If I really need to, I can opt-in to the JS on a site.

+1

[Antechinus]

Can't remember the actual figures offhand, but last time I checked the percentage of people browsing with js disabled was very, very low. Somewhere down around the level where even fussy people wouldn't consider supporting an obsolete browser.

[Ricky.]

I use NoScript. It helps with a lot of intrusive JS. If I really need to, I can opt-in to the JS on a site.

+1

Though here are many people who love to browse sites without JS but I actually love sites with suitable ajax implementation. I am against using Ajax just for fancy and also against those who just keeps adding JS on and on to make their site look cool !!!..  but what I think, it should be used to make site Work Cool/

[bloc]

So..what about redoing the theme system..or is "something-more-AJAX-here-and-there-would-be-cool" all you got?

[Ricky.]

I am happy with current theme system, you are far more experienced, what do you say about redoing?

So..what about redoing the theme system..or is "something-more-AJAX-here-and-there-would-be-cool" all you got?

[bloc]

Not my call, I was asking the topic starter.

[Ricky.]

Ah.. then my mistake.. though I thought you are asking me !

Not my call, I was asking the topic starter.

[bloc]

No maybe I should more clear on that, sorry..but IMHO this topic is going nowhere when you start that age old AjAX-or-not discussion again. That has always been, and still is, a question of UI layout - not of whether it can be cool to add it or not. But I digress...I believe the ball is now back to the topic starters corner(if he is still there )

[Vekseid]

Had no idea this was replied to...

SMF's theming is its most widely criticized weakness. There's a reason for this, it would be awesome to see it addressed.

It is? Whats the reason for that, in your opinion?

People who complain about it are generally pretty specific - that it's obtuse to design themes for. This in and of itself could be fine, if it was in fact not so obtuse as to say, require you to edit one of SMF's most criticals file just to alter the menu.

Does anybody actually disable js these days? [Unknown] was musing last year that we should really be requiring js these days, because of the obvious benefits (security being one of them).

None that aren't either a) bots or b) using something like noscript. It wouldn't be any upset to require it.

Not my call, I was asking the topic starter.

I have no idea what you're referring to. Not once in this thread have I mentioned AJAX.

Most of what I discussed in my first post is still fully valid, two and a half years later. For example: What are PM options doing as part of theme options?

Right now, though, I'm working on my own software based on what was discussed for the Youracore project. I'll continue to work on SMF optimization notes and such as long as my forums still run SMF, but my vision for communities is not shared by the team here. Which is perfectly fine, but I don't feel like getting heated over it.

[spiros]

What I would love to see, would be a way so that themes (design), is completely separated from functionality. I.e. mods do not interfere with theme code directly, but only through hooks (so that mods install automatically on any theme, rather than having the admin mess up manually with the code). Most CMSs work that way, would this be impossible for a forum? Isn't this something worth striving for in our case?

[Kindred]

yes and no...

it is a worthy goal - however, one of the things that makes SMF so powerful IS the full theme design.

Hooks are good... but not everything can be handled with hooks. Even wordpress (which is nothing but hooks) add-ons occasionally need template file updates (Which makes theme updates annoying)

[spiros]

Even in that case, IMHO there should be some effort towards simplifying the procedure or minimizing theme-specific edits. Some mods require editing for 5+ or 10+ theme files which is too much really. Joomla for example is a favorite with designers and it offers great extensibility without theme-editing (or with minor theme editing). I think this is one of the major reasons that account for its popularity: great availability of well-designed themes which do not mess with functionality.

By the way, I cannot create new topics on this board...

[Illori]

By the way, I cannot create new topics on this board...

only team members can create topics in this board for several reasons.

[Kindred]

as I said... it is a worthy goal and is being looked into (as has been mentioned several times in this thread and elsewhere).

The introduction of hooks was a good first step and we all know that more hooks need to be added, but that is different from "themes (design), is completely separated from functionality".
It's really not possible to do that "completely" while still keeping the full functionality of the SMF theme system.


Joomla is actually moderately limited in what you can do with the stock theme designs...   when I ran a joomla system, I was continually editing the theme template files in order to get them to do what I needed.

[spiros]

Which was the last Joomla version you used? Apart from standard Joomla features and the versatility they afford, there are some theme frameworks out there with amazing versatility straight out of the control panel (i.e. Warp, T3, Gantry frameworks).

[mark87]

Any chance they will bring back the 1.1 ability to change the background image easily in themes ? I always thought that was a very cool option.

[Arantor]

Unlikely

[Antechinus]

Eh? What 1.1.x option?

[Arantor]

Some themes actually offered that as an option - easy recolouring straight from the ACP.

[Antechinus]

Ah. Inline styling. It'd be easy to do in 2.1 or any version since it's just a custom theme setting. Which brings to mind an interesting question.

If the mod guidelines get stricter and outlaw inline styling, what happens if someone write a mod to give recolouring from the admin panel? In fact, oh dear, how exactly do membergroup colours work, and how are they going to work in future?

TBH, if you want to do a good job of things like that in future versions, or even in 2.1 FFS, you'd use the setting to assign a class rather than force a colour inline. This would be no more code for Sources but far more flexibility for themes. Having stuff in Sources is fine, as long as it's accessible to themers in some way. Currently, far too much of it isn't.

[Arantor]

Yes but that limits flexibility oh noes

You're preaching to the converted and the ways to solve all this stuff *nicely* are 3.0 territory. But they *are* doable.

[Antes]

isn't theme variants designed for this? Multiple colors, or having same theme with small changes. no?

[Arantor]

Sort of but there are a lot of people that for whom CSS would be too complicated and just want something nice and friendlier in the admin panel.

Like XF has, for example.

[Antechinus]

Case in point, actually. I've done several multi variant themes, for 1.1.x and 2.0.x, and the variant system brings in problems.

Say you want to create a dark variant and a light one. This means the best text colours are often going to be different. For example, if you have one membergroup coloured purple it may be perfectly fine on the light variant, but almost illegible on the dark one. If you have a group coloured a pale yellow it may be fine on the dark variant but not on the light one.

Then there's the background colours themselves, regardless of lightness or darkness. Some colours just don't go well together, and the more adventurous you get with variants the more you'll find yourself wishing that some dumb motherf***ers hadn't forced everything to be one way in Sources. You'll find yourself long for things like group colours assignable by theme and by variant. You might even think about writing a mod for it, when it should have been doable in default.

[Arantor]

Except it would raise more issues because 'why do we have to do this' because it's not like this has never been asked before or anything

The variant thing is also actually less common than you might think, at least going out into the wider world of forum software and seeing what people actually do on their sites (and not just SMF ones)

[Antechinus]

Sort of but there are a lot of people that for whom CSS would be too complicated and just want something nice and friendlier in the admin panel.

Like XF has, for example.

Yup, that too. Although it does bring a performance hit with it.

And speaking of complex CSS, even for people who can write it there often comes a point where you will start thinking that Zen Garden showing off is all very well, but it really would make more sense to switch the markup.

Except it would raise more issues because 'why do we have to do this' because it's not like this has never been asked before or anything

The variant thing is also actually less common than you might think, at least going out into the wider world of forum software and seeing what people actually do on their sites (and not just SMF ones)

It's not just about variants though. It's about any site which offers more than one background colour. If you offer a selection, there's a good chance you won't want presentation forced one-size-fits-all in Sources.

[Arantor]

Although it does bring a performance hit with it.

Only if done properly. XF's setup is not unperformant - and is *significantly* easier to use for non technical people; after all, the vast majority of SMF admins are not technical. Something that lets them do a simple change in the admin panel is enough for most people.

[Antes]

Then give membergroups specific class and colorize it via CSS with that all colors fit, since you can change them based on variant.

I don't find it extreme difficult, I think anyone with basic FTP/File edit knowledge can do this. Its not unlearnable.