I want to create a wiki using MediaWiki.

I am looking for a simplified way to create a wiki using MediaWiki. UnnamedChannel079 (talk) 08:02, 7 July 2025 (UTC)

@UnnamedChannel079: You might be interested in something like Miraheze; a wikifarm like that is probably the simplest. But if you want to install your own wiki, start at Manual:Installing MediaWiki and then ask specific questions here with the things you have trouble with. Sam Wilson 08:32, 7 July 2025 (UTC)

I tried accessing Miraheze but the link doesn't work. UnnamedChannel079 (talk) 08:33, 7 July 2025 (UTC)

@UnnamedChannel079: Can you be more specific (e.g. which link, and what happened)? Sam Wilson 08:36, 7 July 2025 (UTC)

I tried accessing this link: https://miraheze.org/

It doesn't work at all. UnnamedChannel079 (talk) 08:37, 7 July 2025 (UTC)

That link and the Meta site load fine where I am. Is a local firewall or similar ISP constraint blocking your access, for instance? --Slgrandson (talk) 03:32, 14 July 2025 (UTC)

It no longer blocks my access. UnnamedChannel079 (talk) 04:37, 14 July 2025 (UTC)

I can code on FANDOM but a mainstream coding language is way too complex for me. That's why i need a simplified way to create a wiki using MediaWiki. UnnamedChannel079 (talk) 08:39, 7 July 2025 (UTC)

Check logged user from Index.php

hi,

on MW 1.35 I was using $wgUser->isLoggedIn() on index.php to check if the user was logged.

The method isnt available on MW 1.43 but I still need a way to check it and redirect in some cases.

is there an easy way to do this?

thx for help Valeriocipriani (talk) 11:32, 8 July 2025 (UTC)

This rings a bell. This code extract might help, though I'm checking for "sysop" here:

