Project:Support desk

Welcome to the MediaWiki Support desk, where you can ask MediaWiki questions!

(Read this message in a different language)

See also

• Other places to ask for help

Before you post

• Check the basic How does MediaWiki work? guide.
• Check the FAQ and Errors and symptoms .
• If your question is about a specific feature, check the relevant technical manual , end-user help or extension page and consider asking on its talk page .
• For issues about the mediawiki.org website, report to Village Pump instead.
• For trying out wiki editing, use the Sandbox instead.

Post a new question

1. To help us answer your questions, please indicate which versions you are using, as found on your wiki's Special:Version page:
   • MediaWiki version
   • PHP version
   • Database type and version
2. Please include the web address (URL) to your wiki if possible. It's often easier for us to identify the source of the problem if we can see the error directly.
3. To start a new thread, click "Start a new topic".

I tried accessing Toolforge today and I got this warning:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the [] key sent by the remote host is []. Please contact your system administrator. Add correct host key in [] to get rid of this message. [] Host key for login.toolforge.org has changed and you have requested strict checking. Host key verification failed.

I have removed [some information] thinking maybe it shouldn't be public. What does it mean exactly and what should my course of action be? Can someone help me?

It probably means they reinstalled the operating system. The error means that you are talking to a different computer than last time you connected. In theory it could be someone evesdropping on the connection, but in practise it usually just means toolforge was updated.

If your paranoid, check the value against those listed at https://wikitech.wikimedia.org/wiki/Help:SSH_Fingerprints/login.toolforge.org

@Bawolff, thanks a lot for the straightforward answer! What exactly should I be changing so it allows me to login in again?

This: login.toolforge.org,185.15.56.48 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBFnJSjCGW7kli+cdgtmndPAl4xLZNc9uqP9KWlsnVDqr8yQ2RkR5ACbXe6XZ+dS09Wc9ulOmGTOwCImMi9Fho78=

To this: login.toolforge.org,185.15.56.48 ecdsa-sha2-nistp256 xxW0+dRvWgCzYOq7uBKXXo7Xze0FVezt0QikIkpeMKI= ?

That can't be right because I already tried that and I got the same message while still not being allowed to log in.

Generally i just delete the particular line from the config file (on next login it will ask if you want to trust, if you press y it will add an appropriate line back). Usually there are 2 lines you need to remove, one for the domain name and one for the ip address.

It worked and I'm now logged in. I deleted the old file as well.

Last question: In my known hosts, beside Toolforge, I also had this: [gerrit.wikimedia.org]:29418,[208.80.154.137]:29418 ssh-rsa AAAAB3Nza...+oVFf1CgQ==

What exactly is that and would I need to change anything in regard to it or does the Toolforge update not have any connection whatsoever with that?

They are separate. Gerrit is the wikimedia code review tool (which also uses ssh). If you ever used git review (or git push) on a wikimedia code base, that is where that line comes from.

I have. Again, thanks a lot for the fast and straightforward answers. My past experiences with WikiTech stuff have been frustrating and I've usually been redirected in the IRC chat channels. I saw that you were singlehandedly handling all the request here and that's to be appraised. Thank you and have a good day! :)

@Klein Muçi, Remember if you use cloud services, It's highly recommend to subscribe to at least the cloud-announce mailing list, The relevant topic for this announcement was [Cloud-Announce] [IMPORTANT] login.toolforge.org now points to Buster Grid Engine, for your first post.

@P858snake, where do I subscribe to these mailing lists?

@Klein Muçi Create a account on our Mailman install (or login, if you already have one) at https://lists.wikimedia.org/ then if you navigate to the clouds-announce mailing list and choose the subscription option.

Wow, so many possible lists! Is the "Mailman install" a new thing? I didn't have an account for it apparently but I remember doing something more old-school for subscription in the past. I created an account and indeed I had some lists I had subscripted to already. I'm very much fond of this "new way" though. I did subscribe to it. Thank you for assisting me through this!

@Klein Muçi We migrated from Mailman 2.X to 3.X last April/May which brought quite a few improvements.

