If bad content handler is an issue, why T49270 is fatal and this is not?

Kind of duplicate of T49270 ?

Just ran into this when importing some sample WMF wiki into my test one. I think the proper behaviour should be that data should be loaded, they may be not accessible or something.

So, as it turns out, sort is sitting there waiting for data from stdin which never come.

Looks like node is waiting for the external process running and the threadpool is not used at the moment.

Maybe not the best place to ask - do you also measure how many times the user had to expand the compact list to get where she wants?

If node is hanging on I/O, external process execution etc. this might indicate problems with asynchronous I/O and exhaustion of the thread pool. A workaround could be to increase node thread pool size with "env UV_THREADPOOL_SIZE=128 node" when starting node (it's an env variable).

Looks like those merge strategies are just an ugly (hopefully temporary) hack...

Thank you for a very quick migration.

Thank you very much for instant help! Yay!

Hello, I'd like to invite PostgreSQL developers to engage with MediaWiki developers (I'm having a talk on a pgconf.eu conference on November 4th).

We should check if the issue is still there

This may require getting just the old patch and try to make it work.

Still present as of rMW590aa0fb7f70d59974af8ccf9f3fea4997c647ea

As of now 590aa0fb7f70d59974af8ccf9f3fea4997c647ea I was able to install on PostgreSQL via the commandline installer from scratch. It didn't work ca. two weeks earlier.

Any updates on this? Are https://phabricator.wikimedia.org/T142129 and https://phabricator.wikimedia.org/T109837 supposed to fix this?

I have uploaded the patch to restore this functionality:

I came to conclusion this feature is not really needed. It is not only about lack of attention, I also think this feature is really unnecessary.

One more thing, the documentation at the extension page listed some probably obsolete variables, which I have removed. Is this okay?

And by the way, we shouldn't need to use http (and allow http) to talk to the local wiki.

@Yurik thank you very much, I forgot to add my workaround here: https://github.com/saper/mediawiki-extensions-Graph/commit/7985fd39623b345f9a446a8a59ecef240a748f97

I have downloaded the JSON world data using

I just run into this today by adding this to my composer.local.json:

Thank you @Jdlrobson work picking this up! Much appreciated!

An example how to improve wfDebugTimestamp logging:

Thanks @Krinkle. You are right we are talking here about server-generated HTML code and only the final touch (current selection) needs to be brought into play.

Maybe instead of strategy and the annual plan we should just bring back a little fun to MediaWiki development:)

What would be the best strategy to pre-select active tab based on the # on the preferences screen without causing the page to reflash (HTML, CSS and then pre-selecting code run in async)?

Steps 1-5 indicate there is something wrong in the architecture, why can't they communicate more efficiently?

Hi @sbonds - I have pushed your patch to the "code review" (i.e. the red tape needed to get this thing included), I only would love to include your name and email address in the git commit, since you are the author. Can you mail me at saper@saper.info? Thanks

@TheDJ Lucky you, at least you can do it yourself; and a prolonged code review is merely a nuisance when you have +2

@Yaron_Koren from commits like this https://github.com/mediawiki4intranet/SemanticForms/commit/90c13ba9fe49599f4c6b94e2680407793c7e5f0e http://wiki.4intra.net/Mediawiki4Intranet/en seems to be a Russian distribution of MediaWiki with patches.

I am not sure that CU viewfinder and maximum block ranges should be necessarily in sync. If CheckUsers can't easily see a wider range, they won't event know if the current maximum block range is sufficient. But this is mostly theoretical as those ranges are pretty large and CheckUser queries should not cause performance issues.

Looks like a perfect candidate to be a reason.

@Yaron_Koren I have reviewed Paladox patches' and this thing is going beyond their scope.

if we go with serialized PHP, will HHVM Authoritative Repo mode be able to load it?

Thanks for quick merge and discussion. I actually think that even a better fix is possible - for skins Composer installer should just read the value added to "ValidSkinNames":

@Bawolff can you have a look at https://gerrit.wikimedia.org/r/#/c/260173/ ? It is not fully ready yet (it does not fix T120216 yet), but it should migrate existing 1.24 data (it can even run on 1.24).