Wedge

I'm not entirely right on this one, though, as we'll see in a moment.No, it actually checks the last id. There was a time when it did check the number of replies, however.Well it's a little more complicated, I'm presuming you're actually talking about merging topics, not merging posts (which is also possible), but let's examine all of it.

Merging posts (post A, post B, then becomes post A which contains post B's contents as well) - if post B is created and merged in the time it takes the new post to be written, the last msg id is unaffected; it is effectively no different to post A being edited in mechanical terms. If the post B was present when starting to write the message, but is no longer present uniquely under its own id (because it's now been merged), this would be the sort of case where the last id would drop but no notification would occur to the user.

Merging topics... if we merge in a topic into the current topic, there are now more replies than before. However, it all comes down to whether there were any messages in the merged-in topic that are after the existing topic's last post, if not, there's no notification because as far as it knows, the last message id hasn't changed. If the last id has changed, then yes, it should trigger it.

If we try to reply to a topic that no longer exists, it tells us so with our old friend "The topic or board you are looking for appears to be either missing or off limits to you."

Not merging, moving. The move topics stuff does a strange switch of languages.

I still haven't seen it fail yet...

Yeah, that was what prompted it :P

But yeah, I don't think it would be *that* common but remember, the bulk of the logic is already there anyway. Instead of checking the number of replies, check the last message id. If that's different, something's changed between starting to reply and hitting the button. It shouldn't even add any extra work that isn't being done already.

No, but providing last message id would probably be enough, unless we care about earlier messages being split off.

Then it will be broken because all of the loadPlugin* functions need two parameters ;) They need the plugin id and the plugin file to load. I don't mind how we do that, as I suggested before we could accept it as author:plugin:file, explode on : then recombine the first two.Well, there's no enforcement on what the id can be other than it has to be author:plugin and less than 255 characters (though, frankly, it probably should be alphanumerics only plus that middle : separator) and separating files to load with ,

Wait a minute though, if you're calling this for a given plugin, the implication is that you'll already have the plugin id... still gotta pass that through to loadPluginLanguage but otherwise yeah it's just a regular path that you're missing at that point.

The plugin server and the update process have common code elements. And it's why I'm so adamant about them being separate physical servers, to cope with the heavy load they're going to get.

But the plugin server is actually a higher priority for me to get running - I actually have no qualms about deferring an 'upgrade' process until we're nearer actually needing it, and honestly I have no problem with the first update or two being manually pushed out until we're in a position to do automated push updates.

Well, the add_plugin_js_file malarky is primarily just a wrapper around the internal JS loading business (or it should be), so any behaviour like that is not a plugin's specific bug, but a bug spawned out of the fact that the plugin loader has not been kept in step with the main loader.

In theory, the add_js_file and add_plugin_js_file should behave consistently from calling perspective, i.e. they add the file requested. If the backend wants to perform some magic, it should do it consistently the same for both.

The plugin server is firmly in my domain ;)