No worries about derailing the topic. I think it's important we have this conversation, really! :)
This is going to be a long reply, sorry!
Bugfix mods make sense IMHO. Easy to remove and then install the official update later. Hard for hooks to do this.
I'm not opposed to bugfix mods, per se. The fact that someone bothers to find a bug and post a fix is, on the whole, a good thing. I brought it up before, because it's one of the many infuriating things, that they can't seem to agree on a policy and actually stick to it.
In the SMF climate in particular, and in similar other climates, it indicates a few less desirable characteristics:
1. If your community is producing bug fix packages, we have to ask the question why aren't being made part of the core product?
Is it because your release schedule is far too long and people need the bugs fixed before you can/will get a new version out? Or is it because for some other reason, you're actually not going to incorporate that patch into the core?
In the case of the IE8 jumping text bug, having a mod submitted by one of the core dev team, rather than actually fixing it in trunk (considering that, in the timeframe of a matter of days, a patch to 1.1.x was actually released) - I cannot see any justification for *not* patching it.
2. It discourages people from upgrading. To me, an upgrade shouldn't just be about fixing problems, it should be an overall iteration on what was there before, so improvements (not necessarily new features, but improving existing ones) as well as fixing bugs.
I was amazed how many people weren't upgrading to RC5 because of a bug in RC3/4 and that they thought it was sufficient to use the small patch rather than actually doing the upgrade. Some of those people won't upgrade to final even though it has security-related changes.
I don't exactly want to encourage bugfix mods, which won't be possible with just hooks anyway, if nothing else it means that something else is wrong in the development process.
Definitely. And this is a large problem. However, fixing it by accepting the poison (of no one doing anything interesting) seems like a bad solution to me.
Oh, I'm not accepting the poison. Having spoken to as many people as I can on it, the one factor that seems to be causing it predominantly is mods, and that with having to 'dumb down' what they do because of kow-towing to mods, I went the other way. By making it so mods aren't able to touch templates, or at the very least, if they do (through TOX-G), they can do so non-invasively, that hurdle virtually ceases to be a hurdle.
I accept there are uses for direct file edits, but the more I think about it, the harder I find it to justify having direct file editing as a base feature.
The biggest problem with it is that it promotes a certain level of being lazy. For instance, there was a mod that set up a default avatar. The quickest route for most authors to implement that would be a template edit - with all the problems that brings, and far too few authors would have implemented it in loadMemberContext - though it did happen eventually.
Most of the mod authors are not strong programmers, and invariably look for the easiest route to implement something, which means template edits in the first line of attack, source edits in the second, and almost never taking advantage of the resources actually in SMF to pull some of it off.
It's only since RC4 and RC5 that we're starting to see authors actually take the time and effort to figure out smarter ways of implementing mods, i.e. using the expanded hooks now in SMF. (It's still broken, structurally, but it's a lot better than it was.)
It's kinda like if PHP had say, "ah, PHP 4 classes suck, so no one uses them. Got it - let's just remove them in PHP 5."
Not to me, it's not. The comparative statement would be "ah, PHP 4 classes suck, so no one uses them. Why does no-one use them?" IOW, start by figuring out why no-one uses them, what is it they're after, what is it about the current behaviour that's broken?
When I asked myself the same question about the package manager, about what was broken, about what I wanted to see it capable of, I came up with the following:
* File permissions, and making files writable to PHP, is one of the single most asked questions on the support boards -> can we make mods that don't need to make the core files writable?
* Mods only working on certain versions, people asking whether mods will be updated -> does a mod expressly have to ask for a version, or can it attempt to determine if all the features it needs are available?
* Mods searching for code and not finding it, because the original code has been modified (either by a later version, wherein even the comments get modified sometimes, or by another mod) -> can we make mods that either don't need to modify the files, or can better manage to sort themselves out without having to trip over each other?
* Mods that need to modify templates -> why do they need to modify templates? Does it always have to be a template edit, or is it about the data the templates output? Can content be injected into a template in some other fashion?
The first one screams hooks. The second works better if hooks are available because you can even do detection then based on an add-on requiring certain hooks in order to work, and if they're not available, it won't work. The third just generally pushes away from editing files in general, and the last implies something like TOX-G.
It wasn't entirely a knee-jerk reaction as Nao could probably confirm; originally I planned to make the package manager be able to handle more, like registering hooks and so on from the get-go without having to dive into making an installer script, but the more we talked about it, the more I felt comfortable abandoning file edits in the base.
However, something like an "RPG/Shop" mod (a constant request, or at least used to be) is somewhat more specialized and can't always be done via hooks.
It does come up regularly enough. I'm not sure what you couldn't do with strategic insertion of hooks, it doesn't need to be insane.
Fixing that is a separate issue, though. Overreacting to a problem by fixing it too many ways is a bad fallacy.
Or, as I tend to find, you're solving the wrong problem: the solution applied is right for a different problem to the one you thought you had. I don't honestly think the approach I'm pushing for is wrong. It has pros and it has cons, like everything else, and I believe that overall, the pros outweigh the cons more than in the current scenario.
Sure. In part, this is probably because building package servers is just plain not documented.
It's not that hard to figure out. But premium sites can't use it because by definition everything in a package server has to be accessible by a simple GET and as far as I can tell, without any authentication handling.
I dunno, having looked around a bit on occasion to help people, I found it very fragmented. I agree that SMF doesn't have an effective set of themes or mods.
To me that's a consequence of everything else: all the stuff we've talked about here, seems to me to discourage creators from creating new big stuff, and to a lesser degree, new little stuff too. I would note that all the big projects (the portals, Aeva, SimpleDesk) almost without exception go back 2+ years - SimpleDesk is the only really sizeable mod that turned up in 2010 from what I remember, though there are a handful of modestly sized mods (such as the WP user integration or SimpleSEF) from the same sort of timeframe. What I'm getting at is that the big stuff goes back and the smaller stuff is what's emerging - no doubt 2.0's slow dev cycle was a major factor in that too, with no-one really willing to contribute anything until 2.0 final came in, with all the retesting and updates required for each RC.
The thing most people seem to forget is that the bulk of mod authors aren't people just writing stuff to give away - they tend to write it for themselves and their site, then share.
Going back to the list of mods in particular:
1. I don't see why this shouldn't be a "mod", if you will, just one that applies equally to all themes (if the theme has a facility for showing that type of user information.) This is the sort of problem I tried to fix with TOX-G.
It's a tweak, changing the existing behaviour. It's not really a 'new feature', is it?
2. This seems like a good candidate for a core feature. Ideally, it should be built to that standard (I'd always wanted to see features "baked" as mods before going into the core, not sure if that ever happened.)
This is a particularly weird case. It is actually a core feature, just one that has no admin interface and is undocumented. All the mod package does is provide that interface in the admin panel. (It's been a core feature for years, too.)
3. Bugfix mods make sense IMHO. Easy to remove and then install the official update later. Hard for hooks to do this.
See above. If you have to accept bugfix mods, there needs to be a reason why they're not in the core, especially when they affect a lot of users.
The Google +1 button is in between being a 'tweak' and being a new feature of sorts. And any such change, where it is per post, seems to me like it's tweaking the layout and presentation - and an ideal candidate for something like TOX-G, rather than having to modify any code.
5. This definitely seems like hook territory. I assume it's got its own area and doesn't touch other sections.
Yes. It's even implemented actually using hooks, too.
6. This is a harder problem, but if it uses jQuery.noConflict it shouldn't cause issues even if there's a separate version of jQuery on the page. That said, a consistent js framework is a good idea.
jQuery is a core feature in Wedge and is slated to be in SMF 2.1 too. But it's slightly awkward that there's no facility to figure out what JS is being included and whether you need to include it yourself. (This is possible with Wedge.)
7. Sounds like hook territory.
Or better IMO, make the editor buttons configurable to the admin, so if they want to add them, they can. But yes, this could be achieved with hooks (even in SMF) and I don't think it is.
8. Sounds like a fairly basic mod that has no theme problems.
Well, I'd personally debate that it should be a core feature rather than a mod.
I get the feeling that we're never going to entirely agree on this, but where we're coming from, I think we both feel justified in the stance we take - and are prepared to defend that if necessary. I don't feel uncomfortable with kicking out file edits off the bat, because if they're actually needed, the mod author who needs to use them can document them and deal with it.
The other thing is, a number of the popular SMF mods, I'm going to be writing equivalent (not necessarily replacement) versions of, and making them available, so I'm also making sure the system is capable of the things that I want it to be able to do; I'm not just designing this in some hypothetical vacuum of what it should or should not be able to do, I'm actively building it for my own use as much as anything else.
I think the reason for small tweaks being the most common kind of mod is that the whole review thing scares away mid-sized mods
I'm not sure it does, to be honest. I think it's more systemic than that. The mods that are big and scary (SP, TP, Aeva, SimpleDesk etc.) all have one common thing: the actual code editing SMF is relatively small, and everything else is in their own files. Meanwhile the mods that are small are just pure code edits (except for the few that are now hook-only).
You mention phpBB and vBulletin... I thought phpBB mods were still, basically, find/replace instructions. (A cursory examination of the phpBB site seems to bear this out but it is strictly a glance rather than a proper study)
As for vB, I have no idea, never used it as an admin, never particularly wanted to.
But I've seen even large-scale phpBB mods done, well, as lists of file editing, which says to me either there aren't hooks, or they're not really in use much.
I'm not sure why SMF doesn't have much in the mid-range, but I'm fairly sure it's not the review process. Small mods are fine with the find/replace approach, but larger mods invariably tend to need more changes and after a point it becomes too much of a pain to maintain with all the changes, and/or they start outgrowing the confines of doing it like that and start needing their own files.
That all said, I'm willing to bet that part of the problem is simply that most mods are contributed by people in their spare time, without any interest or desire in writing big and complex mods - they wrote things for their own site(s) and leave it at that. They don't need or want big and complex mods, so they don't write them. Which also comes back to the lack of premium contributions - what I've seen tends to be that paid mods come into a market first then free competition springs up in response, but SMF didn't really go over that tipping point.
Hooks cannot possibly solve every thing a mod ought to be able to do, and if they are really enforced, you're only relegating to always being in the situation of large only-just-touching mods and tiny tweak mods.
I agree, to a point. The thing is, apart from the fact that it doesn't seem to have hurt MyBB or WordPress (and especially WordPress), I'm not convinced it will restrict to large or tiny mods. As I've proved before now, all kinds of curious things can be done with some ingenuity even in the current SMF environment (like, for instance, adding multiple helpdesk departments as boards to the board index, but using a custom icon, custom description and link and so on - without a single template edit, even if it is woefully ugly because the structure just doesn't support it normally)
There is one overriding factor here. SMF and some hooks and a hook manager won't be enough. It won't solve the problem at all to do that.
For example, permissions. It's easy enough to add new permissions provided all you want to do is add new permissions for per-board profiles or to a group generally, but anything else, you have to implement it yourself from scratch. Aeva, SimpleDesk, Project Tools and others have had to do this, because the existing system only lets you expand it in one dimension when it needs to be able to provide for two - even if it only barely uses the second dimension itself.
Or, the board index as I mentioned above - there's no reason why there couldn't be an expansion of the board index, not only to be able to understand the board structure and hierarchy but also to have some awareness of the *type* of board, so that new things can make use of it if they want.
That's really what we have to do: just expanding hooks on its own won't be enough. We have to make everything else be more open to extension too, and upon doing that, almost anything should be possible.