Wedge

lighttpd, yes, seeing how it is intended to be 100% compatible with Apache. Have they fixed the ridiculously crippling memory leaks yet?

nginx is a different story altogether, and it's possible the pretty URLs code will need tweaking to work on it.

See, here's what people don't realise about me.

Before I came to PHP, I did ASP.Classic, and before that, Visual Basic itself. Except I was doing stuff using the Windows API itself because VB's own set.

And the stuff I wrote 10 years ago... with one exception, it all still works on Windows 7. That particular exception is because of an API that was deprecated back in 2000, and naturally doesn't exist now. If you can do this on an operating system, why can't we apply the same basic techniques to programming in a higher level environment?

As far as what I want Wedge to be, I want to take SMF and fix what I see as the problems in it, mostly for users but solving some of those that I saw for modders too. I want to be able to write extensions for it that don't require me to babysit them as versions change unless something dramatic happens.

SimpleDesk was mentioned earlier on; I want to be able to create a counterpart for Wedge that doesn't require version specific hacks. I want to be able to create something that big and scary that runs on multiple versions and doesn't require me to patch it, or update its listing, just because a new version of Wedge came out.

I want to be able to port my mods to Wedge. I want to be able to write some of the other mods I've thought about over the last 2 years, except the frustration involved in writing most of them in a way that won't cause me to do support is why I didn't.

That's the thing: it could be a good kick up the arse to do it right the first time, or a middle-finger because so many modders wouldn't sit and maintain mods for different SMF RCs, which is virtually the same thing on a technical level, if not a semantic one.

Plenty of examples and docs should help though.

SD 2.0 still requires multiple file edits (which I swear I said several times) because the hooks don't exist in SMF that would be needed to make it work, and in one case the hook exists but it doesn't support the operations required by SimpleDesk.

But since it's become increasingly clear that I'm barking up another wrong tree, I might as well revert what I've done and go with my first plan of enhancing what's there and praying to $deity that my fears are baseless, except I know full well I'm right there.

Anyway. I have more alcohol to drink right now, a hangover for the morning, followed by a 200 mile road trip, just so I can go to a family funeral tomorrow, I'm looking forward to setting out in... a little over 5 hours yay. Have fun discussing it in my absence, but FWIW I already reverted the changes I made, so whatever I do when I come back will be fresh rather than deluding myself that I could fix all the problems I found with SMF, bring on all the worst problems SMF has without much of the solutions I'd hoped and believed could have been solved.

(See, Unknown's someone I look up to and when he says in not so many words that he thinks I'm working off broken logic, I tend to agree with him. Then I remember that he's younger than me and still managed to achieve so much more than I have so far, and I quietly begin to question myself. I hear my beer calling.)

Well, here's the thing, while you could build an interface, the content for it is very complicated with regular expressions, and if you can cope with regexps, you can add code...

Unfortunately right this moment I don't have time to reply to everything but the stuff I see as really important I'll deal with right now and tackle everything else shortly.And that's because they still depend on version checking. My proposed method explicitly does NOT check for Wedge version.That's one of my points: I don't see people being careful. I see it as enabling the shortest route to a problem, which leads to all the things I mentioned before.Following on from that: I'm not against file edits per se, for all the reasons you've mentioned. I just don't want to leave them in because people will continue using practices they learned in SMF rather than learning new habits, like using hooks where there are hooks available for things.It probably does, I haven't spent any time in their ecosystems. But given the mods submitted, the relative skill level of the coders and so on, the majority are certainly not contributed by veteran coders.

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!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.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.)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.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.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.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.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:It's a tweak, changing the existing behaviour. It's not really a 'new feature', is it?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.)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.Yes. It's even implemented actually using hooks, too.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.)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.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'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.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.