[MediaWiki-l] Looking for a maintainer for the Lingo extension

[Stephan Gambke via MediaWiki-l]

Hi,

I do not find the time anymore for MediaWiki extension development. Maintenance 
for most of my extensions has been taken over by the guys of ProfessionalWiki, 
however for the Lingo extension I am still looking for somebody.

Lingo is a glossary extension that lets you define a list of terms together 
with their definitions on a glossary page and then displays these definitions 
whenever a term is hovered over in an article (see [1]). As far as I know it is 
the only extension providing this functionality and it is currently in use on 
at least 141 wikis according to WikiApiary ([2]).

The extension has required remarkably little maintenance in the past, but in 
view of the upcoming changes on Parser hooks it is likely that things will 
start to break. So, if anybody would like to take over, please get in contact.

Cheers
Stephan


[1] https://www.mediawiki.org/wiki/Extension:Lingo
[2] https://wikiapiary.com/wiki/Extension:Lingo

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] SimpleBatchUpload 1.3.2 - Security release

[Stephan Gambke]

I don't normally advertise new releases of this extension, much less minor 
ones, but this concerns a security issue, so here goes...

I just released the SimpleBatchUpload extension version 1.3.2 which fixes an 
unauthenticated arbitrary file upload vulnerability present in the Blueimp
jQuery-File-Upload module used by this extension ([1], [2]). This vulnerability 
allows remote execution of code on the server.

This vulnerability affects all versions of SimpleBatchUpload < 1.3.2 on 
MediaWiki < 1.27.4/1.28.3/1.29.2/1.30.0. Higher versions of MediaWiki block the 
/vendor directory for direct webaccess, so while the unauthorized upload of 
files is still possible, at least they cannot be used as remote entry points, 
so execution of code should not be possible.

If you are using one of the affected versions, please upgrade SimpleBatchUpload 
as soon as possible.

Stephan

[1] https://nvd.nist.gov/vuln/detail/CVE-2018-9206
[2] http://www.vapidlabs.com/advisory.php?v=204

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Lua/Scribunto

[Stephan Gambke]

Protoypes is a good pointer. Thanks!

I didn't find any automatisms, but I can do

someTable={}
setmetatable( someTable, { __index = table} )

and I am set to do someTable:insert(), someTable:concat(), etc. Neat.

Unfortunately it is not as easy for strings. There actually is an automatism 
for strings in vanilla Lua, but it is turned off in Scribunto. [1]

Stephan


[1] 
https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual#Metatables:"Note:
 In Lua, all strings also share a single metatable, in which __index refers to 
the string table. This metatable is not accessible in Scribunto, nor is the 
referenced `string` table; the string table available to modules is a copy."

‐‐‐ Original Message ‐‐‐
On July 17, 2018 10:43 PM, Derk-Jan Hartman  
wrote:

> Maybe you missed that table.foo (and similarly string.foo) is the prototype 
> for any someTable, which thus automatically has someTable.foo(). And that 
> someTable:foo(args) is just syntactic sugar for someTable.foo( someTable, 
> args ) ?
>
> It's one of those weird Lua quirks
>
> DJ
>
> On Mon, Jul 16, 2018 at 1:05 PM Stephan Gambke  wrote:
>
> > I have been playing with Scribunto recently and the one thing that struck 
> > me as odd was that Lua has a number of methods like table.foo or 
> > string.foo, but I did not find any factory module leveraging these methods 
> > to provide someting more intuitive like someTable:foo or someString:foo.
> > Is it just not worth it or did I miss anything?
> >
> > Stephan
> > ___
> > MediaWiki-l mailing list
> > To unsubscribe, go to:
> > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] Lua/Scribunto

[Stephan Gambke]

I have been playing with Scribunto recently and the one thing that struck me as 
odd was that Lua has a number of methods like table.foo or string.foo, but I 
did not find any factory module leveraging these methods to provide someting 
more intuitive like someTable:foo or someString:foo.
Is it just not worth it or did I miss anything?

Stephan
___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Is it possible to store uploads encrypted?

[Stephan Gambke]

