User Details
- User Since
- Nov 29 2014, 10:11 AM (233 w, 4 d)
- Availability
- Available
- LDAP User
- Alexander Mashin
- MediaWiki User
- Alex Mashin [ Global Accounts ]
Dec 4 2018
https://www.wikiapiary.com/wiki/Traditio not updated.
Nov 11 2018
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.
Nov 8 2018
I used this:
$wgEnabledTranscodeSet = [
'160p.webm',
'240p.webm',
'360p.webm',
'480p.webm',
'720p.webm',
'1080p.webm',
];Nov 7 2018
Checking out branch 1.32 (MW stayed at 1.31) and running php maintenance/rebuildLocalisationCache.php --force helped. The extension loads with wfLoadExtension ().
Nov 4 2018
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.
Nov 3 2018
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/resourceloadeNov 1 2018
Anybody reads this?
Oct 30 2018
Oct 17 2018
May 6 2018
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.
Mar 16 2018
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.
Mar 15 2018
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.
Feb 24 2018
PHP 8 is expected to use JIT, which means that performance is lilkely to be boosted by strict typing.
Feb 22 2018
Feb 21 2018
If {{GRAMMAR}} is indeed called client-side, then it's pointless.
Feb 20 2018
- Who talks about JavaScript? $wgGrammarForms is meant to be set in LocalSettings.php.
- 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.
Feb 19 2018
To be able to look up in a dictionary, for example. Or to programmatically implement inflectional paradigms that are more complicated than regular expressions.
Jan 21 2018
Oct 17 2017
Oct 15 2017
declare(strict_types=1); seems more attractive but there could be some problems with hooks. Unless they are restricted to callable, perhaps.
Oct 13 2017
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.
Oct 12 2017
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?
Oct 8 2017
--force doesn't help.
Oct 2 2017
Thank you, now I know that those queries could be cached in spite of the initial SET; that was my concern.
Sep 30 2017
Sep 24 2017
Sep 23 2017
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:
Sep 11 2017
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.
Even worse: these queries use a wrong index on page, at least under MariaDB 10.2.8!
SELECT SQL_NO_CACHE /* MessageCache::loadFromDB(en)-small */ page_title,old_id,old_text,old_flags FROM `page`,`revision`,`text` WHERE page_is_redirect = '0' AND page_namespace = '8' AND (page_title LIKE '%/en' ESCAPE '`' ) AND (page_latest=rev_id) AND (rev_text_id=old_id) AND (page_len <= 131072); ... 1 row in set (2.41 sec)
But if I force the index page_redirect_namespace_len:
SELECT SQL_NO_CACHE /* MessageCache::loadFromDB(en)-small */ page_title,old_id,old_text,old_flags FROM `page` USE INDEX (page_redirect_namespace_len),`revision`,`text` WHERE page_is_redirect = '0' AND page_namespace = '8' AND (page_title LIKE '%/en' ESCAPE '`' ) AND (page_latest=rev_id) AND (rev_text_id=old_id) AND (page_len <= 131072); ... 1 row in set (0.02 sec)
One hundred times faster.
Query plan with the wrong index:
EXPLAIN SELECT /* MessageCache::loadFromDB(en)-small */ page_title,old_id,old_text,old_flags FROM `page`,`revision`,`text` WHERE page_is_redirect = '0' AND page_namespace = '8' AND (page_title LIKE '%/en' ESCAPE '`' ) AND (page_latest=rev_id) AND (rev_text_id=old_id) AND (page_len <= 131072); +------+-------------+----------+--------+-------------------------------------------------+----------+---------+-----------------------------------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+-------------+----------+--------+-------------------------------------------------+----------+---------+-----------------------------------+------+-------------+ | 1 | SIMPLE | page | range | name_title,page_len,page_redirect_namespace_len | page_len | 4 | NULL | 81 | Using where | | 1 | SIMPLE | revision | eq_ref | rev_id | rev_id | 4 | (my wiki).page.page_latest | 1 | | | 1 | SIMPLE | text | eq_ref | PRIMARY | PRIMARY | 4 | (my wiki).revision.rev_text_id | 1 | | +------+-------------+----------+--------+-------------------------------------------------+----------+---------+-----------------------------------+------+-------------+ 3 rows in set (0.01 sec)
With the right index:
EXPLAIN SELECT /* MessageCache::loadFromDB(en)-small */ page_title,old_id,old_text,old_flags FROM `page` USE INDEX (page_redirect_namespace_len),`revision`,`text` WHERE page_is_redirect = '0' AND page_namespace = '8' AND (page_title LIKE '%/en' ESCAPE '`' ) AND (page_latest=rev_id) AND (rev_text_id=old_id) AND (page_len <= 131072); +------+-------------+----------+--------+-----------------------------+-----------------------------+---------+-----------------------------------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+-------------+----------+--------+-----------------------------+-----------------------------+---------+-----------------------------------+------+-------------+ | 1 | SIMPLE | page | range | page_redirect_namespace_len | page_redirect_namespace_len | 9 | NULL | 493 | Using where | | 1 | SIMPLE | revision | eq_ref | rev_id | rev_id | 4 | (my wiki).page.page_latest | 1 | | | 1 | SIMPLE | text | eq_ref | PRIMARY | PRIMARY | 4 | (my wiki).revision.rev_text_id | 1 | | +------+-------------+----------+--------+-----------------------------+-----------------------------+---------+-----------------------------------+------+-------------+ 3 rows in set (0.00 sec)
Note the different indices on page.
If I add the following in the line 521 of includes/cache/MessageCache.php:
['USE INDEX' => ['page' => 'page_redirect_namespace_len']]
, my nearly-dead wiki immediately comes back to life..
Sep 9 2017
There is one topic here: empty branches. That master requires MobileFrontend 2.0 is not necessarily an error itself, it just makes using master branch instead of REL1_29 impossible.
Sep 7 2017
Aug 30 2017
May 24 2017
Forget it, I wrote the comment before reading the code, thinking that mysql_real_escape_string () is a standard PHP function, not a method.
May 17 2017
I worked around this bug with the following change to (path to mediawiki)/includes/libs/rdbms/database/DatabaseMysqli.php:
in line 314 within protected function mysqlRealEscapeString( $s ) replace:
return $conn->real_escape_string( $s );
with:
return $conn->real_escape_string( (string) $s );.
Apr 29 2017
Apr 23 2017
Feb 1 2017
Such a hook should definitely be added.
Looks like the submitted patch has been applied.
Jan 29 2017
Jan 24 2017
Will it be backported to REL1_28?
Jan 5 2017
Issue present under MW 1.28 (table user_properties).
The same thing with user_properties unde MW 1.28.
Sep 25 2016
And as of MW 1.26.3 and 1.27, this workaround no longer helps.
Aug 13 2016
You don't understand the logic behind this patch, and I don't fully undestand the logic behind URL processing.
Aug 2 2016
MW 1.27.0, SMW 2.4.1, SF 3.6.
Aug 1 2016
Yes, it is.
Jul 31 2016
Installation with Composer by composer require --prefer-source mediawiki/semantic-forms "3.5.*" is broken totally:
Fatal error: Uncaught Error: Call to undefined method stdClass::getPropertyLabels() in /var/www/wiki/w/extensions/SemanticForms/includes/SF_Utils.php:257\nStack trace:\n#0 /var/www/wiki/w/includes/Hooks.php(195): SFUtils::initProperties()\n#1 /var/www/wiki/w/extensions/SemanticMediaWiki/src/PropertyRegistry.php(420): Hooks::run()\n#2 /var/www/wiki/w/extensions/SemanticMediaWiki/src/PropertyRegistry.php(79): SMW\\PropertyRegistry->registerPredefinedProperties()\n#3 /var/www/wiki/w/extensions/SemanticMediaWiki/includes/dataitems/SMW_DI_Property.php(412): SMW\\PropertyRegistry::getInstance()\n#4 /var/www/wiki/w/extensions/SemanticForms/includes/SF_Utils.php(187): SMW\\DIProperty::newFromUserLabel()\n#5 /var/www/wiki/w/extensions/SemanticForms/includes/SF_FormLinker.php(164): SFUtils::getSMWPropertyValues()\n#6 /var/www/wiki/w/extensions/SemanticForms/includes/SF_FormLinker.php(384): SFFormLinker::getFormsThatPagePointsTo()\n#7 /var/www/wiki/w/extensions/SemanticForms/includes/SF_FormEditAction.php(59): SFFormLinker::getDefaultFormsForPage()\n#8 /var/www/wiki/w/extensions/SemanticForms/includes/SF_FormEditAction.php(145): SFFormEditAction::displayTab()\n#9 /var/www/wiki/w/includes/Hooks.php(195): SFFormEditAction::displayTab2()\n#10 /var/www/wiki/w/includes/skins/SkinTemplate.php(1076): Hooks::run()\n#11 /var/www/wiki/w/includes/skins/SkinTemplate.php(474): SkinTemplate->buildContentNavigationUrls()\n#12 /var/www/wiki/w/includes/skins/SkinTemplate.php(247): SkinTemplate->prepareQuickTemplate()\n#13 /var/www/wiki/w/includes/OutputPage.php(2282): SkinTemplate->outputPage()\n#14 /var/www/wiki/w/includes/MediaWiki.php(756): OutputPage->output()\n#15 /var/www/wiki/w/includes/MediaWiki.php(520): MediaWiki->main()\n#16 /var/www/wiki/w/index.php(43): MediaWiki->run()\n#17 {main}Somehow, I've managed to submit this: https://gerrit.wikimedia.org/r/#/c/302088/. I'm afraid this learning curve is too steep for me.
Jul 30 2016
No, it can't. URLs in incoming HTTP requests are treated incorrectly, not wikilinks on pages.
Anydody here?
Jul 28 2016
Coroutines, for example, are a natural way to iterate through a nested table.