Has the parser just been changed with regards to tildes (~~~~) inside
HTML comments? It appears they used to be ignored, and are now
suddenly being replaced en masse the next time someone edits the page
(and can't be easily reverted - it just changes the sig to the
reverter's instead). See
http://en.wikipedia.org/wiki/Wikipedia:Articles_for_creation/2006-06-02-ear…
for an example.
I distinctly remember there was a way to add a title to a special page
simply by entering in a URL, then adding the title to the wiki edit
field, and then saving. The new "writing a new special page" how-to is
very confusing - and it wants me to write PHP to get the title to show
up. There was an easier way...
I can't find this how-to anywhere- though I'm sure it used to exist. FX
can you walk me through how you've added a wiki page title to a special
page?
Thanks!
-----Original Message-----
From: mediawiki-l-bounces(a)Wikimedia.org
[mailto:mediawiki-l-bounces@Wikimedia.org] On Behalf Of Rick DeNatale
Sent: Thursday, May 19, 2005 2:33 PM
To: MediaWiki announcements and site admin list
Subject: Re: [Mediawiki-l] Re: How to create a new Special page
On 5/13/05, FxParlant <f-x.p(a)laposte.net> wrote:
> Hello;
> There is a paragraph on how to create a special page in the FAQ
>
>
>
http://meta.wikimedia.org/wiki/Meta:FAQ#How_do_I_add_my_own_dynamic_cont
ent_to_MediaWiki.3F
>
> It's not so difficult. At the end,it says you have to create a simple
> page and write the name of your special page in it. If you forget this
> the title of your special page will have < and > around. I
haven't
> got a clue why creating a page with the name in it solves this, but it
works
That page seems to have changed, it now just has a pointer to an
article about writing an extension which really doesn't seem to build
a special page.
I just figured out how to build a new special page which is like the
Uncategorized pages page, but looks at the Image namespace. I wrote it
up at http://meta.wikimedia.org/wiki/Writing_a_new_special_page
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)Wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
I'm currently trying to adapt several gadgets that are meant for wikis using the Monobook/Vector skins to the Monaco skin, and so far, I've managed to successfully port over the UTC Clock gadget and Sandbox page gadget to Monaco, but aside from those I've been having trouble since, frankly, my knowledge of Javascript/JQuery is slim and I'm not familiar with all the variables used in writing user scripts. I've fairly decent with CSS style sheets, but I still need help with Javascript, so does anyone know of some good resources I could look into, preferably tailored for writing scripts on MediaWiki?
Also, if anyone wants to see what I have done so far (and have released publicly), the wiki I have been testing my live gadget/user script code on is here:
https://mediawikitesters.orain.org/wiki/Main_Page
Hi.
I am an operator of a small wiki. The log of the wiki is not preserved currently.
The wiki is running on a container which is on a Hashicorp Nomad node. You can assume it as just a docker container.
For a monetary reason, I want to use a free plan of a logging stack cloud service, for example Grafana Loki or OpenObserve.
I set up the mediawiki used monolog so that logs flowed to stdout, and let Vector[1] agent on a machine collected it and sent to the OpenObserve cloud. I wanted logs are not stored in the storage, because I did not want logrotate.d.
But for some reason, storage became closely full, I've disabled the whole logging system. I've not inspected it.
Before re-enable the logging system or inspect it, I hope to know how people deploy the log system. If you have some experience, please reply to this or review my approach.
Regards.
1: https://vector.dev/
Hello,
For many years, some classes in MediaWiki implemented the IDBAccessObject
interface (which only provides several public constants) and then would
call them indirectly (e.g. self::READ_NORMAL). Since these constants were
public, other parts of MediaWiki started to call them through the
implementing class as well (e.g. calling User::READ_LATEST).
This is inconsistent with the access pattern of other constants in
MediaWiki. it's also confusing (e.g. it's unclear to a newcomer why
UserFactory is implementing IDBAccessObject) and it's prone to clashes
(e.g. BagOStuff class has a clashing constant).
Since it's not possible to trigger a deprecation warning in such cases, It
can't follow the usual stable interface policy path [1] and here is the
email to wikitech-l as required by the policy.
In three weeks we will remove indirect access to these constants by
removing IDBAccessObject from implementation. This will take effect from
1.42 release.
Classes that won't have those constants anymore are including but not
limited to:
* User
* WikiPage (and its subclasses)
* File (and its subclasses)
* Title
* ActorStore
* RevisionStore
* UserOptionsManager
* And more.
To find such cases in extensions you maintain, you can search for
"(?<!IDBAccessObject)::READ_" (regex) and check if the constant being used
is an indirect call to IDBAccessObject. Be careful that there might be some
false positives such as custom defined constants, constants referring to
BagOStuff ones and similar cases like that.
We have already removed all cases in core and extensions deployed to
Wikimedia production.
You can follow the work and see examples of how the migration is done in
extensions (for example gerrit:993112
<https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Echo/+/993112>) in
T354194 <https://phabricator.wikimedia.org/T354194>.
[1] From the policy
<https://www.mediawiki.org/wiki/Stable_interface_policy#Hard_deprecation>:
"If it is not reasonably possible for the deprecated code to emit
deprecation warnings, hard deprecation can be applied by announcing the
removal on wikitech-l in a timely manner."
Thank you and sorry for the inconvenience,
--
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation <https://wikimediafoundation.org/>
Hello everyone!
I need some advice... I am currently stuck on MediaWiki 1.39.2 and can't
upgrade to newer versions within this LTS release.
I am using PluggableAuth and SimpleSAMLphp to authenticate users to our
wikis. Starting with MW 1.39.3, these extensions were updated to newer
versions (7.0.0) that don't work any more, at least with PostgreSQL as
database (see https://phabricator.wikimedia.org/T348543). I am still
using MW 1.39.2 with versions 6.2 of PluggableAuth and 5.0.1 of
SimpleSAMLphp.
I would like to combine MW 1.39.6 with the older versions of the
extensions, but here
https://extdist.wmflabs.org/dist/extensions/
only the newer ones are available.
I have tried to use composer (with which I have zero knowledge and IMHO
the documentation is ... challenging), and I was able to install
MediaWiki itself and PluggableAuth via composer, but not SimpleSAMLphp.
This extensions seems to be completely unknown to composer.
Switching from PostgreSQL to MySQL is a last resort. The migration does
not seem to be straight forward at all, and it is even unclear if it
would solve my problem in the first place.
Any ideas how to move forward are welcome!
Maybe what I really would like to ask for is: Don't make major updates
to (essential) extensions within an LTS release of MediaWiki, please
coordinate them with major updates of MediaWiki core.
Cheers,
Joern
--
Jörn Clausen
https://www.uni-bielefeld.de/bits