:		# new code based on https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/EditAccount/+/0f3d1420214a68e4eed5151f4600cf9c68b05661/includes/specials/SpecialCloseAccount.php
:		
:		$user = $this->getUser();
:		$effectiveGroups = MediaWikiServices::getInstance()
:			->getUserGroupManager()
:			->getUserEffectiveGroups( $user );
:		$isSysop = in_array( 'sysop', $effectiveGroups );
:		if ( $isSysop ) {
:			...
:

Jonathan3 (talk) 12:36, 9 July 2025 (UTC)

Cannot edit a page after editing and saving it.

Hi!

We have recently upgraded our MediaWiki to 1.43.1.

When we try to edit a page that has been edited and saved a few seconds ago, the blue loading bar does not finish. It only happens with the Visual Editor of MediaWiki. We have to reload the window to be able to edit.

We have enabled the log file, and we detected several [silenced-error] messages like the following one:

[silenced-error] [658fe352037f46d8bb8c4c6e] /wiki/index.php?title=Wiki   PHP Warning: filemtime(): stat failed for /var/www/html/wiki/extensions/VisualEditor/editcheck/i18n/api/es.json
#0 [internal function]: MWExceptionHandler::handleError()
#1 /var/www/html/wiki/includes/language/dependency/FileDependency.php(75): filemtime()
#2 /var/www/html/wiki/includes/language/LocalisationCache.php(581): FileDependency->isExpired()
#3 /var/www/html/wiki/includes/language/LocalisationCache.php(612): LocalisationCache->isExpired()
#4 /var/www/html/wiki/includes/language/LocalisationCache.php(479): LocalisationCache->initLanguage()
#5 /var/www/html/wiki/includes/language/LocalisationCache.php(381): LocalisationCache->loadItem()
#6 /var/www/html/wiki/includes/language/Language.php(433): LocalisationCache->getItem()
#7 /var/www/html/wiki/includes/language/Language.php(510): MediaWiki\Language\Language->getNamespaces()
#8 /var/www/html/wiki/includes/title/Title.php(2968): MediaWiki\Language\Language->getNsText()
#9 /var/www/html/wiki/extensions/CategoryLockdown/CategoryLockdown.php(28): MediaWiki\Title\Title->getParentCategories()
#10 /var/www/html/wiki/includes/HookContainer/HookContainer.php(159): CategoryLockdown::onGetUserPermissionsErrors()
#11 /var/www/html/wiki/includes/HookContainer/HookRunner.php(2029): MediaWiki\HookContainer\HookContainer->run()
#12 /var/www/html/wiki/includes/Permissions/PermissionManager.php(553): MediaWiki\HookContainer\HookRunner->onGetUserPermissionsErrors()
#13 /var/www/html/wiki/includes/Permissions/PermissionManager.php(507): MediaWiki\Permissions\PermissionManager->checkPermissionHooks()
#14 /var/www/html/wiki/includes/Permissions/UserAuthority.php(373): MediaWiki\Permissions\PermissionManager->getPermissionStatus()
#15 /var/www/html/wiki/includes/Permissions/UserAuthority.php(237): MediaWiki\Permissions\UserAuthority->internalCan()
#16 /var/www/html/wiki/includes/user/User.php(3318): MediaWiki\Permissions\UserAuthority->authorizeRead()
#17 /var/www/html/wiki/includes/actions/ActionEntryPoint.php(405): MediaWiki\User\User->authorizeRead()
#18 /var/www/html/wiki/includes/actions/ActionEntryPoint.php(146): MediaWiki\Actions\ActionEntryPoint->performRequest()
#19 /var/www/html/wiki/includes/MediaWikiEntryPoint.php(200): MediaWiki\Actions\ActionEntryPoint->execute()
#20 /var/www/html/wiki/index.php(58): MediaWiki\MediaWikiEntryPoint->run()
#21 {main}

Thanks! Diegxalv (talk) 11:56, 8 July 2025 (UTC)

Hi again!

I have just performed a clean install of MediaWiki 1.43.3 and this problem persists. I can edit a page, but when I try to edit it again (without reloading the browser tab) the blue loading bar does not finish.

I have tried different browsers and I deleted the browsing data.

Is anyone else experiencing the same problem? I'm confused. Thanks Diegxalv (talk) 19:24, 8 July 2025 (UTC)

Maybe a shot in the dark but does your "clean install" imply not using CategoryLockdown? Assuming its page here is up to date it was last updated in 2021 which is a long time ago especially for an extension that intends to provide functionality that greatly differs from the way MediaWiki works. Tactica (talk) 15:45, 13 July 2025 (UTC)

Hi!

This silent error message was detected in our updated MediaWiki instance, but is the same in a clean install (without the CategoryLockdown extension).

We restored a backup, we upgraded to MediaWiki 1.39.13 (legacy long-term support release of MediaWiki) and this problem disappeared.

Thanks for your help!! Diegxalv (talk) 13:08, 16 July 2025 (UTC)

Add email address to account without password?

So, I have the following issue: I am logged in, but when creating my account I did not provide an email address for password recovery. I wanted to add that email address now, but to do so, I need a password, which I don't recall (I probably used the pass the system recommended to me). Is there any way to set an email address without your password? BlaUser234 (talk) 14:57, 8 July 2025 (UTC)

@BlaUser234: If you used a system-generated password it should've asked you to change it when you used it to log in. If you really can't remember your password you might be a bit stuck. If you can somehow prove who you are to whoever runs your wiki, they can reset your password for you. Sam Wilson 21:23, 8 July 2025 (UTC)

I can code on FANDOM but a mainstream coding language is way too complex for me.

I can't access Miraheze, especially this link: https://miraheze.org/

The link doesn't work. That's why i am looking for a simplified way to create a wiki using Media Wiki. UnnamedChannel079 (talk) 17:31, 8 July 2025 (UTC)

The website works so maybe they've blocked your IP address. (Similarly, I can't post here without disabling my VPN.) Jonathan3 (talk) 12:39, 9 July 2025 (UTC)

The website works for me now. UnnamedChannel079 (talk) 13:56, 9 July 2025 (UTC)

Error Class "Title" not found with Flex Diagrams extension

Product Version

MediaWiki 1.44.0

PHP 8.3.6 (apache2handler)

ICU 74.2

MariaDB 10.11.13-MariaDB-0ubuntu0.24.04.1

wikidiff2 1.14.1

LDAPAuthentication2 3.0.1

LDAPProvider 3.0.1

PluggableAuth 7.5.0

Flex Diagrams 0.8 07:35, 30 June 2025

After an update from 1.43.0 to 1.44.0 adding my diagram into new article we get an error: Error: Class "Title" not found.

If I call my diagram for editing all works fine.

Any Ideas? ~2025-17160-7 (talk) 09:39, 11 July 2025 (UTC)

Pinging @Yaron Koren. FWIW I'm having the same problem with Extension:Chartie, so far without a reply from the developer. Tactica (talk) 15:27, 13 July 2025 (UTC)