I am making a book on book creator, and would like to do stop-motion. However, I cannot figure out how to duplicate a page. I tried the drop-down list, but no luck. Google doesn't know either. Can someone help?

Updating from 1.35 to 1.37 on FreeBSD/PostgreSQL 13.5, PHP 8.0 the upgrade script, both manual and web, are barfing with

...index user_properties_pkey already set on user_properties table.
Changing column type of 'log_search.ls_value' from 'varchar' to 'VARCHAR(255)'
...column 'content.content_id' is already of type 'BIGINT'
...column 'l10n_cache.lc_value' is already of type 'TEXT'
Changing column type of 'l10n_cache.lc_key' from 'varchar' to 'VARCHAR(255)'
...index l10n_cache_pkey already set on l10n_cache table.
Adding index module_deps_pkey to table module_deps ...Wikimedia\Rdbms\DBQueryError from line 1809 of /usr/local/www/mediawiki/includes/libs/rdbms/database/Database.php: Error 42704: ERROR:  index "md_module_skin" does not exist

Function: Wikimedia\Rdbms\Database::sourceFile( /usr/local/www/mediawiki/maintenance/postgres/archives/patch-module_deps-pk.sql )
Query: DROP INDEX md_module_skin


#0 /usr/local/www/mediawiki/includes/libs/rdbms/database/Database.php(1793): Wikimedia\Rdbms\Database->getQueryException('ERROR:  index "...', '42704', 'DROP INDEX md_m...', 'Wikimedia\\Rdbms...')
#1 /usr/local/www/mediawiki/includes/libs/rdbms/database/Database.php(1768): Wikimedia\Rdbms\Database->getQueryExceptionAndLog('ERROR:  index "...', '42704', 'DROP INDEX md_m...', 'Wikimedia\\Rdbms...')
#2 /usr/local/www/mediawiki/includes/libs/rdbms/database/Database.php(1327): Wikimedia\Rdbms\Database->reportQueryError('ERROR:  index "...', '42704', 'DROP INDEX md_m...', 'Wikimedia\\Rdbms...', false)
#3 /usr/local/www/mediawiki/includes/libs/rdbms/database/Database.php(5407): Wikimedia\Rdbms\Database->query('DROP INDEX md_m...', 'Wikimedia\\Rdbms...')
#4 /usr/local/www/mediawiki/includes/libs/rdbms/database/Database.php(5340): Wikimedia\Rdbms\Database->sourceStream(Resource id #1333, NULL, NULL, 'Wikimedia\\Rdbms...', NULL)
#5 /usr/local/www/mediawiki/includes/libs/rdbms/database/DBConnRef.php(68): Wikimedia\Rdbms\Database->sourceFile('/usr/local/www/...')
#6 /usr/local/www/mediawiki/includes/libs/rdbms/database/MaintainableDBConnRef.php(35): Wikimedia\Rdbms\DBConnRef->__call('sourceFile', Array)
#7 /usr/local/www/mediawiki/includes/installer/DatabaseUpdater.php(704): Wikimedia\Rdbms\MaintainableDBConnRef->sourceFile('/usr/local/www/...')
#8 /usr/local/www/mediawiki/includes/installer/DatabaseUpdater.php(805): DatabaseUpdater->applyPatch('/usr/local/www/...', false, 'Adding index mo...')
#9 /usr/local/www/mediawiki/includes/installer/DatabaseUpdater.php(533): DatabaseUpdater->addIndex('module_deps', 'module_deps_pke...', 'patch-module_de...')
#10 /usr/local/www/mediawiki/includes/installer/DatabaseUpdater.php(497): DatabaseUpdater->runUpdates(Array, false)
#11 /usr/local/www/mediawiki/maintenance/update.php(193): DatabaseUpdater->doUpdates(Array)
#12 /usr/local/www/mediawiki/maintenance/doMaintenance.php(108): UpdateMediaWiki->execute()
#13 /usr/local/www/mediawiki/maintenance/update.php(264): require_once('/usr/local/www/...')
#14 {main}

