The SimpleBatchUpload [1] extension uses the MW API to batch-upload files. In
the simplest case the user just goes to Special:BatchUpload, dumps a bunch of
files and they are uploaded in parallel.
I got a bug report recently [2] where I am not sure what to do:
"Our group has been using
ction."
‐‐‐ Original Message ‐‐‐
On Friday, November 15, 2019 4:15 PM, David Barratt
wrote:
> as far as I know, extensions shouldn't be declaring a dependency on MediaWiki
> in composer.json and if one is, it should probably be fixed.
>
> On Fri, Nov 15, 2019 at 9:50
e declaring a dependency on
>> MediaWiki in composer.json and if one is, it should probably be fixed.
>>
>> On Fri, Nov 15, 2019 at 9:50 AM Stephan Gambke via Wikitech-l <
>> wikitech-l@lists.wikimedia.org> wrote:
>>
>>>
>>> When running `composer update`
When running `composer update` MediaWiki injects a mediawiki/mediawiki package,
so extensions can declare a dependency on a particular MW version range.
However, when doing a `composer update --dry-run` this package gets not
injected causing the dry run to fail.
Does anybody know a
So here is one vote in favor, if that helps.
Because seeing what is achieved and that there is somebody who actually cares
makes me a bit happier each week.
I do not find these threads too intrusive and there is too little positive
news, anyway.
Maybe, to help people filter these mails out
‐‐‐ Original Message ‐‐‐
On Thursday, March 14, 2019 3:56 PM, David Barratt
wrote:
> Is the Wikimedia Foundation responsible for people's emotions?
Yes. Frustration, mostly. It is not entirely unexpected that this message
originates from @wikimedia.org.
cher "School for Mental Health and Neuroscience,
> Maastricht University" and "Medical Humanities, Amsterdam UMC"
>
> Use SMW to cohere business knowledge scattered across information sources —
> and integrate on search
> Lex Sulzer Knowledge Management Solutions Ar
> So we have to make a trade-off between the burden on extension
> developers and on core developers. When it seems likely that
> basically no non-public extension/skin uses the feature, I think it's
> reasonable to say that we should do what's easiest for core
> developers. If a few people out
> of work they have to do. The deprecation policy is just to give
> extension maintainers a bit of breathing room so they don't have to
> scramble to update their extension before it breaks.
Exactly. It also makes it easier for them to maintain their extensions for more
than the last version of
There have been several proposals for removal without deprecation in the past
few days, each with more impact on existing code - from "virtually certain
nobody ever used" to "the fix is trivial".
I know it is annoying as heck to keep outdated code, but if you ask me, unless
there is an
> Frankly the harsh response from proponents and handling here, to the
> point of bypassing normal processes and misusing rights to enforce
> something that was never even decided as a community, seems completely
> at odds with the spirit and intent of the CoC in the first place. If
> we're
ne for both PHP and Javascript (which is why your browser console
>
> will tell you that jquery ui is deprecated when you use it).
>
> DJ
>
> On Mon, Apr 23, 2018 at 10:47 PM, Stephan Gambke s7ep...@protonmail.com wrote:
>
> > On a tangent to T192752 ([1]), are there any
On a tangent to T192752 ([1]), are there any general guidelines on which
classes are or should be used by core and extension devs on HTML elements for
styling?
On mw.org I found scattered remarks about mw-ui-progressive,
mw-ui-constructive, and the like and I found the page on OOUI ([2]),
> What's making you happy this week? You are welcome to comment in any
> language
I have not always been happy in the past with the handling of deprecations, but
I really appreciate on how it is done for the PHPUnit upgrade (incl. provision
of compat layer and clear instructions on what to
> On Tue, Jun 27, 2017 at 1:02 PM Stephan Gambke <s7ep...@protonmail.com> wrote:
>
>>>> See https://phabricator.wikimedia.org/T118683
>>>> https://gerrit.wikimedia.org/r/#/c/244044 introduced a change that causes
>>>> warnings on extens
> Original Message
> Subject: Re: [Wikitech-l] "How can MW 1.27.1 be stable with a broken hook?"
> Local Time: June 27, 2017 10:41 PM
> UTC Time: June 27, 2017 8:41 PM
> From: innocentkil...@gmail.com
> To: Stephan Gambke <s7ep...@proton
See https://phabricator.wikimedia.org/T118683
https://gerrit.wikimedia.org/r/#/c/244044 introduced a change that causes
warnings on extensions that implemented the TitleMoveComplete hook signature
according to documentation at
https://www.mediawiki.org/wiki/Manual:Hooks/TitleMoveComplete.
Hi.
I have an extension that hooks into ParserAfterParse to modify the
generated HTML (Lingo). The problem is, that apparently this hook is never
called when a page is edited using Visual Editor, which means my extension
does not get to modify the page's HTML content until it is purged
Ok, that's what I'll use then. Thanks!
Stephan
On 10 February 2016 at 17:12, Chad <innocentkil...@gmail.com> wrote:
> On Tue, Feb 9, 2016 at 12:21 AM Stephan Gambke <s7ep...@gmail.com> wrote:
>
>> I now used
>> https://github.com/wikimedia/mediawiki-extensi
On 9 February 2016 at 09:26, Addshore <addshorew...@gmail.com> wrote:
> Take a look at https://www.mediawiki.org/wiki/Special:ExtensionDistributor
I already did.
>> On 8 February 2016 at 23:51, Stephan Gambke <s7ep...@gmail.com> wrote:
>> > The ExtensionDistributo
be interested.
Stephan
On 8 February 2016 at 23:51, Stephan Gambke <s7ep...@gmail.com> wrote:
> It is possible to download extensions in ZIP format from the WMF repo
> using a link like this:
>
>
> http://git.wikimedia.org/zip/?r=mediawiki/extensions/FooBar.git=so
It is possible to download extensions in ZIP format from the WMF repo
using a link like this:
http://git.wikimedia.org/zip/?r=mediawiki/extensions/FooBar.git=someTag=zip
However, this will produce a package with the extension's files in its
root folder. An unsuspecting user will probably
Thanks to whoever helped out!
On 30 January 2015 at 11:18, Stephan Gambke s7ep...@gmail.com wrote:
What is the process to add people as owners of an extension?
What is described on mw.org [0] does not work. Contrary to what is
written there I can not add group members myself to a group that I
What is the process to add people as owners of an extension?
What is described on mw.org [0] does not work. Contrary to what is
written there I can not add group members myself to a group that I am
in. And a request I added there is open now for more than three
months.
So, what do I have to do
Don't know, if that's the correct way, but it is done in SRF for the
excel format:
https://github.com/SemanticMediaWiki/SemanticResultFormats/blob/master/formats/excel/SRF_Excel.php#L249
On 19 January 2015 at 19:45, Jeroen De Dauw jeroended...@gmail.com wrote:
Hey,
On my local wiki I have a
On 25 November 2014 at 04:13, Mark A. Hershberger m...@nichework.com wrote:
I am happy to announce the final release candidate for MediaWiki 1.24.0.
Download links are given at the end of this email. There won't be any
more RC candidates before a final release on Wednesday unless someone
Maybe somewhat more useful as distribution:
I am not employed by the WMF nor do I know the relevant policies of
the WMF. I am also not a lawyer.
I do not think that the use of Glyphicons is a problem in the case of Chameleon.
1. The Chameleon skin does not actually contain the Glyphicons
Halflings font. In fact, it does not even contain
Ok, last attempt.
This needs merge: https://gerrit.wikimedia.org/r/#/c/151370/
Somebody shat on it (-2), so it looks ugly, sorry for that.
Didn't come back to clean up their mess, either, instead told me to
advertise it here.
Sorry for putting it like this, in particular with the Sumana's
. Properly deprecating the
class variables will have to wait until we can use traits (PHP 5.4), as
that seems to be the consensus of how it should be done.
I would appreciate if somebody could finally merge
https://gerrit.wikimedia.org/r/#/c/151370/.
Stephan
On 2014-08-23 00:33, Stephan Gambke
TL;DR: Please review [1]
I was asked to discuss the topic on the mailing list, so here goes.
Since some time Siebrand is making an effort to improve code quality by
making it phpcs-strict compliant [0]. This involves explicitly declaring
the visibility of class members.
Alas, intended or not,
On 23 August 2014 01:56, Brian Wolff bawo...@gmail.com wrote:
The most major objection I would have, is that the code would make all
private/protected properties accessible, not just the recently
deprecated. Otherwise the code kind of seems like a lesser evil.
I thought about introducing
I consider it rather bad style to launch personal attacks in what
should be a technical discussion.
In particular when your own arguments basically amounted to a
statement that having to execute some git command would be a pain in
the ass.
It was to be expected, that there would be some snags.
Hi,
I would appreciate if somebody could have a look at
https://gerrit.wikimedia.org/r/139268
This is the second patch on a bug on CSSMin url() value remapping.
Remapping was thrown off if the CSS contained comments containing
curly braces. The fix just replaces all comments (except embed
On 1 June 2014 22:45, Daniel Friesen dan...@nadir-seen-fire.com wrote:
What kind of decoupling did you have in mind?
Not specifying that each skin has to have exactly one lc identifier
and then starting to rely on this requirement and generate all sorts
of secondary names, identifiers, paths,
I'll not answer all your points. I'd just like to (again) question the
need to keep all the names and identifiers of a skin identical
whatever the cost. Maybe I am daft, everybody else seems to take this
as some given great goal and nobody else is questioning it.
As I see it it introduces all
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There seem to be three popular ways:
* $IP/skins/SkinName.php for the main file plus $IP/skins/skinname/
for
...
* $IP/skins/SkinName/ for both assets and PHP files
($IP/skins/skinname/SkinName.php etc.), using require_once in
...
*
.
Cheers,
Stephan
Sent from my mobile
-- Forwarded message --
From: Stephan Gambke s7ep...@gmail.com
Date: Mar 11, 2014 12:18 AM
Subject: Re: [Wikitech-l] GSoC Proposal : Simultaneous Modification of
Multiple Pages with Semantic Forms
To: wikitech-l@lists.wikimedia.org,
semediawiki-u
Is there a particular reason for making them extensions and not
(installable) skins?
Cheers,
Stephan
On 12 Mar 2014 16:47, Jon Robson jdlrob...@gmail.com wrote:
Okay to make sure stuff comes out of this thread...
So unless someone does this before me I am going to move CologneBlue out of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
@wikitech-l:
Could a core developer with a database background please have a look
at Pawan's patches:
* https://gerrit.wikimedia.org/r/#/c/110503/
* https://gerrit.wikimedia.org/r/#/c/110949/
I tried reviewing them, but I really don't know much
Hello,
is there a particular reason, why OutputPage::addModuleScripts,
OutputPage::addModuleStyles, ParserOutput::addModuleScripts, and
ParserOutput::addModuleStyles do not resolve module dependencies? Or
is this just something nobody ever bothered to implement?
Cheers,
Stephan
Hi Nasir,
yes, I am working on the Chameleon skin [0].
I updated it to Bootstrap 3 a few days ago. Right now I have a working
version here that will allow you to add your own customizations on top
of Bootstrap, e.g. change colors and fonts from your LocalSettings.php.
I'll check that in this
Hi Yury,
great news. This must have been a lot of work. Thanks for the effort!
One issue: I included the youtube link, but there seems to be a
problem with the template and properties. Could you have a look?
(http://semantic-mediawiki.org/wiki/SMWCon_Fall_2012/Filtered_result_format)
Cheers,
Hi,
is there a recommended work flow for bugfixing?
Right now what I do is submit a patch to gerrit and, if I remember, set
some tag in bugzilla. At some point somebody approves and merges the
patch. Then, if I remember, I set the bug to resolved/fixed in bugzilla.
There is a bit too much
On 11/08/2012 07:43 PM, Daniel Friesen wrote:
Would it be possible/sensible to automatically close a bug when the
patch is merged? Or did I miss something?
That would require two things:
A) Far more integration between Gerrit and Bugzilla than we currently have.
B) An assumption that every
Hi,
the next batch of extensions to be transferred to Git is overdue for
more than a week now. Any idea, when it will actually happen?
(http://www.mediawiki.org/wiki/Git/Conversion/Extensions_queue)
Cheers,
Stephan
___
Wikitech-l mailing list
Ok, I don't get it. All the time I do a pull I get conflicts. Latest
just now:
CONFLICT (delete/modify): includes/api/ApiTokens.php deleted in HEAD and
modified in 4cee7f1bb6f5b40134f211a626fd70504fc216dd. Version
4cee7f1bb6f5b40134f211a626fd70504fc216dd of includes/api/ApiTokens.php
left in
Am 28.04.2012 14:37, schrieb Chad:
If you start changing files or trying to merge branches then
you run the risk of getting conflicts...
Even on files I did not even touch?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
Am 28.04.2012 14:43, schrieb Chad:
If you didn't touch them, then I don't know how
there would be a conflict.
Me neither. That's why I asked.
Will try to start over with a fresh clone.
Thanks anyway.
Cheers,
Stephan
___
Wikitech-l mailing list
Am 28.04.2012 21:09, schrieb Daniel Friesen:
What is the diff? By any chance do you still have svn attached?
Sorry, don't have the files anymore. But no, no it was a clone from git.
Have a different setup now and so far it seems to work.
Cheers,
Stephan
Am 23.03.2011 23:33, Tim Starling wrote:
recursiveTagParse() is the function to use from a tag hook or other
parser hook, to parse text when a parse operation is already in
progress on the same Parser object. It should not be used when a parse
operation is not in progress. Its output is
I work on an extension that used to call parse() directly. Then after
some advice from mw developers this was changed to a call to
recursiveTagParse because parse should not be called directly.
Only problem is, the method that used to call parse() is used to
populate a Special page, so parse() is
53 matches
Mail list logo
