Now that 1.5 is running, and the big bugs bite^W are on the verge of extinction, I feel it is my duty to introduce some new ones. :-)
Did anyone look into the validation feature again? I have fixed what seemed to be the most pressing problems. I'm not sure about performance, but I'm pretty sure it doesn't load the whole table into memory at any point.
There has been a request for the feature on the German mailing list, and I'd wager it won't stay the only one, on many lists.
Should we * sit back and wait for it to mend itself magically * let everyone have a final look and turn it on to see what happens * turn it on right now ?
Magnus
I looked at it again and the interface hadn't changed, its still hardcoded (rather than using XHTML/CSS) and completely out of sync with the rest of the UI, it has some hardcoded strings and a generally hard-to-understand UI.
Magnus Manske wrote:
Now that 1.5 is running, and the big bugs bite^W are on the verge of extinction, I feel it is my duty to introduce some new ones. :-)
Did anyone look into the validation feature again? I have fixed what seemed to be the most pressing problems.
It was last modified June 22. If you've made changes since, I don't think they got checked in. :)
I'm not sure about performance, but I'm pretty sure it doesn't load the whole table into memory at any point.
Well, about that...
# Reads all revision information of the specified article function prepareRevisions( $id ) { global $wgDBprefix; $this->rev2date = array(); $this->date2rev = array(); $sql = "SELECT * FROM {$wgDBprefix}revision WHERE rev_page='{$id}'"; $res = wfQuery( $sql, DB_READ ); while( $x = wfFetchObject( $res ) ) { $this->rev2date[$x->rev_id] = $x; $this->date2rev[$x->rev_timestamp] = $x; } }
That function gets called in validatePageForm, showDetails, and showList. As near as I can tell there's basically nothing you can touch in the validation feature that won't try to load the complete revision history of the page -- which may be thousands or tens of thousands of revisions for certain pages.
It may not have to load up the page text anymore, but that's still a lot of records and a lot of fields being scraped off the database's disk and dumped into memory on the web server.
That's the first function defined in the file, so there may be other interesting problems lower down as well that need attention, but it's a big one.
There has been a request for the feature on the German mailing list, and I'd wager it won't stay the only one, on many lists.
Should we
- sit back and wait for it to mend itself magically
- let everyone have a final look and turn it on to see what happens
- turn it on right now
It must not be turned on until it's been fixed.
(I would also recommend moving it out of the core code and making it an extension if possible.)
-- brion vibber (brion @ pobox.com)
# Reads all revision information of the specified article function prepareRevisions( $id ) { global $wgDBprefix; $this->rev2date = array(); $this->date2rev = array(); $sql = "SELECT * FROM {$wgDBprefix}revision WHERErev_page='{$id}'"; $res = wfQuery( $sql, DB_READ ); while( $x = wfFetchObject( $res ) ) { $this->rev2date[$x->rev_id] = $x; $this->date2rev[$x->rev_timestamp] = $x; } }
I don't think it's been said yet, someone has to say it. The name of the revision table is not "{$wgDBprefix}revision", it is $db->tableName('revision'). If those two produce the same text, consider it conincidence. wfQuery() and wfFetchObject() are deprecated. Instead use wfGetDB() to get a Database object and call the query() and fetchObject() member functions.
-- Tim Starling
I've only looked into it enough to get a basic understanding, and I honestly only have a rough understand of the issues with it, but love the concept and agree that this could be used in a variety of ways on many wikis. I'm going to use it for ratings on my wiki.
I'd be happy to help "fix" it (write code) but unfortunately need some more detailed guidance on what exactly needs to be done.
Best Regards, Aerik Sylvan
Magnus Manske wrote:
Now that 1.5 is running, and the big bugs bite^W are on the verge of extinction, I feel it is my duty to introduce some new ones. :-)
Did anyone look into the validation feature again? I have fixed what seemed to be the most pressing problems. I'm not sure about performance, but I'm pretty sure it doesn't load the whole table into memory at any point.
There has been a request for the feature on the German mailing list, and I'd wager it won't stay the only one, on many lists.
Should we
- sit back and wait for it to mend itself magically
- let everyone have a final look and turn it on to see what happens
- turn it on right now
?
Magnus
Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Aerik Sylvan (aerik@thesylvans.com) [050706 07:14]:
I've only looked into it enough to get a basic understanding, and I honestly only have a rough understand of the issues with it, but love the concept and agree that this could be used in a variety of ways on many wikis. I'm going to use it for ratings on my wiki. I'd be happy to help "fix" it (write code) but unfortunately need some more detailed guidance on what exactly needs to be done.
See discussion at http://meta.wikimedia.org/wiki/Article_validation_feature and linked pages.
Brion's post of problems with it (incomplete) is at:
http://mail.wikimedia.org/pipermail/wikitech-l/2005-June/030325.html
- d.
David Gerard wrote:
Brion's post of problems with it (incomplete) is at:
http://mail.wikimedia.org/pipermail/wikitech-l/2005-June/030325.html
I consider at least the HTML safety issue as "fixed". The "management" page is not too comfy indeed, but it will only be used to add topics, which is about a dozen or so total, by experienced people (no newbies).
Exxessive database usage needs to be looked into, as well as changing display to CSS (which I *thought* I did!).
Magnus
Magnus Manske (magnus.manske@web.de) [050706 18:13]:
David Gerard wrote:
Brion's post of problems with it (incomplete) is at: http://mail.wikimedia.org/pipermail/wikitech-l/2005-June/030325.html
I consider at least the HTML safety issue as "fixed". The "management" page is not too comfy indeed, but it will only be used to add topics, which is about a dozen or so total, by experienced people (no newbies).
Mmm. Playing with it on test.leuksman.com, I could get the interface to do what I wanted. And presumably the interface will only be used at all *very* rarely - presumably by someone at steward level to put in a consensus-agreed list of topics (with links in the text) and ranges.
- d.
wikitech-l@lists.wikimedia.org