I find the error string in https://github.com/saltstack-formulas/mediawiki-formula/blob/master/mediawiki/mediawiki.sql which is an innodb call, and maybe isn't being called correctly in a postgreSQL install.

It appears the code in question triggering this was added in this commit to patch-module_deps-pk.sql https://github.com/wikimedia/mediawiki/blame/686abd50bf96cde41518db0fe17c156185acfca4/maintenance/postgres/archives/patch-module_deps-pk.sql

DROP INDEX md_module_skin;
ALTER TABLE module_deps
 ADD PRIMARY KEY (md_module, md_skin);

@Ladsgroup - any insight? Would a conditional check for the index exists before dropping it avoid the update fail? Can this drop index just be commented out as a quick fix?

For now, I'd just modify that file to remove that DROP INDEX statement, and it should be possible to complete the update process. Then please file a ticket in Phabricator for the problem.

@DGessel That's just a delete of this INDEX https://github.com/wikimedia/mediawiki/commit/5e69ad1aade1977d60e60de2f00e150223b50f60#diff-0cc829d85cfcaeec780e78ed97012034779b0ae049ab82742de25fe58abb927cL686

Yes, deleting the DROP INDEX md_module_skin; quickly got past that error, but got stuck a little later at

Creating index 'rev_page_timestamp' on table 'revision' (rev_page,rev_timestamp)
Changing 'user.user_touched' to not allow NULLs
Changing 'user.user_token' to not allow NULLs
Wikimedia\Rdbms\DBQueryError from line 1809 of /usr/local/www/mediawiki/includes/libs/rdbms/database/Database.php: Error 23502: ERROR:  column "user_token" of relation "user" contains null values

Function: PostgresUpdater::changeNullableField
Query: ALTER TABLE "user" ALTER user_token SET NOT NULL

#0 /usr/local/www/mediawiki/includes/libs/rdbms/database/Database.php(1793): Wikimedia\Rdbms\Database->getQueryException('ERROR:  column ...', '23502', 'ALTER TABLE "us...', 'PostgresUpdater...')
#1 /usr/local/www/mediawiki/includes/libs/rdbms/database/Database.php(1768): Wikimedia\Rdbms\Database->getQueryExceptionAndLog('ERROR:  column ...', '23502', 'ALTER TABLE "us...', 'PostgresUpdater...')
#2 /usr/local/www/mediawiki/includes/libs/rdbms/database/Database.php(1327): Wikimedia\Rdbms\Database->reportQueryError('ERROR:  column ...', '23502', 'ALTER TABLE "us...', 'PostgresUpdater...', false)
#3 /usr/local/www/mediawiki/includes/libs/rdbms/database/DBConnRef.php(68): Wikimedia\Rdbms\Database->query('ALTER TABLE "us...', 'PostgresUpdater...', 0)
#4 /usr/local/www/mediawiki/includes/libs/rdbms/database/DBConnRef.php(297): Wikimedia\Rdbms\DBConnRef->__call('query', Array)
#5 /usr/local/www/mediawiki/includes/installer/PostgresUpdater.php(976): Wikimedia\Rdbms\DBConnRef->query('ALTER TABLE "us...', 'PostgresUpdater...')
#6 /usr/local/www/mediawiki/includes/installer/DatabaseUpdater.php(533): PostgresUpdater->changeNullableField('"user"', 'user_token', 'NOT NULL', true)
#7 /usr/local/www/mediawiki/includes/installer/DatabaseUpdater.php(497): DatabaseUpdater->runUpdates(Array, false)
#8 /usr/local/www/mediawiki/maintenance/update.php(193): DatabaseUpdater->doUpdates(Array)
#9 /usr/local/www/mediawiki/maintenance/doMaintenance.php(108): UpdateMediaWiki->execute()
#10 /usr/local/www/mediawiki/maintenance/update.php(264): require_once('/usr/local/www/...')
#11 {main}

This appears to come from the // 1.37 block of PostgresUpdator.php, line 615. I'm guessing I can manually remove null values from the column "user_token" of of the relation "user" - no?

