Project:Support desk

Welcome to MediaWiki.org's Support desk, where you can ask MediaWiki questions!

Read in your language

There are also other places where to ask :

• IRC
• mailing lists
• Wikimedia Developer Support
• Q&A
• mwusers (unofficial forum)

Before you post

• Make sure you have read our fundamental introduction.
• Please carefully check our FAQ and Errors and Symptoms pages.
• Project:Current issues is where you should discuss issues about the mediawiki.org website itself.
• If your question is about a specific function, please read the relevant technical manual , end-user help or extension page and consider asking on its talk page .
• Test wiki editing at the Project:Sandbox.

Post a new question

1. To help us answer your questions, please always indicate which versions you are using (reported by your wiki's Special:Version page):
   • MediaWiki
   • PHP
   • Database
2. Please include the URL of your wiki unless you absolutely can't. It's often a lot easier for us to identify the source of the problem if we can look for ourselves.
3. To start a new thread, click "Start a new topic".

Previous page history was archived for backup purposes at Project:Support_desk/old on 2015-07-30.

I started to use Extension:CodeEditor the other day, and it works well for CSS and JS pages.

Today I read about Extension:CodeMirror (which does similar for wikitext) on User:Jeroen De Dauw's website. I think this will send him a ping: @Jeroen De Dauw:

Of course I'll install CodeMirror and give it a go, but does anyone know already whether these two extensions work well together? Thanks.

Now I could not make login after I inputted correct 2FA numbers.

[XlKqEmLnWDD73fb2L9iWcwAAAAE] /index.php?title=%ED%8A%B9%EC%88%98:%EB%A1%9C%EA%B7%B8%EC%9D%B8&returnto=%EC%9C%84%ED%82%A4:%EB%8C%80%EB%AC%B8 Error from line 151 of /(wiki directory)/wiki/extensions/OATHAuth/src/Key/TOTPKey.php: Class 'jakobo\HOTP\HOTP' not found Backtrace:

1. 0 /(wiki directory)/wiki/extensions/OATHAuth/src/Module/TOTP.php(88): MediaWiki\Extension\OATHAuth\Key\TOTPKey->verify(array, MediaWiki\Extension\OATHAuth\OATHUser)
2. 1 /(wiki directory)/wiki/extensions/OATHAuth/src/Auth/TOTPSecondaryAuthenticationProvider.php(110): MediaWiki\Extension\OATHAuth\Module\TOTP->verify(MediaWiki\Extension\OATHAuth\OATHUser, array)
3. 2 /(wiki directory)/wiki/extensions/OATHAuth/src/Auth/SecondaryAuthenticationProvider.php(65): MediaWiki\Extension\OATHAuth\Auth\TOTPSecondaryAuthenticationProvider->continueSecondaryAuthentication(User, array)
4. 3 /(wiki directory)/wiki/includes/auth/AuthManager.php(651): MediaWiki\Extension\OATHAuth\Auth\SecondaryAuthenticationProvider->continueSecondaryAuthentication(User, array)
5. 4 /(wiki directory)/wiki/includes/specialpage/AuthManagerSpecialPage.php(356): MediaWiki\Auth\AuthManager->continueAuthentication(array)
6. 5 /(wiki directory)/wiki/includes/specialpage/AuthManagerSpecialPage.php(484): AuthManagerSpecialPage->performAuthenticationStep(string, array)
7. 6 /(wiki directory)/wiki/includes/htmlform/HTMLForm.php(690): AuthManagerSpecialPage->handleFormSubmit(array, VFormHTMLForm)
8. 7 /(wiki directory)/wiki/includes/specialpage/AuthManagerSpecialPage.php(417): HTMLForm->trySubmit()
9. 8 /(wiki directory)/wiki/includes/specialpage/LoginSignupSpecialPage.php(313): AuthManagerSpecialPage->trySubmit()
10. 9 /(wiki directory)/wiki/includes/specialpage/SpecialPage.php(575): LoginSignupSpecialPage->execute(NULL)
11. 10 /(wiki directory)/wiki/includes/specialpage/SpecialPageFactory.php(611): SpecialPage->run(NULL)
12. 11 /(wiki directory)/wiki/includes/MediaWiki.php(296): MediaWiki\Special\SpecialPageFactory->executePath(Title, RequestContext)
13. 12 /(wiki directory)/wiki/includes/MediaWiki.php(900): MediaWiki->performRequest()
14. 13 /(wiki directory)/wiki/includes/MediaWiki.php(527): MediaWiki->main()
15. 14 /(wiki directory)/wiki/index.php(44): MediaWiki->run()
16. 15 {main}

Seems the composer dependencies of your oathauth extension install are not installed.

You might want to read Composer#Using_composer-merge-plugin

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)

