Wedge

The difference is that at least there you could talk to people without having to spend several minutes even rummaging for somewhere to post. The SMF team at least has a 'feature requests' board, as opposed to the PHP people who have an RFC mailing list but you have to have karma before you can post there but it's not entirely clear how to earn karma >_<

That sounds like a plan to me. No-one really worries about feed links when moving from other forum software to/from SMF, I see no reason why we are any different - it's not like we're really an SMF version any more.OK, so quick look. Reusing the gallery code makes plenty of sense when pulled under the feed... and I can understand the need also to initialise it in a way the gallery would expect. Though it might mean a gradual overhaul of the gallery code in time, I don't know.

The reorganisation of manage plugins is fine, and the new hook is fine also though personally I might have called it feed_types since that's what it really is. But 'feed' is absolutely fine too.

On the subject of passing variables by reference, yes, technically we should probably update everything to not have & in it. However it is nice to leave them in to indicate what the rest of the code expects will be passed by reference; the problem is that hooks can dictate the rules themselves because the receiver indicates its nature rather than the caller. But if we indicate what should be passed, and how (because that intimates what is safe to change and what isn't) that should be OK too.

I seem to recall the determine_location hook only really being useful for pretty URLs because anything else would naturally just head to index.php through a conventional scheme. I dunno. It doesn't hurt to have it where it is though it does mean that even non-PURLs cases would go there too.

The feed compatibility with SMF was always one of those tricky things, as was the mgallery->media change. I personally don't feel a burning need to retain compatibility but that's just me. While SMF->Wedge is the obvious target for conversion, there will be conversions from other systems too and I don't see why they should be treated as second class citizens by comparison. The playing field should be kept level where possible.

I'm curious, why should $_GET be used explicitly for actions? There is one interesting circumstance, though I can't remember where it would ever be an issue, is that if both $_POST and $_GET were to provide an action, $_REQUEST would contain the $_POST version not the $_GET one.

You're going to create a precedent by specifically writing exceptions.

Now you need to add a hook in there for anything else that wants to do the same thing. Creating an exception for the sake of (theoretical) backward compatibility also means creating a precedent and a means for everyone else to do the same.

I outlined two solutions I'd be happy with already.

Short of rewriting how the entire execution flow works, you can't fix it any other way, because what you're asking for is a way to selectively block logging based on a subaction while leaving the main action otherwise logged. But since execution doesn't get to handle subactions until after logging has already occurred, we have a problem in trying to support it like this.

Given that this is very firmly an exception rather than the rule, I don't really want to up-end a lot of code for the sake of an implied backward compatibility that isn't really that important in the grand scheme of things. Normally I'd be more inclined to support it but I'm not that worried here.

Except that if users use pretty URLs it's going to change anyway (since the PURLs scheme doesn't match what's available in any of the SMF mods)

People do expect URLs to change when software changes and it doesn't tend to upset others, I'd personally be inclined to not worry about it and just have it be whatever it is.

No it isn't, seeing that there can already be three parameters (plugin added actions will add function, file, plugin id) which means it would become 3 or 4 parameters depending on plugin.I explained all this when I wrote it into the plugin manager.

The first question: "Is it truly and completely sane to load a function to run a function, every page load, just to add one line to an array?" (Rinse, repeat for every plugin that adds an action.)

Of course it's not. Which is why the plugin manager can add actions directly. The whole point of plugins declaring actions up front in plugin-info.xml is so that they don't have to be hooked in the conventional sense but can be added on to the list via the point when hooks are loaded (when $settings is loaded)

That's why we don't add directly to $action_list. But if you really believe it would be better to have files loaded just to run hooks to extend the actions list, like SMF does, we can remove it. I'd really prefer you didn't, though, since it would also mean rewriting part of the plugin system (both loader and manager)

This is also why we have the third parameter in the first place. Plugins do not and cannot use loadSource which is what $action_list expects. The third parameter is the plugin id so that it knows 1) to even call loadPluginSource and 2) it has all the information it actually needs to do so.Eh, Notepad++ can do that. And I did start out with that but 'licence' wasn't one of the words I checked for. That, and the fact I wanted to skim through the language files, nice to see things I don't look at very often.Not observed in Chrome 26. I still have issues with the horizontal scrollbars though.