Topic: [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.