Mediawiki 1.33.1 on a late 2012 Mac Mini Server running Yosemite (10.10.5) using Server Internal Apache Version 2.4.16, PHP 7.2.21, MySQL 5.6.22

I have been successfully running for 4 months now as per the above. All is fine, except for regular but unpredictable behaviour of my server becoming unresponsive, requiring a hard reboot of the server to get access once again.

Symptoms at failure point:

- Browser becomes unresponsive and progress bar stalls

- Closing/reopening browser does not seem to help

- Same behaviour from all access points (tried phone, or another computer) so it appears server related

- Other web installations on the same server such as Piwigo, Webtrees and Avideo continue to work fine

FYI - I am the only user of the server (it is private) so the server load is low.

Debug attempts so far:

- Enabled as much logging as I could understand, but logs do not show any entries

- Checked: error_log, access_log, php_errors.log

- Have experimented with Caching scheme, the following seems to be the most stable:

$wgMainCacheType = CACHE_DB;

$wgSessionsInObjectCache = true;

$wgSessionCacheType = CACHE_DB;

#$wgObjectCacheSessionExpiry = 3600; (so disabled)

$wgParserCacheType = CACHE_DB;

- Tried Chrome/Firefox in addition to Safari with same results

- Tried emptying Browser Cache with no effect

- Tried php maintenance/update.php before reboot with no effect

Clue? Hunch?:

- Previously I had $wgObjectCacheSessionExpiry enabled and the problem would occur at expiry time if the server stayed responsive long enough to reach the Expiry time

Could it be related?

Questions:

1. Are there any specific debug actions I could take to collect relevant information?
2. I don't fully understand the different caching schemes, so I would guess that what I have configured is not optimal. Any recommendations?
3. It seems relevant that my other web installations work fine without interruptions, Avideo is PHP based so it seems there is something specific to Mediawiki that is problematic with my setup and I am reluctant to change my PHP installation unless necessary. I could provide any/all LocalSettings.php values as needed. Please suggest any that could help.
4. Is there a way to reboot/restart Mediawiki without a hard reset/power cycling of my server?

Thank you,

Gregg

Its very hard to know without more details about what MediaWiki is getting stuck doing. Some possibilities is it might be getting stuck doing some sort of recache event (like for localisation cache) that never finishes so it tries to redo it on every request. Or similarly some job that just never finishes and gets retried on every request. Its somewhat odd that rebooting the server would actually fix but just waiting a while does not, since the PHP part of MediaWiki is mostly stateless. Are you using the same webserver for all apps?

It might be a little bit of a pain to setup, but if you could setup profiling - Manual:Profiling that might be helpful. As a first step though, if next time this happens you could run top on your server to see what process if any is using CPU. Setting $wgDebugLogFile to a file would also be helpful to get debug logging (Its important that wherever you set it is somewhere that apache has permission to write to)

So caching advice generally:

• Do you have php-apcu installed? If so, CACHE_ACCEL would probably be a better choice for $wgMainCacheType
• Some people say that CACHE_NONE is better for $wgMainCacheType than CACHE_DB, if CACHE_DB is all you have available.
• Try to set $wgCacheDirectory to some location that the webserver can write to (preferably not web accessible). This may be more efficient for localization cache.

Thank for the detailed reply. You have given me some things to try.

Re: Are you using the same webserver for all apps?

Ans: Yes - all using same Apache service

Re: Setting $wgDebugLogFile to a file

Ans: Already done, forgot to mention. Nothing recorded on failure..

Here is my plan based on your reply:

Trial 1:

- I will set the $wgCacheDirectory

- For next failure I will wait much longer to see if it fixes itself or an error message appears. If after 10 mins nothing happens I will assume that it can't fix itself - unless you think 10 mins is too short?

If something does appear I will update this issue with what I have found.

- I will check for renegade processes using top during the waiting period

Trial 2:

- I do have php-acpu install so I will try $wgMainCacheType = CACHE_ACCEL I think I did try this before but will try it again.