is
> >
> > where is the key stored. To do something like this, you would probably
> >
> > put your encryption key in LocalSettings.php (Even if you do something
> >
> > more complex, MediaWiki would have to have access to the key at some
> >
> > point in order to decrypt the files to send them to your users). If
> >
> > you don't have control to the host, the attacker could just read the
> >
> > key out of your LocalSettings.php (or in more complex schemes, PHP's
> >
> > memory), and thus defeat the encryption.
> >
> > The type of system where this sort of thing makes more sense, is if
> >
> > you are storing files on a different server then your main web server
> >
> > (Say amazon S3 or whatever). If you don't trust the file server, but
> >
> > do trust your web server, then encrypting the files could make sense
> >
> > as long as the key stays only on the server you trust.
> >
> > --
> >
> > Brian
> >
> > On Mon, May 28, 2018 at 2:08 PM, Stephan Gambke  
> > wrote:
> >
> > > To prevent unauthorized access I may have to ensure that uploaded files 
> > > are stored encrypted. Wiki pages themselves are less critical, and may 
> > > remain in clear text.
> >
> > > The scenario is a relatively small wiki (30,000 pages, 10,000 files, but 
> > > only 27 users) on a virtual server where I have full remote root access. 
> > > The host of the virtual machine is not under my control.
> >
> > >
> >
> > > - Is there any obvious problem that makes this conceptionally impossible?
> >
> > > - Is anybody already doing this or working in that direction?
> >
> > > - What could be viable approaches and what limitations would there be?
> >
> > >
> >
> > > I know, it's a rather broad topic. Still, any pointers would be welcome.
> >
> > >
> >
> > > Cheers
> >
> > > Stephan
> >
> > >
> >
> > > ___
> >
> > > MediaWiki-l mailing list
> >
> > > To unsubscribe, go to:
> >
> > > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
> >
> > ___
> >
> > MediaWiki-l mailing list
> >
> > To unsubscribe, go to:
> >
> > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] Is it possible to store uploads encrypted?

[Stephan Gambke]

To prevent unauthorized access I may have to ensure that uploaded files are 
stored encrypted. Wiki pages themselves are less critical, and may remain in 
clear text.
The scenario is a relatively small wiki (30,000 pages, 10,000 files, but only 
27 users) on a virtual server where I have full remote root access. The host of 
the virtual machine is not under my control.

- Is there any obvious problem that makes this conceptionally impossible?
- Is anybody already doing this or working in that direction?
- What could be viable approaches and what limitations would there be?

I know, it's a rather broad topic. Still, any pointers would be welcome.

Cheers
Stephan

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Is it possible to re-introduce "pageviews" and "PopularPages" in MediaWiki (in any hackish way) - or go with an install of 1.24?

[Stephan Gambke]

I am very much with Lewis on this: Using outdated MW versions poses significant 
security risks.

That said, there is to my knowledge no one download package containing more 
than one skin. In fact, in the case of Chameleon there is no drop-in download 
package at all. You need to use Composer for installation. On the upside, it is 
compatible with MW 1.22 or higher. See installation instructions here: 
https://github.com/cmln/chameleon/blob/master/docs/installation.md

You could also download old skin versions from Github, e.g. for Monobook go to
https://github.com/wikimedia/mediawiki-skins-MonoBook , select the REL1_24 
branch and download the ZIP.

Of course, if you think that hitcounters are worth having, consider giving that 
unmaintained extension some love and making it compatible with modern MW. 
Others will thank you for it.

Stephan


‐‐‐ Original Message ‐‐‐

On May 27, 2018 5:02 PM, Morten Blaabjerg  wrote:

>
>
> On Sun, May 27, 2018 at 1:47 PM, Lewis Cawte lewisca...@googlemail.com
>
> wrote:
>
> > Never tried it but the functionality was moved into an extension,
> >
> > https://www.mediawiki.org/wiki/Extension:HitCounters
>
> I found this, but is seems unsupported, and I would probably be just as
>
> worse off with this as I would be with using 1.24 with a compatible skin.
>
> > The MediaWiki site probably will not distribute the old versions of skins
> >
> > although they do exist in the old branches of their respective Git
> >
> > repositories.
>
> Would be great if I could just get a link to download a package of some of
>
> the compatible skins. I'm going to hack them to pieces anyway, just need to
>
> get the wiki up and running with a skin, which is not too difficult to work
>
> with. Foreground, Chamaeleon, Tweeki or even some of the old simple skins
>
> would probably do for starters.
>
> > Is there any particular reason why you are using such an old unsupported
> >
> > version of MediaWiki?
>
> Yes. The new version doesn't support "pageviews" and the
>
> "special:popularpages" has been removed. Why they would not simply leave it
>
> in to people to enable or disable it according to their tastes, I don't
>
> get. I always thought it was quite useful for a small wiki to get an
>
> indication of what pages were actually read by people.
>
> > Sorry I can't be of more help at the moment - currently sat on a campsite.
> >
> > Sure! Thanks for your time!
>
> I am an old user/admin of MediaWiki from way back in the early days.
>
> A lot has changed since then for MW - a lot to the better. But I don't like
>
> the serious roadblocks that are in place for someone like me to not get to
>
> use an earlier version of the software, if I so please. Should be fairly
>
> simple to keep old skins around to get to, if one had the taste for it.
>
> -- Lewis Cawte
>
> > On Sun, 27 May 2018, 12:13 Morten Blaabjerg, mortenblaabj...@gmail.com
> >
> > wrote:
> >
> > > I am building a proof of concept site, which will at a later stage, if it
> > >
> > > works the way I intend, be rebuilt from scratch and up.
> > >
> > > I wanted to use MediaWiki for this project, because of the speed by which
> > >
> > > it is possible to create a lot of articles in a short amount of time, and
> > >
> > > it has some cool statistics and special pages too to manage things, and I
> > >
> > > simply love the template functionality too.
> > >
> > > However, upon installing, I was surprised to learn, that the "pageviews"
> > >
> > > and "special:popularpages" was gone from the mediawiki from 1.25 onward,
> > >
> > > and I had great trouble installing 1.24 which was the last version with
> > >
> > > this functionality, because no skins were included with the old version,
> > >
> > > and I failed in finding compatible skins for this version, despite
> > >
> > > spending
> > >
> > > most of an evening online searching. On the official repository I can
> > >
> > > find
> > >
> > > only skins compatible back to 1.27.
> > >
> > > I would like to use a modern skin which is compatible with 1.24, or the
> > >
> > > other way around, re-introduce the "pageviews" and "popularpages"
> > >
> > > functionality into the current mw version, via an extension, if possible.
> > >
> > > I don't want to go all the way to install google analytics. I just need
> > >
> > > the
> > >
> > > simple indication of how many times a page was asked for by a browser,
> > >
> > > and
> > >
> > > the accumulative results shown in the "special:popularpages" special
> > >
> > > page.
> > >
> > > What is the best way to achieve that? I can understand the functionality
> > >
> > > removal was done with some dissent, so maybe someone already made an
> > >
> > > extension for this functionality, or would it be comparatively easy to
> > >
> > > build one by oneself (since the code already exists, I assume).
> > >
> > > This is for a small mediawiki project, with just 1 editor, and no signups
> > >
> > > for anyone else, so I intend to 

[MediaWiki-l] Lingo extension needs testing

[Stephan Gambke]

I worked on the Lingo extension ([1]) in the past few days, fixing bugs and 
restructuring the injected HTML to be less intrusive in the main article text. 
In the past there were reports about incompatibilities with other extensions 
and the latest changes should potentially fix some of these issues. 

There are currently 4 specific tasks on Phabricator related to 
incompatibilities with other extensions:

* https://phabricator.wikimedia.org/T123966 (SpamBlacklist)
* https://phabricator.wikimedia.org/T123962 (MobileFrontend)
* https://phabricator.wikimedia.org/T123968 (Visual Editor)
* https://phabricator.wikimedia.org/T123971 (Page Schemas)

My problem is, that I do not use these extensions and don't know much about 
them, so I would be really grateful if somebody else could do some testing 
together with the latest dev version of Lingo and give me feedback.

Cheers
Stephan
​​

[1] https://www.mediawiki.org/wiki/Extension:Lingo

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Assistance needed

[Stephan Gambke]

From where did you run `composer update`, MW root or extension dir?



​​

‐‐‐ Original Message ‐‐‐

On March 4, 2018 1:08 AM, Huji Lee  wrote:

> ​​
> 
> Hi all,
> 
> I am trying to test a package called UAParser, which is on Packagist
> 
> already. I created this patch\[1\] to demonstrate it. After making the change
> 
> shown in the patch, I ran composer update and verified that UAParser is in
> 
> the /vendor directory. However, when I open Special:HelloWorld on wiki, I
> 
> get the following error message: Class 'UAParser\\Parser' not found
> 
> I am not super informed about composer and Packagist, and don't know how to
> 
> fix this issue. Any advice would be highly appreciated.
> 
> Thanks,
> 
> Huji
> 
> \[1\] https://gerrit.wikimedia.org/r/#/c/409701/
> 
> MediaWiki-l mailing list
> 
> To unsubscribe, go to:
> 
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l



___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Messages not available client-side

[Stephan Gambke]

Bleagh. I was sure I had the messages defined together with the module that was 
using them. Turns out I had them defined with the module holding the styles 
instead.

​Thanks for the heads-up, Legoktm

​Cheers
Stephan

