Or try a diff between the two release trees, which probably wouldn't apply cleanly in most cases.
If you don't have any modifications, of course, this isn't a problem. The only trouble is, the diff is enormous since the RC5->final patch modified every single PHP without exception.
It means your stuff is wrong and has to be rewritten now, no matter what.
Yes, if the API changes in some fashion. That's the single biggest factor in migrating SMF 1.1.x mods to SMF 2.0, in fact.
then I don't think there's generally any good reason for a theme ever to change the meat of an administrative section.
Let me explain what exactly my edits did, and I'll let you judge for yourself. FWIW, I'm of the view that these are acceptable, not necessarily desirable.
I just checked, there are three template edits being made in SimpleDesk 2.0:
* manage attachments
* package manager
* track IP
Manage Attachments is one of those necessary edits. For a variety of reasons, we had SimpleDesk take SMF's attachments and modify the core code, specifically so that if attachments worked normally, SD's would too. All that we do is store the SD-specific metadata in its own table, and don't attach a topic id to the normal attachments (and yes, I did account for that in the maintenance... I think I did, anyway... have to check that now, it's been a year since I wrote it)
All the template edit has to do is add to the 'Browse attachments' / 'Browse thumbnails' links in the browse files area, to add 'Browse helpdesk attachments' / 'Browse helpdesk thumbnails'. Since it's injecting two links directly into the template, I wasn't uncomfortable with it.
Package Manager... well, SD has a form of plugin manager (which is to say, it has an interface for managing hooks that other things might use). For convenience I used SMF's package manager to get the plugins onto the server and files in the right places, then SD's code deals with activation and making them work.
Since that was already the case, I moved SD plugins into their own block of the package manager which is a template edit to expand. (Were I in charge of this, I wouldn't have it as a template edit, I wouldn't require one, I'd have the setup of the $context variables specifically to avoid needing any kind of edit, but that's me.)
There are only a handful of mods for the package manager, one of which I wrote, and I knew full well that it wouldn't be a problem to integrate this in with it.
Lastly, track IP. Underneath the 'list of posts from this IP', we add 'list of helpdesk posts from this IP'. It's not commonly modified, and it's just another call to the generic list template, really, so that's a not a problem either - it's just that if the template weren't a single monolith but a list of templates, it would be trivial to add another.
but potentially they could be used for hooks (e.g. instead of something liek query_see_board.)
I actually made is substantially easier for a mod to declare such things, and add them to the query; it's now possible to define your own without having to modify the DB code itself - which is the sort of thing I meant when I said that hooks weren't the only thing to contend with.
Well, I agree with designing in a way that this is not necessary to think about. Just like security; anything that can be made automatic is better that way, as long as it doesn't have other downsides
That's really what I'm trying to do, is to make it possible to automate as much as possible without having to make mod authors and/or mod users deal with it.
Sure. Although that can't do everything. Imagine if the recycle bin functionality were to be made a mod (in fact, I'm fairly sure it was at first.)
Something like that would have to be done as manual edits, I don't think there's any way around that - but on the other hand, something like that should be in the core anyway.
Then you need to at least do code review.
There is an informal code review going on with commits.
So you're screwed that way too, even without the package manager needing things writable.
*nods* But it was still hitting and enveloping instances that weren't running suexec, too, because of elevated permissions. Most people do not modify their permissions back after the event, because it's convenient for them not to have to do so.
Not true. Two plugins hooking the same hook can also cause issues
Sure they can, but it's far more common when it's file editing going on. Looking at the sorts of stuff that was emerging in SMF's ecosystem, the vast majority was additive rather than anything else, such that the order of installation for most things wouldn't be an issue at all in most cases. And usually, where order of installation is important for some reason, it's either documented by the mod author (who can also deal with support), or they deal with it in the mod itself (e.g. SlammedDime's SimpleSEF periodically makes sure it is the last hook called - though I recognise that it's possible a second mod will attempt to do the same and cause issues that way, but I gotta say that's very much an edge case there, order of execution is not that much of an issue for the *majority* of mods)
That doesn't seem wrong to me, in any case. That said, if it's becoming necessary, that seems bad.
I don't think it's becoming necessary. But it is becoming far more common, that people seem to feel it is becoming more necessary because there is a hurdle for them to overcome. The majority of admins want it to just work and become very upset/flustered when it doesn't, especially when it goes wrong and really breaks something.
Well, unless major changes happen again, as did with SMF 2.0. What if they separate out the core, and now all the syntax for everything has to change again? Are these "maintenance" areas really big problems between e.g. 1.1.1 and 1.1.2, etc.?
When you have any big jump, that's going to be expected. With a big jump you expect to have to do stuff like that. But between small version jumps, you shouldn't have to do much, if anything. Yet there are a great many mods that interfere with version updates and vice versa.
SMF is really a bad case to discuss this sort of thing. SimpleDesk now has less maintenance and editing in the really key areas - and they're the key areas that are high-maintenance: actions, admin menu, permissions, plus it has less maintenance by using a hook for one of the display template functions too.
Yes, when 2.1 rolls around it will need to be modified, of course. But for the meantime I can rest easy in that mods and updates shouldn't affect those parts of SimpleDesk - at all.
If anything, it's going to be less hassle than developing alongside the RCs was, because each RC brought new things with it that weren't bug fixes (RC3, 4, 5 and final all brought style specific changes, RC4, 5 and final all brought hook related changes)
Yeah, I know it was there, initially it wiped out installed.list IIRC. I think we moved to a database to remove the requirement of that file being writable, and may never have fully moved everything over.
That's the problem: it's all in the database, and the upgrader doesn't deal with it properly. The file is still present, though, it just contains the timestamp of the last install. Quite *why* it does that, I have no idea.
Which means, in other words, that they were betas. And if the last RC and the final and major behavioral changes (which I gather it did), then basically a release candidate was never made.
That's pretty much the story of 2.0 from RC1 onwards. Each release brought changes that were ultimately non trivial.
This sounds like a bad idea. I would rather just say "hey, this version says it won't work, want to try it anyway?" I even thought it did that.... but I guess it probably doesn't.
You can't do it that way: remember we talked about multiple versions being handled in the same package? There's your reason not to do it that way. Imagine you have a mod that states it supports 1.1.13 and 2.0 RC5, and you're on 1.1.14. Which set of instructions should it use as a 'default' fallback?
This always felt like a hack to me, actually, and I never felt completely comfortable with the way board specific permissions kinda shook out. They still confuse me, which is a bad sign.
Board permissions confuse a lot of people and 2.0's move to using profiles for boards is even more confusing. I know the entire setup needs to change but I'm not yet sure which way to go for the best.
At least we're not (or at least I hope I'm not) arguing about the color of the bikeshed.
I don't think we are, and that's not what I meant by my comment either. We agree there are issues with the current state of play, and we agree on how some of those issues may be resolved, and disagree on others - but really, our ground is not that uncommon, we're seeing the same issues with different coloured glasses. You're coming at it from your point of view, wherein maintenance and bugfixes - and practical measures that apply - are more important, while I'm coming from trying to make it as easy to use and possible for users, to minimise their hassle. Call it glass-half-full vs glass-half-empty at this point, because that's what it is, really.
Does SMF's system yet allow for multiple subtemplates to be used on the same page? Example: "poll", "poll", "calendar", "post_list"? I think I mentioned on SMF I have since moved to this system (and TOX-G uses it too.)
No, it doesn't. It can do template layers and a single inner-most template. Wedge does not have that limitation and we already use it in this fashion in a few places - though not nearly enough.
Actually, a reason not to have things in the core also is attack surface.
I can see that as an argument, it's entirely valid. And to your last point here in particular about file permissions... most users really do not want to have to do that. They want it to work as simply and cleanly as possible - and juggling file permissions is not part of that, IMHO.
From my perspective, the calendar as it stands is not that useful, so having it in core is not necessarily the smartest move, but if it were to be more useful, there would be more reason for it to be present.
Sure, except it can narrow the mindset.
I don't think there's any way to avoid that, though. Every time someone writes some code and releases it, it adds to the total substance of what's available - and every time that happens, there's one or more people out there who won't roll their own version of the same. From my POV, I see it as priming the pump for the most part, because I know others out there will think of ways to expand on what we come up with, and I know I won't be writing every possible permutation of mod either, so others who want it differently will invariably come up with their own spin on it.
