Install in Other (New) Themes

[James Gryphon]

Version
SMF 2.0.15.

Description
A mod that allows admins to go to the package section, and only "install in other themes", so that new themes can be added without the hassle of uninstalling and reinstalling every single mod.

Permissions
Available to anyone with the ability to install mod packages.

Feature Set
There needs to be a way to access the 'install' page from the main packages list, as well as 'uninstall'. On the install page, if there were a checkbox next to the main installation section, so that it can be activated or turned off like each theme in 'install in other themes', that should suffice for every purpose. That way, you can check the box next to only the themes you want to install the mod functionality on without changing anything else.



This has been requested a number of times for the 'next version of SMF', but I'm not sure if anyone ever thought to ask for a mod that does the same thing. The go-to answer in all of those threads was 'you shouldn't have to do it this way, use hooks, etc.'. Now, that might be the best way, and it's understandable to take that approach if we're talking about features for 2.1 or 3.0 or what have you. However, that doesn't help us much right now, since the reality is that for 2.0 there are quite a few important mod packages that do exactly that, as well as image files and things which don't get automatically added.

[Arantor]

If mods were probably written this wouldn't be necessary at all.

It's also reliant on mods being correctly installed first time and no manual edits taking place, and implementing it would break some mods that already exist.

Couldn't recommend it, it would actually cause more damage to try to have this than to make the problem go away in the first place.

[James Gryphon]

If mods were probably written this wouldn't be necessary at all.

Well, users deal with the mods there are, not the ones they wish they had or should have. It's good to talk about how things ought to be when we're laying out a foundation for a future platform, but it doesn't change the fact that many, perhaps even most, mods don't actually work this way in the present. If time spent unnecessarily uninstalling and reinstalling everything can be saved now, I don't see why that should be avoided on the grounds that the problem shouldn't have come up to begin with.

It's also reliant on mods being correctly installed first time and no manual edits taking place, and implementing it would break some mods that already exist.

If the installation was broken, though, you already have a problem, and will whether you have access to this or not.

As far as manual edits go, the current system of uninstalling every single thing and reinstalling it all over again isn't any better. In fact, this is an improvement in that area since there's the possibility that the changes to other themes aren't that substantial (adding a few image files or tweaking a couple of lines of CSS), just tedious to do by hand.

For existing mods, I'm unaware of an example of this and would like to be clued in; if they don't affect the package manager, I admit it isn't clear to me how it would break them.

I'm not trying to be rude or antagonistic, and I apologize if I've come off that way. I just don't see at present how telling the package manager to not do anything except a step that seems to be already separate from the rest of the process (enough so that you can choose to omit it, without any ill effect) is worse than leaving the real inconvenience it's attempting to patch alone.

Now, if changing the other themes isn't an isolated step, contrary to what the GUI seems to suggest, then I could understand the hassle here. I'm not aware if that is the case or not; if it is, I'll certainly stand corrected.

[Arantor]

I think you misunderstand.

You're assuming the package manager can accurately track which themes a mod has been installed on. It can't.

Let me explain. You have default and core, you install a mod, you install successfully to default, but core doesn't. Let's say you fix core by hand... how can SMF know you have installed it into core?

It can't so next time, it'll ask you to install on core and whatever other theme you might have, because short of you, personally, editing the database, it has no way of knowing whether it is installed or not.

And if anyone uses the previously published tool to mark things as installed, all bets are off.

Instead of trying to fix the symptom, a much better use of effort would be to make mods that don't need manual edits in the first place.

[James Gryphon]

Ah, I see, and I think you overestimate my intent.

I wasn't expecting it to keep track of what anything's been installed on. I supposed that the admin would do that on their own. I appreciate that it's a hacky solution and that there's potential problems with that, but there's problems as it is.

As far as manual edits, it's not really about that. The idea is more about adding the things that the mod didn't add the first time around (because the theme got installed after the mod and wasn't there then). It would make having manually edited mods easier, probably, but if someone wants to run a forum that way, that's their problem; caveat utilitor.

[Arantor]

Firstly, I wouldn't trust any SMF admin, not even me, to correctly and accurately keep track of that.

Secondly, I'm aware SMF already tracks this as best it can in its own logs...

Thirdly, I'd still encourage spending the time and effort addressing the actual problem, not one of its symptoms. Bear in mind I frequently deal with things that are "impossible" like how the 2.0.14 login bug *had* to be a theme edit until I did a proof of concept making it not required to be a theme edit... and it applied to every theme and mod.

[Gwenwyfar]

I think this could be a good idea too. It could even be as simple as a button to "install mod only in this theme", maybe with a button to do all of them in sequence.

If you just installed a new theme, then you know for sure none of your mods are installed in it. If you have failing edits to do manually anywhere else, it becomes even more of a mess to uninstall and reinstall. If keeping track of what you have installed is hard, doing that on manual edits you did is even more complicated. I eventually made a local github repo just to keep track of a few of those things, even having just a index.template.php in new themes I still would have no clue what changed in it after a while. The best alternative ends being: Don't install any new themes, or do it before you install any mods.

It would be nice if the problem could be avoided or didn't exist at all, certainly, but we can't change the fact a very large chunk of all mods in the mod site do a lot of edits, and we can't force all authors to not do it. I'd personally wager for themes to not edit the html at all instead, then that would hardly be a thing in the first place.

[Arantor]

Except for the fact it invites (and makes more likely) double installation issues.

[Gwenwyfar]

It should install in one theme only. If you use it without being sure where it has already gone to, then yes that could happen. But it would still be better than doing everything all over again just because you want a new theme.

Might be more problematic if you end picking the wrong theme and don't notice, but this would depend on how the interface looks like.

[Arantor]

*shrug* I just think it's a bad idea, just as putting "remove all hooks" in repair_settings is a bad idea.

I'd especially encourage people upgrading mods to 2.1 to do it properly but even that isn't happening from what I can see.

[Gwenwyfar]

I'd especially encourage people upgrading mods to 2.1 to do it properly but even that isn't happening from what I can see.

These three things are not exclusive of each other and can all apply at the same time.

1) If it depended only on me, themes would not edit the html. It specially doesn't help that we allow authors to use html for things they should edit in the css, and that could be at least something too.
2) Mods for 2.1 still have stricter requirements on using hooks where possible, and we could definitely encourage that in other ways as well.
3) A lot of mods are still going to continue being problematic (plus, not everyone will upgrade to 2.1 straight away) and the way to handle it with the standard software is poor at best. It's a trade of bad for a different type of bad.

[Arantor]

1. Requires a rewrite of theme system. Tough but doable.

3. It's only problematic if you let it be a problem. I already experimented with this approach in Wedge and until it was undone after I walked away, it encouraged making hooks more powerful and more effective rather than doing template edits.