General observation about mods and themes

[Rozak]

I've been playing around with SMF now for a few months, building a few different sites for different things - wonderful stuff - the consistent issue I see is that while the application of mods and themese is reasonably automatic in principle, as soon as you add 'enough' it becomes increasingly more and more problematic to add or upgrade. Having now had to hand-hack more and more changes into sites one thing that struck me was the need to have some more standardised 'plug-in' points in the base code.

There are some fairly obvious common places in the distribution code for adding tabs, pages, menu options, admin features, new permissions, $txt[] entries etc - but the community as a whole appears to be somewhat 'lacking' in its adherence to these placeholders.

As I look over the posts and comments in the various mods and themes available for download most of the issues are along the lines of 'it broke my forum' or 'it installed but I cant see it on theme x'.

Having looked over most of the source and spent a long time working my way up and adding several downloadable mods and themes, and now working on my own mods,  it struck me that it might not be a bad idea to populate the distribution code with some 'known' comment blocks - places people can hang modifications on. For example '// INSERT NEW MENU OPTIONS AFTER THIS LINE' springs to mind, or '// PLACE YOUR ADDITIONAL $txt DEFINITIONS HERE' - or at least something that can be searched and used to hang code diffs on.

[bloc]

Good points..and something we aim to improve in future versions. The template files needs some more common "anchors" and sections to search for, both in default theme and certainly in custom themes, where most of the trouble arise.

[Paracelsus]

I support 110% your observation...


MODs and Themes difficult coexistence is for me Achilles tendon of SMF, its weakest point.
Over time, SMF has encouraged the modification process of the base code and it was that small but very important detail that turned SMF into one of the most well-known fast-growing/developing forum system. But one has to put order on this. Customization is good, but chaos is bad. Therefore, I really do believe that the SMF Dev´s have one task to accomplish which somehow seems forgotten: to turn SMF systematic to develop, specially for the average/initiate PHP user.
It´s not that we don´t like challenges (I personally love to cut here, put there, try this and that to customize everything), it´s just that we don´t like to get too frustrated. If for every "average installing difficulty" MOD and Theme we get a "very high installing difficulty" when we put them together, then we start to have a real problem.

[bloc]

Well, the trouble will always be there, as this is somewhat inherent in the system. SMF is not meant to house zillions of mods nor loads of themes. If you install mnay of each, you WILL have a lot of work to do - especially if your website doesn't allow package manager to run for example.

Aside from that, having more common "things" to search for is helpful. But degrading the theme system to make it more "easy" to adjust, will not happen. Thats crippling a very powerful and good feature in which SMF really shines.

[Rozak]

Yes Bloc - agree with you totally, I've tried many many different forum/CMS platforms and finally settled on SMF for a whole pile of reasons - but primarily because the code base itself is pretty simple to get inside and making changes, adding features and generally making it do what you want it to do is generally straight forward. Also agree that if you are going to apply mods you are already in the realms of having to get your php screwdriver out and play a bit to get things working.
The modification/packaging process generally hangs off 'known' text patterns in the code, all well and good when dealing with a reasonably un-tweaked platform - but even something as simple as augmenting the current code base with a few well choosen comment fields would help make that process a bit more robust - and making those who choose to create themes (where >50% of the trouble comes from) can then at least try to make their themes replicate some of the comment.
The other way (and probably a bit more professional ) would be to introduce an additional layer of abstraction in the code for mod and theme creators to use.
By way of example, introducing an additional tab into the main menu across the top of each screen is pretty trivial to do, but still requires some tweaks in the core php files. Having this seperated out into a more 'friendly' configuration file just make it that much simpler.
Anyway - like I said at the start - just an observation and something to park in the mind when looking at v2  

[vbgamer45]

I love some things to be made a little simpler to understand for mod and themes. And for me for mods to install easier on other themes. Would be hard to make these changes for the themes.

[perplexed]

