Last modified: 2011-11-15 19:47:20 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T34318, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 32318 - Moved ArticleSave hook breaks backward compatibility
Moved ArticleSave hook breaks backward compatibility
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
1.18.x
All All
: Normal normal (vote)
: 1.18.0 release
Assigned To: Aaron Schulz
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-11-09 17:13 UTC by Joshua C. Lerner
Modified: 2011-11-15 19:47 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Joshua C. Lerner 2011-11-09 17:13:30 UTC
The ArticleSave hook has been moved to WikiPage, along with the doEdit() method. Any code that depends upon the first hook argument ($this) will fail, as $this now is a WikiPage object (instead of an Article object).

Not sure what can or should be done about this, apart from updating the release notes as well as http://www.mediawiki.org/wiki/Manual:Hooks/ArticleSave.
Comment 1 Rob Lanphier 2011-11-10 19:14:37 UTC
Looks like we need to at least get something in the release notes about this one.  Josh, which methods of the Article object are you counting on in your extensions?
Comment 2 Joshua C. Lerner 2011-11-10 19:19:42 UTC
Just Article::getContent() - updated that bit to $wikipage->mLastRevision->mText.
Comment 3 Aaron Schulz 2011-11-10 19:25:22 UTC
(In reply to comment #1)
> Looks like we need to at least get something in the release notes about this
> one.  Josh, which methods of the Article object are you counting on in your
> extensions?

Notes changed in r102565.

Most function calls are b/c.
Comment 4 Mark A. Hershberger 2011-11-11 04:32:15 UTC
(In reply to comment #3)
> Most function calls are b/c.

$ grep 'public function ' includes/Article.php | sed 's/(.*//g' | sort > 1.txt
$ grep 'public function ' includes/WikiPage.php | sed 's/(.*//g' | sort > 2.txt
$ diff -u 1.txt 2.txt | grep ^- | wc -l
50
$ wc -l 1.txt 2.txt 
  57 1.txt
  64 2.txt

When there are 57 public functions and 50 of them are not in the WikiPage class (as the above shows), how does that reflect "most functions are b/c"?
Comment 5 Aaron Schulz 2011-11-11 05:05:11 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Most function calls are b/c.
> 
> $ grep 'public function ' includes/Article.php | sed 's/(.*//g' | sort > 1.txt
> $ grep 'public function ' includes/WikiPage.php | sed 's/(.*//g' | sort > 2.txt
> $ diff -u 1.txt 2.txt | grep ^- | wc -l
> 50
> $ wc -l 1.txt 2.txt 
>   57 1.txt
>   64 2.txt
> 
> When there are 57 public functions and 50 of them are not in the WikiPage class
> (as the above shows), how does that reflect "most functions are b/c"?

I said "Most function calls are b/c" not "Most function are b/c". Extensions tended to be using the backend functions (which are in WikiPage). getContent()/fetchContent() were the important edge case functions (mixing UI and backend) and were not moved to WikiPage. A few callers had to be updated. Also see http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91123#c22036 .

Also, it makes sense that most (50/57) of the functions in Article now are not in WikiPage, as the vast majority of WikiPage functions were moved there *from* Article.
Comment 6 Rob Lanphier 2011-11-15 18:19:54 UTC
Aaron, could you update the release notes for 1.18, then either change the target milestone, or mark "WONTFIX"?
Comment 7 Aaron Schulz 2011-11-15 19:47:20 UTC
More notes added in r103215. Closed.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links