> 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.