What is the proper way to make an empty edit of an existing article programmatically, in a maintenance script? I tried this:
$title = Title::newFromText("My existing article name"); // succeeds
$wikiPage = new WikiPage($title); // succeeds
$wikiPage->doEditContent($wikiPage->getContent(Revision::RAW), '');
but doEditContent just sits there until I get "limit.sh: timed out" in my shell. I can do an empty edit through the browser (click Edit, click Save) just fine.
Thanks, DanB
On 14-04-17 11:58 AM, Daniel Barrett wrote:
What is the proper way to make an empty edit of an existing article programmatically, in a maintenance script? I tried this:
$title = Title::newFromText("My existing article name"); // succeeds
$wikiPage = new WikiPage($title); // succeeds
$wikiPage->doEditContent($wikiPage->getContent(Revision::RAW), '');
but doEditContent just sits there until I get "limit.sh: timed out" in my shell. I can do an empty edit through the browser (click Edit, click Save) just fine.
I do the following in my calendar extension:
<?php $dbw = wfGetDb( DB_MASTER );
$revision = Revision::newNullRevision( $dbw, $articleId, $details, true );
if( $revision ) { $revision->insertOn( $dbw ); }
$dbw->commit(); ?>
HTH!
Cheers, Rob.
On Thu, 17 Apr 2014 17:58:19 +0200, Daniel Barrett danb@vistaprint.com wrote:
What is the proper way to make an empty edit of an existing article programmatically, in a maintenance script?
I'd look at maintenance/edit.php if I were you :)
I asked:
What is the proper way to make an empty edit of an existing article programmatically, in a maintenance script?
Bartosz Dziewonski replied:
I'd look at maintenance/edit.php if I were you :)
Thanks. I just tried the technique in edit.php and it worked great... at first. I merely changed these lines, which get text from stdin:
# Read the text $text = $this->getStdin( Maintenance::STDIN_ALL ); $content = ContentHandler::makeContent( $text, $wgTitle );
to reuse the original page content:
# Read the text $content = $page->getContent();
and it produced a null edit as desired. But for some mysterious reason, the script hangs if the article contains a scaled image ANYWHERE in it, such as:
[[File:Example.jpg|202px]]
Any idea why that would happen?
Thank you very much, DanB
This was asked just few days ago on this list... https://www.mediawiki.org/wiki/Manual:Pywikibot/touch.py is regularly used to make millions null edits, don't bother inventing something else.
Nemo
Federico Leva (Nemo) writes:
https://www.mediawiki.org/wiki/Manual:Pywikibot/touch.py is regularly used to make millions null edits, don't bother inventing something else.
Awesome! This worked perfectly. Thank you so much!! DanB
On Fri, Apr 18, 2014 at 5:22 PM, Federico Leva (Nemo) nemowiki@gmail.comwrote:
This was asked just few days ago on this list... https://www.mediawiki.org/wiki/Manual:Pywikibot/touch.py is regularly used to make millions null edits, don't bother inventing something else.
It seems touch.py should be updated to make use of forcelinkupdate, forcerecursivelinkupdate and generator parameters of api.php?action=purge, to reduce traffic.
https://www.mediawiki.org/wiki/API:Purge
-Liangent
Nemo
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Liangent wrote:
It seems touch.py should be updated to make use of forcelinkupdate, forcerecursivelinkupdate and generator parameters of api.php?action=purge, to reduce traffic.
As far as I can tell, touch.py should not be necessary. Purging (including links updates) should just work in MediaWiki. Individual users shouldn't feel compelled to manually null edit or aggressively purge pages. I'd personally rather see time and energy invested into making the need for null edits obsolete instead of making touch.py more robust.
MZMcBride
There're still cases / some bugs where *links tables can't be updated automatically. touch.py and similar techniques work as a workaround.
On Sat, Apr 19, 2014 at 9:12 AM, MZMcBride z@mzmcbride.com wrote:
Liangent wrote:
It seems touch.py should be updated to make use of forcelinkupdate, forcerecursivelinkupdate and generator parameters of api.php?action=purge, to reduce traffic.
As far as I can tell, touch.py should not be necessary. Purging (including links updates) should just work in MediaWiki. Individual users shouldn't feel compelled to manually null edit or aggressively purge pages. I'd personally rather see time and energy invested into making the need for null edits obsolete instead of making touch.py more robust.
MZMcBride
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Liangent wrote:
There're still cases / some bugs where *links tables can't be updated automatically. touch.py and similar techniques work as a workaround.
Workaround or... hack. :-) I agree that touch.py is useful right now. I wish it were not necessary, though. If anyone's interested in killing the purge action in MediaWiki: https://bugzilla.wikimedia.org/54902.
MZMcBride
I'm the original poster -- here is my real-world use case where a null edit is required.
My wiki has a custom parser tag, (say) <foobar>. Many articles include it in their wikitext.
We modified the code for <foobar> to add a feature: autocategorizing. It automatically categorizes any article that contains it (say, in "Category:Articles containing the foobar tag").
After this code change is deployed, if you visit an article Blat that previously contained <foobar>, you will see it is properly categorized at the bottom. However, if you visit the category page for "Articles containing the foobar tag", it is missing Blat (and tons of other articles).
If you perform a null edit on Blat, it then shows up on the category page. Purging Blat (action=purge) does not have this effect.
DanB
refreshLinks.php[1] can fix that.
[1] https://www.mediawiki.org/wiki/Manual:RefreshLinks.php
On Tue, Apr 22, 2014 at 12:36 AM, Daniel Barrett danb@vistaprint.comwrote:
I'm the original poster -- here is my real-world use case where a null edit is required.
My wiki has a custom parser tag, (say) <foobar>. Many articles include it in their wikitext.
We modified the code for <foobar> to add a feature: autocategorizing. It automatically categorizes any article that contains it (say, in "Category:Articles containing the foobar tag").
After this code change is deployed, if you visit an article Blat that previously contained <foobar>, you will see it is properly categorized at the bottom. However, if you visit the category page for "Articles containing the foobar tag", it is missing Blat (and tons of other articles).
If you perform a null edit on Blat, it then shows up on the category page. Purging Blat (action=purge) does not have this effect.
DanB
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Apr 22, 2014 at 12:36 AM, Daniel Barrett danb@vistaprint.comwrote:
We modified the code for <foobar> to add a feature: autocategorizing. [Now] if you visit an article Blat that previously contained <foobar>, you will see it is properly categorized at the bottom. However, if you visit the category page for "Articles containing the foobar tag", it is missing Blat (and tons of other articles).
Liangent wrote:
refreshLinks.php[1] can fix that.
Thanks, but I ran refreshLinks.php and it didn't update the category page (MW 1.21.8). Performing a null edit is the only technique I've found to work.
DanB
On Apr 23, 2014 11:52 AM, "Daniel Barrett" danb@vistaprint.com wrote:
On Tue, Apr 22, 2014 at 12:36 AM, Daniel Barrett <danb@vistaprint.com wrote:
We modified the code for <foobar> to add a feature: autocategorizing. [Now] if you visit an article Blat that previously contained <foobar>, you will see it is properly categorized at the bottom. However, if you visit the category page for "Articles containing the foobar tag", it is missing Blat (and tons of other
articles).
Liangent wrote:
refreshLinks.php[1] can fix that.
Thanks, but I ran refreshLinks.php and it didn't update the category page
(MW 1.21.8). Performing a null edit is the only technique I've found to work.
DanB
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
RefreshLinks.php disables extensions (which is silly imo), which is why it didnt work.
--bawolff
wikitech-l@lists.wikimedia.org