Trial 3:

- I will endeavour to setup Profiling and hope to provide some meaningful output..

Thanks again,

Gregg

Here is a data point from Trial 1:

- No change in the log files - Nothing logged during 10-15 mins of waiting

Snapshot of top

Starting Trial #2:

ie. Changed $wgMainCacheType = CACHE_ACCEL

Here is a second data point from Trial #2 with CACHE_ACCEL

- No change in the log files - Nothing logged during 10-15 mins of waiting

Observation: Anecdotally I would say on my server CACHE_ACCEL also accelerates the time to failure..

Attached is another top output.

Another Observation: There seems to be an active connection trying to be maintained between the browser and the server during the 'stalling' period. When I reboot the server, the browser then comes back with a 'lost connection' type of message where it says it can no longer reach the server while the power down is happening. When the server come back online, the message disappears and the browser goes back to trying to reconnect and do something as it was doing before the reboot.

Question: Is there a way to soft reboot Mediawiki so that I don't have to power cycle my server?

I will now try to enable Profiling but this will take some time.

Gregg

top output

Hi again.

Trial #3 Results:

I have failed to be able to install XHProf and/or Tideways. I get compiler errors when running make.

I have also reverted to CACHE_DB for the MainCacheType as it is more reliable (with CACHE_ACCEL I get the stalling in less than an hour).

Gregg

You can restart apache instead of reboot the computer.

The TOP displays a load of 2.06. However, the most CPU intensive process is top itself with 2.01%... And I don't see the I/O wait indicator in that top command (which is very useful to detect contention problems)

You seem to be using php as mod_php in apache. You may get some insights in apache subprocesses looking at this https://www.tecmint.com/check-apache-httpd-status-and-uptime-in-linux/

I don't really know, but it sounds like this is maybe more an issue with apache or php, and not with MediaWiki.

To confirm, its loading forever (like the webserver keeps the connection open)? Its not just loading a blank page, but stalled trying to load something? It might be interesting to know what the network tab of the web browser developer console says, if it says that loading is stalled at a specific step (not that I would know what to do with that information)

Hi.

I will endeavour to read up on mod_php. Is this the recommended method vs the alternatives?

I confirm the browser is loading forever (showing nothing) and it seems the browser/server connection is trying to be (re)established.

It is not loading a blank page. The progress bar/circle runs but does not progress.

I find it interesting that my other applications using the same Apache service all run great without interruption.

Gregg

mod_php and fastcgi or the two most popular methods for running php. Both are reasonable choices, and the differences are small enough to probably not make any difference in practice.

Thanks.

Other than restarting Apache, is there some way to reset Mediawiki so that I don't affect all server websites?

Gregg

mod_php causes it to run inside the webserver worker processes. There's no way to reset "only" one application.

Hi, still trying to debug this problem.

Recently I noticed a stoppage instead of stalling and getting some output in the browser and in the logs. From Apache error_log:

[Thu Feb 20 09:27:52.552990 2020] [php7:notice] [pid 70816] [client 192.168.1.1:52945] PHP Notice:  unserialize(): Error at offset 492 of 1505 bytes in .../mediawiki/1.33.1/includes/libs/objectcache/APCUBagOStuff.php on line 111, referer: .../mediawiki/1.33.1/index.php/Main_Page

[Thu Feb 20 09:27:52.553115 2020] [php7:notice] [pid 70816] [client 192.168.1.1:52945] PHP Stack trace:, referer: .../mediawiki/1.33.1/index.php/Main_Page

[Thu Feb 20 09:27:52.553131 2020] [php7:notice] [pid 70816] [client 192.168.1.1:52945] PHP   1. {main}() .../mediawiki/1.33.1/load.php:0, referer: .../mediawiki/1.33.1/index.php/Main_Page

[Thu Feb 20 09:27:52.553145 2020] [php7:notice] [pid 70816] [client 192.168.1.1:52945] PHP   2. require() .../mediawiki/1.33.1/load.php:31, referer: .../mediawiki/1.33.1/index.php/Main_Page

[Thu Feb 20 09:27:52.553157 2020] [php7:notice] [pid 70816] [client 192.168.1.1:52945] PHP   3. require_once() .../mediawiki/1.33.1/includes/WebStart.php:77, referer: .../mediawiki/1.33.1/index.php/Main_Page

