Lis ton message de Nganguem Victor avant qu'il ne soit effacé!
Pour lire ton message, suis simplement ce lien:
http://eu1.badoo.com/chatnoirxx/in/p4hxwt052ok/?lang_id=6
D'autres personnes sont aussi présentes:
Oded (Tel Aviv, Israël)
Priya (Udaipur, Inde)
RajaYogi BK (Udaipur, Inde)
Karuna (Udaipur, Inde)
Chika Reginald Onyia (Pnompen', Cambodge)
...Qui d'autre?
http://eu1.badoo.com/chatnoirxx/in/p4hxwt052ok/?lang_id=6
Les liens ne fonctionnent pas dans ce message? Copie les dans la barre d'adresse de ton navigateur.
Tu as reçu cet email suite à un message envoyé par Nganguem Victor de notre système. S'il s'agit d'une erreur, ignore simplement cet email. La requête sera alors effacée du système.
Amuse-toi bien !
L'équipe Badoo
Courrier automatique de Badoo suite à l'envoi d'un message à ton attention sur Badoo. Les réponses ne sont ni stockées, ni traitées. Si tu ne veux plus recevoir de message de Badoo, fais-le nous savoir:
http://eu1.badoo.com/impersonation.phtml?lang_id=6&mail_code=65&email=media…
Hi Valerio!
Thank you for looking into this.
Reviewing these links implies that this requires an extension? So it
cannot be done simply, directly from LocalSettings.php?
Could you provide please a minimal example how to set as
$CUSTOM_VARIABLE = "custom-content";?
Template are generally awesome but won't work here.
The use case here is multiple domain support, an alternative domain name
accessing the same wiki/database, which already works great for me.
What I really want to set is something similar to
{{SERVER}} = //www.example.com
{{SERVERNAME}} = www.example.com
But I only need
{{CUSTOM_APEX_DOMAIN_NAME}} = example.com
The use case in mediawiki markup would then be:
[{{protocoll_handler}}://forums.{{apex_domain_name}} our forums]
(I.e. "relative domain names which support sub domain changes")
This is the multiple domain support snippet which already works for me:
###
if (preg_match("/onion.onion/i", $_SERVER['SERVER_NAME'])) {
$wgServer = 'http://www.onion.onion';
$wgCanonicalServer = 'https://www.example.com';
$wgAllowExternalImagesFrom = array( 'http://127.0.0.1/',
'http://www.onion.onion/' );
$wgRenderHashAppend = "www.onion.onion";
$wgCachePrefix = "www.onion.onion";
$wgFileCacheDirectory = "$IP/cache/www.onion.onion";
$wgLocalisationUpdateDirectory = "$IP/cache/www.onion.onion";
$wgCacheDirectory = "$IP/cache/www.onion.onion";
$MY_FQDN = "http://www.onion.onion";
} else {
$wgServer = '//www.example.com';
$wgCanonicalServer = 'https://www.example.com';
$wgAllowExternalImagesFrom = array( 'http://127.0.0.1/',
'https://www.example.com/' );
$wgRenderHashAppend = "www.example.com";
$wgCachePrefix = "www.example.com";
$wgFileCacheDirectory = "$IP/cache/www.example.com";
$wgLocalisationUpdateDirectory = "$IP/cache/www.example.com";
$wgCacheDirectory = "$IP/cache/www.example.com";
$MY_FQDN = "https://www.example.com";
}
###
If I had the snippet to add custom magic words to LocalSettings.php,
then kinda what I would add there is this:
if (preg_match("/onion.onion/i", $_SERVER['SERVER_NAME'])) {
$CUSTOM_APEX_DOMAIN_NAME = 'onion.onion';
} else {
$CUSTOM_APEX_DOMAIN_NAME = 'example.com';
}
Basically, how would I make $CUSTOM_APEX_DOMAIN_NAME available from
inside the mediawiki?
I've left the lengthy description of my use case out from my original
post for brevity.
Kind regards,
Patrick
Valerio Bozzolan:
> Hi Patrick
> Here some documentation for your specific question:
> https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/ParserF…
> https://www.mediawiki.org/wiki/Manual:Hooks/ParserFirstCallInit
> Having said that, do you really need it? Why not just a new template?
> Create a page [[Template:Something]] to use {{Something}}.
> -boz
> On mer, 2021-12-29 at 10:46 +0000, Patrick Schleizer via MediaWiki-l
> wrote:
>> Could you explain please how to add a custom magic word to mediawiki
>> LocalSettings.php?
>>
>> Example:
>> When writing in the wiki {{CUSTOM_VARIABLE}} it will expand to:
>> custom-content
>>
>> In other words... I want to set in LocalSettings.php
>>
>> $CUSTOM_VARIABLE = "custom-content";
>>
>> and that custom variable should then be available inside the wiki be
>> as
>> {{CUSTOM_VARIABLE}}.
>>
>> If avoidable, writing a mediawiki extension should be avoided.
>>
>> Is this possible?
>>
>> Cheers,
>> Patrick
>> _______________________________________________
>> MediaWiki-l mailing list -- mediawiki-l(a)lists.wikimedia.org
>> To unsubscribe send an email to mediawiki-l-leave(a)lists.wikimedia.org
>> https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/
Could you explain please how to add a custom magic word to mediawiki
LocalSettings.php?
Example:
When writing in the wiki {{CUSTOM_VARIABLE}} it will expand to:
custom-content
In other words... I want to set in LocalSettings.php
$CUSTOM_VARIABLE = "custom-content";
and that custom variable should then be available inside the wiki be as
{{CUSTOM_VARIABLE}}.
If avoidable, writing a mediawiki extension should be avoided.
Is this possible?
Cheers,
Patrick
Hello!
I just updated some wikis to 1.35.5 and also installed the current skins
and extensions that I use.
On .../Special:Version, the version of MediaWiki itself is correctly
shown as "1.35.5", but the versions of the skins and extensions have
remained at the versions before (or even some updates before). For
example: I have installed "Metrolook-REL1_35-7671f0e", but
Special:Version shows
7.0 alpha 2 (74d7661) 18:04, 4. Sep. 2021
which I had installed before. Another identical wiki shows
7.0 alpha 2 (abd1ca1) 14:40, 18 April 2021
I see the same for e.g. PluggableAuth: Installed is
"PluggableAuth-REL1_35-efff551", but I see
5.7 (e5976c0) 03:13, 4. Sep. 2021
5.7 (2a465ae) 00:07, 11 July 2020
respectively.
Are the versions somewhere stored in the database and not updated properly?
Joern
--
Jörn Clausen
BITS - Bielefelder IT-Servicezentrum
https://www.uni-bielefeld.de/bits
Hi all,
On Wednesday we will be issuing a security and maintenance release to all
supported branches of MediaWiki.
The new releases will be:
- 1.35.5
- 1.36.3
- 1.37.1
This release includes fixes for multiple high severity authorization
bypasses in MediaWiki core, it is recommended you patch immediately. A
short LocalSettings.php configuration snippet will also be shared to
disable the vulnerable functionality if you are unable to patch right away.
This snippet should work across all vulnerable MediaWiki versions,
including end-of-life ones.
In addition to that, this will resolve other issues in MediaWiki core and
also includes some fixes previously committed to git, including minor
security and hardening patches along with bug fixes included for
maintenance reasons.
It also fixes 2 issues in MediaWiki tarball bundled extensions.
We will make the fixes available in these respective release branches and
master. Tarballs will be available for the above mentioned point releases
as well.
A summary of some of the security fixes that have gone into non-bundled
MediaWiki extensions will also follow later.
Hello all,
As you may have seen recently, Log4j has a severe zero-day exploit
affecting many projects, including Elasticsearch. For anyone using
CirrusSearch or Semantic MediaWiki’s ElasticStore, here’s what you need to
know:
- If you are using JDK 11 or above, you’re not affected. 😊
- If you are using the latest version of the Elasticsearch 6.x Docker
images, you’re not affected. This is because 6.6 uses JDK 11, 6.7 uses JDK
12, and 6.8 uses JDK 15. 😊
- If you are using JDK 8 or under, you are likely affected. 😭 There are a
few ways to fix this:
-- First, Elasticsearch 6.8.21 is being released to remedy this. Upgrading
to this version should resolve the issues even if you are using JDK 8 or
below.
-- If you are using Elasticsearch 6.5.4, 6.6.x, 6.7.x, or you are otherwise
unable to upgrade to the latest version of Elasticsearch 6.x, I strongly
recommend you try upgrading your JDK version to at least JDK 11 or upgrade
Elasticsearch to 6.8.21 when it comes out.
-- If you can’t upgrade your JDK or Elasticsearch, you can set the JVM
option Dlog4j2.formatMsgNoLookups=true
You may have seen information on the CirrusSearch extension page saying
CirrusSearch 6.5.4 only currently works with Elasticsearch 6.5.4. That is
not correct; CirrusSearch 6.5.4 works just fine with 6.8.20 (for instance,
Project Canasta uses the ES 6.8.20 Docker image) and the extension page has
been updated to reflect that.
For more information from Elastic themselves, please see this:
https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulner…
Thanks,
Jeffrey
Is it possible to use Semantic Drilldown (or another extension) to select
wikipages via categories when each page belongs to multiple categories? For
example, a page belonging both to TECH and MEDICAL categories could be
found by clicking on TECH and then MEDICAL or vice versa. I believe this
approach is called faceted search. I'd like to get this working without
Cargo or semantic markup if possible--just good old-fashion categories.