[suggestion] Remove theme capability for SMF 3 (or earlier)

[bloc]

Ever since the release of SMF 2 we have seen a good amount of themes get released that rely mostly on the Curve layout - nothing wrong with that in itself - but less and less themes provide a different basic layout than said Curve. Some have dared to do it, but its mostly been futile. People that create themes don't want to code/change anything but index.template most of the time. Maybe occasionally Boardindex and Display but thats it.

So why is that? Lack of knowledge to code? Perhaps...but I think the bigger reason - because coding can be learnt - is that mods that need to change templates will no longer install if you change them in custom themes. So they stay away from it and focus on the CSS instead.

That leads to the conclusion that changing templates for custom themes is a rare thing, and having a system to are able to do it, is effectively under-used.

So I suggests SMF 3 ships with NO THEMES capability whatsoever. Specifically:

• all templates will be located in default theme only(where site owners can change those if they dare) and only leave  variations to play with.
  
• variations use only CSS.
  
• Default theme provides a hook to add custom layers for those that need to add into index.template in any given variation. Preferably after the body layer, so a new framing could be added. Possibly also separate the pure framing elements of Curve, so they are easily replaced. In either case: it can be changed with CSS too..so its not *really* necessary.
  

With these changes you gain the benefits of:

- every mods will install without problems(at least not due to custom theme code).
- CSS changes are maintained during upgrades.
- No need to provide a big section for themes, only the variations.
- "current theme settings" will be a thing of the past, since ALL settings apply to default theme anyway.
- easier previewing since only the CSS file - and possibly hooks - will be previewed.

The downsides are of course:

- no truly unique layouts possible other than by modding the templates, which could be argued being better since less new theme code will be inserted. A whole theme is potetnially repalcing bits that don't need replacing.
- site owners that needs custom themes will need a designer to hack the default theme - but again, that could be a mod rather, applied after upgrades for example.

* * *

I hope you seriously consider this for SMF 3(or earlier) since you would move forward in the mod/theme dilemma. It might introduce new problems too, but that won't outweigh the advantages by changing the system.

[Ashley S]

I agree with you Bloc .

[Masterd]

Nice suggestion. I also agree with you.

[redone]

There certainly needs to be a more streamline way of including custom code in your forum- that obviously effects themes for the most part.

For beginners the good thing about curve has been that ability to modify very easily. Simply put but not done is the separation of modifications from themes period. Not easy but very essential for future versions of SMF.

~RedOne

[bloc]

There certainly needs to be a more streamline way of including custom code in your forum- that obviously effects themes for the most part.

For beginners the good thing about curve has been that ability to modify very easily. Simply put but not done is the separation of modifications from themes period. Not easy but very essential for future versions of SMF.

~RedOne

This isn't new - I talked about this for over 4-5 years ago and nothing has happened since then. If anything its gotten worse, so I am done trying to change it.

The sad truth is that no-one cares about innovative and exciting themes - but they do care if their 50+ mods work or not. So why waste a whole system on themes which no-one utilizes anyway? The conclusion is to remove it and bet on variations instead.

Give me just ONE example of a theme that fully use the system today.(aside from my attempts) If you do find one, compare that to the 100+ other themes that DON'T. The math is quite simple here.

[Arantor]

To be fair, the majority of those who actually tried to push the boundaries of what could be done with themes disappeared a long time ago. The same is mostly true of mods, too, that people who really put in the time to come up with something different and new mostly left a long time ago.

Consequently, the only knowledge that's left is how to approach things from the simplest direction - for themes, we're talking simple variations; for mods that's the shortest route to achieving the result by template changes. So much more is possible without template changes, yet invariably it doesn't happen.


I actually have a few examples of this drawn from the work that's gone on with SimpleDesk, both historically and recently. It has a feature whereby you can turn off the forum stuff and just have a helpdesk, which is cool since you get a bunch of themes for it But that means removing the unread/unread replies links from the header, as well as the search box since we don't have a search function (yet). Now, I could have done that with template edits and driven myself mad(der), or I could be a little more creative and use the buffering system to allow me to edit it after the templates are done - without a template edit.

Another thing I've been playing with is the ability to present the helpdesk as a board, much like Project Tools can, except I was conscious of two problems: users with custom themes with a custom board index, and users who use things like the vB style board index mod, both of which prevent Project Tools from working to its best. But armed with the knowledge of SMF and a suggestion from SleePy, I crafted it to work without a theme edit, and still present it nicely - and however the theme would make use of that information.


