Again this ticket needs more detail, even with the example I really don't understand / see the issue your trying to show.

This is down to the configuration, for example on the wikibase registry correct URLs are shown using the docker images.

I think this ticket needs a little more explanation.

In T191424#4301999, @GoranSMilovanovic wrote:

• We need to understand how to track forms. Will forms have a namespace?

The solution here again is for people to modify the setup and not just use the example.

This is again probably falling out of the scope of the wikibase-containers project and perhaps should be retagged with mediawiki-containers?

In install/update process, provide way to input for arbitrary LocalSettings.php lines

This is probably starting to get out of the scope of general "wikibase-containers".

Do you have a stacktrace?

In T191424#4297796, @GoranSMilovanovic wrote:

@Lydia_Pintscher @Addshore https://gerrit.wikimedia.org/r/#/c/analytics/wmde/scripts/+/440901/

Q1. Where do you make this SQL calls from? It would help me to understand the workflow.

This is not technical a blocker or a solution to the previous parent ticket.

This isn't yet resolved.

In T197252#4289410, @WMDE-leszek wrote:

What line in Wikibase actually does this unserialization? perhaps we could change that to something that wouldn't have such a global effect.

That's where the fun lies. Technically speaking, Wikibase itself does not do serialize/unserialize. PHP serialization happens in EntityRevisionCache::set/get which are basically calling set/get on BagOStuff putting EntityRevision instance in the cache.

That actually brings up another option we've briefly mentioned in the exploration group yesterday (as with others, I am not suggesting it being a good pick):

4. Do not store EntityRevision objects into MW cache, but use own serialization of those objects or so. Do problem of handling of unknown EntityIds etc would not really be solved. Wikibase would be more in the control of such situations, though. Which might be good, or not that good thing.

I saw "memcached" in the description so I will add this comment here:

In T197252#4283504, @WMDE-leszek wrote:

Some options to overcome the issue (list not complete and not sorted in any way)

1. Always run the same version of the software on both systems. Tricky/Maybe even not wanted, as not only means enabling WikibaseLexeme, WikibaseMediaInfo etc on wikiedias, but to get things 100% right, means always having the same version of Wikibase running on both systems. Not doable with the current deployment strategy with deploying Wikibase to different wikis on different days

This will be set to take the train on the week of the 25th of June, providing everything goes well on group0 over the coming week.

Going to mark this as resolved as our lovely .999 branch with the main current MCR patches is on group0 now and has been since last night.

For phabricator searchability the branch name is wmf/1.32.0-wmf.999

I got @Dzahn to fix our patches for now.
I guess as a gerrit admin he can see this button on everyone's patches.

Should be unbroken now, but we need to resolve the root issue here too.

In T195615#4282248, @gerritbot wrote:

Change 440295 had a related patch set uploaded (by Addshore; owner: WMDE-leszek):
[mediawiki/extensions/Wikibase@wmf/1.32.0-wmf.8] Statement transclusion: when entity of unknown type in statement, display ID as string

https://gerrit.wikimedia.org/r/440295

In T195615#4280121, @greg wrote:

I presume the fatal on https://test.wikipedia.org/wiki/Main_Page is known?

senses do not have to be considered, yet (covered by hike implementing T195652 ff.)

Done

In T195652#4281273, @Lydia_Pintscher wrote:

And also: I want to test :P

In T189935#4058351, @Lydia_Pintscher wrote:

@Addshore: native speaker check: Should it be "on the project" or "at the project" in the messages? If it is "on the project" then we also need to adjust the messages for the item and property datatypes.

The plan is that the patches will be merged into master during EU morning time tomorrow (14th)
Testing on the beta cluster will follow throughout the EU day time.
In the evening of the 14th we will attempt a new branch with these 3 MCR patches for group0.
That branch will remain on group0 for 14th-25th
On the 25th / 26th the success can be determined and the code will probably continue on the train that week in the next branch.

Looks like something to do with this ticket is reproducable in my mediawiki docker dev setup https://github.com/addshore/mediawiki-docker-dev/issues/57#issuecomment-396919300

The patches will be:

WMF cloud project: wikidata-dev
Instance name: wikidata-mobile
URL: https://wikidata-termbox.wmflabs.org/Q123

@GoranSMilovanovic fancy trying to modify the script?

Creating wikidata-termbox.eqiad.wmflabs

Well... we can't use a tool with wikidata in the name.. T190707

I really don't like this, now instead of using a descriptive name "wikidata-termbox-prototype" i have to use a less descriptive name of "termbox-prototype" or "wd-termbox-prototype".

Happens for other tools names too...