I am not an expert or a coder, but so far for me, my experience of this software and adding mods hasnt been too bad   I recently upgraded to 1.1.2 and currently have 33 mods installed and only had to alter 2 pieces of code, which I think is pretty good, especially for someone like me who doesn't know how to code, but can happily cut and paste

It would be nice if mods could install on other themes easier, as I tend not to use them for that reason.  I use mainly default theme with different colour schemes as I don't have time to mess around with it.

[Rozak]

But degrading the theme system to make it more "easy" to adjust, will not happen. Thats crippling a very powerful and good feature in which SMF really shines.

Actually I'm not sure its about 'degrading' the theme system - and I certainly don't think its about 'crippling' it - strong words. It's simply about introducing an abstraction layer that is a little more robust than the one that is in place today.

I mean that could actually be as simple as moving some of the array definitions out into seperate files and pointing people at those to mod, or insisting that the language files in themes are maintained correctly (rather than theme writers installing lines into the core files or into the default language files, or into their own mod specific files) etc etc. The certification process that is in place already can be used to validate that.

I actually dont think this is something that is 'broken' in that respect - just a suggestion for an improvement. I also don't think it is anyone's 'fault' - and in fact most of the issues I've seen in my (small) exposure to the wonderful world of multiply theme'd SMF sites the issues tend to arise from over-generous mod hacking around inside all sorts of places in the code and non-comformant theme source. There is also the issue of varying levels of programming consistency/capability between mod and theme authors to content with.

The only point in raising this here was to say, basically, flicking through the forums, reading people's comments, playing with SMF - the largest cause of 'posts' and 'pleas' for help relate to the mod v template system and that there are a couple of ways of improving that - additional comments in the source will help (rather than having to mod against lines of code that may change from version to version of SMF or indeed if mod authors themselves have changed lines), an abstraction layer to isolate 'often mod'd sections of code' may well be a big job but would also go a long way to reducing the number of 'help me' posts.

I personally don't think that is a 'crippling' issue - but Bloc you are the developer here and for that I take my hat off and respect your opinion. I'm just a guy with more years of kernel programming behind me than I care to remember. Having seen the benefit of architectural seperation and abstraction in large code bases in environments where source code release is on a grand scale and co-operative development is the key to rapid but controlled incremental change - I merely put it forward as a suggestion for consideration. PHP application deployment is not my area of expertise - kernel development and management is - they are two different problems but there may be common lessons.

[bloc]

I hear you. The need for some more abstraction is def. needed and we are looking into the best way for it to happen. Initally it could mean to separate more common parts into functions. As modding around a function call is easier than trying to mod around the actual(most likely changed) code.

[Rozak]

100% agree

[d03boy]

I personally think there should be interfaces (functions instead of messing with context variables) to work with and maybe an "observer" pattern here or there. That is only talking about using the SSI though. I've never made a theme.

[Rudolf]

The comments are there to hang code to them. They are not always smart and don't always say clearly their purpose, but I used them to hang code to them.
The problem is that when you need to modify some existing code, comments won't help you at all. There will always be people who will get stuck when trying to apply code manually. I use comments around my code in my mods. Those who can't figure out how to apply the changes I made to the default theme to their custom theme, extra comments won't help them.

I think one nice thing would be if the Package manager would at least try to apply the template changes to every theme on the forum. It could be an option.
I think the biggest challenge is how to let the user know which themes failed, without failing the whole installation.
A long time I was thinking about this.

[JayBachatero]

Well DE tries to install the mods in every theme.  If the test are successful it will install on that theme.  If not it will skip that specific one.

[Joshua Dickerson]

Thanks for the suggestions. I would too like to see more places to "hang code." And language strings should be placed in 'modifications.[language].php'.

Rozak: what do you mean by an abstraction layer? I am familiar with the term, but where would we use it? If you mean that we should be moving more towards a MVC structure, I just want to let you know that is a goal of the development team.

[Rozak]