What I'm getting at - slowly - is that the problem is not so much people wanting their mods to work (hell, I want all my mods to work too) but more about the fact that the mods themselves do not go into as much thoroughness and depth as would be best for them to do, and invariably the shortest route between two points is what's taken. I remember spending so much more time on mods to avoid making theme edits and I got a much lower support overhead as a result (then it just became a mess of people whining about things I didn't want to implement, but that's another story)

What it really needs is people generally to build mods better, to not require theme edits where possible, to make use of the full range of techniques to avoid theme edits so more and more mods work on more and more themes. It's possible to do all kinds of things with sufficient ingenuity, as I've proven more than once.

[Antechinus]

Why remove the ability to make truly custom themes though? If people don't use it very often is that a reason to stop anyone ever using it? Personally I'd like to think we could keep that flexibility.

[Arantor]

Because the rest of the SMF ecosystem actively forces themers NOT to be custom.

People want their mods to work and they'd rather sacrifice themes in the name of mod compatibility - in which case, might as well remove custom themes so that mods always work. It would certainly improve compatibility of mods and raise the profile of SMF as a whole that mod installs are more likely to work.

You'd still have jokers like me who go to extreme lengths to avoid theme edits, but people like me are the distinct exception. Can you imagine someone carving up Subs-BoardIndex.php to build fake boards (and even fake categories at times) and adding a call in the output buffer handler, instead of just tacking the new markup into the theme? Honestly, can you imagine that? Because I can't.

[live627]

But would ripping out the theme system truly solve the problem? Let's think about that for a minute.

A higher load would be on the support staff because people would constantly be asking (demanding) how to change the look of their site. And such an action would possibly cause a rebellion since people would be like "Oh SMF used to support themes but now it doesn't while everybody else does, bye-bye!" They would leave SMF and these events would pile on to each other like pancakes and would ensure nails for the coffin.

And once the theme got modified, mods get more or less compromised anyway, so what's the point?

I'd like to propose something different. Infest the theme with hooks. Place a big, bold alert on mod installs that modify the theme. Maybe even disable $themedir altogether.

[Arantor]

Maybe even disable $themedir altogether.

*shrug* Then you have to disable $themes_dir too Oh, and it'll break mods that add images into the theme dir, or CSS files...

Yes, you can throw a boatload of hooks at it, it'll certainly help. It won't achieve everything though.

[Norv]

If the problem is that mods edits cannot be done in certain custom themes... then:
- you can switch (deeply changing) custom themes to mod packages. That doesn't remove themes..., it forces them in mod format. That allows a bit (arguably) better handling because at least it shows you when there are conflicts, it edits less code, too.
Yet, you'd still have the conflicts, because if you couldn't install a certain mod on a custom theme as it would be today, then if you package the theme as a mod, you'd still have that edit fail.
- you can have an API for theme insertions/changes. (i.e. hooks, events, etc). It will allow you to do things that change the layout (certain defined parts), and can be used both for a "theme" as for a "mod".
- you can have an API to add parts of your own...

Why do mods modify themes?
This is a serious question.
We have many mods in this community, testing the possibilities of what SMF can be made into. What are the things that mods need to modify themes in order to do them?

[Arantor]

Why do mods modify themes?

Invariably the answer isn't because they have to, it's because it's the shortest route for them to do so. I've demonstrated time and again that theme edits do not always need to be done, even for very complex operations.

Case in point: SimpleDesk removes links and facilities that appear in the default theme and in index.template.php and yet doesn't require a theme edit to achieve this. It also dynamically extends the board index to produce custom boards that are directly geared to it, and yet doesn't require a theme edit for that either.

In the past I've also added an MP3 player widget to attachments, a popup menu appearing on the usernames in posts - and all these without template edits.

I'm sure if I go back through the mods I've written I can find you more examples where functionality that traditionally would be done with theme edits can be added without, though it's through hoops. Adding hooks removes the need to jump through hoops so much, but a far bigger problem than the lack of hooks is the lack of people willing to spend time getting to understand SMF's internals to the point where they would be able to achieve things without theme edits.

