Wedge

*shrug* The bottom line is that if you provide a system in the core, other plugins should generally adhere to it, but the harder you make it for them to use, the less likely they are to use it. So make it easy for plugins to do things - i.e. have it 'just work' and plugins will benefit without having to specifically code for it.

But if it's effort for plugins to support it, they won't, making the exercise a bit of a waste.

It's an interesting concept but I'm not sure plugins will behave cleanly with it, I suspect unless it's managed pretty much automatically they won't use it.

Mind you, most plugins will only use PURLs features that are managed automatically (very few plugins for SMF ever cared, and those that did, were pretty much portals and/or PURLs type plugins in the first place), so if it can be done transparently and 'just work', plugins can use it but otherwise they probably won't.

I know that, but there are circumstances where the incorrect query string won't be passed to PHP properly at all on those servers.

Well done for quoting my post but missing my point. It won't work on 'all' webserver as you quote.

Before I reply, I should note that I've been fighting with DIY endeavours today and am very tired and frustrated (and still only got one of the two items built)You can't set it with ini_set. It's a PERDIR setting, not an ALL setting. You can only set it via .htaccess if your host allows you to do so (since it's a PHP setup thing, if you do it by ini_set, it's already too late as $_GET will by then already have been processed)No, no, no it doesn't. Read what the code does. It detects whether arg_separator is ; or not, if it is, it sanitises $_GET based on it, if it's not, it re-parses the query string.

You cannot do this in ini_set, and if you make it rely on having ; set as arg_separator, Wedge WILL break if that code is removed.Are you planning on restricting Wedge to hosts that are VPSes or better, or allow users to reconfigure things in .htaccess (specifically PHP settings via .htaccess)?

You don't actually have much of a choice on this. arg_separator is not ; by default, it's &, and since that's set up prior to a PHP script running, you don't have much choice in how that works. Either you restrict Wedge to hosts that allow custom configuration, or you leave the code alone because it works just fine as it is.I did the same thing you did, a $context setting to have it never inject SID into URLs. But since you've committed it, I didn't bother (and I wasn't that happy with it, I felt there should have been something more elaborate)I know what they were trying to fix, I know exactly what and how they were trying to fix it, I just don't understand why that was there.For the same reason IP addresses are unreliable as sin anyway, things like NAT routing, where an IP address does not relate to a unique computer any more nor to a unique user.Except that I saw cases where the trailing ; was present and cases where it wasn't - in the same page.

You mean I'd have to run SMF instead of running Wedge on my sites (since I'd be banned from using it)?

The reason for not including the start date in the message index is simply becaue it's already VERY CLUTTERED and putting in more clutter makes it harder to use, not easier.

I'd also note that most of the time people do not care when a thread was started.