Yes, deleting the default empty user with the null values using phpPgAdmin (after patching it for PHP 8.0) did the trick. Install complete. A few bugs with some of the plugins to deal with.

Error 1091: Can't DROP INDEX `log_user_text_type_time`; check that it exists (localhost)

Function: Wikimedia\Rdbms\Database::sourceFile( C:\inetpub\wwwroot\MediaWiki/maintenance/archives/patch-drop-logging-user-fields.sql )

"Post a new question" in the sidebar.

There are some sites that I've come across that have the (customcssprotected) and (customjsprotected) permissions. However these permissions don't have their own permission summaries. From what I've researched, they are similar to the (editusercss) and (edituserjs) permissions. But what's the difference?

Those are not permissions, those are the errors returned when you do NOT have the permissions. See also: https://gerrit.wikimedia.org/g/mediawiki/core/+/1ecbfab0c81a97cdfd87b800b1b9fe9236649ac9/includes/Permissions/PermissionManager.php#1331

There are a few sites that use them as actual permissions. But the permissions don't have descriptions. Here's one example.

In that case I would ask fandom.

MediaWiki 1.36.1 with long URLs.

I want to tell search engines not to crawl anything which isn't part of the main namespace and Category: namespace.

How to do that?

I currently use the following code written by @Bawolff but I am not sure why is the allow: are there because we already blocked anything else by the two disallow: didn't we?

