Hiding special-page links in Minerva.js

On my Miraheze wiki, the Minerva.js settings currently contain this code:

mw.util.addPortletLink('p-navigation', '/wiki/Special:WhatLinksHere/' + mw.config.get( 'wgPageName' ), 'What links here', 'nav-wlh');

However, it should be quickly noted that "What links here" is invalid for pages in the Special namespace themselves; to that end, I'd like to know exactly what wraparound to use for cancelling it out if special pages are visited. Once I receive a tip (from @Bawolff or otherwise), the same procedure will apply for overviews of related changes.

Still, with Good Friday and Easter weekend close at hand, this might take a little while. --Slgrandson (talk) 01:56, 18 April 2025 (UTC)

@Slgrandson I havent tested, but generally an ISO timestamp will likely work yyyy-mm-dd hh:mm:ss —TheDJ (Not WMF) (talk • contribs) 08:16, 21 April 2025 (UTC)

@TheDJ: If so, which part of the calls is the timestamp appended to? --Slgrandson (talk) 20:58, 21 April 2025 (UTC)

Leaving this message up in case anyone else has a better solution. --Slgrandson (talk) 07:43, 5 May 2025 (UTC)

Giving this appeal another try... --Slgrandson (talk) 02:31, 19 May 2025 (UTC)

Restrict access to certain types of resource-intensive requests

Hi everyone. I don't generally mind even malicious bots scanning my wiki, I rather accept a few overzealous ones rather than over-block IP adresses etc. However, I see spikes of bot traffic that call very very odd and specific URL parameter requests, and those appear to be calling version diffs, certain timespans of related changes etc, in short, requests that (even for human users) often take more than a second or two, and are more resource intensive database calls than just accessing regular sites or more common requests (that are served via several layers of caching). Is there a way to restrict use of such specific requests to logged in users only? I see absolutely no value in having bots crawl these things.

Here are some example requests (seeing hundreds per minute - this is copy and paste not all of this may be malignant):