> Original Message 
>Subject: Re: [MediaWiki-l] Messages not available client-side
>Local Time: November 6, 2017 8:16 PM
>UTC Time: November 6, 2017 7:16 PM
>From: lego...@member.fsf.org
>To: mediawiki-l@lists.wikimedia.org
>
>On 11/04/2017 07:00 AM, Stephan Gambke wrote:
>>Is there a module I need to/should/could wait for? I thought RL was making 
>>sure that basic modules like mw and jquery were available before 
>>loading/running other stuff?
>>
>> You just need to wait for the module that depends upon those messages to
>> load before you can use those messages. If you're doing that, it should
>> work. Could you provide a link to your code?
>>
>> -- Legoktm
>>
>MediaWiki-l mailing list
> To unsubscribe, go to:
>https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>
___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] Messages not available client-side

[Stephan Gambke]

I'm sometimes getting the message code instead of the message text in JS using 
mw.message(...).text(). The messages in question are declared in the RL module 
declaration.
This happens when doing a normal reload (F5), not when doing a full reload 
(Ctrl+F5), so I guess reloading the module from the net instead of from cache 
gives mw the time to actually set up the messages.

Is there a module I need to/should/could wait for? I thought RL was making sure 
that basic modules like mw and jquery were available before loading/running 
other stuff?

Cheers
Stephan
___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Wikiapiary

[Stephan Gambke]

Ah, thanks (Karsten & Yongmin)!
Karsten, the old address is in my inbox. Good luck changing that. :D

>  Original Message 
> Subject: Re: [MediaWiki-l] Wikiapiary
> Local Time: October 8, 2017 10:22 PM
> UTC Time: October 8, 2017 8:22 PM
> From: mediaw...@kghoffmeyer.de
> To: mediawiki-l@lists.wikimedia.org
>
> Heiya Stephan,
>
> have a look here: [0]. In the meantime the mailing list address has also
> changed: [1]. I had hoped to have replaced all references to the old
> mailing list address. :| It will be nice if you could update in the spot
> you still found this one.
>
> Thanks and cheers Karsten
>
> [0] https://phabricator.wikimedia.org/T169534
> [1] https://lists.wikimedia.org/mailman/listinfo/wikiapiary
>
> Am 08.10.2017 um 22:18 schrieb Stephan Gambke:
>> Hi.
>>
>> Does anybody know what"s up with Wikiapiary (https://wikiapiary.com/wiki/)?
>> The cert seems to have been expired and the mailing list address 
>> (wikiapi...@listbox.com) is not found.
>>
>> Stephan
>> ___
>> MediaWiki-l mailing list
>> To unsubscribe, go to:
>> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>
> ___
> MediaWiki-l mailing list
> To unsubscribe, go to:
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] Wikiapiary

[Stephan Gambke]

Hi.

Does anybody know what's up with Wikiapiary (https://wikiapiary.com/wiki/)?
The cert seems to have been expired and the mailing list address 
(wikiapi...@listbox.com) is not found.

Stephan
___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] how to automate "edit with form and save" on all articles

[Stephan Gambke]

Hi Rich.

Have a look at https://github.com/s7eph4n/SimpleBatchUpload.

It's an extension, not a script, but it was developed with exactly your use 
case in mind. It provides a Special page for uploading multiple files to 
MediaWiki and setting a standard template call as the wikitext of the uploaded 
file's page. That template could then set your properties or a category.
(You will need to use the development version to get the full functionality.)

Cheers
Stephan

 Original Message 
On Sep 28, 2017, 17:21, Evans, Richard K. (GRC-H000) wrote:

> Hi.
>
> I set my FILE namespace to have a default form to edit with which adds 
> semantic properties with default values based on the article name.
>
> The problem is that when I upload a file, the upload process doesn't use the 
> form. (There is also the problem that hundreds of legacy files need to go 
> through the "edit with form and save" steps to get the semantic properties 
> set with their default values.
>
> My question is --- is the a maintenance script I can run that will automate 
> the task of "editing with form" and then "save" for each article without me 
> having to visit each article?
>
> An alternate question is --- is there a non-SMW way to include an in-page, 
> in-line image gallery that is the result of a keyword search for the image 
> and file article names?
>
> better way to get searchable semantic properties with default
>
> Thank you!
> -Rich
>
> ___
> MediaWiki-l mailing list
> To unsubscribe, go to:
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] composer installers: Behavior of type "mediawiki-*"

[Stephan Gambke]

Hi Robert.

That's because skins used to be stored in folders with lower-case names.
E.g. see https://github.com/wikimedia/mediawiki/tree/1.23.17/skins

Cheers
Stephan

