I was under the impression that the article was never saved if the
content
hasn't changed, and therefore the hook wouldn't trigger in that
situation
anyway.
No new revision is saved but the hook is run. See Article.php, lines 1285-90 and 1359-63 in v1.8.2.
Is 'ArticleSave' also run? If not, you could set a variable in ArticleSave and check for it in ArticleSaveComplete. If it _is_ run then that sounds like an error.
ArticleSave is also run.
In reference to ArticleSaveComplete hook run in Article.php:
So does that mean that the $article passed to the function contains an invalid state - i.e. current content but old revision ID? Or is the whole object the pre-save version of the page? To be honest, both of those sound like a mistake.
The $article is the pre-save version of the page: - mContent contains the pre-saved text - mLatest is one revision behind - mRevision corresponds to the outdated mLatest - mCurrent is set to true (outdatedly) - mLastRevision is similar to mRevision but its mText is null
Either way, my point still stands - this should be fixed (in whatever way is appropriate) by patching the Article class, not by adding an extra hook parameter.
If Article's mLatest and mRevision were updated to reflect the new state of the article and mLastRevision represented the revision that the user loaded in order to change the page, that would work great for me. We're talking about changing parameters - existing extensions relying on the current behavior will break.