var_dump shows

object(User)#215 (35) {
  ["mId"]=>
  int(0)
  ["mName"]=>
  string(15) "Გამაგ"
  ["mActorId":protected]=>
  NULL

the revision is 14466 in that dump.

Originally, I thought this was becaue of the --no-local-users flag, but now I'm able to reproduce it consistently, even with --skip-to=14400.

Testing now. Ran before with --no-local-users and got T238149

So far, so good.

In T224949#5654605, @daniel wrote:

In T224949#5653825, @MarkAHershberger wrote:

Could you clarify what sounds risky? Is it the use of mwdumper? Or my automation?

Using mwdumper. mdumper re-implements the MediaWiki database schema, so it would need to be kept up to date with all the schema changes. But it's not:

In T224949#5650149, @daniel wrote:

In T224949#5637909, @MarkAHershberger wrote:

You can see the exact process I used here. I used these tools to create an SQL dump that I then loaded with mysql's cli.

Oh, that sounds risky.

Note that during the upgrade I also ran into the same thing that @Absorbcium mentions above: an empty content_models table.

My extension can be deleted.

In T224949#5630202, @daniel wrote:

So, this started happening for you at some point using 1.33?

@daniel: it happened before and after. I upgraded to see if the fixes here would fix this issue.

Looks like I ran into this upgrading from 1.31 to 1.34. From https://asyncwiki-earth.wmflabs.org/demo/index.php/Main_Page:

MediaWiki internal error.

In T235392#5584148, @Jdforrester-WMF wrote:

I disagree. This is what releases are for.

Try the SuggestedTitles extension.

Now...

[51fbb8ea5f47e21ee0143081] [no req]   MediaWiki\Revision\RevisionAccessException from line 1635 of /opt/htdocs/mediawiki/includes/Revision/RevisionStore.php: Main slot of revision 934 not found in database!
Backtrace:
#0 /opt/htdocs/mediawiki/includes/Revision/RevisionStore.php(1671): MediaWiki\Revision\RevisionStore->loadSlotRecords(string, integer)
#1 [internal function]: MediaWiki\Revision\RevisionStore->MediaWiki\Revision\{closure}()
#2 /opt/htdocs/mediawiki/includes/Revision/RevisionSlots.php(165): call_user_func(Closure)
#3 /opt/htdocs/mediawiki/includes/Revision/RevisionRenderer.php(169): MediaWiki\Revision\RevisionSlots->getSlots()
#4 /opt/htdocs/mediawiki/includes/Revision/RevisionRenderer.php(128): MediaWiki\Revision\RevisionRenderer->combineSlotOutput(MediaWiki\Revision\RenderedRevision, array)
#5 [internal function]: MediaWiki\Revision\RevisionRenderer->MediaWiki\Revision\{closure}(MediaWiki\Revision\RenderedRevision, array)
#6 /opt/htdocs/mediawiki/includes/Revision/RenderedRevision.php(175): call_user_func(Closure, MediaWiki\Revision\RenderedRevision, array)
#7 /opt/htdocs/mediawiki/includes/Storage/DerivedPageDataUpdater.php(1266): MediaWiki\Revision\RenderedRevision->getRevisionParserOutput()
#8 /opt/htdocs/mediawiki/includes/Storage/DerivedPageDataUpdater.php(1288): MediaWiki\Storage\DerivedPageDataUpdater->getCanonicalParserOutput()
#9 /opt/htdocs/mediawiki/includes/Storage/DerivedPageDataUpdater.php(1560): MediaWiki\Storage\DerivedPageDataUpdater->getSecondaryDataUpdates(boolean)
#10 /opt/htdocs/mediawiki/includes/page/WikiPage.php(2106): MediaWiki\Storage\DerivedPageDataUpdater->doSecondaryDataUpdates(array)
#11 /opt/htdocs/mediawiki/maintenance/refreshLinks.php(275): WikiPage->doSecondaryDataUpdates(array)
#12 /opt/htdocs/mediawiki/maintenance/refreshLinks.php(198): RefreshLinks::fixLinksFromArticle(integer, boolean)
#13 /opt/htdocs/mediawiki/maintenance/refreshLinks.php(83): RefreshLinks->doRefreshLinks(integer, boolean, string, boolean, boolean)
#14 /opt/htdocs/mediawiki/maintenance/rebuildall.php(60): RefreshLinks->execute()
#15 /opt/htdocs/mediawiki/maintenance/doMaintenance.php(94): RebuildAll->execute()
#16 /opt/htdocs/mediawiki/maintenance/rebuildall.php(67): require_once(string)
#17 {main}