[Thu Feb 20 09:27:52.553170 2020] [php7:notice] [pid 70816] [client 192.168.1.1:52945] PHP   4. ExtensionRegistry->loadFromQueue() .../mediawiki/1.33.1/includes/Setup.php:127, referer: .../mediawiki/1.33.1/index.php/Main_Page

[Thu Feb 20 09:27:52.553183 2020] [php7:notice] [pid 70816] [client 192.168.1.1:52945] PHP   5. ExtensionRegistry->exportExtractedData() .../mediawiki/1.33.1/includes/registration/ExtensionRegistry.php:173, referer: .../mediawiki/1.33.1/index.php/Main_Page

[Thu Feb 20 09:27:52.553196 2020] [php7:notice] [pid 70816] [client 192.168.1.1:52945] PHP   6. Skins\\Chameleon\\Chameleon::init() .../mediawiki/1.33.1/includes/registration/ExtensionRegistry.php:407, referer: .../mediawiki/1.33.1/index.php/Main_Page

[Thu Feb 20 09:27:52.553208 2020] [php7:notice] [pid 70816] [client 192.168.1.1:52945] PHP   7. ExtensionRegistryHelper\\ExtensionRegistryHelper->loadExtensionRecursive() .../mediawiki/1.33.1/skins/chameleon/src/Chameleon.php:62, referer: .../mediawiki/1.33.1/index.php/Main_Page

[Thu Feb 20 09:27:52.553222 2020] [php7:notice] [pid 70816] [client 192.168.1.1:52945] PHP   8. ExtensionRegistryHelper\\ExtensionRegistryHelper->loadModuleRecursive() .../mediawiki/1.33.1/vendor/mediawiki/mw-extension-registry-helper/src/ExtensionRegistryHelper.php:53, referer: .../mediawiki/1.33.1/index.php/Main_Page

[Thu Feb 20 09:27:52.553235 2020] [php7:notice] [pid 70816] [client 192.168.1.1:52945] PHP   9. ExtensionRegistry->loadFromQueue() .../mediawiki/1.33.1/vendor/mediawiki/mw-extension-registry-helper/src/ExtensionRegistryHelper.php:81, referer: .../mediawiki/1.33.1/index.php/Main_Page

[Thu Feb 20 09:27:52.553263 2020] [php7:notice] [pid 70816] [client 192.168.1.1:52945] PHP  10. APCUBagOStuff->get() .../mediawiki/1.33.1/includes/registration/ExtensionRegistry.php:168, referer: .../mediawiki/1.33.1/index.php/Main_Page

[Thu Feb 20 09:27:52.553277 2020] [php7:notice] [pid 70816] [client 192.168.1.1:52945] PHP  11. APCUBagOStuff->doGet() .../mediawiki/1.33.1/includes/libs/objectcache/BagOStuff.php:183, referer: .../mediawiki/1.33.1/index.php/Main_Page

[Thu Feb 20 09:27:52.553289 2020] [php7:notice] [pid 70816] [client 192.168.1.1:52945] PHP  12. APCUBagOStuff->unserialize() .../mediawiki/1.33.1/includes/libs/objectcache/APCUBagOStuff.php:48, referer: .../mediawiki/1.33.1/index.php/Main_Page

[Thu Feb 20 09:27:52.553301 2020] [php7:notice] [pid 70816] [client 192.168.1.1:52945] PHP  13. unserialize() .../mediawiki/1.33.1/includes/libs/objectcache/APCUBagOStuff.php:111, referer: .../mediawiki/1.33.1/index.php/Main_Page

[Thu Feb 20 09:27:53.510827 2020] [core:notice] [pid 294] AH00052: child pid 70816 exit signal Segmentation fault (11)

[Thu Feb 20 09:27:53.510965 2020] [core:notice] [pid 294] AH00052: child pid 70778 exit signal Segmentation fault (11)

[Thu Feb 20 09:27:54.513008 2020] [core:notice] [pid 294] AH00052: child pid 70779 exit signal Segmentation fault (11)

During this messaging I do get in the Apache access_log:

"OPTIONS * HTTP/1.0" 200 -

A couple more notes:

- I am not using CACHE_ACCEL, still using CACHE_DB

- Other applications on the same Apache server continue to run fine.

- I have edited out my IP and local root directory from the above

Is there somewhere a recommended Apache setup that is known to work well with Mediawiki?

