Looks like I should have done git submodule update --init after upgrade. Now the file is there.

In T52454#2173725, @jeblad wrote:

thus we need a Perl-type lib for Lua of some kind.

Consider rrthomas.github.io/lrexlib.

These seem to be the logging engine uselessly whining,

So, is this an HHVM bug? Broken type hinting?

In T126871#2027697, @Anomie wrote:

Without the specific version of MediaWiki being used, these line numbers are less than helpful.

1.26.2 as is written in the task title.

What about backporting to REL1_26?

In T122300#1900937, @Aklapper wrote:

Wondering how it can gather the wiki user language (API) in case a contributor would like to work on this task.

If the contributor is anonymous, which is not always the case, obviously, the wiki interface language.

In T115779#1889439, @ori wrote:

I can't reproduce this with the current HEAD of facebook/hhvm (3.12):

http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html looks nice, including lpeg.setmaxstack to cause crazy regex to fail.

Just like lrexlib it won't work until you hack luasandbox (and so I did).

After I upgraded Gadgets extension to REL1_26, the message went away, so the bug can be closed now.

In T121311#1875452, @ashley wrote:

CSS-only (gadget) modules should define the ResourceLoader module "position", i.e. top (the other alternative is bottom, but you don't want this when you have a CSS-only module, as that'll cause a "flash of unstyled content" when the CSS is being loaded). For a good example, see the English Wikipedia's various Watchlist* gadgets, such as WatchlistBase.

That being said, I don't quite get why you're seeing this warning for a gadget which seems to have no CSS, only JS. That definitely sounds like a bug or I'm missing something here.

P.S. If I switch debug mode off, the warnings remain.

I managed to run the update script after

composer install --no-dev
composer update --prefer-source

Anybosy here? Anybody cares?

I should notice that videos are transcludable. Only MP3 files handled by MP4 handler aren't.

In T115197#1718751, @brion wrote:

I'm assuming that using Mp4Handler for mp3 files is a hack of some kind that should not be done.

Any alternatives to handle MP3?

Please close. I forgot that the really stable SyntaxHighlight version is 2.0.

I did git reset --hard HEAD; git pull; git checkout REL1_25 and still see -wpred-dct8x8 -level 13.

Will you please backport the patch to REL1_25?

In T113160#1657423, @TTO wrote:

…
What happens if you set $wgArticlePath = '/./$1'?

In this case, MW engine forms ugly-looking but correctly working URLs, which are prettyfied by browsers (I have checked Firefox and Opera): [[/etc]] → <a href="/.//etc"> in page's source code → http://my-server//etc in browser's status bar, in the clipboard when the link is copied and in the address bar if the link is opened. But I don't know how search engines will treat such internal links.

I guess, the bug can be closed now.

So I did: https://www.mediawiki.org/w/index.php?diff=1654307&oldid=1516911.

Since the reasons that prevented using the master branch of Syntax Highlight with MW 1.25 are removed, I think the obscure remotes/origin/REL1_25 can be abandoned now and this issue closed.

I cannot find bug 67746 this bug is supposed to duplicate. Can anyone give me a URL, please?

git branch in extensions/SyntaxHighlight_GeSHi.

T102522: Setting manifest_version should not explode in REL1_25. It's fixed in REL1_25 and will be part of 1.25.2.

BTW, git branch currently reports only one branch: master.

Also, running hhvm maintenance/updateLexerList.php or hhvm maintenance/updateCSS.php under MW 1.25.1 gives this warning:
Warning: Invalid operand type was used: storeToArray expects array(s) in /var/www/traditio.ru/w/includes/registration/ExtensionProcessor.php on line 294.

Indeed, there was an ? at the end of nginx rewrite rule. I don't know what I was thinking when I put it there. I'm at a loss what could mask this error under MW 1.24.2 and previous versions.

If your wiki is public, please provide a link to it so we can see it happening

Also, check in server logs or in a debug log that the parameters are actually arriving to mediawiki and not being lost in some obscure rewrite-rule your server could be applying.

In T100938#1325160, @Aklapper wrote:

Has this been brought up on the MediaWiki.org Support Desk? I'm just wondering if other users have also run into this problem...

Honestly, I thought this is Mediawiki's support desk.

@alex-mashin: Any comments?

Some features are provided only by Lua libraries in C (.so). Do you know a way to link such a library via a call into PHP from luasandbox?

So now I have to glue it like this:

If you want something done, then do it yourself © Zorg. Well, it's more or less

RFC 902: https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/902.

I think there should be a way open to web admins to dynamically link lua libraries to both LuaSandbox and Lua standalone engine.

In T76264#794419, @Legoktm wrote:

This is likely due to an extension calling something too early during the setup process. Can you provide a full backtrace? See https://www.mediawiki.org/wiki/Manual:How_to_debug#PHP_errors for instructions on how to turn that on.

In addition, having logged in here with some difficulty, I was unable to set any meaningful "Projects" field.