fixed by adding a row with role_id=2 and role_name='aux'

No, I'm not sure. I just found this bug and hoped it was the same.

> select * from slot_roles;
stdClass Object
(
    [role_id] => 1
    [role_name] => main
)

Just ran into this on https://asyncwiki-moon.wmflabs.org/demo/index.php/Main_Page ... looking at the patch.

Is it your view that people will never create a field tag on purpose
that has "mandatory" and "restricted", but no "default"?

I think this problem can be resolved by not doing error checking on
hidden fields. If they are hidden, the user hasn't had a chance to see
them.

The patch was submitted prematurely. I would like to refactor PF so that it is easier to find and fix bugs.

I am just checking my emails and got a few "table is full" emails from
the mysql before I saw these reports.

I understand the concern regarding new defaults on old pages, but it is currently possible to create restricted fields that are required and have a default.

In T226857#5389802, @Ladsgroup wrote:

So how that can be done?

@mmodell has +1'd the change and we're looking for a way to merge it.

Since we're just using git to produce the diffs and diff production is automated based on the last release (even when the release is a .0 release), I think this is done.

Wrote the initial docs in a README, @mmodell said he would add to them and move the docs to the appropriate wiki place.

I think using gerrit to branch server-side (as is done in the code), means that this is essentially resolved.

This seems easy... Why hasn't anyone done this in the past three years?

This is done now since we have an official docker image https://hub.docker.com/_/mediawiki

I would love to have someone else handle this

This ship has sailed and everything is done that can be done.

No time machine!

We do not have a time machine.

@Bawolff we'd like to keep this moving forward and know you've done a lot here. Could you point us to how the lua is generated on wiki?

Wikia said something on RIOT about having an extension for this that was published but probably not usable by others.

Can we re-title this?

I would love to get WikiApiary support built in and make whatever changes we need to support.

Found via Suppport Desk.

If you are using only one LocalSettings.php, then you'll need to check the HTTP headers when someone visits to see which site they're going to and set $wgServer according to that.

Are you trying to use one LocalSettings.php to serve the same wiki from two different domains?

In T229043#5371208, @Ravikzm wrote:

Defined the wiki.internal.domain.com as relative url in $wgServer in LocalSettings.php file. also IdP reply url configured as wiki.internal.domain.com

• I went and looked at the old SAMLAuth page and saw that it does not provide anywhere to provide a redirect url.
• I see that in your working config and notworking config files for SimpleSAMLphp, the redirect.trustedsites configuration is NULL or an empty list.

In T229043#5371040, @Ravikzm wrote:

...we have hosted the website in Azure (Azure App Service) (wiki.domain.com) and the same website is configured with Custom domain url (internal domain in my reference - wiki.internal.domain.com). So when user access the Azure Domain Url (wiki.domain.com) and after authentication they will landed/redirected to wiki.internal.domain.com.

This needs a better fix.

If anyone here has wants to contribute code to the SMW project, but hesitates because of SMW is not governed by the WMF's CoC, I will work with them to privately contribute their code with or without attribution, whichever is preferred. I voluntarily place my collaboration in this mode under the WMF's CoC and any arbitration there.

In T226199#5342865, @Jdlrobson wrote:

[1] A codesearch across Wikimedia didn't show any results for dataAfterContent so it was not clear that https://gerrit.wikimedia.org/r/#/c/mediawiki/skins/Vector/+/518095/1/includes/templates/index.mustache would impact SemanticMediaWiki.

In T226199#5342865, @Jdlrobson wrote:

What is the downside of fixing SemanticWiki usage retroactively using one of the more skin-agnostic ways like @Legoktm proposes? Is help needed here?

From meeting:

• Write documentation
• Mukunda reviews code
• See what the issue is with composer
  • Mark ran composer because he read reports on Support Desk about missing composer libs. Were they actually missing?
  • If it is an issue, how should problems like this be resolved?

Copying this comment of mine from code review because I think this is a clear summary of my argument:

In T226199#5337828, @Legoktm wrote:

The intention of this change was to standardize how all skins display content using the SkinAfterContent hook (that is, moving it explicitly after the content area, as the name implies). I think we all agree that long-term the skin standardization that @Isarra, @Jdlrobson, and others are working on is a good thing, yes?

In T226199#5337828, @Legoktm wrote:

If so, I think we should be looking for ways to move forward rather than an attitude of "don't change stuff ever, because it might break things".

In T226199#5337512, @Isarra wrote:

this extension should be using a parser hook, as Cite does.

This changed causes layout problems with SMW: "Move DataAfterContent outside of main content block" breaks Factbox display.

Maybe migrateComments.php could check the table schema and change it if needed?

Since this has happened to two separate people, it seems likely that there are a number of other people experiencing the same problem that we don't know about.

In T191231#5236862, @Skizzerz wrote:

In any case, splitting DBMS out of core is an absolute non-starter until the installer can make use of them somehow without LocalSettings.php existing. Once that happens and is well-supported rather than an afterthought, I’d be happy to re-evaluate moving less-supported DBMS into extensions or whatever system is devised for that.

As the task stood, you did not misunderstand. However, since creating it, I've been working on doing the DB support as a pure extension which I hope to move to Gerrit soon. That is where this task should be targeted.

rejected...

$ git clone ssh://gerrit.wikimedia.org:29418/test/gerrit-ping test-gerrit-repo
Cloning into 'test-gerrit-repo'...
remote: Counting objects: 2, done        
remote: Finding sources: 100% (1/1)        
Receiving objects: 100% (5/5), done.
remote: Total 5 (delta 0), reused 5 (delta 0)        
$ cd test-gerrit-repo/
$ git checkout -b sandbox/hashar/testcreation
Switched to a new branch 'sandbox/hashar/testcreation'
$ git push origin sandbox/hashar/testcreation
Total 0 (delta 0), reused 0 (delta 0)
remote: Processing changes: refs: 1, done            
To ssh://gerrit.wikimedia.org:29418/test/gerrit-ping
 ! [remote rejected] sandbox/hashar/testcreation -> sandbox/hashar/testcreation (prohibited by Gerrit: create not permitted for refs/heads/sandbox/hashar/testcreation)
error: failed to push some refs to 'ssh://gerrit.wikimedia.org:29418/test/gerrit-ping'

In T213893#5320412, @TheDJ wrote:

I note that this introduced php 7 syntax into the update.php script.
This means that if you use php56 and try to run update.php and accidentally you use php56 as a command line default etc. the version check for php won't help you in giving useful feedback as you will receive a syntax error.

In T227159#5313336, @Paladox wrote:

@MarkAHershberger i had to create the account manually using createAndPromote.php, i've sent the details through email for logging in.

In T227159#5312322, @hashar wrote:

Ah indeed. So All-Projects.git has:

[access "refs/heads/sandbox/${username}/*"]
    create = group Registered Users
    push = group Registered Users
    pushMerge = group Registered Users

Which apparently mean that any registered user can create a branch anywhere under refs/heads/sandbox/. So tentatively @Hexmode might be able to create a branch under my sandbox (ex: refs/heads/sandbox/hashar/hexmode).