Sorry about that! I had mostly fixed handling for MW 1.44+ in Flex Diagrams, but somehow had missed one line, in the handling of the #display_diagram function. I just added a fix, so if you get the latest Flex Diagrams code, it should work correctly. Yaron Koren (talk) 14:19, 14 July 2025 (UTC)

turning off self-link bolding

Help:Self link is unclear, is this css setting supposed to work to turn off self-link bolding or does it only apply to underlining? Is there a way to turn off bolding? I've put it on my css and it doesn't seem to work. ~2025-17606-3 (talk) 01:33, 12 July 2025 (UTC)

Apparently I can't copy and paste it here, but I mean the css snippet at the very beginning of Help:Self link ~2025-17606-3 (talk) 01:34, 12 July 2025 (UTC)

@~2025-17606-3: That only removes the underlining. For bold you could do something like:

.mw-selflink { font-weight: normal !important; }

Sam Wilson 03:23, 12 July 2025 (UTC)

Thank you, Sam! That works! ~2025-17606-3 (talk) 07:52, 12 July 2025 (UTC)

12th. July PAWS not functioning

Today, 12th. July 2025 the tool PAWS (Pywikibot) doesn't run: https://hub-paws.wmcloud.org/. Can you check it? Thanks. Leonprimer (talk) 16:54, 12 July 2025 (UTC)

@Leonprimer Please see the top of that page where to report issues in the right place - thanks. Malyacko (talk) 14:24, 13 July 2025 (UTC)

Uploading files under redirecting name

Suppose I have a file that I've moved from Image (Version 1) to Image (Version 2) as a bureaucrat on a third-party wiki, and have decided to make a new upload under the leftover redirect Image (Version 1). Before I conduct this action on Miraheze, is it actually safe to do so? --Slgrandson (talk) 19:07, 14 July 2025 (UTC)

Replacing the redirect with a new upload will simply make it stop working as a redirect, so pages linking there will use the new upload instead of being redirected to version 2 of the image, that's all. Tactica (talk) 00:01, 16 July 2025 (UTC)

I'm not sure it will actually work that way. A reupload doesn't modify the file description page when it already exists, and if it contains a redirect, it will still act as a redirect. You'll have to manually edit the rediect page, blanking it or replacing it with a proper description. Ciencia Al Poder (talk) 13:42, 18 July 2025 (UTC)

EMail doesn't seem to be sending in 1.43.0

I have a server running mediawiki 1.43.0 that doesn't seem to be sending mails. I'm using SMTP to send it and have "$wgEnableEmail = true;" in the LocalSettings.php. Is there a log of what it is trying to do? I don't get any errors when running other than "Warning: Undefined global variable $wgEmailNotificationsMailerConf in /var/www/html/extensions/EmailNotifications/includes/EmailNotifications.php on line 86" when I have the debug line listed above enabled.

Any ideas or tips on where else I can look? MarisaG2025 (talk) 07:48, 15 July 2025 (UTC)

I'm not sure, but it sounds like you are using Extension:EmailNotifications ? That specific extension seems to use a different mail configuration system than the core mediawiki code. —TheDJ (Not WMF) (talk • contribs) 11:06, 17 July 2025 (UTC)

Updating to 1.44: Skin errors

After upgrading to MediaWiki 1.44, I’m seeing a fatal error on all pages:

