Hi,
is there a possibility to stop or reset the counter of the autonumbering
function within parser.php without using clearState()?
Thank you very much
Christoph
On the toolserver, the pagelinks table contains lots'o'links to a blank target:
select * from pagelinks where pl_title="" limit 100 ;
(tried up to limit 10000, found 10000 but sloooow)
Apparently, many links to empty page titles in namespace 0. This
surfaced when one of my tools spat out blank results. It wasn't there
a few weeks ago (two month at most). Tested for en and de wikipedia.
Is this a toolserver replication thing, or are these things in the
live database as well? It's probably not a showstopper, but we might
want to get rid of both links and bug anyway.
Magnus
I'm working on a WebDAV interface to MediaWiki, based on the WebDAV
module I contributed to the Gallery project:
http://www.mediawiki.org/wiki/WebDAV
The goal of this project is:
* To support connecting to MediaWiki with WebDAV clients like
[http://www.webdav.org/cadaver/ cadaver] and
[http://0pointer.de/lennart/projects/fusedav/ fusedav].
* To support integrating MediaWiki with editors that support WebDAV,
like Emacs and Eclipse.
* To explore MediaWiki article histories with WebDAV clients that
support the WebDAV versioning extension, DeltaV.
* To support connecting to MediaWiki with a Subversion client like the
command line or Eclipse Subclipse plugin.
Connecting with Subversion is in the scope of this project because
Subversion supports a protocol which is very close to WebDAV and DeltaV:
http://subversion.tigris.org/webdav-usage.html
By supporting Subversion clients, I can edit MediaWiki articles using
the Emacs version control mode and I can explore MediaWiki article
histories using the Eclipse Subclipse plugin. If I maintain a software
project's documentation in MediaWiki, I can use the Subversion
[http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html
externals] feature to checkout MediaWiki articles along with the source
code. These can then be distributed with the project or converted to PDF
or manpage using XSL as part of the build process.
So far I have implemented:
* Some WebDAV features: GET, PUT, PROPFIND and DELETE. I can edit
articles with cadaver, fusedav, Emacs and Eclipse.
* Some DeltaV features: version-tree and baseline support. I can explore
article histories and old revisions with cadaver.
* Subversion checkout: I can checkout articles from the command line and
explore article histories with Subclipse. Checkin will need support for
the svndiff format, which happily is well documented in the Subversion
source.
You can install it by executing in your MediaWiki root directory:
svn co http://svn.freegeek.org/svn/mediawiki-webdav/trunk .
However the code is still very "proof of concept" - I'm still figuring
out how the code will be finally organized. Unless I can contribute this
interface to the MediaWiki project, I guess it should be organized as a
MediaWiki extension? However I'm still getting familiar with how
MediaWiki delegates requests to extensions. Most WebDAV clients demand
hierarchical URLs and don't support query strings, so I currently use
two additional PHP landing pages in the MediaWiki root directory:
* webdav.php handles WebDAV requests for articles like
webdav.php/<MediaWiki_Article_Name>
* deltav.php is responsible for DeltaV functionality. Its layout is
based on Subversion's, e.g. deltav.php/ver/<Revision_ID>,
deltav.php/bc/<Revision_ID>, etc.
If I continue using this layout, I will spend some time cleaning and
reorganizing the code. But before I do, I'd love some feedback from
MediaWiki developers: Is this a reasonable design? What are the
alternatives to and the consequences of introducing these two new
landing pages?
Eventually, I would like to move this project to the MediaWiki
Subversion repository. Here is my SSH public key, signed with my GPG
key: http://cgi.sfu.ca/~jdbates/tmp/freegeek/id_dsa.pub.gpg
My username is "jablko".
I look forward to your input on this project! Thanks, Jack
Hi,
within the last few days we had various complaints in the OTRS (info-de)
that people cannot log into their accounts on de.WP. Can somebody please
check if there is any problem on the server side? And it is not the
password=username-problem.
Best regards,
Sven
On Wed, 13 Jun 2007 connelm wrote
>
> So, sysops never make mistakes like this?
> http://en.wiktionary.org/w/index.php?title=Special%3ALog&type=delete&user=&p
> age=%D7%A1%D7%A4%D7%99%D7%99%D7%93%D7%A8%D7%9E%D7%9F While including the
> deleted text was neat for the first couple days, I don't think it is so
> great, now.
Perhaps the automatic inclusion in the comment of "content was"
followed by the first characters of the text should be review. To
solve this problem it would be enough that a comment is required (most
of the time just one or two words are enough to explain, so not a big
time effort)
AnyFile
>On 11/06/07, Daniel Cannon <cannon.danielc(a)gmail.com> wrote:
>> Yes, I do love that! I think this would be a great addition to the
>> deletion mechanism, and, seeing as it's already been done for block,
>> will not serve too difficult to do. If I can find some time this week
>> (and if Titoxd doesn't finish up the script player for the API testing
>> -- meaning that I would need to get back to doing what I'm supposed to
>> be doing here :D), maybe I'll take a stab at this.
>
>Gosh, speeding in a culture of template responses? Can't wait for that.
Bated breath.
>
>
>Rob Church
So, sysops never make mistakes like this?
http://en.wiktionary.org/w/index.php?title=Special%3ALog&type=delete&user=&p
age=%D7%A1%D7%A4%D7%99%D7%99%D7%93%D7%A8%D7%9E%D7%9F While including the
deleted text was neat for the first couple days, I don't think it is so
great, now.
Connel
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.472 / Virus Database: 269.8.15/847 - Release Date: 6/12/2007
9:42 PM
On en.wiktionary.org, the broad majority of sysops use the feature in
[[wikt:WT:PREFS]] to override the deletion message unconditionally, to
prevent libelous information from appearing in the deletion logs. Since our
deletion logs ARE harvested, it seemed rather prudent. The only sysops that
don't have it turned on, are sysops that essentially never delete stuff.
With the appearance of the deletion log on deleted pages, we're revisiting
how we handle misspellings. It would be nice to know if this lovely new
feature will stay around long enough to make a decent test of the new method
(not yet started.)
On another note, the fantastic mechanism now in play for "Block messages"
is, I think, a superb template for how Deletion log comments should be
entered.
--Connel MacKenzie
http://en.wiktionary.org/wiki/User:Connel_MacKenzie
somewiktadmin(a)gmail.com
Ragib Hasan wrote:
> Since many users are not familiar with editing, the workshop
> involves showing them how to create an account, [...]
>
> However, it came to our notice that from a single IP address, no
> more than 6 new accounts could be created.
As a technical solution (and this is why I'm moving this
discussion to wikitech-l) to aid this social process, I think it
could be useful if one user could "sponsor" or "adopt" (i.e.
become the "parent" of) a newcomer. Then the teacher in such a
scenario could be the "sponsor" of 20 new accounts, and the limit
of 6 new accounts per IP address would only need to apply to
non-sponsored (or "orphan") new accounts. As the newcomer gets
older and more mature, the sponsorship link could be dropped.
People trying to contact the newcomer, would be directed to the
parent/sponsor. Or messages to the newcomer would be copied to
the parent/sponsor.
The ability to sponsor new accounts should perhaps be limited to
admins or some other trusted class of users. There could also be
a limit in numbers, so that one teacher could sponsor 50 newcomers
but not 500.
I think this feature could be useful both in WMF projects and when
MediaWiki is used for other (educational) type situations.
Has this been tried?
--
Lars Aronsson (lars(a)aronsson.se)
Aronsson Datateknik - http://aronsson.se
robchurch(a)svn.wikimedia.org schrieb:
> Revision: 22867
> Author: robchurch
> Date: 2007-06-09 16:19:38 +0000 (Sat, 09 Jun 2007)
>
> Log Message:
> -----------
> * Clean up and document Linker::makeBrokenImageLinkObj()
> * (bug 6743) Don't link broken image links to the upload form when uploads are disabled
>
This commit has broken 3 parsertest:
http://tools.wikimedia.de/~hashar/tinder/?offset=20&limit=20
The problem seems to be the generated link:
http://localhost/wikitest/index.php?title=Special:Upload&wpDestFile=Image:F…
It contains now the keyword "Image:" which results in a wrong insert in
the upload form (field "Destination filename:").
Raymond.
Just found an odd problem -- not sure if it's something I did or if it's
just screwed up in general though.
Noticed that a scap was recently done on Wikimedia and so went to try out
Special:Blockip to find that the "Prevent user from sending e-mail" message
(MediaWiki:Ipblockemail) displayed as <ipblockemail> (or whatever
screwiness it is when there is no such message), although the message had
been defined in MessagesEn.php. When I went to the system message, it
displayed the correct default message but did not take effect until I saved
the message (creating it with its default value). This problem does not seem
to exist on testwiki, and it never did on my local wiki or my public
testwiki. Any idea what's going on?
--
Daniel Cannon (AmiDaniel)
http://amidaniel.com
cannon.danielc(a)gmail.com