>  Original Message 
> Subject: [MediaWiki-l] composer installers: Behavior of type "mediawiki-*"
> Local Time: September 14, 2017 3:23 PM
> UTC Time: September 14, 2017 1:23 PM
> From: vo...@hallowelt.com
> To: MediaWiki announcements and site admin list 
> 
>
> Hi!
>
> I"ve stumbled over a strange implementation in the composer installer for 
> MediaWiki related projects:
>
> A package with the name "some-cool-extension" and type "mediawiki-extension" 
> will be installed as "/extensions/SomeCoolExtension". --> The name 
> gets translated from "dashed-lowecase" into "UpperCamelCase" [1].
>
> A package with the name "some-cool-skin" and type "mediawiki-skin" will be 
> installed as "/skins/some-cool". --> The "-skin" suffix is being 
> removed, but no further transformation is being applied [2]. (Not even some 
> uppercaseing. E.g. Vector skin circumvents this by the declaration of an 
> "installer-name" [3]).
>
> Does anybody know _why_ this difference is being made?
>
> [1] 
> https://github.com/composer/installers/blob/master/src/Composer/Installers/MediaWikiInstaller.php#L38
>
> [2] 
> https://github.com/composer/installers/blob/master/src/Composer/Installers/MediaWikiInstaller.php#L45
>
> [3] 
> https://github.com/wikimedia/mediawiki-skins-Vector/blob/master/composer.json#L34
>
> --
>
> Robert Vogel
> ___
> MediaWiki-l mailing list
> To unsubscribe, go to:
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Is namespace specific CSS possible?

[Stephan Gambke]