(as you can see, some things keep re-appearing such as limits, recentchangeslinked, "from" and "days" etc. Honestly, knowing the very limited number of my editors and my wiki, these are not humans accessing these sites. And that's just a snapshot. Help is much appreciated. These do not pop up in the firewall or security software of my server so they must be fairly "regular" bots, but they just get a bit too active...

Rebastion2 (talk) 17:23, 13 May 2025 (UTC)

trying extension:lockdown with

$wgActionLockdown['history'] = ['user'];

$wgSpecialPageLockdown['Whatlinkshere'] = [ 'user' ];

$wgSpecialPageLockdown['Recentchangeslinked'] = [ 'user' ];

see if that does anything... but the way these URLs are directly called... not sure if I am messing around a step too deep Rebastion2 (talk) 17:53, 13 May 2025 (UTC)

OK I found Externsion:Lockdown and Externsion:DisableSpedialPages to theoretically lock these down, but the way they are called (via url paramters, not directly) I think makes these moot, plus, of course it doesnt stop these before php kicks in, so maybe the only thing that will really help me is buy Cloudflare? Rebastion2 (talk) 20:42, 14 May 2025 (UTC)

testing as an anonymous user, the lockdown works even for the URL parameters the bots use, but alas, the sheer amount of bot requests just does it.... too bad Rebastion2 (talk) 20:55, 14 May 2025 (UTC)

School-wide database for Google Drive users?

Hi - thank you for giving me your time. I've browsed the guides but don't have the answer . We have a small non-profit school that uses Google drive and Gmail for all of our business. We'd like to incorporate a private wiki so that we can have/share/look up resources by anyone here, present and future. Is there a way to do this with this platform? Can we host a version in Google Drive somehow, accessible by anyone with our @davincisv.org emails? Or am I barking up the wrong tree with WikiMedia? 2603:3024:151B:9200:B019:92C4:2597:8F80 18:12, 14 May 2025 (UTC)

No, that is not really how MediaWiki works. It sounds like you are looking for something like sharepoint or similar solutions. I advise to get some consultation from a professional if you want to run software in a professional setting. —TheDJ (Not WMF) (talk • contribs) 09:34, 17 May 2025 (UTC)

Mediawiki upgrade path

Hello! I am new to media wiki and I am looking for some assistance in identifying the proper upgrade path for our companies implementation of MW. They are running a very old version (1.17.0) on a Centos 6.10 VM with Apache 2.2.15 and PHP 5.3.3. I need to migrate the implementation to a VM running Ubuntu 22.04 and would really appreciate some guidance on an upgrade path. Please let me know if you need any additional information. I apologize if this information has already been identified on this site, I was unable to locate it. Thanks in advance! Sleepinfire (talk) 12:53, 15 May 2025 (UTC)

See Manual:Upgrading#Frequently_asked_questions. Basically you have to upgrade to 1.35, then to 1.39, and lastly to 1.43. Tactica (talk) 17:44, 15 May 2025 (UTC)

@Sleepinfire The biggest advise, lots of backups and go step by step when updating various components. When extensions give you trouble during upgrade, disable them, update the core, then turn the extesion back on and run the same upgrade again. Some old extensions might no longer be supported and will not be able to be upgraded, you might have to find alternatives for them or sacrifice the functionality. —TheDJ (Not WMF) (talk • contribs) 09:39, 17 May 2025 (UTC)

How can I

Make a wiki JadenGotLost (talk) 22:59, 15 May 2025 (UTC)

See Hosting services for details and options. With luck, you can get one through Miraheze's RequestWiki service (as long as you have an e-mail address attached). --Slgrandson (talk) 23:15, 15 May 2025 (UTC)

Keeping Vector 2010--but ditching Vector 2022--on a third-party wiki

If there's really a means of doing so--tried hiding the 2022 option on my site's Special:Preferences as founding bureaucrat, but that interface is still appearing in "useskin" mode--let me know in advance. Pinging @Bawolff/@TheDJ/@Pppery/@Universal Omega/@MacFan4000/@Reception123 just in case. (Based on a recent Miraheze help-desk discussion.) --Slgrandson (talk) 23:34, 15 May 2025 (UTC)

The translation tool and its documentation is very confusing ..

I find the hints and messages that appear in and around the "Wikipedia translate page" very hard to understand. Often I have no idea what they are even referring to.

So I chose to ignore the gibberish and simply try the translation interface to see what happens:

• I open w:Block-stacking problem which is the page I wanted to translate to German. I hover the mouse pointer over "Contributions" in the top right corner and click on "Translations" and I am taken to "https://en.wikipedia.org/w/index.php?title=Special:ContentTranslation&campaign=contributionsmenu&to=en&filter-type=automatic&filter-id=previous-edits&active-list=draft&from=es#/"
• I am asked for the name of the Wikipedia article to be translated which takes me to "https://de.wikipedia.org/w/index.php?title=Spezial:Inhalts%C3%BCbersetzung&from=en&page=Block-stacking+problem&to=de"
• Here the title of the English Wikipedia page is automatically translated to the German "Blockstapelproblem". Exciting! But unfortunately all the following paragraphs are simply copied over to the right column exactly as they appear in the original article. No further translation seems to be happening.
• To the right of the page I read: "Translation services not available for the selected languages. Why?"
• When I click on "Why?" I am taken to "Special:MyLanguage/Help:Content translation/Translating/Initial machine translation" which explains exactly nothing about why the translation service might be able to translate the title but is "not available" for the actual content of the English Wikipedia article.
• The content of "Special:MyLanguage/Help:Content translation/Translating/Initial machine translation" is utterly confusing so I won't even start bothering to mention all the question that this help page raises. But it would be good to know if there is any way to choose between the six translation services listed on this help page and how to go about it.
• When I go to the discussion page of "Special:MyLanguage/Help:Content translation/Translating/Initial machine translation" and try to add a topic I am advised "Please do not post support questions here." Instead I am referred to this page here.
  • User:Prototypeperspective has posted on the discussion page that he is facing the same issue as myself and is pointing to the German page "https://de.wikipedia.org/wiki/Wikipedia_Diskussion:Technik/Skin/Beta/ContentTranslation#Nutzlos_(?)" where it becomes apparent that the problem might have persisted since 2022 or even 2017.
• Also on the right side of the "Wikipedia translate page" 3 "issues" are announced only 2 of which are actually displayed. I was not able to copy the text of the issues but none of them explain why the english passages from the left column are not translated into German when I click "Add translation" in the right column. One issue is titled "Template unavailable" and the other issue is titled "Part of your translation contains 100% unmodified text." Well, yes, this is exactly the problem I am trying to resolve. Below I am directed to "https://www.mediawiki.org/wiki/Help:Content_translation/Translating/Translation_quality" which also does not give any hints as to why the automatic translation might only work for the page title and not for the body of the article.

All of the help pages about the translation service I have been looking at are rather incomprehensible and pose many more question which I would be happy to list if anyone is interested ..

Any suggestions on how to get the automatic translation going?

best regards, KaiKemmann (talk) 01:31, 16 May 2025 (UTC)

This is not what you want to hear but the talk page for Help:Content translation/Translating/Initial machine translation is the right place to ask about this project in particular, or at least better suited than this desk. The "don't post support questions here" bit is meant for people who would mistakenly ask about general problems with MediaWiki itself, which should be done here. Tactica (talk) 12:46, 16 May 2025 (UTC)

Mediawiki with AI capabilities

Do we have any option to integrate AI with MediaWiki?

Like an AI search engine? Has anyone thought about this?

Regards/GT Testergt1302 (talk) 07:40, 16 May 2025 (UTC)

@Testergt1302 All AI systems affectively already search Wikipedia. When you say AI, do you perhaps mean a conversational engine, backed by an AI language model ? —TheDJ (Not WMF) (talk • contribs) 09:44, 17 May 2025 (UTC)

Hi, We have a private wiki, that have huge data/content. So, I am just thinking, if there is any AI capability that we can integrate with our wiki, that can help users while searching or editing etc... Testergt1302 (talk) 07:35, 19 May 2025 (UTC)

MediaWiki provides an API and HTML. AI's can index both generally. So you just need to configure your AI agent to be able to index and search these web pages. —TheDJ (Not WMF) (talk • contribs) 14:42, 20 May 2025 (UTC)

Exporting to xml in english only

Is it possible to export only the English language version of the page code and templates to an xml file? Kszwaba (talk) 11:06, 18 May 2025 (UTC)

@Kszwaba See the answer that you received last time you asked the same question. https://www.mediawiki.org/w/index.php?title=Topic:Yftpbcesi4md3jg3&topic_postId=yfu3hpq909syxm7v&topic_revId=yfu3hpq909syxm7v&action=single-view Malyacko (talk) 15:26, 20 May 2025 (UTC)

Database connection error

I have an arch linux driven server on which I maintain my own wiki using Mediawiki.

Until an update two weeks ago, the whole wiki worked perfectly, but since the update I get an error message that the database cannot be accessed.

I have set up my wiki with the following components:

• mediawiki with php8
• sqlite as database
• lighttpd as webserver

The following updates were made during the update on 05/03/25 (php-cgi & php-sqlite always have the same version number as php):

• mediawiki: 1.42.1-1 -> 1.43.1-1
• php: 8.3.9-1 -> 8.4.6-2
• sqlite: 3.46.0-1 -> 3.49.1-1
• lighttpd: 1.4.76-1 -> 1.4.79-2

On 05/10/2025 I carried out another update as part of a troubleshooting process:

• mediawiki: 1.43.1-1
• php: 8.4.6-2 -> 8.4.7-1
• sqlite: 3.49.1-1 -> 3.49.2-1
• lighttpd: 1.4.79-2

The error persisted. After each update of Mediawiki I have performed php maintenance/run.php update.

After activating the corresponding flag in LocalSettings.php I get the following error message:

MediaWiki internal error.

Original exception: [b923ab9115bdc4186a4ba4d9] /mediawiki/index.php?title=Hauptseite Wikimedia\Rdbms\DBConnectionError: Cannot access the database: Error 14: unable to open database file
Function: Wikimedia\Rdbms\DatabaseSqlite::open
Query: PRAGMA synchronous = NORMAL

Backtrace:
from /usr/share/webapps/mediawiki/includes/libs/rdbms/database/Database.php(1221)
#0 /usr/share/webapps/mediawiki/includes/libs/rdbms/database/DatabaseSqlite.php(230): Wikimedia\Rdbms\Database->newExceptionAfterConnectError()
#1 /usr/share/webapps/mediawiki/includes/libs/rdbms/database/Database.php(263): Wikimedia\Rdbms\DatabaseSqlite->open()
#2 /usr/share/webapps/mediawiki/includes/libs/rdbms/database/DatabaseFactory.php(157): Wikimedia\Rdbms\Database->initConnection()
#3 /usr/share/webapps/mediawiki/includes/language/LCStoreDB.php(143): Wikimedia\Rdbms\DatabaseFactory->create()
#4 /usr/share/webapps/mediawiki/includes/language/LCStoreDB.php(56): LCStoreDB->getWriteConnection()
#5 /usr/share/webapps/mediawiki/includes/language/LocalisationCache.php(566): LCStoreDB->get()
#6 /usr/share/webapps/mediawiki/includes/language/LocalisationCache.php(612): LocalisationCache->isExpired()
#7 /usr/share/webapps/mediawiki/includes/language/LocalisationCache.php(479): LocalisationCache->initLanguage()
#8 /usr/share/webapps/mediawiki/includes/language/LocalisationCache.php(381): LocalisationCache->loadItem()
#9 /usr/share/webapps/mediawiki/includes/language/Language.php(567): LocalisationCache->getItem()
#10 /usr/share/webapps/mediawiki/includes/title/MediaWikiTitleCodec.php(120): MediaWiki\Language\Language->needsGenderDistinction()
#11 /usr/share/webapps/mediawiki/includes/title/Title.php(1157): MediaWiki\Title\MediaWikiTitleCodec->getNamespaceName()
#12 /usr/share/webapps/mediawiki/includes/page/Article.php(494): MediaWiki\Title\Title->getNsText()
#13 /usr/share/webapps/mediawiki/includes/actions/ViewAction.php(78): Article->view()
#14 /usr/share/webapps/mediawiki/includes/actions/ActionEntryPoint.php(733): ViewAction->show()
#15 /usr/share/webapps/mediawiki/includes/actions/ActionEntryPoint.php(510): MediaWiki\Actions\ActionEntryPoint->performAction()
#16 /usr/share/webapps/mediawiki/includes/actions/ActionEntryPoint.php(146): MediaWiki\Actions\ActionEntryPoint->performRequest()
#17 /usr/share/webapps/mediawiki/includes/MediaWikiEntryPoint.php(200): MediaWiki\Actions\ActionEntryPoint->execute()
#18 /usr/share/webapps/mediawiki/index.php(58): MediaWiki\MediaWikiEntryPoint->run()
#19 {main}

Exception caught inside exception handler: [b923ab9115bdc4186a4ba4d9] /mediawiki/index.php?title=Hauptseite Wikimedia\Rdbms\DBConnectionError: Cannot access the database: Error 14: unable to open database file
Function: Wikimedia\Rdbms\DatabaseSqlite::open
Query: PRAGMA synchronous = NORMAL

Backtrace:
from /usr/share/webapps/mediawiki/includes/libs/rdbms/database/Database.php(1221)
#0 /usr/share/webapps/mediawiki/includes/libs/rdbms/database/DatabaseSqlite.php(230): Wikimedia\Rdbms\Database->newExceptionAfterConnectError()
#1 /usr/share/webapps/mediawiki/includes/libs/rdbms/database/Database.php(263): Wikimedia\Rdbms\DatabaseSqlite->open()
#2 /usr/share/webapps/mediawiki/includes/libs/rdbms/database/DatabaseFactory.php(157): Wikimedia\Rdbms\Database->initConnection()
#3 /usr/share/webapps/mediawiki/includes/language/LCStoreDB.php(143): Wikimedia\Rdbms\DatabaseFactory->create()
#4 /usr/share/webapps/mediawiki/includes/language/LCStoreDB.php(56): LCStoreDB->getWriteConnection()
#5 /usr/share/webapps/mediawiki/includes/language/LocalisationCache.php(539): LCStoreDB->get()
#6 /usr/share/webapps/mediawiki/includes/language/LocalisationCache.php(403): LocalisationCache->loadSubitem()
#7 /usr/share/webapps/mediawiki/includes/language/LocalisationCache.php(419): LocalisationCache->getSubitem()
#8 /usr/share/webapps/mediawiki/includes/language/MessageCache.php(1267): LocalisationCache->getSubitemWithSource()
#9 /usr/share/webapps/mediawiki/includes/language/MessageCache.php(1209): MessageCache->getMessageForLang()
#10 /usr/share/webapps/mediawiki/includes/language/MessageCache.php(1103): MessageCache->getMessageFromFallbackChain()
#11 /usr/share/webapps/mediawiki/includes/Message/Message.php(1554): MessageCache->get()
#12 /usr/share/webapps/mediawiki/includes/Message/Message.php(1036): MediaWiki\Message\Message->fetchMessage()
#13 /usr/share/webapps/mediawiki/includes/Message/Message.php(1127): MediaWiki\Message\Message->format()
#14 /usr/share/webapps/mediawiki/includes/exception/MWExceptionRenderer.php(253): MediaWiki\Message\Message->text()
#15 /usr/share/webapps/mediawiki/includes/exception/MWExceptionRenderer.php(399): MWExceptionRenderer::msg()
#16 /usr/share/webapps/mediawiki/includes/exception/MWExceptionRenderer.php(107): MWExceptionRenderer::reportOutageHTML()
#17 /usr/share/webapps/mediawiki/includes/exception/MWExceptionHandler.php(135): MWExceptionRenderer::output()
#18 /usr/share/webapps/mediawiki/includes/exception/MWExceptionHandler.php(239): MWExceptionHandler::report()
#19 /usr/share/webapps/mediawiki/includes/MediaWikiEntryPoint.php(222): MWExceptionHandler::handleException()
#20 /usr/share/webapps/mediawiki/includes/actions/ActionEntryPoint.php(82): MediaWiki\MediaWikiEntryPoint->handleTopLevelError()
#21 /usr/share/webapps/mediawiki/includes/MediaWikiEntryPoint.php(206): MediaWiki\Actions\ActionEntryPoint->handleTopLevelError()
#22 /usr/share/webapps/mediawiki/index.php(58): MediaWiki\MediaWikiEntryPoint->run()
#23 {main}

Opening the corresponding database with

sqlite bp_wiki.sqlite

as http and checking the database with

sqlite> .database

gives

main: /usr/share/webapps/data/bp_wiki.sqlite r/w

showing that the database is present and also readable and writeable. The database is owned by user and group http.

So it seems, that the database containing the wiki content is not accessable by php!?

What could be the cause of this error? Mrpaul2025 (talk) 09:21, 19 May 2025 (UTC)

A common cause for this is an issue with temp file access. In order to work with sqlite, you need to be able to create temp files. —TheDJ (Not WMF) (talk • contribs) 14:40, 20 May 2025 (UTC)

ok, and which folder or path could be the problem? Is there a special path or program, one of the components (mediawiki, php, sqlite) needs?

What I don't understand is, that it worked until my first update listed in the question. But I didn't find any log entry, that the update caused some changes in the permissions. 77.22.252.46 17:29, 20 May 2025 (UTC)

Can't add Gregorian chant due to old bug

I tried to add Gregorian chant to a wiki page with Extension:Score, and I ran into this problem: T289651

It looks like that bug has been stalled for a few years. Is there any workaround I can use in the meantime, or anything I can do to help get that fixed? 50.230.238.42 04:01, 21 May 2025 (UTC)

The details are obscure to me, but the documentation recommends using Shellbox if you can't trust everyone who edits your wiki and configuring LilyPond directly. "Certain functionality will not work in safe mode, the fix for that is to modify LilyPond to allow that functionality in safe mode" - assuming of course, you know what functionality is affected and how to enable it. Rand(1,2022) (talk) 06:47, 21 May 2025 (UTC)

page links vs V.T.E template links

Hello there, is it currently possible to differentiate (in database) between links that appear actually to the reader in a Wikipedia page, and links that appears at the very bottom in the V.T.E template section ? 2A01:E0A:3DB:9860:AD21:80D5:197F:5E7F 10:53, 22 May 2025 (UTC)

Vector 2022 dark mode behavior with caching

Does anyone know if you make the "os" setting the default will the caching work correctly? Using regular MediaWiki caching, not Varnish. I remember that was a concern when dark mode was being developed. I want to hear if it is fixed or if there are settings that need to be adjusted. Flounder ceo (talk) 18:18, 22 May 2025 (UTC)

Project in root directory help

I have my mw install in the root directory and followed the advice found in these pages 1, 2, 3 and some advice found in discussions there meaning I have the following:

$wgScriptPath = "";
$wgArticlePath = "/$1";

and in my Apache .conf

 ServerName name.wiki
 ServerAlias www.name.wiki
 DocumentRoot /var/www/wikiname
 ... SSL stuff
 
 RewriteEngine On
 RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
 RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d
 RewriteRule ^(.*)$ %{DOCUMENT_ROOT}/index.php [L]
 
 RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
 RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d
 RewriteRule ^/?images/thumb/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$ %{DOCUMENT_ROOT}/thumb.php?f=$1&width=$2 [L,QSA,B]
 
 RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
 RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d
 RewriteRule ^/?images/thumb/archive/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$ %{DOCUMENT_ROOT}/thumb.php?f=$1&width=$2&archived=1 [L,QSA,B]
 
 <Directory /var/www/wikiname/images>
   Options -Indexes
   AllowOverride None
   AddType text/plain .html .htm .shtml .phtml
   AddType image/webp .webp
   <Files "*.php">
     SetHandler !
   </Files>
   Header set X-Content-Type-Options nosniff
 </Directory>

LocalSettings.php is safe and permissions seem fine, however, I'm able to access random files through the URL in the directory like .txt files and other files like that in directories. How do I go about only having necessary files be web-accessible?

EDIT: This bit of documentation seems like the right direction. Do I have this right?

 ServerName name.wiki
 ServerAlias www.name.wiki
 DocumentRoot /dev/null
 ... SSL stuff
 
 Alias /index.php /var/www/wikiname/index.php
 Alias /api.php /var/www/wikiname/api.php
 Alias /load.php /var/www/wikiname/load.php
 Alias /thumb.php /var/www/wikiname/thumb.php
 Alias /img_auth.php /var/www/wikiname/img_auth.php
 Alias /opensearch_desc.php /var/www/wikiname/opensearch_desc.php
 Alias /images /var/www/wikiname/images
 Alias /robots.txt /var/www/wikiname/robots.txt
 
 <Directory /var/www/wikiname>
   Require all granted
   Options -Indexes
   AllowOverride None
   ... Move rewrites here
 </Directory>
 <Directory /var/www/wikiname/images>
   .. Same as before
 </Directory>

Porcupinez (talk) 13:08, 23 May 2025 (UTC)

@Porcupinez: By .txt files and other files like that in directories, do you mean in the images/ directory, or just the general MediaWiki application files? If the latter, there's no problem with them being accessible. I think ideally you should be able to restrict it to serve only index.php, api.php, rest.php, thumb.php, thumb_handler.php, img_auth.php, and load.php (i.e. get rid of the -d and -f checks you've got above) but some extensions still want to serve images etc directly from their directories. Sam Wilson 01:10, 25 May 2025 (UTC)

