Project:Support desk

Welcome to the MediaWiki Support desk. This is a place where you can ask any questions you have about installing, using or administrating the MediaWiki software.

(Read this message in a different language)

See also

• Other places to ask for help

Before you post

• 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.
• Ask technical questions about Wikimedia websites on meta:Tech instead.

Post a new question

1. To help us answer your questions, please indicate which version of MediaWiki you are using, as found on your wiki's Special:Version page:
2. If possible, add $wgShowExceptionDetails = true;error_reporting( -1 );ini_set( 'display_errors', 1 ); to LocalSettings.php in order to make MediaWiki show more detailed error messages.
3. 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.
4. To start a new thread, click the box with the text "Start a new topic".

Version 1.39.3

https://jfwiki.org

I am not able to create new accounts, I get the error:

"An account creation for this username is already in progress. Please wait."

Changing the username makes no difference.

Using createAndPromote from the command line returns the same error.

I attempted to rename a user w/ Special:RenameUser resulting in this error:

Internal error

[ZpVjTbzkAommjGxmWP@BlwAAQJE] /index.php?title=Special:RenameUser Error: Call to undefined method User::isCreatableName()

Backtrace:

from /home/jfwiki/wiki139/extensions/Renameuser/includes/SpecialRenameuser.php(251)#0 /home/jfwiki/wiki139/includes/specialpage/SpecialPage.php(701): SpecialRenameuser->execute(NULL)#1 /home/jfwiki/wiki139/includes/specialpage/SpecialPageFactory.php(1428): SpecialPage->run(NULL)#2 /home/jfwiki/wiki139/includes/MediaWiki.php(316): MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, RequestContext)#3 /home/jfwiki/wiki139/includes/MediaWiki.php(904): MediaWiki->performRequest()#4 /home/jfwiki/wiki139/includes/MediaWiki.php(562): MediaWiki->main()#5 /home/jfwiki/wiki139/index.php(50): MediaWiki->run()#6 /home/jfwiki/wiki139/index.php(46): wfIndexMain()#7 {main}

___________________________________________

What's up with isCreatableName?

I updated from WM 1.35 to 1.39.3 a year ago and I haven't tried to create a user since, so this likely happened during the update.

Error reporting is showing this, I'm not sure that it's relevant:

Deprecated

: Use of $wgUser was deprecated in MediaWiki 1.35. [Called from VectorHooks::makeGlobalVariablesScript in /home/jfwiki/wiki139/extensions/Vector/Vector.hooks.php at line 186] in

/home/jfwiki/wiki139/includes/debug/MWDebug.php

on line

381

Deprecated

: Use of User::getOption was deprecated in MediaWiki 1.35. [Called from StubObject::_call in /home/jfwiki/wiki139/includes/StubObject.php at line 120] in

/home/jfwiki/wiki139/includes/debug/MWDebug.php

on line

381

Deprecated

: $wgUser reassignment detected [Called from VectorHooks::makeGlobalVariablesScript in /home/jfwiki/wiki139/extensions/Vector/Vector.hooks.php at line 186] in

/home/jfwiki/wiki139/includes/debug/MWDebug.php

on line

381

_____________________________________________________

I have enabled Create Account in case you'd like to see it:

https://jfwiki.org/index.php?title=Special:CreateAccount&returnto=Main+Page

Thank you for any help

Sean

It sounds like you are trying to use MW 1.35 extensions with MediaWiki 1.39. Try and ensure that all extensions have also been upgraded to the appropriate version.

Of special note - RenameUser extension functionality is now in MediaWiki core. The extension cannot be used with newer versions of MediaWiki and must be removed on mediawiki 1.39.

I've just deployed an internal wikipage for my company. As of now we have a couple of sections on the left navigation pane (we have more but only three are being used at the moment).

Section 1 Section 2 Section 3

Whenever I click on one of the sections I get the URL:

http://mediawiki.my.domain/mediawiki/index.php/Section 1

What we desire to do is to get URL: http://mediawiki.my.domain/mediawiki/Section 1

Please, don't instruct me to read: https://www.mediawiki.org/wiki/Manual:Short_URL, the guide might be clear for you guys but at least for me, it isn't. A real life scenario example would make things a LOT easier...but there aren't any available, not even outside their wikipage. I've also read similar threads here on stack overflow, but still, no luck.

According to what I've been reading, file LocalSettings.php should have at the end:

 ## The URL base path to the directory containing the wiki;
 ## defaults for all runtime URL paths are based off of this.
 ## For more information on customizing the URLs please see:
 ## http://www.mediawiki.org/wiki/Manual:Short_URL
 $wgScriptPath = "/mediawiki";
 $wgScriptExtension = ".php";
 $wgArticlePath = "{$wgScriptPath}/wiki/$1";
 $wgUsePathInfo = true

But there has to be an htaccess file also on the mediawiki web directory with something like this:

RewriteEngine On
 RewriteRule ^/?mediawiki/wiki(/.*)?$ %{DOCUMENT_ROOT}/w/index.php [L]
 RewriteRule ^/mediawiki*$ %{DOCUMENT_ROOT}/w/index.php [L]*

So if I create this file on the mediawiki directory, will this work? any other information I might be missing here?

Based on what you've been describing (You desire http://mediawiki.my.domain/mediawiki/ArticleNameHere . index.php is in the mediawiki directory), you need a couple of differences: $wgArticlePath = "mediawiki/$1"; for the article path instead of what you wrote (rest of LocalSettings.php is fine).

and for the .htaccess you want

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d
RewriteRule ^/?mediawiki(/.*)?$ %{DOCUMENT_ROOT}/w/index.php [L]

At least I think. I haven't tested this, ymmv. The .htaccess may depend on what webserver and if its configured to read .htaccess files.

Hey @Bawolff

Thanks for answering!

I'll try this in a moment, web server is Apache and I'm not really sure where to put the file. Should this be in /mediawiki path? or in the webserver main root path?

@Bawolff

I edited local httpd.conf file to AllowOverride All, so .htaccess could have permissions to change the URL.

I also created the .htaccess file in /var/www/html with the content provided. However when browsing to http://mediawiki.my.domain/mediawiki, page is blank :(

Also edited LocalSettings.php as you said

Any ideas?

Also, at this point, I don't know if .htaccess has to be placed at /var/www/html or the media wiki path...

These questions seems to be about Apache HTTPD and not about MediaWiki. See https://httpd.apache.org/dev/debugging.html, https://stackoverflow.com/questions/9234289/how-to-debug-htaccess-rewriterule-not-working/16378968, etc. Seehttps://httpd.apache.org/docs/current/howto/htaccess.html

Hi @Malyacko

I understand these questions are more suitable for HTTPD/Apache, but we are not even sure if the code:

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d RewriteRule ^/?mediawiki(/.*)?$ %{DOCUMENT_ROOT}/w/index.php [L]

is correct.

Can you personally confirm that so I can move on to Apache/HTTPD Forums? Because if the code is wrong, there's no use on checking Apache

note those rewritecond rules are apache code not mediawiki code. I personally think its in scope here as configuring apache to work with mediawiki short urls is a common system admin task, and one lots of people have trouble with, but ultimately that is an apache question not a mediawiki question

UPDATE:

Used this on Local Settings:

$wgScriptPath = "/mediawiki";

$wgArticlePath = "/mediawiki/$1";

And used this on .htaccess

RewriteEngine On

RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule ^mediawiki/(.*)$ w/index.php?title=$1 [PT,L,QSA]

RewriteRule ^mediawiki/*$ w/index.php [L,QSA]

RewriteRule ^mediawiki$ w/index.php [L,QSA]

It is now redirecting ok, but stating MainPage is not found on directory

I'm not quite sure what your last problem is regarding, but this tool can create automatic configurations.

in fairness you didn't mention in your otiginal post that mediawiki was in a directory named w.

Hi @Bawolff

Actually that tool serves me right if the domain is public and it currently isn't

MediaWiki directory is in /mediawiki. Pretty sure that has something to do with it

UPDATE: So I change my LocalSettings.php content to:

$wgScriptPath = "/mediawiki";

$wgArticlePath = "/mediawiki/$1";

And .htaccess to:

RewriteEngine On

RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule ^mediawiki/(.*)$ mediawiki/index.php?title=$1 [PT,L,QSA]

RewriteRule ^mediawiki/*$ mediawiki/index.php [L,QSA]

RewriteRule ^mediawiki$ mediawiki/index.php [L,QSA]

Replacing all /w to mediawiki as it is the directory where it is installed

When I browse to http://mediawiki.my.domain/mediawiki I get:

Not Found

The requested URL /mediawiki/Main_Page was not found on this server.

Looks like rewriting works fine but there's no content now... (and there previously was)

htaccess had to be on root path not mediawiki path, that was it! Thanks!

may i know what do u mean by root path? i am facing your not found issue.

the root path is usually "public_html" folder, it is the base directory where the webpage files are put.

since 20240620, those two columns are not returned in automated dump at https://dumps.wikimedia.org/enwiki/

here's DDL of 20240601

CREATE TABLE `pagelinks` (

  `pl_from` int(8) unsigned NOT NULL DEFAULT 0,

  `pl_namespace` int(11) NOT NULL DEFAULT 0,

  `pl_title` varbinary(255) NOT NULL DEFAULT '',

  `pl_from_namespace` int(11) NOT NULL DEFAULT 0,

  `pl_target_id` bigint(20) unsigned NOT NULL,

  PRIMARY KEY (`pl_from`,`pl_target_id`),

  KEY `pl_namespace` (`pl_namespace`,`pl_title`,`pl_from`),

  KEY `pl_backlinks_namespace` (`pl_from_namespace`,`pl_namespace`,`pl_title`,`pl_from`),

  KEY `pl_target_id` (`pl_target_id`,`pl_from`),

  KEY `pl_backlinks_namespace_target_id` (`pl_from_namespace`,`pl_target_id`,`pl_from`)

) ENGINE=InnoDB DEFAULT CHARSET=binary ROW_FORMAT=COMPRESSED;

here's DDL of post 20240601

CREATE TABLE `pagelinks` (

  `pl_from` int(8) unsigned NOT NULL DEFAULT 0,

  `pl_from_namespace` int(11) NOT NULL DEFAULT 0,

  `pl_target_id` bigint(20) unsigned NOT NULL,

  PRIMARY KEY (`pl_from`,`pl_target_id`),

  KEY `pl_target_id` (`pl_target_id`,`pl_from`),

  KEY `pl_backlinks_namespace_target_id` (`pl_from_namespace`,`pl_target_id`,`pl_from`)

) ENGINE=InnoDB DEFAULT CHARSET=binary ROW_FORMAT=COMPRESSED;

can someone look into this please

The pagelinks table was refactored to use a separate table for link targets. See https://lists.wikimedia.org/hyperkitty/list/[email protected]/message/U2U6TXIBABU3KDCVUOITIGI5OJ4COBSW/ and Manual:Linktarget table

thank you, indeed it was refactored, Manual:Pagelinks table is outdaded

It was half in there, but I made it more obvious now.

My wiki is missing a bunch of pages. I think it's specifically the pages that only had one revision. Possibly only if that revision was very old.

Here's an example page: https://www.qbwiki.com/wiki/St._Anne%27s . It says there's no text in this page, but the page, revision, and text tables all seem to have the right data.

Other observations:

• The page header has "Read", "Edit", and "View History" tabs, as opposed to a page that really doesn't exist, which only has "Create"
• Editing the page displays

The revision #0 of the page named "St. Anne's" does not exist.

This is usually caused by following an outdated history link to a page that has been deleted. Details can be found in the deletion log.

(but the deletion log doesn't show anything)

• When I try to save an edit, I am told there is an edit conflict ("Someone else has changed this page since you started editing it.")
• I can delete the page and then re-create it
• I fiddled around with the PHP code to see where the error text was coming from. It's Article.php line 436, in the fetchRevisionRecord() method:

// $this->mRevision might already be fetched by getOldIDFromRequest()
if ( !$this->mRevision ) {
	if ( !$oldid ) {
		$this->mRevision = $this->mPage->getRevision();

		if ( !$this->mRevision ) {
			wfDebug( __METHOD__ . " failed to find page data for title " .
				$this->getTitle()->getPrefixedText() . "\n" );

			// Just for sanity, output for this case is done by showMissingArticle().
			$this->fetchResult = Status::newFatal( 'noarticletext' );
			$this->applyContentOverride( $this->makeFetchErrorContent() );
			return null;
		}
	…

But I don't know enough about how MediaWiki works (or PHP in general, really) to figure out what's going wrong.

This problem likely started after an upgrade that I struggled with. Unfortunately, I didn't notice this problem until long after the upgrade, and when I finished the upgrade I had thought everything turned out okay, so I don't remember exactly what went wrong.

The upshot is that there are a bunch of pages (this was just one example) whose contents exist in the database but can't be accessed through the website. I'm not sure even how to systematically identify such pages. I suspect some rows or values are just missing from some table(s), but I have no clue which or how to find out.

Thoughts?

Do you have backups from before the upgrade?

It is most likely that either the actor or comments migration has gone wrong. MediaWiki does a LEFT JOIN on those tables so missing entries in there will cause those revisions/pages to appear as missing.

If it is about comments, see https://phabricator.wikimedia.org/T249904.

If it is about actors, I had the following trick:

1. identify the user names for those revisions
2. Create proper users for them, e.g. `User::newSystemUser( '...', [ 'steal' => true ] );`
3. Run database queries UPDATE revision SET rev_user = 0 where rev_user_name = '...'; (and similar for all affected tables, mostly logging, archive and recentchanges)
4. Run php maintenance/cleanupUsersWithNoId.php

But you need backups to do this in case the rev_user and equivalent fields are already dropped. I guess it's possible to do it afterwards by updating the rev_actor and equivalent fields too, but I have not done that myself.

I do have backups from before the upgrade, but the upgrade was about a year ago so restoring from the backup isn't viable.

Thanks for pointing me at revision_comment_temp and revision_actor_temp. It looks like the problem is the latter—this query returns 164 rows:

SELECT * FROM revision WHERE rev_id NOT IN (SELECT revactor_rev FROM revision_actor_temp)

Do you agree with that reasoning? (Some of the corresponding pages do exist, but the revisions seem to be missing when I view the history through the web interface.)

The rev_user_text column contains the username, so that should address your step 1, right? Are you able to elaborate on step 2 (how do I do that? what's the steal thing?) and 3 (which tables are affected?)? Thanks so much!

I'd suggest running `php maintenance/migrateActors.php --force` to observe if there are errors. If there is, you should get list of usernames that match the rev_user_text of those rows. You could try running cleanupUsersWithNoId.php first or maybe even findMissingActors.php (if you have it) to see if is sufficient.

But if they don't work, my step 2 basically creates and user and actor for the name. The issue may be that there is no used account for the name, so actor cannot be created. Step 3 removes broken references to user ids which do not exist, so that cleanupUsersWithNoId can process it. The relevant tables and names should be printed out by the migrateActors script.

Thanks. migrateActors produced a bunch of messages like this:

User name "X" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

cleanupUsersWithNoId produced a bunch of output but didn't seem to actually do anything.

I don't know how to actually do your step 2. It looks like PHP code I'm supposed to run, but I don't know how to run custom code within the MediaWiki environment.

I don't have findMissingActors.

There is shell.php and eval.php under maintenance, both allow you to run that code interactively.

Thanks. I had to fight with shell.php pretty hard to get PsySH to work, but I think everything works now, including the solution of my original problem. I appreciate your help.

I had a very similar problem and this thread was very helpful, thank you. I was able to resolve with this SQL:

INSERT INTO revision_actor_temp (revactor_rev, revactor_actor, revactor_timestamp, revactor_page) SELECT rev_id, 1 as actor, rev_timestamp, rev_page FROM revision WHERE rev_id NOT IN (SELECT revactor_rev FROM revision_actor_temp);

I was not concerned with correctly matching up the actors (and indeed think this data is lost), so replaced all of them with actor 1 (Administrator on my wiki). All of the page revisions are now accessible again. The missing actors were old now non-existent users that must have been lost in the 1.31 to 1.35 migration somewhere.

I should add I needed to run php maintenance/update.php afterwards as well.

thank you for this! the sql statement saved my wiki :-)

The SQL statement above also fixed issues on our wiki's.

The solution posted by 81.174.133.236 only works, however, on file pages the connection of the files to their pages is not reinstated. This means the files are not shown on the wiki. Reuploading with the same name is not possible either.

Note that I went from 1.25 to 1.31, to 1.32, to 1.33, 1.34 and now to 1.35. Needless to say that migrateActorswithNoId.php was useless to run. It detected the actors but did not clean them.

Going the rebuildImages.php path does not help, and neither the cleanupUsersWithNoId.php/migrateActors.php path.

I am clueless as to how to mitigate this. Looks to me like I may have run into this which I will still have to investigate. Edit: No, I do not think this is the issue.

You may try to use this version of cleanupUsersWithNoId.php for MediaWiki 1.35 that fixes other corner-cases that the original script did not fix.

Thanks for the pointer to your patched version of the script "cleanupUsersWithNoId.php." You are a hero! In the case of the current wiki I worked on, it was a lifesaver. Let me share my experience:

Going directly from MW 1.31 to MW 1.35 and applying the script on MW 1.35 after running "update.php" did not work. The wiki was in a disastrous condition after the upgrade and is no longer usable. This outcome is expected since the script had nothing to work on in the MW 1.35 database.

Going from MW 1.31 to MW 1.32, then to MW 1.33, using the patched script you linked to on 1.33 after running "update.php," did work. For some reason, the wiki was still unusable in version MW 1.33; however, upgrading to MW 1.34 with "update.php" and from there to MW 1.35 with "update.php" mitigated the issues emerging on the wiki. As a result, the wiki is working fine as it appears to me (still pending user feedback). This way, I could prevent massive issues, including this one, from occurring if I used core software. I am still determining why the wiki is broken in version 1.33, but it is probably another story.

Directly going from MW 1.31 to MW 1.35 is not recommended for wikis, with issues surfacing after the upgrade. Do it branch by branch and apply the patched script to MW 1.33. Going from MW 1.31 via MW 1.32, MW 1.33, and MW 1.34 to MW 1.35 using the script "cleanupUsersWithNoId.php" provided by core will also not work. The result will be a disaster. On the way, "update.php" will complain for MW 1.33 to MW 1.35 that you need to run "cleanupUsersWithNoId.php," however, it will ultimately do nothing.

Hi, I would like to share my experience here since I've been struggling with updating my MW from 1.31 onwards. Originally, I wanted to go from MW 1.31 to 1.32 and then 1.33 some time ago. As 1.33 broke my wiki due to the known actor nightmare (cleanupUsersWithNoId.php does not help), I decided to postpone the update.

Now, I gave everything another shot and followed the instructions posted by @Kghbln.

1) MW 1.31 to MW 1.32 using update.php

2) MW 1.32 to MW 1.33 using the enhanced version of cleanupUsersWithNoId.php by @Ciencia Al Poder first and only then executing update.php

3) MW 1.33 to MW 1.34 using update.php

4) MW 1.34 to MW 1.35 using update.php

Afterwards, my wiki was working fine on MW 1.35. As 1.39 is already out, I decided to continue the update process. To be on the safe side, I performed the update for each version separately (1.36 -> 1.37 -> 1.38 -> 1.39). Everything works fine now under PHP 7.4, my next step is going to push the PHP version to 8.1 but that's not related to this issue.

Btw, the query posted by 81.174.133.236 was not necessary as the enhanced script took care of everything.

Another issue I had facing this update was the removal of Manual:$wgDBmysql5. My database was still using latin1 collations and everything was working fine with $wgDBmysql5 = true; until this setting was removed in MW 1.33. Therefore, I had to adjust my DB accordingly to avoid encoding issues with special characters (some hints are given on the talk page of the setting, also see Topic:Wqktznc6b8nyc29g).

I really would like to thank @Ciencia Al Poder and @Kghbln and everyone involved for sharing the script and their paths for the update!

No! I recommend wait to next stable version MW, because upgrade scipt must accept upgrade from PHP 7.x to 8.2 and some distributions as Debian for example, 8.0 and 8.1 skiped. But MW 1.42 with support PHP 8.2 not released. I know that is complication, but another choice isn't for now.

Say, I appear to have this issue in my wiki. However, I'm unable to use the above solution as my wiki has already been upgraded a few times (currently on 1.41), and I don't think I have access to the older versions anymore.

migrateActors.php --force shows 0 errors currently.

I also note that if I look at the history of a problematic page, I can see, for example, three users with edits. All appear in the list of users, and have other unaffected pages.

Any suggestions on how I might dig myself out of this?

Did you try to run the above SQL statement? That worked for us.

Yes, it errors out as there is no "revision_actor_temp"

There's no fix once your wiki database has been upgraded to later versions. The information of those old users is gone. Forever. There are only actor ids now. You'll have to manually select those actor ids and replace them by whatever other actor id that may be the best replacement for them.

Hmm, well, unfortunately I'm not even sure how to find the old actor IDs. Currently despite being able to see old revisions, I can't find the page in the database, but I may be not searching correctly. I'm certainly no expert on how the database is structured.

OK, so I think I have a better idea how to fix things now.

I did some reading up on the mediawiki manual that describes the structure of the database. It now made sense that I didn't have a "revision_actor_temp", as that was only around v1.3.1 – v1.3.8, and I've already upgraded past that.

I have been able to identify a few problem pages just by coming across them browsing my wiki. I'm using phpMyAdmn tool at part of the cPanel set up for my instance. Selecting my database and searching for an exmaple page title let me find the page record, and in that, find the page ID number.

The, searching the revision field only (by selecting it and using the search tool), I was able to search for all revision entries for that page ID number. The very last/latest revision had an rev_actor ID of "0". When I had been looking at the list of revisions in the wiki, it shows them up to that point.

After backing up my database (in case I mess things up), I edited the rev_actor ID for that one revision from "0" to "1" (the ID of the main admin account). Now that revision appears with the name of the main admin account as having done the revision, and the page appears normally in the wiki.

Now I certainly can just have folks report when they run into one of these pages, and fix them as I come across them. However, my question is: Is there a legitimate use of the rev_actor ID being "0", or is that most assuredly an indication of a problem with the page? I could easily find/replace them, but I see about 2.5K entries that have a rev_actor ID of "0" currently. The wiki doesn't have anonymous edits, by the way - or at least I though so, I can historically see some edits just have IP addresses, as I look at entries that contain the null ID.

Further searching (and some exporting and deduping search results) has given me a list of about 1000 pages/categories etc to check.

I'm finding in many cases there are pages that work, but have one or more rev_actor IDs in their edit history. These don't show in the history unless I modify it from "0", then I can see them. I'm assuming that aside from skipping steps in the view of the history, they would only be an issue if one were to attempt to revert to them (or possibly around them), but I'm probably going to fix them in any case.

So, would doing the following work?

UPDATE `revision`

SET `rev_actor` = 1

WHERE `rev_actor` = 0

I have a template where I need to loop through multiple anonymous parameters.

{{My template
 | Cats
 | Dogs
}}

The template uses the variables in different places, so I cannot use

{{My template | Cats }}
{{My template | Dogs }}

How can I create a template that doesn't add all cases of {{{1}}}…{{{99}}}?

__NOTOC____NOEDITSECTION__<!-- 
 -->{{#vardefine:mode|{{{mode|full}}}}}<!--
 -->{{#ifeq:{{{1}}}|||{{#vardefine:1|{{{1}}}}}}}<!--
 -->{{#ifeq:{{{2}}}|||{{#vardefine:2|{{{2}}}}}}}<!-- 
 -->{{#ifeq:{{#var:mode}}|full|
== Magic ==

<ul>
{{#if:{{#var:1}}
 |Magic stuff with {{#var:1}}
}}
{{#if:{{#var:2}}
 |Magic stuff with {{#var:2}}
}}
</ul>

== Templates ==

}}
{{#if:{{#var:1}}
 | {{Other template/{{#var:1}}}}
}}

{{#if:{{#var:2}}
 | {{Other template/{{#var:2}}}}
}}

Is it only possible with Extensions like Extension:Loops and Extension:LoopFunctions?

It sounds like you'd do better with Extension:Scribunto, so you could either construct the entire template in Lua, or create a function that'd check for the param's existence (e.g. via frame:getParent()).

I wonder what extensions are recommended atm if you need comments or a forum.

On Structured Discussions I read that the project ended in November 2023 and everyone is advised to archive their discussion (what the?). Is there a follow-up? On the other hand this very support desk uses exactly this?

What should I use if I start a wiki nowaydays and want future-proof comments under article pages instead of talk pages?

• Extension:Comments looks very old.
• What will mediawiki.org use?

Structured discussion is dead, I wouldn't use it. I'd argue it is impossible to maintain for 3rd parties, with a lot of exceptions and interventions that differ from how we do things in MW.

Everything Wikimedia will eventually switch to using DiscussionTools.

Thanks. Let's hope this will be supported longer than Flow.

I have a much better feeling about discussion tools than flow. Its already been fairly well recieved by the community, where flow was controversial right out of the gate. I think it has staying power (just my 2 cents, i dont have access to a crystal ball any more than anybody else)

@Subfader: Out of general curiosity, exactly what is the problem with Comments? As the maintainer and primary developer of it since 2011, I'd be curious to know. :) Its User Interface is pretty stable and definitely not using the latest fancy design things, but it gets the job done. (I'll admit, though, that OOUI did end up lasting for several years longer than it did, but that, too, is being phased out and I'm sure that the successor will also be sunset in favor of a newer, shinier gadget, give it some time. Not using these sort of frameworks comes with the unexpected benefit of your code working regardless, if you can tolerate a somewhat "dated" looking UI.)

For the record: the initial version was written circa 2006 (!) and as it (like other social tools originating from ArmchairGM which enable new content types, like Extension:FanBoxes, Extension:LinkFilter, Extension:Video, ...) predates MediaWiki's ContentHandler system by many years, it does things in a way which isn't ideal, yet it's surprisingly functional and shockingly robust (in my biased opinion), because even major core changes aren't likely to disrupt this little extension which does things in its own way.

Some people argue that "no recent code commits" (or something similar) equals to a dead project. I largely disagree; while it may mean that the end-user should exercise a bit of caution and carefully test things etc., not all MediaWiki developers are huge fans of "move fast and break stuff", which, alas, seems to be all too common these days. Sure, it bumps up a repository's commit count a lot, but what for, and at what cost?

Now, as for Comments' actual architectural shortcomings...while the comments are associated with a(n existing wiki) page, they are indeed in other ways separate, they are not regular wiki page content or anything. So implementing a history interface (phab:T156736) or the ability to undelete previously deleted comments (phab:T127595) is very tricky, to say the least, and I for one would be very surprised (but in a positive way!) to see those implemented before Comments turns 20 years old in 2026.

Sorry, not old as outdated code but interface-wise. From the screenshots it looks like forum discussions from early 2000s.

Do you know of sites that use it which you could link or mail me?

In over 15 years I went from ArticleComments to some forum extension I forget and then Flow. Each time I was forced to throw away all old comments and posts. Not funny when you try to run a community. This timed I prefer some more LTS.

CSS wizards can probably suggest tweaks to the existing styles to make 'em more modern. I'm not enough of a CSS guru nor "modern" to know, though. :) The look hasn't bothered me and nobody's submitted a patch to improve things, so alas. As always, patches are more than welcome (but as a volunteer I cannot guarantee that they would definitely be tested/reviewed in a given time, or merged)!

Comments is one of those social tools extensions which doesn't even require SocialProfile and it's a pretty popular, basic functionality, so I'd expect plenty of sites out there to use it. (If only WikiApiary was a bit more stable...) Here's an example page on Brickipedia, the LEGO encyclopedia hosted by ShoutWiki, which uses comments.

Ah, ArticleComments...I remember that. It's been a while, eh? Out of sheer curiosity I did some digging, dug up the MW 1.20-compatible version and tried getting it working. It wasn't even that difficult, although it's still not working perfectly for me locally. The code somewhat shows its age, although admittedly its brilliance is that the "comments" are indeed just regular wiki edits on a regular wiki page. For example, the PostComment extension by wikiHow took a similar approach.

Flow was always dead-on-arrival software, but the problem was that you couldn't say it out loud that the Emperor has no clothes. I'm sorry you ended up wasting your time with it. The WMF has a rather poor track record with discussion-related extensions, although Extension:DiscussionTools is doing better than Flow ever did and it has been more positively received by the various communities on WMF web properties.

Migrations absolutely are horrible to do, and it's oftentimes just uncharted territory, and basically always so with MediaWiki extensions (e.g. "how do I migrate from extension X to Y or Z?"). There are various reasons as to why, but I think the main ones are technical complexity and a ridiculously small target audience, plus probably funding or the lack of thereof.

Predicting the future is, of course, impossible. There are many reasons why some of the social tools are kinda horrible, as I explained in my earlier response; and yet, bizarrely enough, these same reasons might also be why they're surprisingly great (in my biased opinion, of course). Comments and others precede ContentHandler by several years, and while this has rather obvious drawbacks, it also means that these extensions have stayed surprisingly stable over the years (or decades, I should say, for a lot of them will be turning 20 years old in ~2-3 years (!)) by not relying on the standard MediaWiki way to do things. Whether this is or isn't something you want is a question only you (and your community) can answer.

Also, I should point out that there are probably some other, likely even better commenting/discussion-related extensions. I just happen to be most familiar with the extension that I maintain.

After a software upgrade, MediaWiki began throwing a runtime exception on any content page. The directory mentioned in the exception did not exist. Changing $wgTempDirectory to point to a directory which does exist fixed the problem.

I just upgraded to MediaWiki 1.42.1 and now I get a RuntimeException on any content page.

The error message is as follows:

[Zo7mSqEjpbLgQB5NVrqDPwAAAgg] /wiki/index.php?title=Main_Page RuntimeException: Could not open '/home/brassgog/tmp_a5xawf/mw-GlobalIdGenerator1087-UUID-128'.

There is also a backtrace, but the spam filter won't allow me to post it.

My wiki is at https://brassgoggles.net/wiki/ Short of nuking it from orbit, how can I fix this?

Try just deleting the file /home/brassgog/tmp_a5xawf/mw-GlobalIdGenerator1087-UUID-128 . Sometimes this file gets created with wrong permissions if you run maintenance script as wrong user,but its safe to delete and that usually fixes it.

That file already doesn't exist. There is no directory /home/brassgog/tmp_a5xawf .

Is $wgTmpDirectory pointing somewhere writable by whatever user mediawiki is running as?

No. It's pointing to tmp_a5xawf . I assume you want me to set to to something that does exist?

I changed it to /home/brassgog/tmp, and that seems to have fixed the problem. Thanks.

Merhaba güvenlik konseyi almadan önce sezonluk birlik açılacak deniliyor ama 2 defa aldım ve biraz önce aldım açılmadı lütfen bunu düzeltin

You are most likely in the wrong place. This is the support forum for the Mediawiki software.

I am looking for help:

After deactivating the plugin TinyMCE (editor that seems to have become incompatible), the visual editor no longer works (MediaWiki Vers. 1.42.1, VisualEditor Vers. 12ef5b7). Clicking on the editing button scrolls to the top of the site (or simply does nothing if the top view is already shown)

Another oddity is that I can no longer open the tab "editing" (as well as any other tab) in the settings section.

I checked the log file but could not find any hint about the problem (but most probably I am not competent enough to understand what I am looking at).

The code editor still works but the editing toolbar is gone. So, editing has become quite uncomfortable.

Any advice as to how to tackle the issue is appreciated

When did you last update VisualEditor?

I used the version shipped with Mediawiki. When the issue occurred, I updated to GitHub master; it's shown as "– (12ef5b7) 09:34, 8 July 2024" on the MediaWiki version page

Can you try again after downloading VisualEditor for 1.42 specifically? What other plug-ins do you have that could cause this issue?

I changed back to Version origin/REL1_42 (a219f95 vom 11 July 2024) - still not working

These extensions are also activated:

Flex Diagrams

Translate

CodeEditor

WikiEditor

Babel

CategoryTree

Cite

EmbedVideo

ImageMap

InputBox

ParserFunctions

Poem

Scribunto

SyntaxHighlight

TemplateData

PDF Handler

CLDR

Clean Changes

MultimediaViewer

SecureLinkFixer

UniversalLanguageSelector

Have all of the extensions (including skins) been upgraded to 1.42? What happens if you disable all extensions except VisuaEditor (and anything absolutely necessary)?

deactivated all "unnecessary" plugins and VisualEditor started working again 👍 will activate the plugins one by one again and maybe find out what caused the issue... thanks for your help

The link icon is not displayed

In the timeless skin, there was originally a link svg in the upper right corner of the inserted link text, but it was not displayed

Dear Wikimedia Support Team,

content strikken

[edited by administrator]

@Srigurukripa this is a support desk for the software and not a general appeals platform. So not only are you in the WRONG place, you added your comment to a random other thread, using an alternate account from your actual account. Please don't. -- User:TheDJ

@TheDJ can you please tell me from where I can get support. can you please help by providing me support desk link of Wikipedia.

https://en.wikipedia.org/wiki/Wikipedia:Appealing_a_block but please dont hijack threads.

Hmm.. Can anybody please help me with this problem. I will be very thankful.

@Kohana240: to clarify you mean the little square with an arrow pointing out of it, icon that comes after external links. E.g. like like this ?

If your wiki is public, a link to it would be helpful.

Yes. The icon after the link is always not displayed. And the link of the website is soka.cafe. It is a Chinese website.

soka.cafe is the link

The external link icon is supposed to be located at https://soka.cafe/skins/Timeless/resources/images/ext-link.svg - however i think the short url setup is intercepting the url and treating it as an article, preventing MediaWiki from loading the icon. What url MediaWiki uses for this is controlled by $wgStylePath.

p.s. I love the customization of the Timeless skin, it is very pretty.

Thank you very much!

Profile

Pseudo-static

How should I set $wgStylePath? I try many ways to solve this problem. I found if I set the profile of the website, the svg displays, but the File, Mediawiki pages can't load. Maybe because of my terrible skill. But if I set the pseudo-static of the website, all pages can load corrctly. Only the link's svg can't display.