disallow: /index.php?
disallow: /index.php/*:
allow: /index.php/Category:
allow: /index.php/קטגוריה:

In Hebrew קטגוריה means category.

Allow overrides disallow

No, "allow" doesn't exist in robots.txt syntax

http://www.robotstxt.org/robotstxt.html

@Ciencia Al Poder I assume it existed in the past and was scrapped. Am I wrong?

Yes, you're wrong. Maybe some search engines support it, but that's not a standard thing

@Ciencia Al Poder

Thanks

I guess I am willing to sacrifice crawling of category pages for sole crawling of articles, as articles are the main "meat" which brings readers to my website and if I need to sacrifice a million other webpages (including category pages) just that articles would be the only thing crawled, I guess I should painfully do that.

I'll keep using the "non standard" exception suggested by Bawolff though, just in case.

Both google and bing support allow. I'm not sure what other search engines exist anymore.

Two MediaWiki developers here say contradicting things :)

By whom's say should I go? :)

Read the documentation of each crawler, because robots.txt is not MediaWiki related

@Ciencia Al Poder

I didn't think it was MediaWiki related...

From my check, it is true that in the page you linked to, the term allow: isn't mentioned, but it might effect as legacy or would suddenly be added (or returned) so I keep it. In case I'm impressed it's a problem to keep it, I'll remove it.

I agree that getting updated about changes in robots.txt language is important.

Not one have I bumped in webmasters "arguing" about if allow: effects or not. Strange.

We're not really disagreeing with each other.

Allow is not in the official standard. It is however supported by most of the prominent implementations. Whether or not that fits with your needs is something you have to determine yourself.

@Bawolff But why is it needed here if one didn't do a general

disallow: /index.php

?

Because, /index.php/*: would normally match /index.php/Category: as * means match anything.

A wildcard and an exception to the wildcard.

Some webmaster in WebMasters StackExchange once told me that there is no regex in robots.txt, this may have biased me from finding the connection.

This is glob syntax not regex, which is slightly different than regex for how it works and what is supported

We are MediaWiki, not VPP. This is off-topic here.

Hi Team,

I am trying for building vpp in a vm.

Using ubuntu18.04 machine and cloned the vpp code from the below github page

"https://github.com/FDio/vpp/tree/stable/2106"

But after trying sudo make install-dep seeing the below errors

"E: Unable to locate package enchant-2

E: Unable to locate package libffi7

Makefile:312: recipe for target 'install-dep' failed

make: *** [install-dep] Error 100"

On trying with ./build-root/vagrant/build.sh getting the below errors:

"@@@@ Configuring vpp in /home/ubuntu/vpp/build-root/build-vpp-native/vpp @@@@

-- The C compiler identification is GNU 9.4.0

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

-- Check for working C compiler: /usr/bin/gcc - skipped

-- Detecting C compile features

-- Detecting C compile features - done

-- Performing Test compiler_flag_march_haswell

-- Performing Test compiler_flag_march_haswell - Success

-- Performing Test compiler_flag_mtune_haswell

-- Performing Test compiler_flag_mtune_haswell - Success

-- Performing Test compiler_flag_march_tremont

-- Performing Test compiler_flag_march_tremont - Success

-- Performing Test compiler_flag_mtune_tremont

-- Performing Test compiler_flag_mtune_tremont - Success

-- Performing Test compiler_flag_march_skylake_avx512

-- Performing Test compiler_flag_march_skylake_avx512 - Success

-- Performing Test compiler_flag_mtune_skylake_avx512

-- Performing Test compiler_flag_mtune_skylake_avx512 - Success

-- Performing Test compiler_flag_mprefer_vector_width_256

-- Performing Test compiler_flag_mprefer_vector_width_256 - Success

-- Performing Test compiler_flag_march_icelake_client

-- Performing Test compiler_flag_march_icelake_client - Success

-- Performing Test compiler_flag_mtune_icelake_client

-- Performing Test compiler_flag_mtune_icelake_client - Success

-- Performing Test compiler_flag_mprefer_vector_width_512

-- Performing Test compiler_flag_mprefer_vector_width_512 - Success

-- Looking for ccache

-- Looking for ccache - not found

fatal: unsafe repository ('/home/ubuntu/vpp' is owned by someone else)

To add an exception for this directory, call:

git config --global --add safe.directory /home/ubuntu/vpp

CMake Error at CMakeLists.txt:40 (string):

  string sub-command REPLACE requires at least four arguments.

-- Performing Test compiler_flag_no_address_of_packed_member

-- Performing Test compiler_flag_no_address_of_packed_member - Success

-- Performing Test compiler_flag_no_stringop_overflow

-- Performing Test compiler_flag_no_stringop_overflow - Success

-- Looking for pthread.h

-- Looking for pthread.h - found

-- Performing Test CMAKE_HAVE_LIBC_PTHREAD

-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed

-- Check if compiler accepts -pthread

-- Check if compiler accepts -pthread - yes

-- Found Threads: TRUE  

-- Performing Test HAVE_FCNTL64

-- Performing Test HAVE_FCNTL64 - Failed

-- Found OpenSSL: /usr/lib/x86_64-linux-gnu/libcrypto.so (found version "1.1.1")  

-- The ASM compiler identification is GNU

-- Found assembler: /usr/bin/gcc

-- Looking for libuuid

-- Found uuid in /usr/include

-- subunit library not found - vapi tests disabled

-- Found Python3: /usr/bin/python3.6 (found version "3.6.9") found components: Interpreter

-- libbpf headers not found - af_xdp plugin disabled

-- Intel IPSecMB found: /home/ubuntu/vpp/build-root/install-vpp-native/external/include

-- dpdk plugin needs libdpdk.a library - found at /home/ubuntu/vpp/build-root/install-vpp-native/external/lib/libdpdk.a

-- Found DPDK 22.3.0 in /home/ubuntu/vpp/build-root/install-vpp-native/external/include

-- -- numa library not found - dpdk plugin disabled

-- -- libnl3 headers not found - linux-cp plugin disabled

-- Found quicly 0.1.3-vpp in /home/ubuntu/vpp/build-root/install-vpp-native/external/include

-- rdma plugin needs libibverbs.a library - found at /home/ubuntu/vpp/build-root/install-vpp-native/external/lib/libibverbs.a

-- rdma plugin needs librdma_util.a library - found at /home/ubuntu/vpp/build-root/install-vpp-native/external/lib/librdma_util.a

-- rdma plugin needs libmlx5.a library - found at /home/ubuntu/vpp/build-root/install-vpp-native/external/lib/libmlx5.a

-- Performing Test IBVERBS_COMPILES_CHECK

-- Performing Test IBVERBS_COMPILES_CHECK - Success

-- -- libdaq headers not found - snort3 DAQ disabled

-- -- libsrtp2.a library not found - srtp plugin disabled

-- -- mbedtls headers not found - tlsmbedtls plugin disabled

-- Looking for SSL_set_async_callback

-- Looking for SSL_set_async_callback - not found

-- Found picotls in /home/ubuntu/vpp/build-root/install-vpp-native/external/include and /home/ubuntu/vpp/build-root/install-vpp-native/external/lib/libpicotls-core.a

-- Configuration:

VPP version         :

VPP library version : NOTFOUND

GIT toplevel dir    :

Build type          : release

C compiler          : /usr/bin/gcc (GNU 9.4.0)

C flags             :

Linker flags (apps) :

Linker flags (libs) :

Host processor      : x86_64

Target processor    : x86_64

Prefix path         : /opt/vpp/external/x86_64 /home/ubuntu/vpp/build-root/install-vpp-native/external

Install prefix      : /home/ubuntu/vpp/build-root/install-vpp-native/vpp

Library dir         : lib/x86_64-linux-gnu

Multiarch variants  : hsw skx icl

-- Configuring incomplete, errors occurred!

See also "/home/ubuntu/vpp/build-root/build-vpp-native/vpp/CMakeFiles/CMakeOutput.log".

See also "/home/ubuntu/vpp/build-root/build-vpp-native/vpp/CMakeFiles/CMakeError.log".

Makefile:644: recipe for target 'vpp-configure' failed

make[1]: *** [vpp-configure] Error 1

make[1]: Leaving directory '/home/ubuntu/vpp/build-root'

Makefile:592: recipe for target 'pkg-deb' failed

make: *** [pkg-deb] Error 2

ubuntu@upf-vpp:~/vpp$"

Can anyone help me in solving this issue?

Thanks and Regards,

Sindhu.

That looks unrelated to MediaWiki

I've just set up a new wiki and imported exactly one Wikipedia template/module combo (https://en.wikipedia.org/wiki/Template:Interlinear, using Scribunto, along with the necessary ), and I'm getting intermittent 'internal server error' messages on preview / save:

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator at [email protected] to inform them of the time this error occurred, and the actions you performed just before this error.

More information about this error may be available in the server error log.

This error seems to be related to page content, in that if I delete most of the content of a page and then try to preview again, it'll work; but doing a/b testing with removing various bits of content gives no sensible trigger content - the last time I tried it, the error seemed to be triggered by a simple line of unformatted prose. A few minutes later exactly the same page content worked fine, and I saved it, at which point I ended up in a situation where trying to preview the unchanged page text triggered the error message! I set up a log file dump, but the log file is massive and I don't know where to look in it for anything related to my error.

Does anyone have any tips as to where to go to debug this, or a better means to find the problem than just adding a log file dump line to LocalSettings.php?

(along with the necessary extra TemplateStyles extension*)

What does your apache log file say?

> I set up a log file dump, but the log file is massive and I don't know where to look in it for anything related to my error.

I assume you mean mediawiki debug log file? For this type of error,that's probably not useful. I would reccomend looking at apache log first (as the error message is an apache error), and php log file second.

Where can I find/make the Apache log? I don't see anything like that in my current directory, and a quick glance at the MediaWiki page on debugging doesn't show anything useful.

Alright, after some searching, I found the log file; it seems like some of my page content is matching ModSecurity patterns and throwing false-positive security warnings?

[Sun May 01 15:48:19.189908 2022] [:error] [pid 211720:tid 3635522836224] [client 67.198.30.42:13934] [client 67.198.30.42] ModSecurity: Warning. Pattern match "\\\\b(?:if(?:/i)?(?: not)?(?: exist\\\\b| defined\\\\b| errorlevel\\\\b| cmdextversion\\\\b|(?: |\\\\().*(?:\\\\bgeq\\\\b|\\\\bequ\\\\b|\\\\bneq\\\\b|\\\\bleq\\\\b|\\\\bgtr\\\\b|\\\\blss\\\\b|==))|for(?:/[dflr].*)? %+[^ ]+ in\\\\(.*\\\\)\\\\s?do)" at ARGS:wpTextbox1. [file "/dh/apache2/template/etc/mod_sec3_CRS/REQUEST-932-APPLICATION-ATTACK-RCE.conf"] [line "412"] [id "932140"] [msg "Remote Command Execution: Windows FOR/IF Command Found"] [data "Matched Data: if theyre identical) or the insertion of an epenthetic vowel between them(if theyre different). however certain pairs of different consonants merge into a geminate when they come together. in the table below these otherwise unexpected mergers are given in bold.(expected geminates are non-bold and epenthetically separated pairs are indicated by --.) {| class=wikitable ! second phoneme \\xe2\\x86\\x92 !! rowspan=2|t !! rowspan=2|l !! rowspan=2|n !! rowspan=2|k |- ! first phoneme \\xe2\\x86\\x93 |- ..."] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.2"] [tag "application-multi"] [t [hostname (deleted to let me post this)] [uri "/mirja-wiki/index.php"] [unique_id "Ym8OMwVs6zcJi7b7GJ57XgAAAAs"], referer: (deleted to let me post this)/index.php?title=Phonology&action=edit&section=1

What in the world am I supposed to do to make this not happen?

Ideally disable mod_security in your apache config. It causes all sorts of problems like this for very questionable benefits. I think in this case it doesn't like you using the word "if" followed by some other words.

I'll go ahead and do that, but I'm definitely curious as to what the downsides of doing that might be! I'm not super well-informed about security things, so if I'm intentionally disabling a security feature it'd be nice to know what that opens me to.

Mod_security is a WAF, it tries to block things that look "evil".

Unfortunately its not a very good one. Most of its rules have a lot of false positives. Additionally, most of them aren't broad enough to prevent someone actually evil from doing evil things.

Category:X indicates an explicit namespace.

Is there any plan to make the main namespace also explicit?

As with Main:Y?

The "problem to solve" here is that for me and maybe for some others it will just be more convenient, especially when working with robots.txt

For indication Topic:Wupz927brhu1oeo7

No, it's not possible.

I don't see why it would be more convenient for robots.txt if you want to prevent crawlers from indexing other namespaces, since in robots.txt, disallow takes precedence over allow, which makes no difference when the main namespace is prefixed or not, as you'll have to explicitly add disallow to all other namespaces.

@Ciencia Al Poder

disallow: /index.php?
disallow: /index.php/*: # Block all namespaces with exceptions possible in advance
allow: /index.php/Main: # Exception for Main:
allow: /index.php/ראשי:  # Exception for Main:
allow: /index.php/Category: # Exception for Category:
allow: /index.php/קטגוריה: # Exception for Category:

Would have been more clear to me than:

disallow: /index.php?
disallow: /index.php/*: # Block all namespaces with exceptions possible in advance
allow: /index.php/Category: # Exception for Category:
allow: /index.php/קטגוריה: # Exception for Category:

Of course that's just me.

The allow: rule is not standard, robots will ignore it

Google supports allow https://developers.google.com/search/docs/advanced/robots/robots_txt . Its not in the original robots.txt standard but most crawlers support a superset of features.

I successfully installed Synology's version (1.35) of MediaWiki on my NAS but when I try to log in I get a cryptic message (in a pink square) saying there were problems... No hints as to what could be the reason.

Does this possibly ring a bell for anyone?

Thanks in advance,

//Ola

Sorry (new to this...). Versions of software used follow below:

MediaWiki: 1.35.3

PHP: 7.3.24 (fpm-fcgi)

MariaDB: 10.3.29-MariaDB

ICU: 56.1

Lua: 5.1.5

What is the exact text of the message. Also please set $wgShowExceptionDetails=true; in LocalSettings.php to enable detailed error messages.