Browser Message

well the php segfaulting is definitely related.

For the unserialize error - i guess there is something corrupt in the cache. If that is somehow related to this could explain why restarting apache fixes it since i think that would cause a cache purge.

Try setting $wgMainCacheType = CACHE_NONE; to see if that fixes it (this will slow down things, but better a slow wiki than a dead wiki) [the other cache type variables should be fine as default, just comment them out in LocalSettings.php if they are specified. The important thing for this test is that none of them are CACHE_ACCEL since we want to check if apcu is the culprit)

Fwiw, this sounds more like an issue with your version of php (or possibly version of some php extension) than apache

Sorry, i just saw you said you weren't using CACHE_ACCEL. I also just remembered that MediaWiki will still use apcu in certain circumstances (for data in a multi-server setup that you want per server).

Anyways, can you also try adding the following to LocalSettings.php

$wgObjectCaches['apcu'] = [ 'class' => EmptyBagOStuff::class, 'reportDupes' => false ];
$wgObjectCaches['apc'] = [ 'class' => EmptyBagOStuff::class, 'reportDupes' => false ];

Thanks I have this set for now:

$wgSessionsInObjectCache = true;

$wgSessionCacheType = CACHE_DB;

$wgMainCacheType = CACHE_DB;

$wgParserCacheType = CACHE_DB;

$wgObjectCaches['apcu'] = [ 'class' => EmptyBagOStuff::class, 'reportDupes' => false ];

$wgObjectCaches['apc'] = [ 'class' => EmptyBagOStuff::class, 'reportDupes' => false ];

Will report if things change.

Hi Bawolff,

Well it has been 4 days without any stalls so I do believe we have found the root cause using the above configuration. Before closing this issue should I be trying to debug using CACHE_ACCEL any further?

For example:

Q1: In the long run do I need CACHE_ACCEL or in other words under what condition would CACHE_ACCEL be of significant benefit?

Q2: How would I determine if it is in fact my version of PHP (currently 7.2.21) that is at fault and more importantly which version of PHP that I should change to?

Q3: How would I determine if it is in fact a specific extension of PHP that is at fault and more importantly which version of the extension that I should change to?

Thank you very much for your patience and expertise,

Gregg

I've been out of the fold for a while, and in the meantime, something appears to have changed with API action=parse.

See the URL https://commons.wikimedia.org/w/api.php?action=parse&text={%7C%20class=%22wikitable%22%0a%7Chi%0a%7C}&title=Something&prop=text%7Cheadhtml&formatversion=2

The text to be parsed contains a styled table. This wikitext would display with the appropriate styles if I placed it on any Wikimedia Commons page. However, the stylesheets included within the headhtml section of the response do not include the wikitable class.

What's more, the returned styles don't even include correct global fonts. The text appears in the browser default serif font.

What is going on here? Why are these styles missing from action=parse's response?

i think the this is because the legacy.shared module is missing.. Please file a ticket.

mediawiki 1.34

.htaccess

RewriteEngine On
RewriteRule ^/?wiki(/.*)?$ %{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]

localsettings.php

 ## 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 = ""; 

 $wgScriptExtension = ".php"; 

 $wgArticlePath = "/wiki/$1";
$wgUsePathInfo = true;

@SamiWey You posted stuff from files but did not explain what the problem is. Or if you have some question. Or where to see a problem.

$wgScriptPath probably needs to be "/" instead of "" Nope, empty string is fine for this setting.

The configuration looks fine.

Hit the F12 key, select the network tab, and reload the page. Look at requests to the load.php URL and see if some of them return 5XX or 4XX status codes, open them and see if there's any error there.

No idea what "NST Run" or "MY PC Check" is. This place is about MediaWiki.

I'm new to NST.

I've been reading for the past 2hrs.

Is there a 'check my PC to see if it will run NST' ?

I'm not sure if my PC is too old or not.

wrong place to ask

I setup a PageContentSaveComplete hook, but I have some existing pages that I would like to run the hook against. Is it possible to "resave" all my site in an automated method to run the hook against all the articles even though I won't be making any changes to the articles?

Can i ask what you are doing with the hook?

It sounds a little bit like one of the LinksUpdate/SecondaryDataUpdate hooks might be better for your needs, but hard to say.

The hook captures the contents from each page to save into an external database. I'd like to capture this data on some of the pages that were already created, but I don't need to change any of the page's content.