Thanks for the reply! I meant general MediaWiki application files. I edited a bit onto my initial post. Would getting rid of the !-f and !-d flags be enough instead of all that? I would still want to selectively expose files like robots.txt and not break anything with extensions like you mentioned. Porcupinez (talk) 01:19, 25 May 2025 (UTC)

@Porcupinez: I wouldn't bother trying to hide application files. It's all open source anyway! But yeah, with some judicious use of rewrite rules you can hide everything but still have just a few things available. Sam Wilson 09:13, 26 May 2025 (UTC)

@Samwilson Ahh, well, at least it isn't much to worry about. There is a potential issue of LocalSettings.php.save files generated by an IDE, or files potentially blocking the main namespace. I would prefer to, but thankful to confirm it isn't inherently dangerous. Porcupinez (talk) 07:00, 27 May 2025 (UTC)

@Porcupinez: Are you editing with an IDE on prod?! :-P I guess you could add some LocalSettings-specific deny rule, just to be sure. Sam Wilson 07:18, 27 May 2025 (UTC)

@Samwilson I test with a local environment and eventually apply changes with nano? If there's a better alternative please let me know lol Porcupinez (talk) 12:48, 27 May 2025 (UTC)

Enable editing category of protected articles

Hello,

I have a few thousands of protected articles at a wiki: it is working as a news site and the articles written over a week ago are protected as no further edits need to be made. They are called archived. I am facing an issue with categories. From time to time someone proposes a new category and asks for archived articles categories to be updated to add them to the newly added category. Is there a way to allow a user to edit a protected article, but only for purpose of adding categories, and not for anything else, i.e. not alter its content in any other way?

If not, I will need to either allow the interested users to be sysops with focus on only altering categories; or create a new 'archive keeper' user rights group and edit protection level for thousands of pages so that the 'archive keeper' users can edit them. Gryllida 12:03, 24 May 2025 (UTC)

The only way I can think of doing something remotely like this is Extension:AbuseFilter, which only works by taking away rights you had before, not granting people rights they already had, or to split the categories an article has into a separate non-protected page, both of which are impractical when dealing with a backlog of articles archived not using either system.

That said, nothing stops you (given sufficient consensus) from configuring the wiki to have a separate "archive keeper" group that can edit full-protected pages, and doing so would not need you to reprotect thousands of pages (and can of course be combined with the abuse filter approach to technically only let them edit categories too). * Pppery * _{it has begun} 18:26, 24 May 2025 (UTC)

Enable section archival

Some few months ago on talk pages a feature was added allowing to 'reply' to a paragraph, it also shows 'Latest comment: just now | 1 comment | 1 person in discussion'. Could whatever extension is doing this be extended to allow me to delete and/or archive sections from a talk page in one click? Gryllida 12:06, 24 May 2025 (UTC)

That's Extension:DiscussionTools. Deleting or archiving some partial page content sounds out of scope. Why would someone want to do that manually anyway? Malyacko (talk) 14:38, 24 May 2025 (UTC)

