Sep 22 2018
As for the issue reported in this task, it's been resolved. In theory, it will always be
Sep 15 2018
teardown (theoretically at least). But in any case, maybe you could use a test listener (https://phpunit.de/manual/6.5/en/extending-phpunit.html#extending-phpunit.PHPUnit_Framework_TestListener) and implement endTestSuite() ? It's not exactly identical since there are generally multiple suites being executed at once, but I think it might meet your needs.
Sep 8 2018
... and by that you mean "MediaWikiServices::getInstance()->resetServiceForTesting( 'NameTableStoreFactory' );" ?
tests but the table (change_tag) got emptied. Do you do something similar in the tests?
Sep 6 2018
@Ladsgroup I believe this is caused by one of your changes.
Mar 30 2018
The issue is still pending with 1.31 but somehow I get the feeling no one really cares since it has been open for one month without any feedback.
Mar 3 2018
Feb 3 2018
They shouldn't do that.
Jan 8 2018
I'm not sure what you mean, as extensions aren't supposed to be adding things to core's composer.json.
From my POV the script is working as it is expected to
We don't close bugs just because they are inactive.
Closing due to inactivity (1y+) since it cannot be expected that anything will be done within a reasonable amount of time.
I would please ask that you don't try and put words in my mouth.
please let me know instead of ranting on random tickets (it's mostly coincidence that I saw this on IRC).
Jan 3 2018
[mediawiki/core@master] MCR database schema
Dec 24 2017
GraphViz no longer working ...
The SRF devs seem dead against supporting extension registration
Dec 22 2017
[mediawiki/core@master] [MCR] Add optional $title param to Revision byId methods
Nov 29 2017
Nov 11 2017
No. You could check this for yourself very easily
@Reedy Do you think your response in tone is appropriate? I don't think so!
Nov 4 2017
From my POV the script is working as it is expected to - we only used fixed versions in MediaWiki core's composer.json
Do we need to advertise composer.local.json more prominently in documentation? e.g. in
Oct 18 2017
@Legoktm If time permits please comment on the outlined issue.
Oct 13 2017
I'm no longer expecting any response or help from a MW developer on the stated issue but for those who face a similar problem, I added a suggestion that may work for them and is what I understand as community support.
An idea, discussed at SMWCon Fall 2017, is to have a mechanism to directly serve the content of static sources (i.e. files) bundled with an extension.
My understanding is that once MediaWiki complies with (not sure that is the correct terminology) PSR-4, that community will be willing/able to adapt to extension registration.
Oct 11 2017
No reply. Hence assuming yes.
Oct 3 2017
The confusing part here is that Database is logging the internally caught non-error into the debug channel for debugging purposes.
Sep 30 2017
This is more of a status report on running PHPUnit 6.x/PHP 7.1 with MediaWiki since I needed to modify core in order for our tests to pass. Whether the provided information are of interest or value to developers I don't know, I just wanted to disseminate our experience on the related matter.
Sep 29 2017
the log file writes are introducing a slight performance hit (not to mention it makes it harder to find actual errors in them)
ERROR: duplicate key value violates unique constraint "md_module_skin"
Sep 25 2017
A quick checkout of the PR confirms that the system no longer produces above listed exceptions.
Sep 23 2017
You know how to mark bugs as release blockers, so if there's a regression you've found and want to see it fixed, mark it as a release blocker. :)
Do we think that this is going to be fixed in 1.30, given that it has a valid exception stack trace?
Sep 19 2017
Sep 9 2017
I was patiently awaiting (two weeks+) this issue to be triaged since this is clearly a regression since 1.29!
Aug 24 2017
I reckoned there was a similar issue  in the past and I would have expected that a unit test is in place that would prevent such a regression.
Aug 19 2017
So, what is the status of this patch, issue?
Aug 12 2017
I don't think there is an established convention and most extensions actually just use <extensionname> but IMO using MediaWiki\Extensions\... follows from the PSR-4 recommendation that namespaces
Aug 5 2017
do you want some time to do an announcement/anything of that nature first?
since that page disables the OutputPage for some commands and does not set a cache-control header, if this is used in an environment where autocreation can happen, an attacker might be able to cause an admin's session id to be cached
Jul 29 2017
@Legoktm It would be marvellous if could take a peek at this.
Jul 13 2017
On what url did this happen?
Jul 8 2017
Did that not work?
... rc.1 has been released like 10 minutes ago, but it'll make it into the final release.
In which case, I suggest those driving the patch press the cherry-pick button and get a patch up for review on the target branch.
Jul 7 2017
All blockers are now resolved.
Jul 6 2017
With reference to https://gerrit.wikimedia.org/r/363727 and the comment "... should fix warnings about TransactionProfiler in objectcache...", it does NOT as it can be seen from the log output:
This isn't just PostgreSQL, it applies to MySQL too.
... specific to PostgreSQL, but after failing to reproduce the premise, Aaron pointed out "pg" in the wiki name.
Jun 29 2017
Which tests specifically fail for you?
Jun 26 2017
Doing a quick var_dump on $encLike = $this->escapeLikeInternal( $table, '\\' ); reveals that before the PR it would return "unittest\_archive" and now after the change it contains "unittest\_unittest\_archive".
This change just broke all of our integration tests with:
Jun 20 2017
@Seb35 Maybe something you want to have look at a convenient time?
So this is probably some incompatibliity with Semantic Glossary and SMW 2.5?
Jun 19 2017
Jun 15 2017
I think the method of injecting TransactionProfilers needs refactoring to make this more flexible, and given that this warning is mainly intended for developers I don't think it should be a release blocker (since it's not trivial to fix).
Normally, I would use redis but this time around for testing I just used the vanilla setup that comes with SqlBagOStuff out of the box hence the increased log output.
or the cost of writing to a file on the server-side?
Also nothing is thrown here, there is no PHP "exception". Rather it's a debug log message (severity=INFO) that is hidden by default and (for easier debugging) includes a manually created stack trace.
@mwjames can you confirm that everything here works now please?
I was able to confirm that this fixes the reported issue and I'm able to run our integration tests without major interruptions.
@Krinkle As for the last stack trace, it happens on each edit and causes a significant lag during a save action.