So normally in MediaWiki, we use LinksUpdate/RevisionDataUpdates for this sort of thing - where you want to update some sort of secondary data store based on the content of the page (And assuming you can deduplicate the results). Pages in MediaWiki can change for reasons other then an edit (for example if a template changes), and LinksUpdate should run whenever that happens, if people make a null edit, do a linkspurge from the api, or run the script refreshLinks.php.

If you want to keep with the PageContentSaveComplete hook, i guess i would suggest making a dummy edit to all the pages (e.g. adding <!-- foo--> to all pages), but seriously consider if LinksUpdate could be a better fit, because then its much easier to force a linksupdate of all pages.

Thank you so much, this seems perfect. So my understanding is, if I use either the `LinksUpdate` hook or the `RevisionDataUpdates` hook, then I can reprocess all my pages using the `refreshLinks.php` script. And that the difference between the two hooks is the first one runs synchronously, whereas the second one happens asynchronously. Is that correct?

Note: This system has changed a bit recently. I hope everything i say is accurate, but I'm more familiar with the old version than the new version.

Yes, LinksUpdate does run asynchronously (via the refreshLinks job). It also provides access to the LinksUpdate object, which is important in some use cases (but probably not yours). The LinksUpdate will also only be triggered by normal wiki pages (You can use ContentHandler to for example, replace the MediaWiki parser with something else totally different. If you do that, LinksUpdate won't happen because its tied to the parser output)

RevisionDataUpdates can be either I think. If you want it to be asynchronous, you can have your hook insert a job to do the update later. Often people want their update to be in a separate job than the refreshLinks job, because then you can set up separate job queues for it.

There's also several other hooks, and I'm honestly not sure the difference between them all is.

https://github.com/wikimedia/mediawiki/blob/master/docs/pageupdater.md may be a helpful page.

So I have my hook built using <code>$wgHooks['RevisionDataUpdates'][] = 'onRevisionDataUpdates';</code>. It works when I save my pages, but now I want to "resave" all my existing pages. I tried running refreshLinks.php alone and with runJobs.php but its not working as expected. Do I use a different maintenance script?

No, refreshLinks.php should do it (refreshLinks.php calls WikiPage::doSecondaryDataUpdates, which calls DerivedDataPageUpdater::doSecondaryDataUpdates, which calls DerivedDataPageUpdater::getSecondaryDataUpdates, which calls all RevisionDataUpdates hooks. refreshLinks.php also calls DeferredUpdates::doUpdates() which should trigger all updates to be done immediately.

Is is possible to either:

• Show a list of contributors (including IP addresses) with links to their user contributions pages.
• Show an entire list of non-admin/sysop contributors (including IP addresses) with all their contributions shown on the one page. (Non-sysop because on my wiki it otherwise would be too large a list...)

I used to have Extension:Contribution Scores but from memory it only took account of registered users.

Thanks.

this is specific enough, you would probably have to make it yourself.

Closest built un is special:activeusers

Thanks. That's helpful. I'll try to make a special page based on that one. I "just" need to get it to look for users since the year dot, and include IP addresses :-)

I don't need to look at this information regularly, so went for the easier option of saving a MySQL query to run periodically and paste into a wiki page.

SELECT CONCAT ("*[[Special:Contributions/", rev_user_text, "|", rev_user_text, "]] - {{#time:j/n/y|", 
rev_timestamp, "}} - ", COUNT(*), " edit(s) to [[{{namespace|", page_namespace, "}}", page_title, "]]")
FROM wm_revision  
INNER JOIN wm_page ON wm_page.page_id = wm_revision.rev_page
WHERE rev_user_text <> "MY USERNAME"  
GROUP BY CONCAT (rev_user_text, "-", rev_page)
ORDER BY rev_user_text, rev_timestamp

I had to create Template:Namespace using a #switch to convert the page_namespace numbers into their text equivalent.

note: the above query will probably stop working in 1.34 due to schema changes.

Thanks for the warning! :-)

I've seen several posts on various sites dated 2016 and 2018 mainly. I've not found a permanent solution to the automation fail.

