Last modified: 2008-09-27 10:53:05 UTC
It would be useful to have a separate ArticleEditUpdates hook, right before the existing ArticleEditUpdatesDeleteFromRecentchanges hook in Article.php, Article::editUpdates(). This hook would be used by extensions to perform post-edit updates. Currently, the ArticleEditUpdatesDeleteFromRecentchanges is not appropriate, because it is overloaded with other purposes: any extension may want to return false from its hooked function in order to prevent old entries from being flushed from RecentChanges, and this have the side-effect of breaking any other extension depending on the same hook to perform post-edit updates. A dedicated hook to allow extensions perform post-edit updates is then needed. Also note that ArticleSaveComplete doesn't serve for the same purpose, since there are other ways to cause edit updates that don't trigger such hook (like Import and Undelete). I propose a new hook as: function fnMyArticleEditUpdates(&$article, &$editInfo, $changed) { ... } Implemented as: ======================================== --- includes/Article.php (revision 40504) +++ includes/Article.php (working copy) @@ -2713,6 +2713,8 @@ $u = new LinksUpdate( $this->mTitle, $editInfo->output ); $u->doUpdate(); + wfRunHooks( 'ArticleEditUpdates', array( &$this, &$editInfo, $changed ) ); + if( wfRunHooks( 'ArticleEditUpdatesDeleteFromRecentchanges', array( &$this ) ) ) { if ( 0 == mt_rand( 0, 99 ) ) { // Flush old entries from the `recentchanges` table; we do this on ======================================== The rationale for passing $editInfo to the hook is so that extensions may extract data from ParserOutput collected during the parsing of the article text. $text and $newid are not passed since they are already present in $editInfo.
Can't you just use one of the LinksUpdate hooks?
Hi Aaron, I could, but it just doesn't look like the right place to do such things. In fact, I do use the LinksUpdate hook, but for updating links only. Perhaps, the most logical place to put what I need would be "ArticleSaveComplete", but this hook have a few problems: 1. It is not called every time the article needs to perform post-edit updates (like Special:Import and Special:Undelete), this hook is more user-oriented; 2. I would have to parse $text again in order to extract the information I need from the wikitext. The "LinksUpdate" hook has this problem: 3. It is meant to update the many links tables, it seems off to use this hook to update assorted article metadata created by the extension. Specially, it doesn't seem right to have this running during a maintenance/refreshLinks.php. I'm currently using the "ArticleEditUpdatesDeleteFromRecentchanges" hook, that fixes problems number 1 and 3 above, and I get around problem number 2 by sneaking into $article->mPreparedEdit; but also have the drawback mentioned earlier (other extensions may shut off my extension legitimately, since this hook is for different purpose). Note that it is part of the suggestion to pass $editInfo to this new hook. This is the important part. With this feature, I won't need to hurt any OO rules in order to get the ParserOutput object, neither will I have to parse the wikitext again. If you would like, take a look at: http://svn.juliano.info/svn/mediawiki/extensions/Wikilog/trunk/ * file Wikilog.php, method Wikilog::ArticleEditUpdates() and * file WikilogLinksUpdate.php, class WikilogLinksUpdate. If you have any better suggestion, they are welcome! I couldn't find any better way to do this. Note that I also have *another* extension that also have to abuse the wrong hook due to the lack of the hook I propose in this bug: http://svn.juliano.info/svn/mediawiki/extensions/KMLExport/trunk/
Created attachment 5365 [details] Proposed patch. This is the proposed change.
Done in r41302
