Wedge

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.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.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.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.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.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.There is an informal code review going on with commits.*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.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)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.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)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.That's pretty much the story of 2.0 from RC1 onwards. Each release brought changes that were ultimately non trivial.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?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.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.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.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.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.

Why would it make sense?[1]

Why would you need to assign a single topic to one or more people, when presumably you already have people moderating for the board it's in?

1.	Saying that "it would make sense" implies that it's obvious to both you and me that it *should* make sense, except that it doesn't. It makes sense to you, but I'm not seeing it. Explain why it makes sense, then maybe I'll agree...

There are far more useful things for us to worry about in terms of performance than that.

I really, REALLY dislike karma as a concept. This, unfortunately, even more so.

With your methodology, users who have a run of being unpopular will not only be pushed out of the community forcibly, they don't even have much of a chance to redeem themselves.

Plus, it has the single worst characteristic of a meritocracy: long term members who have voice can easily and effectively shut out new people in the community by never giving them much of a say in the first place. It means their crown can never be challenged, so to speak.

The *only* way I'd ever support such a solution is if downvoting, in whatever form, cost the user some of their reputation in order to make.

I do not see us supporting this in the core, doing it as any kind of mod is likely to be frustratingly complex no matter how flexible we make the modding system.

Revision: 828
Author: arantor
Date: 01:30:53, 03 July 2011
Message:
! Fixed some more oddities with the subtemplate not being called right. Also, split up AdminHome into two functions - there is no need for the admin front page to actually do everything needed for the credits as well, and vice versa. (Admin.php)
----
Modified : /trunk/Sources/Admin.php

Oh, I remember that discussion now. It was about what JavaScriptEscape did, and why it was necessary to call it for URLs - because there were all kinds of bad URLs getting into Google (namely the one indicated with %msg_id% in it)

Revision: 824
Author: arantor
Date: 23:56:29, 02 July 2011
Message:
! Remove 'Reports Generation' from Core Features. I mean, it was enabled already and all the Core Feature option does is show/hide the area, it's not like it actually prevents any ongoing performance problems, so there really wasn't much point actually making it optional in the first place. (install.sql, Admin.php, ManageSettings.php, ManageSettings.english.php, ManageSettings.french.php)
----
Modified : /trunk/Sources/Admin.php
Modified : /trunk/Sources/ManageSettings.php
Modified : /trunk/Themes/default/languages/ManageSettings.english.php
Modified : /trunk/Themes/default/languages/ManageSettings.french.php
Modified : /trunk/other/install.sql