• Welcome to Simple Machines Community Forum. Please login or sign up.

Multiple mods, multiple themes, and bears - oh my!

Started by TonyG, January 02, 2015, 01:50:58 PM

Previous topic - Next topic

TonyG

I feel like this should be a FAQ and I'm sorry if I've missed the info elsewhere...

Install a mod to a completely vanilla installation.
Now add a couple themes.
The new themes don't have the mod.

What's the proper way to install the mod into those themes?
Uninstall and reinstall the mod? ick :o
Once a mod is installed the only option we seem to have is to uninstall so we once again can click Install and see what happens with each theme. I would be concerned with what each mod might do or not do to the database and the file system on uninstall and then on reinstall.

I ask because the only theme I have active right now is the default/Curve, and that's because most (not all) mods integrate with this theme in v2.0.9 without a problem. Many mods reported issues with other themes so I didn't install the mods to those themes, or at all. Over time I want to go back to see why selected ones failed, and retrofit the theme files with the mods (reporting this effort to the theme authors in case they care). Then after some testing I'll make each new theme available to members. (I wouldn't do this with more than a few because it seems labor-intensive.) I really don't want to uninstall mods and reinstall because that could affect working themes!

This whole process of installing mods into core and themes seems a bit precarious with the Search/Add mechanism in modification.xml. Are there any plans for a an improved mod mechanism which might not be as fragile? I really hope no one takes exception to that - no offense intended. The mechanism obviously works but it does seem very fragile.

So far I have almost 60 mods installed. I'll probably have 80 by the time I'm done adding desired features. I understand that's a lot. I'd have the above concerns for just a few mods. With this number of mods times some number of themes times some number of files per themes, it seems almost certain that there are going to be issues. Is the answer simply "don't do that"? Gosh, that would be a shame.

Thanks.

( And yes, I am getting frequent backups... )

Hj Ahmad Rasyid Hj Ismail

Quote from: TonyG on January 02, 2015, 01:50:58 PM
What's the proper way to install the mod into those themes?
Uninstall and reinstall the mod?

I think so.

Arantor

Yes, uninstall/reinstall the mods is the way to go. Or only install the one theme before you start.

Or only use mods that behave nicely and don't need theme edits.

Yes, we are all well aware this process is fragile. I have been campaigning for years to change this. Sadly too few people seem that bothered to take the time to write mods that don't do theme edits.
No good deed goes unpunished
All helpful urges should be circumvented

TonyG

OK, good to know that at least I have a good understanding of the concerns. Thanks for your time on my questions here.

To clarify: If I uninstall a mod and then reinstall, is there a risk of losing data or settings?
If settings are preserved:
Pro: no need to reconfigure on reinstall.
Con: seems like database can gather some dust that can't be cleared without delicate surgery.

Should we be avoiding theme mods? Should we petition mod authors to approach their work differently? What can we do SMF netizens to help improve this state?

Offhand, it seems to me that one of the main issues with the mod process is that too much is inserted into the modified files.
For example:

<!-- a recognized comment here -->
... code from mod2 here ...
... code from mod1 here ...


The mod2 code comes before the mod1 code because both searched for the same text and did an Add right after that. But now when mod1 goes to uninstall, it seems it's just going to try to remove the exact text that it added. But if we've modified that text, then it won't find that text and the mod will only partially uninstall.

Proposed remedy - if I may be so bold: Use a template system which injects mod code at runtime:
<!-- a recognized comment here -->
<!-- MOD: name="foomod" file="mod1a.php" -->
<!-- MOD: name="barmod" file="bar1.php" -->
Now the code is in a separate file, and whatever is in the 'file' attribute can be pulled in at runtime. We can modify that file with impunity (as far as this is concerned). Removing the mod is as easy as scanning for any comment that the mod in the 'name' attribute. I use a comment here for the example, but this can as easily be a CSS or PHP comment, or an HTML Span tag or some other benign marker that can be parsed.

The point is to get the mods out of the code and just link to them. This makes modding a lot easier too because a mod update just involves an update to the included files, no more changes to core files or themes themselves.

For added points, the template system can allow for an attribute where the mod developer indicates where the mod needs to be in the sequence if more than one mod is present at the exact same spot. In the above case the foomod might want to be the last mod invoked at that point so there could be another attribute called 'seq' with a value "last".

Is there already some functionality like this that I'm missing? Some CMS packages make heavy use of templating to do exactly this.

Arantor

Most mods do not remove their settings on uninstall - they don't even bother housecleaning. Some do actually offer (there's a tickbox for such on uninstall, unticked by default, to remove database stuff on uninstall) but they're still the minority.

QuoteShould we petition mod authors to approach their work differently? What can we do SMF netizens to help improve this state?

Most of the mods were written years ago and never updated. New mods tend to handle this better as the methodologies for this are better understood.

QuoteUse a template system which injects mod code at runtime

You can be bold if you like, just please understand how much effort you are wasting in this. None of the problems you propose are new, nor are they unsolved to my mind. I have known how to solve these for years. It requires architecture SMF 2.x (including 2.1) does not possess nor is 2.x ever going to possess because it requires a ground up rewrite of everything using a proper templating system. Such things invariably have been shot down many times over the years over concerns of 'flexibility'.

Every single concern you raise, every single one has a solution (often going further than you propose) but the actual problem is convincing the powers that be to make it happen. The current dev team has its hands full with 2.1.
No good deed goes unpunished
All helpful urges should be circumvented

Bruce the Shark

TonyG i am, no expert here but your idea sounds solid but this has been thought of before.
Your trying to reinvent the wheel, but unfortunately its been done before.
Sorry to say.

Advertisement: