Project:Support desk

I recently updated my Mediawiki instance to v1.42, however I am now getting the error :

Deprecated: Use of InterwikiLoadPrefix hook (used in MediaWiki\Extension\Interwiki\Hooks::onInterwikiLoadPrefix) was deprecated in MediaWiki 1.36. [Called from MediaWiki\HookContainer\HookContainer::register in /var/www/vhosts/domain/mediawiki_1_42/w/includes/HookContainer/HookContainer.php at line 436] in /var/www/vhosts/domain/mediawiki_1_42/w/includes/debug/MWDebug.php on line 379.

And yet I have interwiki.php defined in the cache folder, and I'm requiring it in LocalSettings.php:

$wgInterwikiCache = require "$IP/cache/interwiki.php";

Has something else changed in these regards in MW 1.42? I shouldn't get this error when the $wgInterwikiCache variable is defined?

do you have the correct version of Interwiki extension for your version of mediawiki?

I have the version that is bundled with Mediawiki. extension.json says v. 3.2.

I install fresh Mediawiki instances by downloading the tar.gz and extracting:

wget https://releases.wikimedia.org/mediawiki/1.42/mediawiki-1.42.1.tar.gz

just for good measure, I tried removing the Interwiki folder from extensions, and git cloning the extension from gerrit from branch REL1_42. Then I ran maintenance update scripts and composer up for good measure, but no change, still getting the same error.

I might also add that I had it working on MW 1.41 before upgrading to MW 1.42, there were no errors, $wgInterwikiCache was requiring the exact same "$IP/cache/interwiki.php".

Hi,

On this Wiki there used to be several links for years. They are still in the code, but for reason have disappeared of the actual pages. Any idea how I can fix this?

https://wiki.musicmeter.nl/index.php/Verborgen_functionaliteiten

Looks fine to me

Sorry, but I only see them in the code and not on the actual page. This goes for all the pages on https://wiki.musicmeter.nl.

Not sure how to send a screenshot here.

В Микронации Вики отсутствует графа сестемы авторизация , точнее нет графы регистрации но только есть просто вход. Пожалуста доделуйте сайт Микронации Вики чтоб я смог туда регистрироватся.

micronation wiki is not operated by us. You would have to direct this question to the site operator.

Wiki micronation не поддерживается нами. Этот вопрос вам придется задать оператору сайта.

I think you should following these steps:

*Check for a "Sign Up" or "Register" Link:

*Look in the Footer or Header:

*Contact Site Administrators:

*Check the Help or FAQ Section:

*Try Logging In with Common User Accounts:

*Search Online Forums or Communities:

Hi Team, Good day We need your assistance for the below , could you please review and assist.

We have a scenario to migrate media wiki to 1.15 to 1.42.. Old server is CentOS7 - as it has EOL , we are planning to migrate to RHEL8. but we are not able to migrate , following this page https://www.mediawiki.org/wiki/Manual:Restoring_a_wiki_from_backup

1. Re-create the database, user and permissions (Created ) 2. Import the database backup (Success - same tables are visible) 3. Import the MediaWiki files (Copied as it is from old server) 4. Check the configuration file (Validated)

the below errors we are able to see , while running " php update.php " PHP Deprecated: DefaultSettings.php is deprecated and will be removed. Use MainConfigSchema::listDefaultValues() or MainConfigSchema::getDefaultValue() instead. [Called from require_once in /var/www/html/mediawiki-1.42.1/LocalSettings.php at line 25] in /var/www/html/mediawiki-1.42.1/includes/debug/MWDebug.php on line 379 PHP Parse error: syntax error, unexpected token "new" in /var/www/html/mediawiki-1.42.1/extensions/calendar/Calendar.php on line 77

Upgrade existing installation

Updating category collations... Selecting next 100 pages from cl_from = 0... An error occurred: Error 1054: Unknown column 'cl_sortkey_prefix' in 'field list' Function: UpdateCollation::execute Query: SELECT cl_from,cl_to,cl_sortkey_prefix,cl_collation,cl_sortkey,cl_type+0 AS "cl_type_numeric",cl_timestamp,page_namespace,page_title FROM categorylinks STRAIGHT_JOIN page ON ((cl_from = page_id)) WHERE (cl_collation != 'uppercase') AND ((cl_from >= 0 AND cl_from < 100)) ORDER BY cl_from

1.15 is too old to do a direct upgrade, you have to do it in steps. See upgrading

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!

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?

I cloned chessBrowser repo in extensions directory and updated localSettings.php. how could i run its development server and verify the changes made?

Hi!

Is the extension listed on "Special:Version" of your wiki? If so, you should be able to test the functionality by putting any of the examples listed on Extension:ChessBrowser/Test_games to one out your wiki's pages.

hey i made the necessary changes as provided by T363533. What should i do next? I'm new using gerrit and phabricator.

Task : https://phabricator.wikimedia.org/T363533

Also this was docstring task but i'm still not able to figure out how to test extensions.@Osnard

I’m not experienced in MediaWiki commands and stuff, I cannot figure out how to hide redirects from search bar results. I want it to be like Wikipedia where redirects are hidden. I tried putting __NOINDEX__in a page but it didn’t work. I’m using version 1.41.1

Hello

We got this error after automatic upgrade to v 1.39:

