I'm using data from a snapshot of the English Wikipedia and would like
to run a query similar to the following:
SELECT * FROM revision
WHERE rev_id > some_rev_id;
Can I be confident that all revisions returned were saved after some_rev_id?
Thanks!
-Aaron
P.S. I have considered using rev_timestamp and would like to avoid that
if it is possible.
Hello,
I have what I think is strange behaviour with parser called by the API
and tag extensions.
Here is the code of a tag extension :
function efParserInit() {
global $wgParser;
$wgParser->setHook( 'foo', 'effooRender' );
$wgParser->setHook( 'bar', 'efbarRender' );
return true;
}
function effooRender( $input, $args, &$parser )
{
$output = $parser->recursiveTagParse( $input );
return "<div class=\"foo\">" . $output . "</div>";
}
function efbarRender( $input, $args, &$parser )
{
$output = $parser->recursiveTagParse( $input );
return "<div class=\"bar\">" . $output . "</div>";
}
I crate a page on my Wiki with the following text :
<foo>test1<bar>'''test2'''</bar></foo>
When I view the HTML code in my browser, I get :
<div class="foo">test1<div class="bar"><b>test2</b></div></div>
But when I try : wget
"http://mywiki/wiki/api.php?action=query&titles=mypage&prop=revisions&rvprop…",
I get the following in the "parsetree" attribute of the "rev" element ":
<ext><name>foo</name><attr/><inner>test1&lt;bar&gt;'''test2'''&lt;/bar&gt;</inner><close>&lt;/foo&gt;</close></ext>
(sorry for this ugly line...).
My problem is here : there is only one "ext" element which correspond to my
"foo" tag. I was waiting two "ext" elements : one for "foo" tag and one for
"bar" tag.
This is just I want.
Is this behaviour normal ?
A little bit of debug show that the includes/parser/Parser.php, the
"extensionSubstitution" function is only called one time when I access my
page via the API and three times when I access it via the browser. Is the
text parsed not the same in the two cases ? Is it something wrong in my API
call ?
Regards,
Alex
I am glad to announce the first experimental release of imgserve, a
universal image daemon for Wikimedia Foundation, it's a Google Summer of
Code project mentored by Aryeh Gregor. The intended usage in mediawiki
is to migrate all image manipulation work away from Apache servers.
The daemon, written in python, currently only supports image rescaling
and svg rasterization operations. Instructions/Requests are sent to the
daemon as JSON objects over HTTP, which is handled by an simple embedded
HTTP server in the daemon.
To test the daemon, you should follow the install instructions and have
all required package installed on your machine. See install
instructions at
http://pypi.python.org/pypi/imgserve
Source code is hosted at
http://github.com/wuzhe/imgserve
As a GSOC student, I have learned quite a lot from this project, and am
eager to learn more. If you find any bug, or have suggestions, please
let me know, thank you.
--
Wu Zhe
All,
I had this idea cross my mind earlier today, but I got so tied up
in meetings that I couldn't sit down and write out a proper e-mail
until this evening. I was curious as to whether we think FlaggedRevs
might be of use to Mediawiki.org, and if so, how exactly would
we use it?
The idea crossed my mind after the past several days noticing
quite a bit of information on Mediawiki.org is either poorly worded,
outdated or just plain wrong. Now, MW.org doesn't suffer from most
of the issues that are seen on other projects: we're small, we don't
really have anything to edit war over, and we don't seem to get (as
much :) spam and vandalism. I was curious as to whether we could
use FlaggedRevs as a quality control over our documentation.
A lot of the docs have been written by people other than developers,
and a lot of the docs have never been read by a developer. That being
said, using FlaggedRevs we might be able to deliver more solid docs
on MW.org by flagging docs at like two levels. One could be like a basic
"has been looked over for glaring errors and basic readability" and
a second could be "has been thoroughly reviewed and is considered
the doc on the given subject."
Hopefully we can improve the overall quality of the docs on MW.org.
I'm certainly open to other ideas too.
-Chad
I'm very excited to announce some new upcoming hiring for tech... I've
also posted this on our tech blog which is mirrored on Planet Wikimedia:
http://techblog.wikimedia.org/2009/08/cto-position-split/
--
Back in 2005, Wikimedia brought me on as the Foundation's first paid
employee after two years leading MediaWiki development as a volunteer.
Naturally as the *only* member of the tech staff, I started at the top:
Chief Technology Officer.
In the 4 years since, we've gone from one tech employee to a dozen, from
50 servers to 350, from upstart novelty to established web juggernaut.
As our operations and our staff have grown over the years, so have my
responsibilities. Beefing up our tech staff is in some ways just like
adding servers to our data center -- we can get more things done with
less task switching, but scaling still has its overhead.
With the increase in administrative and organizational duties, I've been
less and less able to devote time to the part of the job that's nearest
and dearest to me: working with our volunteer developer community and
end users -- Wikimedians and other MediaWiki users alike -- who have
bugs, patches, features, ideas, complaints, hopes and dreams that need
attention.
The last thing I want to be is a bottleneck that prevents our users from
getting what they need, or our open source developers from being able to
participate effectively!
Multicore brain upgrades aren't yet available, so to keep us running at
top speed I've suggested, and gotten Sue & Erik's blessing on, splitting
out the components of my current CTO role into two separate positions:
As Senior Software Architect, I...
* maintain the MediaWiki development roadmap
* give timely feedback and review on feature ideas, patches and commits
* ensure that end-users and bug reporters are treated respectfully and
that their needs are met
* get developers & users involved and talking at local and worldwide
events as well as online
* represent the "face of the developers" interacting with our user
community (both Wikimedians and third-party MediaWiki users)
As CTO, I...
* set high-level strategic priorities with the rest of WMF
* handle administrative management for the Wikimedia Foundation's
technical department & internal IT
** budgeting
** vendor relations & purchase approval
** hiring & personnel details
* work with the fundraising side of WMF to seek out and make use of
potential resources:
** grants for projects we need
** in-kind donations of infrastructure
** sharing development work with like-minded orgs
* ensure that the operations team has what they need to address current
and predictable future site needs
* ensure that the developers have what they need and are coding smoothly
* plan and implement internship programs and volunteer dev events both
on-site and elsewhere
I'll continue to act in both roles until we've found a satisfactory
candidate to fill the CTO position (full job description will go up
soon), at which point I'll be freed up to concentrate on being a
full-time Senior Software Architect. (Yes, I'll review your patch!)
I will of course continue to work closely with our eventual CTO... the
idea is to find someone who'll make the decisions I would have wanted to
if I only had time. ;)
-- brion vibber (brion @ wikimedia.org)
CTO, Wikimedia Foundation
San Francisco
I have fixed 8 bugs (some fairly trivial) in /phase3/t/ so all of the tests in /t/inc/ now work. I have opened a bug ticket (20112) and attached a patch that fixes the bugs. I have not fixed problems with the tests in /t/maint/ because: 1) they seem to test OS functionality, not the MW software, and 2) they are written in PERL not PHP and my IDE (Netbeans 6.7.1) doesn't support PERL. Perhaps someone who has an IDE with PERL support will develop an interest in fixing them.
This completes the task Brion asked me to take on. What happens next is up to the developer community. I have some ideas about test harness architecture (not radical ideas, but more than just fixing dings in the software) that I will run up the flag pole in subsequent posts. So far, only a few have responded to my posts (admittedly, some were a bit silly, such as the one asking where $wgLocalisationCacheConf is defined), but it seems few developers are interested in MW QA. Well, that isn't exactly unusual. Features are always more interesting that code stability. But, the history of software is littered with products possessing really neat features that eventually failed because developers did not take care of quality.
Enough preaching.
I have fixed 5 bugs in /tests/ and added one feature to run-tests.php (a --runall option so testers can run the PHPUnit tests without using make - although make test still works). With these changes all of the tests in /tests/ now work. A unified diff patch is attached to bug ticket 20077.
I had to make an architectural decision when enhancing run-test.php with the --runall option. The bug ticked describes this decision and suggests two other ways to achieve the same objective. I chose the approach implemented by the patch because it required no changes to the directory structure of /tests/. However, I actually prefer the second possibility. So, if senior developers could look at the bug ticket description and give me some feedback (especially if they also think the second option is better), that would be great.
I also would appreciate some feedback on the following question. One of the tests referenced the global variables $wgDBadminname and $wgDBadminuser. When I ran the configuration script during Mediawiki installation on my machine, the LocalSettings.php file created defined the globals $wgDBname and $wgDBuser. So, I changed the test to use these variables rather than the 'admin' versions. However, I don't remember if the script gave me a choice to use the 'admin' versions or not. Also, if the configuration script has changed, then some installations may use the 'admin' versions and some may not. In either case, I would have to modify the bug fix to accept both types of global variable. If someone would fill me in, I can make any required changes to the bug fix.
Want to point out the working prototype of the Wiki@home extension.
Presently it focuses on a system for transcoding uploaded media to free
formats, but will also be used for "flattening sequences" and maybe
other things in the future ;)
Its still rough around the edges ... it presently features:
* Support for uploading a non-free media assets,
* putting those non free media assets into a jobs table and distributing
the transcode job into $wgChunkDuration length encoding jobs. ( each
pieces is uploaded then reassembled on the server. that way big
transcoding jobs can be distributed to as many clients that are
participating )
* It supports multiple derivatives for different resolutions based on
the requested size.
** In the future I will add a hook for oggHanlder to use that as well ..
since a big usability issue right now is users embedding HD or high res
ogg videos into a small video space in an article ... and it naturally
it performs slowly.
* It also features a JavaScript interface for clients to query for new
jobs, get the job, download the asset, do transcode & upload it (all
through an api module so people could build a client as a shell script
if they wanted)
** In the future the interface will support preferences , basic
statistics and more options like "turn on wiki@home every-time I visit
wikipedia" or only get jobs while I am away from my computer.
* I try and handle derivatives consistently with the "file"/ media
handling system. So right now your uploaded non-free format file will be
linked to on the file detail page and via the api calls. We should
probably limit client exposure to non-free formats. Obviously they have
the files be on a public url to be transcoded, but the interfaces for
embedding and the stream detail page should link to the free format
version at all times.
* I tie transcoded chunks to user ids this makes it easier to disable
bad participants.
** I need to add an interface to delete derivatives if someone flags it
as so.
* it supports $wgJobTimeOut for re-assigning jobs that don't get done in
$wgJobTimeOut time.
This was hacked together over the past few days so its by no means
production ready ... but should get there soon ;) Feedback is welcome.
Its in the svn at: /trunk/extensions/WikiAtHome/
peace,
michael
I am working on the tests in /t/. One, Revision.t, attempts to create a Language object and croaks in getLocalisationCache(), which is called by the Language class constructor. The problem is $wgLocalisationCacheConf is undefined, but referenced. When I Googled $wgLocalisationCacheConf I got the page:
http://www.mediawiki.org/wiki/Manual:$wgLocalisationCacheConf
It states that this global is introduced in 1.16.0. It isn't in my LocalSettings.php file (understandable, since I ran the install script on a version of MW prior to r52503, in which the variable is introduced). I'm not sure how the localization cache works, so would someone let me know what I have to do to get this variable in the scope of getLocalisationCache()?
Thanks.