Oh there are plenty of reasons. There's an entire gadget for it (OneClickArchiver). The bigger problem is that there is no real concept of 'archiving' that is standardized, which makes any sort of implementation for all wikis in the world a lot more difficult. —TheDJ (Not WMF) (talk • contribs) 08:07, 27 May 2025 (UTC)

Problem with Short URL-s after uprgade to Mediawiki 1.43.1

I've run into issue after upgrading my wiki from 1.42.x to 1.43.1. All pages wive error page 404. Looking through all the guidelines and documentation, it seems, that the problem is with Short URL-s.

Details

• Upgrade was done via cPanel (as was original install of the software).
• No error messages during upgrading.
• Upgrade log is all clean - says no errors.
• Wiki is in subdomain of the main doman. (I'm not inclined to share the side address as is it a private hobby project, but is someone is willing to look into it personally, then I can create temporary credentials if needed.)
• Page is configures so, that content can be seen only by users who have logged in.
• Folder /w or /wiki is not in use.

What I've tried so far

• Editing .htaccess
• Editing LocalSettings.php Current settings are: $wgScriptPath = ""; $wgArticlePath = "/$1"; $wgScriptExtension = ".php"; $wgUsePathInfo = true;
• Cache is not enabled

Server information

• PHP: 8.4.6 (litespeed)
• ICU: 71.1
• MariaDB: 10.6.21-MariaDB-cll-lve-log

Used extensions

• Citizen (2.39.3)
• MinervaNeue
• MonoBook
• Timeless (0.9.1)
• Vektor (1.0.0)
• NumberHeadings
• VisualEditor
• Cite
• VisualData
• FontAwesome

Zängov (talk) 15:00, 24 May 2025 (UTC)

This concerns your webserver configuration. which has to parse the urls correctly and then give the right information to MediaWiki. So that's what you should look into. —TheDJ (Not WMF) (talk • contribs) 08:04, 27 May 2025 (UTC)

You should include your .htaccess and any other config related to rewriting urls. Bawolff (talk) 19:43, 27 May 2025 (UTC)

Default time format?

Is it 12h or 24h on a fresh install? Is this configurable?

I think it is weird that the Date format Preference option is using 24h but the site could be using 12h... Dengamlapotatisen (talk) 09:35, 27 May 2025 (UTC)

By default, every wiki out there runs on UTC's 24-hour clock (i.e. the wikis' 00:00 corresponds to 8:00 p.m. EDT, 7:00 Central, 5:00 Pacific at this time of year). Don't think I've ever come across an a.m./p.m. option (or the mere thought thereof)... --Slgrandson (talk) 10:26, 27 May 2025 (UTC)

it looks like this is in reference to OSM wiki, which had a js gadget to replace dates with 12 hour clock. Bawolff (talk) 19:40, 27 May 2025 (UTC)

Making -/ and \- turn the text it's enclosing into Title case

I want to make -/ and \- give the text they are enclosing the Title casing. But how? Even after adding it to LanguageConverter.php, Parser.php, Preprocessor.php and PPFrame_Hash.php, still, it took no effect.
What other files do I have to edit to add this functionality? Kxeon (talk) 16:06, 27 May 2025 (UTC)

If you're editing files at random without understanding how they work, its not surprising it doesn't work. I doubt anyone can answer this question without knowing what you did and if you did it correctly. Bawolff (talk) 19:41, 27 May 2025 (UTC)