In T247629#5970859, @Ammarpad wrote:

No you did something different again; You should use $wgNamespaceProtection [828] = ['editmodule']; as it's all you need. You needn't to 'basically' use something else. NS_MODULE is meant to be used internally in the extension code.

I did it in the hope that this issue will be resolved. The code fragment to which you referred still doesn't explain to me why namespace constants defined in some extensions are not available in LocalSettings.php while others are (like SMW_NS_PROPERTY).

I applied the last patch manually, and the maintenance script started to work.

In T247629#5969187, @Ammarpad wrote:

In T247629#5969186, @alex-mashin wrote:

That's what I did;

No, you used $wgNamespaceProtection [NS_MODULE] = ['editmodule']; that's not the same thing with what I said.

No, when I found out the absence of NS_MODULE, I had to switch to:

if (defined ('NS_MODULE')) {
	$wgNamespaceProtection [NS_MODULE] = ['editmodule'];
} else {
	$wgNamespaceProtection [828] = ['editmodule'];
}

So, I *eventually* had to do basically what you said.

In T247629#5969183, @Ammarpad wrote:

NS_MODULE is a non canonical namespace, you must use the numerical constant

$wgNamespaceProtection[ 828 ] = [ 'editmodule' ];

In T247629#5968878, @Reedy wrote:

Not defined where?

Perhaps, wikilinks should again be parsed before external links?

For the time being, I replaced $wgUrlProtocols [] = '/'; with $wgUrlProtocols [] = $wgScriptPath; to achieve the desired effect, although I am not yet sure whether that has broken something else.

Will anybody review the code in https://gerrit.wikimedia.org/r/553857?

@Yaron_Koren, when I found out that a certain site had banned my wiki's IP for downloading currency exchange rates too often (and I was sure that caching was already enabled); and that I had to create the cache table manually, apart from finding another source of exchange rates; and that the table that I created using the SQL code from the wiki page was wrong (caused MediaWiki crash on non-Latin URIs due to wrong collation)—I decided to automate table creation.

In T237613#5644117, @Aklapper wrote:

@alex-mashin: Basically a duplicate of T232624: Class 'LoggerFactory' not found? But no idea which branch / versions you tested this with...

MediaWiki 1.31.5 (8af9c78)

In T230260#5435781, @Umherirrender wrote:

Looks good now

In T230260#5410920, @Krinkle wrote:

Is the query from page views (OutputPage), from the startup module (load.php), or from the gadget module response (load.php)?

Page views.

@Krinkle, my $wgMainCacheType was set to CACHE_ACCEL. If the task author's wasn't, his $wgMessageCacheType was, and was effectively ignored.

I spent my whole weekend to find a workaround for this bug, tearing through undebuggable spaghetty callback hell.

It seems that I have a similar problem, too (MW 1.31.1, PHP 7.2).

https://www.wikiapiary.com/wiki/Traditio not updated.

OK, thanks, I changed the configuration accordingly.

The issue has gone away. Most probably due to rebuilding the localisation cachem which I had done in connection to another bug.

In T208669#4720436, @Jdlrobson wrote:

You also may want to check you have the latest Minerva version installed in case it might be trying to use this class.

I used this:

$wgEnabledTranscodeSet = [
    '160p.webm',
    '240p.webm',
    '360p.webm',
    '480p.webm',
    '720p.webm',
    '1080p.webm',
];

Checking out branch 1.32 (MW stayed at 1.31) and running php maintenance/rebuildLocalisationCache.php --force helped. The extension loads with wfLoadExtension ().

In T208335#4718444, @Aklapper wrote:

What is in your line 903, as there is no foreach in https://phabricator.wikimedia.org/diffusion/EXDA/browse/REL1_29/ED_Utils.php$903 ?

Also see https://lists.wikimedia.org/pipermail/mediawiki-l/2015-February/044096.html

Read the thread, and don't think it is relevant here.

The idea is to add three items to a array at once. This is not the problem. That the class WebVideoTranscode is not available from LocalSettings.php is.

However, under MediaWiki 1.29 it doesn't work anyway.

This error happens only if $wgDevelopmentWarnings = true. Don't know if this is ExternalData's or MediaWiki's bug.

The same story after upgrading to MediaWiki 1.31.1, but the backtrace now involves Visual Editor and ResourceLoader:

PHP message: PHP Stack trace:
PHP message: PHP   1. {main}() /var/www/wiki/w/index.php:0
PHP message: PHP   2. MediaWiki->run() /var/www/wiki/w/index.php:42
PHP message: PHP   3. MWExceptionHandler::handleException() /var/www/wiki/w/includes/MediaWiki.
2018/11/03 20:57:33 [error] 32644#32644: *306 FastCGI sent in stderr: "PHP message: PHP Notice:  "" is not a valid magic word for "get_web_data" [Called from Language::getMagic in /var/www/wiki/w/languages/Language.php at line 3181] in /var/www/wiki/w/includes/debug/MWDebug.php on line 309
PHP message: PHP Stack trace:
PHP message: PHP   1. {main}() /var/www/wiki/w/load.php:0
PHP message: PHP   2. ResourceLoader->respond() /var/www/wiki/w/load.php:51
PHP message: PHP   3. ResourceLoader->getCombinedVersion() /var/www/wiki/w/includes/resourceloader/ResourceLoader.php:759
PHP message: PHP   4. array_map() /var/www/wiki/w/includes/resourceloader/ResourceLoader.php:678
PHP message: PHP   5. ResourceLoader->{closure:/var/www/wiki/w/includes/resourceloader/ResourceLoader.php:663-678}() /var/www/wiki/w/includes/resourceloader/ResourceLoader.php:678
PHP message: PHP   6. ResourceLoaderStartUpModule->getVersionHash() /var/www/wiki/w/includes/resourceloader/ResourceLoader.php:665
PHP message: PHP   7. ResourceLoaderStartUpModule->getDefinitionSummary() /var/www/wiki/w/includes/resourceloader/ResourceLoaderModule.php:831
PHP message: PHP   8. ResourceLoaderStartUpModule->getAllModuleHashes() /var/www/wiki/w/includes/resourceloader/ResourceLoaderStartUpModule.php:422
PHP message: PHP   9. ResourceLoader->getCombinedVersion() /var/www/wiki/w/includes/resourceloader/ResourceLoaderStartUpModule.php:449
PHP message: PHP  10. array_map() /var/www/wiki/w/includes/resourceloader/ResourceLoader.php:678
PHP message: PHP  11. ResourceLoader->{closure:/var/www/wiki/w/includes/resourceloader/ResourceLoader.php:663-678}() /var/www/wiki/w/includes/resourceloader/ResourceLoader.php:678
PHP message: PHP  12. VisualEditorDataModule->getVersionHash() /var/www/wiki/w/includes/resourceloader/ResourceLoader.php:665
PHP message: PHP  13. VisualEditorDataModule->getModuleContent() /var/www/wiki/w/includes/resourceloader/ResourceLoaderModule.php:828
PHP message: PHP  14. VisualEditorDataModule->buildContent() /var/www/wiki/w/includes/resourceloade

Anybody reads this?

but I think we should also have Scribunto for other frameworks, notably Javascript/ECMASCript like Node.js,

It will not be easy to expand Scribunto in any way. See comments in T189767. It seems that the authors of Scribunto view any proposals regarding it as an attack.

In T189767#4052816, @Anomie wrote:

In T189767, @alex-mashin wrote:

Several years before Scribunto, a proposal to install Winter extension on WikiMedia sites was rejected.

Do you have a link to that discussion?

Sorry, it was abot ten years ago, and I did not take part in it, only watched; and cannot find it now. Could be in some mailing list or IRC.

The first three bugs that you have mentioned were created by myself (I intend to close them in favour of this one). I came to a conclusion that those issues are parts of a bigger picture.

PHP 8 is expected to use JIT, which means that performance is lilkely to be boosted by strict typing.

If {{GRAMMAR}} is indeed called client-side, then it's pointless.

1. Who talks about JavaScript? $wgGrammarForms is meant to be set in LocalSettings.php.
2. How on earth can I know when and where wiki contributors will use {{grammar:}}? They can justifiably do it anywhere; in templates meant for the main namespace, for example.

To be able to look up in a dictionary, for example. Or to programmatically implement inflectional paradigms that are more complicated than regular expressions.

declare(strict_types=1); seems more attractive but there could be some problems with hooks. Unless they are restricted to callable, perhaps.

I therefore suggest a more ambitious goal: make strict typing compulsory in MediaWiki code. This requirement can be enforced by automated testing, as far as I understand.

That's well off-topic for this task. You're welcome to file a separate task for such a proposal.

Done: T178136.

Is there a reason to migrate only to PHP 7.0 and not to PHP 7.1 of even 7.2, as it is going to be released soon?

--force doesn't help.

Thank you, now I know that those queries could be cached in spite of the initial SET; that was my concern.

Formally, this is a request to enhance documentation on linking extra libraries to luasandbox. But if there is no such feature (which, I suspect is the case), then I think this can be closed as resolved by myself.

Found a more correct way to link extra libraries:

UPD: I did OPTIMIZE TABLE page; and CHECK TABLE page; (it's a TokuDB table) and the query without the index hint started to use the right one. Don't know, if it was a broken index.