Deprecated: Caller from MediaWiki\User\UserOptionsManager::loadOptionsFromDb ignored an error originally raised from MediaWiki\Revision\RevisionStore::fetchRevisionRowFromConds: [1054] Unknown column 'rev_actor' in 'field list' in /path/to/rootdir/includes/debug/MWDebug.php on line 381

MediaWiki internal error.

Original exception: [Y4sC-agvWrsHVKR4EV9SnQABNxQ] /Esileht Wikimedia\Rdbms\DBQueryError: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading or after adding a new extension?

Error 1054: Unknown column 'rev_actor' in 'field list'

Function: MediaWiki\Revision\RevisionStore::fetchRevisionRowFromConds

Query: SELECT rev_id,rev_page,rev_timestamp,rev_minor_edit,rev_deleted,rev_len,rev_parent_id,rev_sha1,comment_rev_comment.comment_text AS `rev_comment_text`,comment_rev_comment.comment_data AS `rev_comment_data`,comment_rev_comment.comment_id AS `rev_comment_cid`,actor_rev_user.actor_user AS `rev_user`,actor_rev_user.actor_name AS `rev_user_text`,rev_actor,page_namespace,page_title,page_id,page_latest,page_is_redirect,page_len,user_name FROM `zudn_revision` JOIN `zudn_revision_comment_temp` `temp_rev_comment` ON ((temp_rev_comment.revcomment_rev = rev_id)) JOIN `zudn_comment` `comment_rev_comment` ON ((comment_rev_comment.comment_id = temp_rev_comment.revcomment_comment_id)) JOIN `zudn_actor` `actor_rev_user` ON ((actor_rev_user.actor_id = rev_actor)) JOIN `zudn_page` ON ((page_id = rev_page)) LEFT JOIN `zudn_user` ON ((actor_rev_user.actor_user != 0) AND (user_id = actor_rev_user.actor_user)) WHERE rev_id = 22052 LIMIT 1

Can we do something before the update to fix this issue or is it caused by the installer (Installatron in this case)?

Would manual update work?

Thank you

Gustav

Did you run update.php? This is the type of error you would get if update.php was not run. (Although you would probably have to be going from a version earlier than 1.38)

Note: mediawiki does not have a builtin auto upgrade feature.

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.

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.

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.

Dear Community,

I hope this message finds you well. I am facing a challenge in setting up LDAP login in my MediaWiki version 1.41 and am in need of urgent assistance.

Specifically, I am looking for someone experienced in configuring and setting up LDAP login in MediaWiki. I would greatly appreciate any help or guidance you can provide.

Your assistance would be greatly appreciated. Please do not hesitate to reach out if you have the necessary expertise or know someone who might be able to assist me.

Thank you in advance!

Have you checked out documentation at LDAP hub? If you get stuck, I can probably support you.

Dear Support Team,

I hope this message reaches you safely. I would like to inform you that I have looked at the instructions in LDAP HUB. Therefore, I would like to use the following configuration to manage LDAP authentication and authorization:

Extension: LDAPProvider

Extension: LDAPAuthorization

I use the configuration in LocalSettings.php.

$LDAPProviderDomainConfigProvider = function() {

    $config = [

        "akg.lan" => [

            "connection" => [

                "server" => "ldap://akg-dc-01",

                "user" => "CN=Administrator,CN=Users,DC=AKG,DC=LAN",

                "pass" => "testtestt",

                "basedn" => "DC=AKG,DC=LAN",

                "groupbasedn" => "DC=AKG,DC=LAN",

                "userbasedn" => "DC=AKG,DC=LAN",

                "searchattribute" => "samaccountname",

                "searchstring" => "Administrator@akg.lan", // Replace USER-NAME with actual username

                "usernameattribute" => "samaccountname",

                "realnameattribute" => "cn",

                "emailattribute" => "mail",

                "grouprequest" => "MediaWiki\\Extension\\LDAPProvider\\UserGroupsRequest\\GroupMember::factory"

            ],

            "authorization" => [

                "rules" => [

                    "groups" => [

                        "required" => [ "CN=Mediawiki,OU=Groups,DC=AKG,DC=LAN" ] // Adjust group DN as needed

                    ]

                ]

            ],

            "groupsync" => [

                "mechanism" => "mappedgroups",

                "mapping" => [

                    "sysop" => "CN=Projektmanagement,OU=Groups,DC=AKG,DC=LAN", // Map sysop and bureaucrat groups

                    "bureaucrat" => "CN=Mediawiki,OU=Groups,DC=AKG,DC=LAN"

                ]

            ],

            "userinfo" => [

                "email" => "mail",

                "realname" => "cn",

                // Add additional user info mappings as needed

            ]

        ]

    ];

    return new \MediaWiki\Extension\LDAPProvider\DomainConfigProvider\InlinePHPArray($config);

};

Then i run this comands:

php maintenance/update.php --quick

php maintenance/rebuildLocalisationCache.php

Then when i Try to login on mediawiki i see this:

"The credentials provided could not be verified."

Could you please provide guidance or assistance regarding the setup of LDAPProvider and LDAPAuthorization for this purpose? Any documentation or step-by-step instructions you can share would be greatly appreciated.

Thank you in advance for your prompt attention to this matter. I look forward to your response.

Best regards,

Please wire debug logs and then try to use the CLI script php extensions/LDAPProvider/maintenance/CheckLogin.php --domain=akg.lan --username=<someusername> to test the login. Share a redacted version (may contain sensitive data) of the debug logs here.