Re: [Wikitech-l] Programmatically making an empty edit?
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.
--
E-Mail Disclaimer: Information contained in this message and any
attached documents is considered confidential and legally protected.
This message is intended solely for the addressee(s). Disclosure,
copying, and distribution are prohibited unless authorized.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] On your python vs php talk
On 13-07-28 06:33 AM, Svip wrote: On 28 July 2013 09:52, Виталий Филиппов vita...@yourcmc.ru wrote: Also for example I don't like python's strict typization ideas (for example it throws exception if you concatenate long and str using +). PHP is simple and has no such problems. Except, you know, that is not entirely true. PHP's weak dynamic types causes numerous problems. You cannot compare strings in order to sort them, you need to convert individual characters to their ASCII/Unicode value and compare it that way (and that in itself is not always perfect, because their value may not be in the same order as humans consider an appropriate sorting[0]). If I do `10 == 10' in PHP, PHP will yield true. I can force it to say false (because they are not the same type) by using '===' (except - of course - PHP developers fails to understand what the === operator is for[1]). You should prefix that statement with some so that it reads some PHP developers fails[sic] to understand what the === operator is for. But if I do `10 11' in PHP, it will yield true, Because you didn't properly state what you wanted if this is not what you wanted. because does what == does (converts the types), but there is no way to tell PHP, I don't want that. Indeed there is: if( is_int( 10 ) is_int( 11 ) 10 11 ) Particularly because int nor str doesn't exist in the language, you Yes they do. cannot cast things in PHP to control your types. One certainly can: $int = (int)$string; Furthermore, PHP has an annoying habit of doing stuff without warning you. I recommend you reading this article: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ The writer names 5 stances: predictable, consistent, concise, reliable, debuggable I can only see one failing... consistent and much of that is for historical reasons and the mirroring of C based library functions. All turing complete languages are predictable by definition. PHP is certainly concise compared to many languages. Reliability is dependent on the skill level of the developer. Debuggable is certainly possible, although perhaps more difficult than some languages. Screen prints, log prints, and xdebug generally make the process simple enough. Cheers, Rob. This is one of the main reasons I stopped contributing to MediaWiki; I simply got tired of writing in PHP. I don't like a language where I constantly have to circumvent it, because its developers are stupider than I am. [0] Of course, no other languages solves this issue as well, so that's another thing. [1] === compares values and type… except with objects, where === is only true if both operands are actually the same object! For objects, == compares both value (of every attribute) and type, which is what === does for every other type. Wat. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- E-Mail Disclaimer: Information contained in this message and any attached documents is considered confidential and legally protected. This message is intended solely for the addressee(s). Disclosure, copying, and distribution are prohibited unless authorized. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] On your python vs php talk
On 13-07-28 12:22 PM, Svip wrote: On 28 July 2013 17:48, Robert Cummings rob...@interjinn.com wrote: On 13-07-28 06:33 AM, Svip wrote: Particularly because int nor str doesn't exist in the language, you Yes they do. No, they don't. They only exist in the context you describe below: cannot cast things in PHP to control your types. One certainly can: $int = (int)$string; Can I do var_dump(int);? Well, it turns out the only thing you can do is casting, but even casting in PHP is rather pointless. I can only see one failing... consistent and much of that is for historical reasons and the mirroring of C based library functions. All turing complete languages are predictable by definition. PHP is certainly concise compared to many languages. Reliability is dependent on the skill level of the developer. Debuggable is certainly possible, although perhaps more difficult than some languages. Screen prints, log prints, and xdebug generally make the process simple enough. I have been doing a lot of debugging PHP in my time, and I know how it works. That doesn't change the fact that it is rather annoying and a tedious process compared to other languages. I also like that other languages *tell* you stuff, rather than having to know all these small quirks in a language; this create language overhead, meaning a programmer needs to contain a lot of information readily available when programming. And for what? So I can save 10 minutes when setting up, but enduring 6 months of torture? Yeah, I think I'll pass. PHP wasn't chosen for MediaWiki because it was the language the development team (at least the current) liked the best; but because the first developer on MediaWiki chose it. And that's that. I debunked your original comments and you come back with more false claims and subjective argumentation. I don't foresee a rational dialogue emerging in the future so it's probably best to leave you to your PHP loathing. As for why MediaWiki uses PHP... I guess that's what you get when you invent something-- you get to choose the design and tools. Cheers, Rob. -- E-Mail Disclaimer: Information contained in this message and any attached documents is considered confidential and legally protected. This message is intended solely for the addressee(s). Disclosure, copying, and distribution are prohibited unless authorized. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] History entry without content change?
On 12-03-12 01:20 PM, Marcin Cieslak wrote: Robert Cummingsrob...@interjinn.com wrote: On 12-03-12 05:25 AM, Max Semenik wrote: On 12.03.2012, 12:44 Robert wrote: Hello all, I was wondering if there's a clean way within the Wiki codebase to generate a history entry for an article without actually modifying the content. Essentially, from within an extension, I'd like to treat the history as a logfile for specific events related to the article that don't actually modify the article. See Revision::newNullRevision() Perfect, thank you! or maybe you can do something like $logEntry = new ManualLogEntry( 'something', 'somethingmaybeese' ); $logEntry-setPerformer( $user ); $logEntry-setTarget( $this-mTitle ); $logEntry-setComment( $reason ); $logid = $logEntry-insert(); $logEntry-publish( $logid ); (from WikiPage.php line 2990) Thanks, I'll have a look at that also. Cheers, Rob. -- E-Mail Disclaimer: Information contained in this message and any attached documents is considered confidential and legally protected. This message is intended solely for the addressee(s). Disclosure, copying, and distribution are prohibited unless authorized. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] History entry without content change?
Hello all, I was wondering if there's a clean way within the Wiki codebase to generate a history entry for an article without actually modifying the content. Essentially, from within an extension, I'd like to treat the history as a logfile for specific events related to the article that don't actually modify the article. Thanks, Rob. -- E-Mail Disclaimer: Information contained in this message and any attached documents is considered confidential and legally protected. This message is intended solely for the addressee(s). Disclosure, copying, and distribution are prohibited unless authorized. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] History entry without content change?
On 12-03-12 05:25 AM, Max Semenik wrote: On 12.03.2012, 12:44 Robert wrote: Hello all, I was wondering if there's a clean way within the Wiki codebase to generate a history entry for an article without actually modifying the content. Essentially, from within an extension, I'd like to treat the history as a logfile for specific events related to the article that don't actually modify the article. See Revision::newNullRevision() Perfect, thank you! Cheers, Rob. -- E-Mail Disclaimer: Information contained in this message and any attached documents is considered confidential and legally protected. This message is intended solely for the addressee(s). Disclosure, copying, and distribution are prohibited unless authorized. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Cache Expiry
Hello, I've looked around for methods to manipulate the cache duration for a given article. There are methods to facilitate the expiration of an article, and there are extensions that can disable caching for articles via convenient management interfaces. What seems to be lacking though, is a way to expire the article after some duration. For instance, I'm working with embedded RSS feeds... from what I'm finding I have 3 options: 1. Live with the RSS feed being cached. 2. Immediately invalidate the article cache so that the next request causes the article to be rebuilt. 3. Tell users to use action=purge (or provide a button to manually do this (or invalidate the cache). The first option is not really an option :) The second option is inefficient. The third option is unpalatable. So the question becomes-- Would it be possible to have a new field added to the page database table that determines the duration of the cache? This would be optimal because extensions could then auto determine the maximum duration of the article either by directly manipulating the table entry, or preferably via a hook when the article is saved. Failing a change to the MediaWiki core, I guess I could create a service extension that uses it's own database table to track durations and checks for expirations via the job system at which time it could invalidate articles. But that seems roundabout for something that strikes me as better supported in the core. Thoughts? Cheers, Rob. -- E-Mail Disclaimer: Information contained in this message and any attached documents is considered confidential and legally protected. This message is intended solely for the addressee(s). Disclosure, copying, and distribution are prohibited unless authorized. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Cache Expiry
On 11-06-08 05:02 PM, Brion Vibber wrote:
On Wed, Jun 8, 2011 at 1:50 PM, Robert Cummingsrob...@interjinn.comwrote:
It looks like MediaWiki 1.17 and later support this already, by calling
updateCacheExpiry() on the parser cache output object.
The RSS extension uses this in its rendering hook:
if ( $wgRSSCacheCompare ) {
$timeout = $wgRSSCacheCompare;
} else {
$timeout = $wgRSSCacheAge;
}
$parser-getOutput()-updateCacheExpiry( $timeout );
In theory at least this should propagate the shorter expiry time out to both
the parser cache entry and the actual output page's HTTP headers, though I
haven't tested to double-check myself yet.
Great, that appears to be what I was looking for... I'll go explore the
code now :)
Thanks,
Rob.
--
E-Mail Disclaimer: Information contained in this message and any
attached documents is considered confidential and legally protected.
This message is intended solely for the addressee(s). Disclosure,
copying, and distribution are prohibited unless authorized.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
