SMF Development > Next SMF Discussion

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

(1/7) > >>

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.

青山 素子:

--- Quote from: Vekseid on June 29, 2009, 01:11:54 AM ---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.

--- End quote ---

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.



--- Quote from: Vekseid on June 29, 2009, 01:11:54 AM ---Languages are simply text entries that should be called directly, there should be no need to call them on a per-theme basis, ever.

--- End quote ---

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.



--- Quote from: Vekseid on June 29, 2009, 01:11:54 AM ---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.

--- End quote ---

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.



--- Quote from: Vekseid on June 29, 2009, 01:11:54 AM ---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.

--- End quote ---

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:

--- Quote from: Motoko-chan on June 29, 2009, 02:05:13 AM ---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.
--- End quote ---

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.



--- Quote ---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.
--- End quote ---

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.


--- Quote ---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.

--- End quote ---

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



--- Quote ---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.

--- End quote ---

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.

青山 素子:

--- Quote from: Vekseid on June 29, 2009, 03:47:06 AM ---
--- Quote from: Motoko-chan on June 29, 2009, 02:05:13 AM ---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.
--- End quote ---

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.

--- End quote ---

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





--- Quote from: Vekseid on June 29, 2009, 03:47:06 AM ---
--- Quote ---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.

--- End quote ---

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

--- End quote ---

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.



--- Quote from: Vekseid on June 29, 2009, 03:47:06 AM ---
--- Quote ---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.

--- End quote ---

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.

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page

Go to full version