Last modified: 2011-03-13 18:05:18 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 T16384, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 14384 - New #lastedit parserfunction
New #lastedit parserfunction
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Lowest enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-03 02:16 UTC by Cobi
Modified: 2011-03-13 18:05 UTC (History)
6 users (show)

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


Attachments
Patch for new parserfunction. (1.17 KB, patch)
2008-06-03 02:16 UTC, Cobi
Details
Fixed, tested patch. (3.06 KB, patch)
2008-06-03 12:59 UTC, Cobi
Details
Better patch. (2.26 KB, patch)
2008-06-03 16:11 UTC, Cobi
Details
Even better patch. (2.32 KB, patch)
2008-06-03 23:07 UTC, Cobi
Details

Description Cobi 2008-06-03 02:16:20 UTC
Created attachment 4946 [details]
Patch for new parserfunction.

It would be useful, especially since StatusBot on enwiki was blocked, to have a #lastedit parserfunction which would accept a username as input and return a standard timestamp of the last edit by that username.  I have included a patch file which should do this.
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-06-03 02:49:24 UTC
+		wfGetDB( DB_SLAVE, 'contributions' );

You don't need the contributions server specifically here.  Any slave will do.

+			array( 'rev_user_text' => $s ),

You want to trim $s, and normalize spaces to underscores, and maybe other stuff.

+			array( 'ORDER_BY' => 'rev_timestamp', 'LIMIT' => 1 )

Shouldn't that be 'ORDER BY', not 'ORDER_BY'?  I don't think the latter works.  And don't you want 'rev_timestamp DESC'?  Also, LIMIT is redundant if you're doing selectField.

This parser function needs to be marked expensive.  If we want still more such functions . . . pretty soon we'll be getting 100 extra queries every page view guaranteed.  Sigh.

Was this patch tested?  It doesn't seem as though it would work correctly.
Comment 2 X! 2008-06-03 03:29:04 UTC
Actually, the status of statubot is unknown (no pun intended). I'm still trying to negotiate with the admins a possible solution. 
Comment 3 Cobi 2008-06-03 03:36:54 UTC
(In reply to comment #1)
> +               wfGetDB( DB_SLAVE, 'contributions' );
> 
> You don't need the contributions server specifically here.  Any slave will do.
> 
> +                       array( 'rev_user_text' => $s ),
> 
> You want to trim $s, and normalize spaces to underscores, and maybe other
> stuff.
> 
> +                       array( 'ORDER_BY' => 'rev_timestamp', 'LIMIT' => 1 )
> 
> Shouldn't that be 'ORDER BY', not 'ORDER_BY'?  I don't think the latter works. 
> And don't you want 'rev_timestamp DESC'?  Also, LIMIT is redundant if you're
> doing selectField.
> 
> This parser function needs to be marked expensive.  If we want still more such
> functions . . . pretty soon we'll be getting 100 extra queries every page view
> guaranteed.  Sigh.
> 
> Was this patch tested?  It doesn't seem as though it would work correctly.
> 

No, it wasn't tested.  I didn't have access to a webserver when I was writing it (on my laptop).  Also, this was the first time using the database classes in code modifications.  Yes, you are correct in all instances.
Comment 4 Danny B. 2008-06-03 11:54:11 UTC
Is this somehow useful for creating of wiki content (either articles or community)? If it's just for bots, maybe trying of API would be better.
Comment 5 Cobi 2008-06-03 12:22:16 UTC
(In reply to comment #4)
> Is this somehow useful for creating of wiki content (either articles or
> community)? If it's just for bots, maybe trying of API would be better.
> 

Yes.  It isn't really related to bots at all, except that there was a bot updating hundreds of status pages which contained this information that was transcluded.  Brion blocked that bot for using too many resources.  I think a parser function is a lot more efficient than having a bot query the api every x minutes and update several pages, which would then be transcluded.  On enwiki, people directly transclude these pages onto their user/talk pages or though templates that transclude them.  Also, a few lists of users transclude the pages to show status of the users in the list.
Comment 6 Cobi 2008-06-03 12:59:14 UTC
Created attachment 4948 [details]
Fixed, tested patch.

I have attached a new fixed, tested patch.  :)
Comment 7 MZMcBride 2008-06-03 15:13:40 UTC
Will the #lastedit parser function use the same limits that #ifexist and {{PAGESINCATEGORY}} use? 
Comment 8 Cobi 2008-06-03 16:11:31 UTC
Created attachment 4949 [details]
Better patch.

Attached a better patch, which, I think, takes care of the expensive functions.
Comment 9 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-06-03 21:52:50 UTC
(In reply to comment #7)
> Will the #lastedit parser function use the same limits that #ifexist and
> {{PAGESINCATEGORY}} use? 

It will if it's committed.

+		$parser->setFunctionHook( 'lastedit',         array( __CLASS__, 'lastedit'         ), SFH_NO_HASH );
...
+	'lastedit'               => array( 0,    '#LASTEDIT:'             ),

This looks wrong.  What's that hash doing here?  Is this supposed to be {{lastedit:}} or {{#lastedit:}}?  (It should be the former.)

+		$user = User::newFromName( $s );
+		$s = $user->getName();

This will cause a fatal error if the provided name is invalid, e.g., {{lastedit:<>}}.

+			$ts = $db->selectField(
+				'revision',
+				'rev_timestamp',
+				array( 'rev_user_text' => $s ),
+				__METHOD__,
+				array( 'ORDER BY' => 'rev_timestamp DESC', 'LIMIT' => 1 )
+				);

You're still using LIMIT here, it's unnecessary.

I don't think I want to check this in without first asking Brion what our policy should be on this kind of parser function.  Perhaps all expensive parser functions should be moved to the ParserFunctions extension, to begin with.  Eventually some framework for batching them will be needed, if they keep on multiplying, and it's not clear that constructing such a framework would be the best use of development resources.
Comment 10 Cobi 2008-06-03 23:07:28 UTC
Created attachment 4953 [details]
Even better patch.

This patch fixes Simetrical's problems listed above, except the first issue, which brion said should stay the same.
Comment 11 Tim Starling 2008-06-04 00:30:32 UTC
I suggest if you want to know the last edit timestamp of a given user, you use JavaScript with the API. Saving it into an article using a parser function will mean that it won't update properly, due to the cache.
Comment 12 Tim Starling 2008-06-04 00:58:16 UTC
If you want an online status indicator on user pages, please write it as an extension. That way, it'll have optimal performance, it'll be running on secure, reliable servers, the code will be reviewed, and it can be shared with other MediaWiki sites. 
Comment 13 Brion Vibber 2008-06-04 17:21:59 UTC
I believe this one has been advocated for that purpose:

http://www.mediawiki.org/wiki/Extension:OnlineStatus

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


Navigation
Links