Rozak: what do you mean by an abstraction layer? I am familiar with the term, but where would we use it? If you mean that we should be moving more towards a MVC structure, I just want to let you know that is a goal of the development team.

It's about restructuring the internal architecture of the code to use a layer of indirection - either through something like arrays of function calls that can be used as calling vectors or perhaps using a fairly basic (but more structured) naming convention for function calls in the same way the template system essentially operates, or even using a more explicit file/include mechanism to split out the 'often modded' code areas.

A (very) trivial example might be by looking at the construction of actionArray in the top level of /index.php. Most mods go messing around inside there to add their calling functions to the array - essentially it is the main switching point for SMF. A (very) trivial change might be to split this definiton out (either by file/include structures or through a second level of indirection through a constructor function/vector) to make it easier for people to add entries to the array. Rinse lather and repeat for the permissionList arrays in ManagePermissions.php - another healvily mod'ed area.

The principle is to make it essenitally a 'dont' touch the core code' to add a mod that does the 'common' tasks (adds a tab, adds some permissions etc).

Not sure how familiar you are with file system code inside UNIX kernels but go look at the development of the VFS abstraction layer for a neat (but much more complex) example.

A more simpler process might be to follow a similar example to the rc/init.d type process. There additions to the operating system are dropped into known locations and scanned for at start up - it should be fairly simple to have a 'mod' directory inside SMF where mods can be dropped and either replace or are loaded into core code calling paths - certainly would be a lot less work to introduce a layer of abstraction.

Without knowing too much about what direction you guys are headed (and I certainly don't want to get in the way!) difficult to explain (oh for a whiteboard right now!) - but hopefully that gives you some ideas?

[bloc]

I am in fact experimenting with a new theme where I done some extracting. For example..consider this new code:

Code Select Expand

</head>
<body>
<div id="frame">
<div id="uppersection">
<h1>' , logo() , '</h1>
<div id="user">' , user_section() , '</div>
<div id="site">' , site_section() , '</div>
<div id="navigation">' , template_menu() , '</div>
<div id="linktree">' , linktree() , '</div>
</div>
<div id="mainsection">';
}

function template_main_below()

It will actually move whole sections into functions, making it easier to both radically change the html and mod this easily, as it can ideally just search for the function calls - or the functions themselves. Of course the smaller functions will need html code that allow it to be changed with css easily - so the user don't need to touch the function at all. The calls should be on separate lines though.

[Rozak]

exactly the right sort of thinking - you can even split out the php into files so the hook at the top, say, includes the function defintiions - that way more of the code is protected.

Looking at the way the template system works and restructuring templates in this way actully will go a million miles towards making the mod process simpler.

[bloc]

Yes..well, they won't be gone from the templates, that will in fact limit the theme system a lot, but since they will be separate parts of the same file instead of mixed, the mods can easier target the calls and place their changes. Not to mention ease the theme makers job lol.

Note that this is more of an test-project though, the actual theme system is under development of course, but not quite as dramatic. More use of css and getting rid of a lot of nested tables is number one pri there now.  

[Rudolf]

The main action when creating a mod is to search for an existing text and add something or replace it after.
Searching in one file or the other makes no difference. The more layers you put the harder it is to figure out where I need to change something to get the effect I want. Right now there's already a lot of layers - take for example the user info stuff. First a function loads it from the database, and creates a variable. Then another function fills another variable with basically the same stuff with a little more "formatting". This makes adding an extra profile field a bunch of work - you have to change a lot of things in a lot of place.

I am for a structured programming, and for separating content from presentation and wrapper functions and stuff, but there's a point when it becomes too much.

[Rudolf]

Take for example the template_menu() function in the Theme.
It's only useful purpose I can see for it is to find easier where the heck the main menu is "rendered", and it's easier to move it around (the menu itself).
When trying to modify the main menu the work for a mod creator is the same as it if would be written inline (where it is called).