Trying again with the correct content (s/url/url/):
body.mediawiki {background-image: 
url(https://lh3.googleusercontent.com/mvHbePT-FyB8YpsjecAdCSvK7XoqOcsa4rqpCksWUDZ1koC_2cOfzvt2QU6rPsk5Yuri=w300)
 !important;background-repeat: repeat;}
If this does not work, I blame it on my mail provider.

>  Original Message 
> Subject: Re: [MediaWiki-l] Is namespace specific CSS possible?
> Local Time: August 2, 2017 9:25 PM
> UTC Time: August 2, 2017 7:25 PM
> From: s7ep...@protonmail.com
> To: MediaWiki announcements and site admin list 
> 
> MediaWiki announcements and site admin list 
> Hi Rich.
> First of all, Chameleon should support MediaWiki:Common.css. I just tried 
> setting it to
> body.mediawiki {background-image: 
> url(https://lh3.googleusercontent.com/mvHbePT-FyB8YpsjecAdCSvK7XoqOcsa4rqpCksWUDZ1koC_2cOfzvt2QU6rPsk5Yuri=w300)
>  !important;background-repeat: repeat;}
> on a test wiki and it worked (Careful, this accesses an external resource!).
> If this really doesn't work, you could try adding your own less file. See 
> https://github.com/cmln/chameleon/blob/master/docs/customization.md#changing-styles-fonts-colors-padding-etc
>
> Less is a superset of css, so anything you can put in a css file, you can 
> also put in a less file. However, I suspect if it does not work in 
> MediaWiki:Common.css, it won't work in its own file either. One issue with 
> Twitter Bootstrap used by Chameleon is, that it sometimes sets css rules so 
> specific, that they take precedence over what you try to set. So, make sure 
> to be more specific.
> Cheers
> Stephan
>
>>  Original Message 
>> Subject: Re: [MediaWiki-l] Is namespace specific CSS possible?
>> Local Time: August 2, 2017 7:21 PM
>> UTC Time: August 2, 2017 5:21 PM
>> From: richard.k.ev...@nasa.gov
>> To: MediaWiki announcements and site admin list 
>> 
>> Hi Amanda, yes, thank you!
>> I just discovered that the default skin (monobook) is indeed able to do this 
>> with common.css, but then I quickly discovered that common.css seems to be 
>> completely ignored by the Semantic Mediawiki "Chameleon"
>> https://www.mediawiki.org/wiki/Skin:Chameleon
>> It"s a great skin and I have other reasons for needing to use it. Can anyone 
>> give me a few pointers on how to change the css of a skin like that.. it 
>> seems to not use CSS at all.
>> -Rich
>> ___
>> MediaWiki-l mailing list
>> To unsubscribe, go to:
>> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Is namespace specific CSS possible?

[Stephan Gambke]

Hi Rich.
First of all, Chameleon should support MediaWiki:Common.css. I just tried 
setting it to
body.mediawiki {background-image: 
url(https://lh3.googleusercontent.com/mvHbePT-FyB8YpsjecAdCSvK7XoqOcsa4rqpCksWUDZ1koC_2cOfzvt2QU6rPsk5Yuri=w300)
 !important;background-repeat: repeat;}
on a test wiki and it worked (Careful, this accesses an external resource!).
If this really doesn't work, you could try adding your own less file. See 
https://github.com/cmln/chameleon/blob/master/docs/customization.md#changing-styles-fonts-colors-padding-etc

Less is a superset of css, so anything you can put in a css file, you can also 
put in a less file. However, I suspect if it does not work in 
MediaWiki:Common.css, it won't work in its own file either. One issue with 
Twitter Bootstrap used by Chameleon is, that it sometimes sets css rules so 
specific, that they take precedence over what you try to set. So, make sure to 
be more specific.
Cheers
Stephan

>  Original Message 
> Subject: Re: [MediaWiki-l] Is namespace specific CSS possible?
> Local Time: August 2, 2017 7:21 PM
> UTC Time: August 2, 2017 5:21 PM
> From: richard.k.ev...@nasa.gov
> To: MediaWiki announcements and site admin list 
> 
> Hi Amanda, yes, thank you!
> I just discovered that the default skin (monobook) is indeed able to do this 
> with common.css, but then I quickly discovered that common.css seems to be 
> completely ignored by the Semantic Mediawiki "Chameleon"
> https://www.mediawiki.org/wiki/Skin:Chameleon
> It"s a great skin and I have other reasons for needing to use it. Can anyone 
> give me a few pointers on how to change the css of a skin like that.. it 
> seems to not use CSS at all.
> -Rich
> ___
> MediaWiki-l mailing list
> To unsubscribe, go to:
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] SideBarMenu extension

[Stephan Gambke]

On 23 February 2015 at 17:54, Brenton Horne brentonhorn...@gmail.com wrote:
 4. I then downloaded the zip file for ParamProcessor here
https://codeload.github.com/JeroenDeDauw/ParamProcessor/zip/master,
extracted its contents, copy-pasted it to
|C:\Bitnami\mediawiki-1.24.1-0\php| (where it was in its own
directory ...\ParamProcessor). I then added ||

|require: {|||
|||/Bitnami/mediawiki-1.24.1-0/php/ParamProcessor/param-processor:
~1.0|||
|||}|
to
|C:\Bitnami\mediawiki-1.24.1-0\php\PEAR\AWSSDKforPHP\Composer.json|
as the READEME.md file that came with it said I should and reloaded
the same page on my Wiki to receive the same error.

That's not what it says. There is no need to download or unzip
anything. Just go to your MW base directory (the one with
LocalSettings.php in it) and run
composer require param-processor/param-processor: ~1.0

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] chameleon skin

[Stephan Gambke]

Should be fixed in the development version now. If you want to give it
a try, use

  composer require mediawiki/chameleon-skin:dev-master

from your MW install directory.

Cheers,
Stephan

On 21 November 2014 at 21:28, Legault, Phillip [ITSUS]
plega...@its.jnj.com wrote:
 I'm using the chameleon skin and I see that in the drilldown choose category 
 it is showing bullets for the ul#drilldown-categories.

 I do see that the css is there to remove them.

 Is there any way to fix this?

 Thank you for your help!

 Phil Legault

 ___
 MediaWiki-l mailing list
 To unsubscribe, go to:
 https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Removing links

[Stephan Gambke]

It is hardcoded in SMW.

To remove all footer icons you could add the following to your
LocalSettings.php:

$wgHooks[ 'BeforePageDisplay' ][] = function( $out, $sk) {
   $GLOBALS[ 'wgFooterIcons' ] = array();
};

Should work with any skin.

On 20 November 2014 19:26, chris tharp tharpena...@gmail.com wrote:
 Hi

 This maybe the wrong place to ask this, but does anyone know how to remove
 the link that says Powered by in the case of Semantic Mediawiki?

 I've found the code to remove the Mediawiki Powered by link and the system
 messages to remove the bottom links, but I can't seem to find it for
 Semantic Mediawiki. There's a discussion page on this, but the info is not
 correct.

 All the best
 ___
 MediaWiki-l mailing list
 To unsubscribe, go to:
 https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] chameleon skin

[Stephan Gambke]

The bullets were replaced by :before content resembling bullets.
Probably not such a great idea. I'll think of a fix.