My wiki is new as of four weeks ago. Versions are MediaWiki 1.32.0, PHP 7.2.24 (cgi-fcgi), SQLite 3.28.0, ICU 60.2. Beyond the standard install, I added a line to log output, enabled WikiEditor 0.5.2, and added the DarkVector skin. After starting to add categories, the category pages would not populate "automatically." I've seen several posts on various sites dated 2016 and 2018 mainly. Manually forcing a RefreshLinks on command line populates the categories. After failing to find a valid or even contemporary solution, I set up the log and found every page load was generating a version of the following error (several maybe sensitive bits obscured):

-- log excerpt begins

[runJobs] htmlCacheUpdate User:USERNAME table=redirect recursive=1 rootJobIsSelf=1 rootJobSignature=ffff rootJobTimestamp=0000 causeAction=page-edit causeAgent=unknown requestId=XXXX (id=5,timestamp=0000) STARTING

[exception] [XXXX] /w/index.php?title=PAGE   Wikimedia\Rdbms\DBUnexpectedError from line 4030 of /ROOTPATH/w/includes/libs/rdbms/database/Database.php: HTMLCacheUpdateJob::run: Cannot flush snapshot because writes are pending (JobQueueDB::claimRandom).

#0 /ROOTPATH/w/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1622): Wikimedia\Rdbms\Database->flushSnapshot(string)

#1 /ROOTPATH/w/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1786): Wikimedia\Rdbms\LoadBalancer->Wikimedia\Rdbms\{closure}(Wikimedia\Rdbms\DatabaseSqlite)

#2 /ROOTPATH/w/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1623): Wikimedia\Rdbms\LoadBalancer->forEachOpenMasterConnection(Closure)

#3 /ROOTPATH/w/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1388): Wikimedia\Rdbms\LoadBalancer->flushMasterSnapshots(string)

#4 /ROOTPATH/w/includes/libs/rdbms/lbfactory/LBFactory.php(219): Wikimedia\Rdbms\LoadBalancer->beginMasterChanges(string)

#5 /ROOTPATH/w/includes/libs/rdbms/lbfactory/LBFactorySimple.php(152): Wikimedia\Rdbms\LBFactory->Wikimedia\Rdbms\{closure}(Wikimedia\Rdbms\LoadBalancer, string, array)

#6 /ROOTPATH/w/includes/libs/rdbms/lbfactory/LBFactory.php(221): Wikimedia\Rdbms\LBFactorySimple->forEachLB(Closure, array)

#7 /ROOTPATH/w/includes/libs/rdbms/lbfactory/LBFactory.php(246): Wikimedia\Rdbms\LBFactory->forEachLBCallMethod(string, array)

#8 /ROOTPATH/w/includes/jobqueue/JobRunner.php(288): Wikimedia\Rdbms\LBFactory->beginMasterChanges(string)

#9 /ROOTPATH/w/includes/jobqueue/JobRunner.php(192): JobRunner->executeJob(HTMLCacheUpdateJob, Wikimedia\Rdbms\LBFactorySimple, BufferingStatsdDataFactory, integer)

#10 /ROOTPATH/w/includes/MediaWiki.php(1001): JobRunner->run(array)

#11 /ROOTPATH/w/includes/MediaWiki.php(984): MediaWiki->triggerSyncJobs(integer, MediaWiki\Logger\LegacyLogger)

#12 /ROOTPATH/w/includes/MediaWiki.php(908): MediaWiki->triggerJobs()

#13 /ROOTPATH/w/includes/MediaWiki.php(726): MediaWiki->restInPeace(string, boolean)

#14 /ROOTPATH/w/includes/MediaWiki.php(749): MediaWiki->{closure}()

#15 /ROOTPATH/w/includes/MediaWiki.php(550): MediaWiki->doPostOutputShutdown(string)

#16 /ROOTPATH/w/index.php(42): MediaWiki->run()

#17 {main}

[runJobs] htmlCacheUpdate User:USERNAME table=redirect recursive=1 rootJobIsSelf=1 rootJobSignature=ffff rootJobTimestamp=0000 causeAction=page-edit causeAgent=unknown requestId=XXXX (id=5,timestamp=0000) t=1 error=Wikimedia\Rdbms\DBUnexpectedError: HTMLCacheUpdateJob::run: Cannot flush snapshot because writes are pending (JobQueueDB::claimRandom).

Request ended normally

-- log excerpt ends

Only idea I have is a conflict in current pairing of php x sqlite and even x mediawiki but I haven't found any mentions. Possibly, I don't know what to look for.