Fatal Error After Upgrading to MediaWiki 1.44 — `array_column(): Argument #1 ($array) must be of type array, string given - seems to be traced back to the deprecated sidebar functions (shouldn't be causing an error in 1.44 though?)

TypeError: array_column(): Argument #1 ($array) must be of type array, string given

Backtrace:

from /includes/skins/Skin.php(1548)

#0 /includes/skins/Skin.php(1548): array_column()

#1 /includes/skins/Skin.php(1639): MediaWiki\Skin\Skin->appendSpecialPagesLinkIfAbsent()

#2 /includes/skins/SkinTemplate.php(615): MediaWiki\Skin\Skin->buildSidebar()

#3 /includes/skins/SkinTemplate.php(194): MediaWiki\Skin\SkinTemplate->getPortletsTemplateData()

#4 /includes/skins/SkinMustache.php(131): MediaWiki\Skin\SkinTemplate->getTemplateData()

#5 /includes/SkinVectorLegacy.php(173): MediaWiki\Skin\SkinMustache->getTemplateData()

#6 /includes/skins/SkinMustache.php(93): MediaWiki\Skins\Vector\SkinVectorLegacy->getTemplateData()

#7 /includes/skins/SkinTemplate.php(187): MediaWiki\Skin\SkinMustache->generateHTML()

#8 /includes/skins/Skin.php(682): MediaWiki\Skin\SkinTemplate->outputPage()

#9 /includes/Output/OutputPage.php(3286): MediaWiki\Skin\Skin->outputPageFinal()

#10 /includes/actions/ActionEntryPoint.php(160): MediaWiki\Output\OutputPage->output()

#11 /includes/MediaWikiEntryPoint.php(202): MediaWiki\Actions\ActionEntryPoint->execute()

#12 /index.php(58): MediaWiki\MediaWikiEntryPoint->run()

Ive also tried disabling all extensions and trying all other skins - showing the same error on all.

PenguinBegins (talk) 22:05, 15 July 2025 (UTC)

Did you upgrade your skins while upgrading to 1.44? If you only upgraded MediaWiki itself but are still using pre-1.44 versions of skins, that might be your problem. Tactica (talk) 00:29, 16 July 2025 (UTC)

I think someone forgot the remove a line from Skin.php (and I just downloaded the 1.44.0 zip)

-

Line 1541: private function appendSpecialPagesLinkIfAbsent() {

Line 1639: $this->appendSpecialPagesLinkIfAbsent();

-

The function comments for appendSpecialPagesLinkIfAbsent() says deprecated in 1.44 but in line 1639 is it being used. This does puzzle me greatly. I have not tried removing it yet (as I'm using the docker image, need to expose the Skins directory otherwise I can't edit it) but I'm sure once you comment out line 1639 the error is gone

Regards

Sjoerd Sjoerd72 (talk) 07:13, 16 July 2025 (UTC)

-

I can confirm that the "fix" I mentioned works.. - just comment line 1639 in Skins.php and you are good. add // in front of $this->appendSpecialPagesLinkIfAbsent();

Regards

Sjoerd Sjoerd72 (talk) 07:25, 16 July 2025 (UTC)

A deprecation is a deprecation, it is not a removal. It is specifically there to motivate people to fix the code so that the function can eventually be removed safely. Which skin are you using that is calling this path ? —TheDJ (Not WMF) (talk • contribs) 10:01, 17 July 2025 (UTC)

It seems this code was reworked as well as deprecated, so I suspect a compatibility issue with certain skins. —TheDJ (Not WMF) (talk • contribs) 10:54, 17 July 2025 (UTC)

Please read Manual:Interface/Sidebar#Deprecation warning for Skin::appendSpecialPagesLinkIfAbsent() for information on why that function is there. That said I don't know what the array issue mentioned by PenguinBegins is caused by. Aaron Liu (talk) 01:17, 18 July 2025 (UTC)

Using new Vector's heading menu on Foreground/Chameleon skins

I dislike the new Vector skin generally, but really like the menu on the left that lets you keep track of which heading you're at.

Can this be used on other skins? Jonathan3 (talk) 13:26, 16 July 2025 (UTC)

@Jonathan3 It is a skin feature, so no not without development work. —TheDJ (Not WMF) (talk • contribs) 09:58, 17 July 2025 (UTC)

Thank you. I've now seen Extension:StickyTOC and its comment: "This extension has been archived. Chameleon skin (>4.4) supports this natively. It was archived per T374778." I haven't used Chameleon (only Foreground) but looked at it briefly and didn't see any mention of "sticky" TOCs. But I'll look into it more! Jonathan3 (talk) 13:37, 17 July 2025 (UTC)

Help upgrading software to newest version

Hi there!

Our current wiki is running on software version 1.35.14 and I dont even know where to begin with upgrading to new versions - this has been a job sort of neglected so want to make sure I do it right and dont break anything.

Thank you :) Erinwake (talk) 10:26, 17 July 2025 (UTC)

Upgrade to 1.39, then to 1.43, then 1.44. General instructions are in Manual:Upgrading. Tactica (talk) 12:49, 17 July 2025 (UTC)

Autologin not working since 1.35 -> 1.43 Update

Hi everyone,

We recently upgraded our MediaWiki instance from version 1.35 to 1.43, and since then, our LDAP autologon setup has stopped working. Previously, users were automatically logged in via LDAP without needing to manually enter credentials. Now, they’re redirected to the login page and must log in manually. Logging in manually via domain credentials still works.

Our Setup:
MediaWiki 1.43

LDAP Stack:

wfLoadExtension( 'PluggableAuth' );
wfLoadExtension( 'LDAPProvider' ); 
wfLoadExtension( 'LDAPAuthentication2' );
wfLoadExtension( 'LDAPAuthorization' );
wfLoadExtension( 'LDAPGroups' );
wfLoadExtension( 'LDAPUserInfo' );
wfLoadExtension( 'Auth_remoteuser' );

Configuration:
# PluggableAuth
$wgPluggableAuth_Config['Log In (do)'] = [
    'plugin' => 'LDAPAuthentication2',
    'data' => [ 'domain' => 'do.re.me-so.net' ]
];

$wgPluggableAuth_EnableAutoLogin = true;
$wgPluggableAuth_EnableLocalLogin = false;

# LDAP Provider
$LDAPProviderDomainConfigs = "$IP/provider/ldap.json";
$LDAPProviderDefaultDomain = "do.re.me-so.net";

# LDAPAuthentication2
$LDAPAuthentication2AllowLocalLogin = true;
$LDAPAuthentication2UsernameNormalizer = 'strtolower';

# LDAPAuthorization
$LDAPAuthorizationAutoAuthUsernameNormalizer = 'strtolower';
$LDAPAuthorizationAutoAuthRemoteUserStringParser = 'domain-backslash-username';

#AuthRemoteUser
$wgAuthRemoteuserUserNameReplaceFilter = [
	'^do\\' => 'do.re.me-so.net\\'
];
$wgAuthRemoteuserUserName = [
     $_SERVER[ 'REMOTE_USER' ]
];

But I can see in the logfiles:
mediawiki: MediaWiki\Extension\LDAPAuthorization\Hook\AuthRemoteuserFilterUserName: Check authorization for user 'DO\aUser'.
mediawiki: Resolved to username 'aUser' and domain 'DO'
mediawiki: Could not check login requirements for DO\aUser
mediawiki: No configuration available for domain 'do'!

If I shorten the domain from "do.re.me-so.net" to just "do" in my ldap.json I end up in a loop, but I can see in the logfiles that it successfully matches the user and domain, but does it endlessly.

Autologon worked perfectly in 1.35

All the extensions are updated to match our 1.43 LTS. Slk-fsk (talk) 13:43, 17 July 2025 (UTC)

Looks like Extension:Auth_remoteuser may have some issues with MediaWiki 1.43. I recently had a similar issue (probably not the same), where there was a "memory exhaused" error caused by a deadloop, when $wgAuthRemoteuserAllowUserSwitch was set to false (default).

In your particular case, I believe $wgAuthRemoteuserUserNameReplaceFilter is not properly executed before Extension:LDAPAuthorization tries to split domain and username in AuthRemoteuserFilterUserName hook. Renaming your domain in the configuration to do seems reasonable. I'd recommend checking why the loop happens. Have you enabled the log channel for Extension:Auth_remoteuser and MediaWiki's session channel?

Hint: there is also the new extension Extension:AuthRemoteUser since last year. I haven't used it yet, but it may be worth looking into it. Osnard (talk) 08:23, 22 July 2025 (UTC)

Intl extension in MW 1.43

Hello,

I have been trying to install Mediawiki 1.43 on a Windows 10 desktop. I have been running into the error below:

This is one of the extensions required by Mediawiki 1.43, as shown to the right:

* ctype; * dom; * fileinfo; * iconv; * intl; * json; * mbstring; * xml

However, I am confused, as my research says that the intl extension has been included in the download version of Mediawiki since 2015. Why is it not included in the installation?

BTW, I am using XAMPP 8.2.12 as my server. Would that have any influence?

Dave at david.axtell@gmail.com Dave Axtell (talk) 14:53, 17 July 2025 (UTC)

"Why is it not included in the installation?"

That's a question for the XAMPP maintainers. With a common PHP distribution, you would just enable the extension in php.ini. Tactica (talk) 12:26, 18 July 2025 (UTC)

intl is a php extension, not a Mediawiki extension. It can't be included by Mediawiki. It needs to be enabled in php.ini. Ciencia Al Poder (talk) 13:39, 18 July 2025 (UTC)

How to open inputbox in new tab?

My question about Extension:InputBox. I have this input box to create in new page:

I want to open the create page in a new Tab when click on the button, like target="_blank". How do I do this?

This is my old question. Currently the extention don't support these feature. Is there any way to do this using common.js ? Nimon didarul (talk) 12:42, 18 July 2025 (UTC)

@Nimon didarul: You could do something like:

mw.hook( 'wikipage.content' ).add( () => {
    document.querySelectorAll( '.mw-inputbox-form, .mw-inputbox-form-inline' ).forEach( ( e ) => {
        e.target = '_blank';
    } );
} );

Change that selector to .createbox.mw-inputbox-form if you only want to do page-creation inputboxen. Sam Wilson 08:08, 19 July 2025 (UTC)

@Samwilson Thanks. Its working.👍 Nimon didarul (talk) 08:32, 19 July 2025 (UTC)

Vector-2022 skin is not loading on Chrome

Works fine with edge. I tried the original vector skin and had the same problem.

From the Chrome developer console I am seeing the following errors:

load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector:1

Uncaught SyntaxError: Unexpected token '<' (at load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector:1:1)

Refused to apply style from

'...//localhost/mediawiki/load.php?lang=en&modules=skins.vector.styles.legacy&only=styles&skin=vector' because its MIME type ('') is not a supported stylesheet MIME type, and strict MIME checking is enabled. TerryMcP (talk) 13:11, 18 July 2025 (UTC)

Open the load.php URL directly or on a new tab. It may contain an actual error message, useful to diagnose the issue. Ciencia Al Poder (talk) 13:37, 18 July 2025 (UTC)

Results from opening load.php

<!DOCTYPE html><center><b>Terry's Development Wiki</b></center><br />/* This file is the Web entry point for MediaWiki's ResourceLoader:

   <xxxx://www.mediawiki.org/wiki/ResourceLoader>. In this request,

   no modules were requested. Max made me put this here. */ TerryMcP (talk) 14:08, 18 July 2025 (UTC)

http://myhost/mediawiki/load.php?lang=en&modules=skins.vector.styles.legacy&only=styles&skin=vector

This link opens some html. no errors TerryMcP (talk) 15:19, 18 July 2025 (UTC)

I ran 'composer update' from my mediawiki folder and this didn't help TerryMcP (talk) 14:39, 18 July 2025 (UTC)

Try to open the exact URL that the console shows it's returning an unsupported stylesheet MIME type Ciencia Al Poder (talk) 14:53, 18 July 2025 (UTC)

Well, they absoultely shouldn't open html. They should open css or js. Check if the HTML is coming from your host or generated by any other application. Ciencia Al Poder (talk) 15:40, 18 July 2025 (UTC)

Obligatory security rules that users cannot decide

Hello, as I couldn't get an answer on TR Wiki, is there a way for me to disable email verification? It seems that this is a new tool, but I seriously don't want to be obliged to log in my e mail adress for a code every single time I try to log in my Wiki account. I really don't care if a log in to my account from Planet Mars is detected, I don't want obligatory security tools. Pardon my language but I'm already tired of "you cannot use an old password, you need to pass this laser trap for verification" types of security rules in various websites and apps. I'd hate if Wikipedia is coming to that point. Should I create a phabricator topic? I need help. Tün (talk) 10:18, 19 July 2025 (UTC)

This very page is for general questions about MediaWiki configuration and setup. Phabricator is for bug reports and feature requests, not for topics. If you want to discuss technical aspects of Wikimedia wikis, see https://meta.wikimedia.org/wiki/Tech - thanks. Malyacko (talk) 20:32, 19 July 2025 (UTC)

Distinguishing Visible Page Links from Template Links in Wikipedia Data

Hello,

Is there a way, using the Wikipedia database (such as dumps or APIs), to differentiate between links that are part of the main visible content of a Wikipedia page and those that only appear in navigation templates (like the "V.T.E" boxes at the bottom), without needing to parse the page's HTML or DOM?

Thank you! ~2025-23955-6 (talk) 20:14, 21 July 2025 (UTC)

@~2025-23955-6 No, there is not. A link is a link and content does not have a logical subdivision of itself at the database level to distinguish one part of the content from the other. Technically I guess you could take a dump, find all Navboxes, find links on those pages, and substract those from the links in pages that include said Navboxes, but that would also remove any links in the main content that happen to also be inside the Navboxes. —TheDJ (Not WMF) (talk • contribs) 08:05, 22 July 2025 (UTC)

Thank you for the response. I assume these navigation links were primarily designed with bots and crawlers in mind, as it seems unlikely that human users commonly navigate through them.

Would you recommend processing the enwiki-latest-pages-articles.xml.bz2 dump (which contains the latest content) to extract and map navigation links for each page, then comparing that against the mappings obtained from the page, pagelinks, and linktarget SQL dumps (which I’ve already processed), in order to identify and filter out such links as outliers?

This approach seems feasible, but I’m hoping there might be a more efficient or elegant solution that someone else has already explored. ~2025-24445-5 (talk) 19:24, 22 July 2025 (UTC)