On 21 November 2014 21:28, Legault, Phillip [ITSUS]
plega...@its.jnj.com wrote:
 I'm using the chameleon skin and I see that in the drilldown choose category 
 it is showing bullets for the ul#drilldown-categories.

 I do see that the css is there to remove them.

 Is there any way to fix this?

 Thank you for your help!

 Phil Legault

 ___
 MediaWiki-l mailing list
 To unsubscribe, go to:
 https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Lua: Maintain state between invokes?

[Stephan Gambke]

Hmm, have to keep templates then. Thanks.

On 19 June 2013 17:05, Daniel Friesen dan...@nadir-seen-fire.com wrote:
 On Wed, 19 Jun 2013 07:06:10 -0700, Stephan Gambke s7ep...@gmail.com
 wrote:

 Hi,

 I am struggling with Lua.

 Is there a way to somehow maintain the state of the page building
 between calls to #invoke? A kind of page-wide variable mechanism or
 something like that?

 Problem: I have what is basically a bugtracker where each bug is
 described on a wiki page. For each state change of the bug (new,
 confirmed, fixed, verified, closed) I add a call to a template to the
 page text. The problem is, that the text generated by the template
 depends on both the origin and the target state. Until now I used the
 variables extension to keep track of the current state. Now I want to
 convert to Lua. Apart from the fact that it is clearly not desirable
 to mix the use of the variables extension and Lua, it is also
 impossible: When Scribunto's #invoke is called, parser functions are
 already parsed.

 So, what is the solution?

 Cheers,
 Stephan


 I'm pretty sure that Scribundo is specifically designed to make #invoke
 calls isolated from other calls. Short of trying to find and exploit bugs
 that are unpredictable and will eventually be patched there is no way you're
 going to get state between calls.

 --
 ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


 ___
 MediaWiki-l mailing list
 MediaWiki-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

___
MediaWiki-l mailing list
MediaWiki-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[MediaWiki-l] Lua: Maintain state between invokes?

[Stephan Gambke]

Hi,

I am struggling with Lua.

Is there a way to somehow maintain the state of the page building
between calls to #invoke? A kind of page-wide variable mechanism or
something like that?

Problem: I have what is basically a bugtracker where each bug is
described on a wiki page. For each state change of the bug (new,
confirmed, fixed, verified, closed) I add a call to a template to the
page text. The problem is, that the text generated by the template
depends on both the origin and the target state. Until now I used the
variables extension to keep track of the current state. Now I want to
convert to Lua. Apart from the fact that it is clearly not desirable
to mix the use of the variables extension and Lua, it is also
impossible: When Scribunto's #invoke is called, parser functions are
already parsed.

So, what is the solution?

Cheers,
Stephan

___
MediaWiki-l mailing list
MediaWiki-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Case Study: Skinning Media Wiki

[Stephan Gambke]

Ok, it's probably a bit premature, but I thought while we were all
happily bashing each others skins I might as well contribute a bit.

As Jason, I do (well, did) not have too much experience regarding
skinning, always gave it a wide berth. But since my skin of choice is
not very well maintained any more, I finally created my own. For this I
also used Daniels manual, which is excellent. So, kudos Daniel. Remind
me to get you a beer should we ever meet.

Since I am rather lazy and also have some more plans with this skin, I
utilized Twitter's Bootstrap framework which worked great. It allowed me
to throw it all together in a few evenings last week. No CSS tweaking
needed, thank you very much.

To do this I created two minimal extensions, one for the Bootstrap
framework itself[1], one for a php LESS compiler [2].

Out came a skin with horizontal menus with dropdowns/dropups for the
sidebar (above the article) and toolbar and language links (below).
Alas, I don't have a working wiki to show off, but have a look at the
screenshots at [0].

Next steps:
* Improve the Bootstrap extension to load stuff selectively
* clean up the skin code and refactor stuff into methods
* leverage Bootstrap and the less compiler to allow for changing the
  appearance of the skin; e.g. the colors (Anybody wondered about the
  name of the skin?)

Cheers,
Stephan


[0] https://www.mediawiki.org/wiki/Skin:Chameleon
[1] https://www.mediawiki.org/wiki/Extension:Bootstrap
[2] https://www.mediawiki.org/wiki/Extension:Less

___
MediaWiki-l mailing list
MediaWiki-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] [Wikitech-l] The rest of the SMWCon conference is on YouTube

[Stephan Gambke]

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,
Stephan

___
MediaWiki-l mailing list
MediaWiki-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [MediaWiki-l] Forcing a certain page layout

[Stephan Gambke]

Hi Al,

it depends on how much you want to enforce this.