I'm not a genius, far from it. But I am resourceful enough to examine the source and figure out how to avoid theme edits where possible, for the benefit of everyone else who uses my mods. But most modders are not that resourceful, and as such a theme edit becomes all is going to be done.

[mashby]

I guess there are two types of "mods" from my experiences. The first is more literal. It modifies or adds to existing functionality. ImagesOnBoard/CBI is a good example. Adds an image next to each category when viewing the board index. I know I'm leaving out a billion others... The other adds functionality. AEVA/Gallery/Media mods. And these almost always affect index.template.php to add a menu item in 1.1.x (not true in 2.0 though) and independent display/source files.

To me then, a theme should really just be affecting the entire look and feel of the site (index.template.php). If I ever install a theme that has more than index.template.php (other than the obvious CSS and images stuff), I always delete the extra display files like BoardIndex and others.

[bloc]

Why remove the ability to make truly custom themes though? If people don't use it very often is that a reason to stop anyone ever using it? Personally I'd like to think we could keep that flexibility.

"Not very often" is an understatement lol, you can count the themes that does it on one hand only, at least the free ones. Are the custom themes on peoples sites more "customized" than the free ones? Perhaps. But in both cases its a highly underused system and there have been done VERY LITTLE to resolve that. Yeah, the hooks are good..but thats just adding buttons to a theme. And theres certainly no documentation easy available that show just how modders can use the various hooks in source files..not one that i am aware of.

The problem is still there: mods modify themes out of convenience, lack of knowledge or something between. Theme authors dare not change it since they know many will need support on how to make xx mod work. They rather have the theme work right out the box, and who can blame them? Most of them are designers first, coders second. It discourages them to use the system fully, thus its a waste of resouces. Color variations are more than enough to accommodate theme needs then. I am sure that with minimal changes to Curve it can be even better to throw only CSS edits at.

I guess there are two types of "mods" from my experiences. The first is more literal. It modifies or adds to existing functionality. ImagesOnBoard/CBI is a good example. Adds an image next to each category when viewing the board index. I know I'm leaving out a billion others... The other adds functionality. AEVA/Gallery/Media mods. And these almost always affect index.template.php to add a menu item in 1.1.x (not true in 2.0 though) and independent display/source files.

To me then, a theme should really just be affecting the entire look and feel of the site (index.template.php). If I ever install a theme that has more than index.template.php (other than the obvious CSS and images stuff), I always delete the extra display files like BoardIndex and others.

Which proves my point exactly. SMF users can't be expected to be visionary and see what a full-on theme system can do, that has to come from the team -> meaning MORE must be done to solve this problem. But if the team doesn't see it as a problem, then the only logical conclusion is to simplify it and remove the full-theme feature altogheter.

Lets look into the future. Right now I know that at least mysefl dabbles in making changes in more than index.template. When I stop doing that there will be nonw(that I am aware of at least) and people will continue on the current trend: css and index.template, nothing more. In SMF 2.x more edits will prob. make into Curve theme to make it better, perhaps even a new theme will be added. I do foresee a new theme BASED on current markup though, just because so many themes/mods now rely on Curve anno v2.0.

So who will use this wonderful system then?

[live627]

Yeah, the problem with the hooks is they're relatively obscure and unknown. However, there is a document in the wiki here attempting to change that...

A hook can be added anywhere, not just expanding the buttons like now. One can be used in Settings to extend the theme settings; in Display between each post for HTML ads and blocks; on BoardIndex to change the list; GenericControls to add to the post buttons; I could go on to cover each template. But the point is: hooks can extend anything from the moon to the kitchen sink.

[Arantor]

Yeah, the problem with the hooks is they're relatively obscure and unknown. However, there is a document in the wiki here attempting to change that...

And it's a virtually direct copy of my guide for RC3, which means it's missing some hooks and is likely incorrect in other ways too.

[live627]

(See my edits to the wiki, albeit incomplete)

[Norv]

A point that I need to make here is:
The "shortest route" is not a bad thing, here, it's most of the time a correct way to do it. Mods should not be forced to take a "longer route" (and sometimes disputable) in order to make visual modifications that have less maintenance issues. Modders should not have to read all SMF code in order to know how to do a simple thing with less maintenance issues. If it is really necessary for them to take too long or disputable workarounds in order to achieve that, then that is bad design of the software itself.
Modders should not need to deeply modify core in order to do visual changes in a way that is less conflict-prone, less error-prone, with less maintenance issues than they have today.