Semantic Forms will always include the structured data at the top and
the free text at the bottom of the page. So if your preferred spot for
the semantic stuff is at the top, you'll be alright. If you want it to
be anywhere else, it becomes difficult. And of course, if an editor
edits the page contents using the normal edit form (i.e. bypasses the
Semantic Form) they can do whatever they want, including moving the
semantic stuff somewhere else. Then again it is possible to hide the
link to the normal edit page, so it is not as easy to get at the
normal edit form.

Some links:
* A scratchpad, where you can play with SMW, SF etc.:
http://scratchpad.referata.com/
* A mailing list dedicated to SMW and related extensions:
https://lists.sourceforge.net/lists/listinfo/semediawiki-user

There is also a dedicated IRC channel available on freenode: #semantic-mediawiki

Cheers,
Stephan


On 27 November 2012 18:38, Al Johnson alj62...@yahoo.com wrote:
 I'm thinking about using SMW with MW.  I'll use Semantic Forms and the like 
 to make entering the semantic data easier and then let editors enter free 
 text for other miscellaneous sections.  But, the semantic stuff is the most 
 important and I want to make sure the semantic data section is always on a 
 particular location on the page; say, the top.  I don't want an editor to 
 relocate the info box anywhere he wants.  Is this possible?

___
MediaWiki-l mailing list
MediaWiki-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [Mediawiki-l] Hook called on cache miss?

[Stephan Gambke]

Hi,

On 10 November 2011 00:32, Brion Vibber br...@wikimedia.org wrote:
 I'm looking for a hook that is called when the text of an article is
 parsed because of a cache miss.

 What are you trying to accomplish with a hook that's called during (before?
 after?) parsing that comes after a parser cache miss specifically?

S*mantic Forms form definition pages work to a degree similar to
templates, in that they have some explanatory text in noinclude tags
and the actual form definition in includeonly tags. Currently this
form definition is parsed every time a form is requested. I would like
to cache it. As I understood it, I can do that by setting a property
on the form definition page's ParserOutput object. So my idea was,
whenever there is a cache miss on the form definition page I parse the
part in includeonly tags and cache it along with the page. Then,
when a form is actually to be displayed I get the form definition text
from cache if available.


 Keep in mind that the same article may be parsed with different
 configurations (thus separate cache keys) or may not get cached at all. It
 also gets pre-rendered at default settings before we even check the cache
 during saving -- would this count as a cache miss?

I don't think so. All I wanted was an Ok, this is outdated, we have
to reparse, but I guess it is not that easy. :)
Is there somewhere (apart from the code) were I can read up on how
exactly caching works in MW?


 * There seems to be no elegant way to recognize if the text to parse is
 the actual Article content.

 You generally should not make such assumptions as, indeed, many bajillions
 of things may get parsed, plenty of which are not standalone articles or
 pages.

I noticed. :)

Cheers,
Stephan

___
MediaWiki-l mailing list
MediaWiki-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: [Mediawiki-l] Hook called on cache miss?

[Stephan Gambke]

That's what you get when you are too fixed on one solution, I never even
thought of separating caching the page from caching the definition.

Thanks Brion!


Am 10.11.2011 18:13, schrieb Brion Vibber:
 A more typical caching pattern within MediaWiki would look something like
 this:
 
 * devise an appropriate cache key involving the form's id or title, eg
 wfCacheKey( 'formdata', $page-articleId() );
 * at times when you would fetch the form definition data, first pull that
 key from cache
 ** if cache hit, use that data
 ** if cache miss, fall through to existing article fetch  form definition
 parsing
 *** after generating that data, save it to cache
 * when form pages are saved anew, delete the cache entry so it can be
 regenerated with fresh data
 
 You can grab caches from wfGetMainCache() and friends (by default the main
 cache is a null-op, whereas wfGetParserCacheStorage() will to go the
 objectcache table if something like memcache isn't being used, so will
 always actually store stuff).

___
MediaWiki-l mailing list
MediaWiki-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[Mediawiki-l] Hook called on cache miss?

[Stephan Gambke]

Hi,

I'm looking for a hook that is called when the text of an article is
parsed because of a cache miss.

On IRC I was told to use one of the hooks called by Parser::parse, but I
am not sure that's the solution:
* Parse is also called on cached pages, e.g. to render the 'This page
has been accessed xxx times.' message.
* There seems to be no elegant way to recognize if the text to parse is
the actual Article content.

Currently I hook into ParserBeforeTidy, use a static variable to ensure
the method is executed only once and create a Revision object to get at
the article text. The method is always run regardless of whether there
was a cache miss or not.

There should be an easier and more elegant way to do this, right?

Cheers,
Stephan

___
MediaWiki-l mailing list
MediaWiki-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l