On the contrary, if making visual modifications is prone to maintenance problems, and/or affects themes creativity, SMF should provide easier ways to do them, in a way more viable in the long run.

That said, may I go back to the details

Adding more hooks, that mods can use to modify/insert bits of data or implement behavior, without directly modifying the core, will help. We know that. That's on a rather short-medium term though, i.e. 2.1, and it will likely bring an improvement, it won't be exactly a silver bullet.

You know... It's amazing in a way, to see how popular hooks have become, since RC4 added a little API for their easy use (along with a few more for heavily modded areas). Sure it can be much better, but it's still amazing, because hooks were always there, they weren't many, yes, but they are not many today either. They're not properly documented yet. They're not made known properly yet. The API is really basic for now. And still, after this little API was added, along with a few hooks additions, we have suddenly received much more interest about them than one would expect from a (currently) under-documented feature, questions, requests to add others, from everyone, community, modders, team.
We knew it was the right thing to do, but it's still amazing how it turned out.
An easy to use and understandable API to do things - and it can be much better -, without needing to edit themes (and not only themes), means exactly: a way to do things that doesn't require to heavily delve into SMF innards, on the contrary, and still have little issues on the long run.

Don't think it's a silver bullet though. It's not. It's just a little step in the right direction. There are more to make.
A last note on this: please feel free to propose hooks for needed areas (for 2.1), help with the documentation (thank you,  Arantor and live!), examples of use, point out whatever you feel it's lacking. It took off unexpectedly well under the circumstances, but there are a lot of things left to do there, and we need your feedback and help.

[Arantor]

The "shortest route" is not a bad thing, here, it's most of the time a correct way to do it. Mods should not be forced to take a "longer route" (and sometimes disputable) in order to make visual modifications that have less maintenance issues.

So, a route that quickly causes conflicts is the 'correct' way to do it? Really? Thank $deity then that I'm stupid enough not to use the 'correct' way.

If it is really necessary for them to take too long or disputable workarounds in order to achieve that, then that is bad design of the software itself.

Then SMF is badly designed. Any theme that wants to be creative has to do so at the peril of making mods more fragile, which was the point of this thread, and is why most themes just don't bother being creative. Mind you, most mods conflict with one another because of the same problem...

On the contrary, if making visual modifications is prone to maintenance problems, and/or affects themes creativity, SMF should provide easier ways to do them, in a way more viable in the long run.

Yes, it should. In case you missed it, this thread was about forcing SMF to stop sitting on the fence and pretending there isn't a problem with the status quo, because there is.

Sure it can be much better, but it's still amazing, because hooks were always there, they weren't many, yes, but they are not many today either

Apart from the fact that they were fundamentally broken, unusably so, prior to RC4 because you could only ever call one function per hook at that point, and there weren't very many hooks that were actually useful outside of integrating SMF to something else. These things changed, which is good.

Mind you, I stand by my assertion that the current changes are half the job, either they should have been left alone (in line with the feature lock) or done thoroughly, not scattering maybe a dozen new hooks about the place. There are reasons why other systems have hundreds or thousands of hooks... not a couple of dozen.

A last note on this: please feel free to propose hooks for needed areas (for 2.1)

Just ask SlammedDime, that's a good enough head start. Though how about every single action, every single template, breaking some of the stuff down into more modular units, then having hooks for those too.

Oh, and the ability to actually require a file elsewhere other than just on the main page load, I don't want to add a trillion files every page load if I don't need them, thanks.

[bloc]

You know...if SMF really wanted to finally let mods-changing-templates and themes-changing templates co-exist in harmony, you would pick up ideas that were brought up ages ago: that of compiling templates.

Hooks are nice, but they are too few and too late IMO. The theme-base won't change now, not now that so many mods will prob. not even convert to it. It should be done years ago.


But maybe this is really futile anyhow... do people really WANT other themes than the old trusty "standard forum" layout? Ask Mashby here, or any of the others that agreed on my proposal in this topic and you will know the answer is a resounding "no".

All the more reason to stop pretending SMF is such a great theme-encouraging software when no-one use it anyway. So clean out house and bet on variations - simpler and cleaner and no doubt following the tradition so far anyway.