In T293767#7441135, @Reedy wrote:

In T293767#7441105, @redrooster wrote:

But why does the mediawiki image-viewer try to show this version? What tells the image-viewer that this 1920px version should exist?

I don't think anything tells it it exists. I'm guessing it's some maths of screen size and image size

You are right with your example. But using the 404 thumb handler would solve nothing, because the bug here is that the thumbnail creation of the 1920px version is not even triggered according to my research. Thus, it never can be shown of course. But why does the mediawiki image-viewer try to show this version? What tells the image-viewer that this 1920px version should exist?

P.S.: I tried to upload that failing jpg, but my browser didn't let me...

Trust me, "existing values only" is true by default in REL1_35 and also
5.1. And no, I have not something like "existing values only=false" in
my field definition. I sent a patch that fixes this, without that there
is no way to turn off "existing values only" because this is a bug in
the code.

I rolled back to REL1_35 to restore the used functionality and I discovered, that comboboxes in this version have the same bug as in 5.1. It looks like the option "existing values only" at comboboxes is set by default. I think this is the reason why comboboxes blank out existing values (because if they only accept existing values and a different text is given, the combo simply refuses to show that value and thus, blanks out the value in the template on saving the article). Is there any way to switch this off?

This is a code snippet from the person form we have. It works perfectly
with tag REL1_35 (shows a text input with autocomplete). But in 5.1 this
shows an empty combobox and blanks out the attribute (Nachname) on the
template if I save. Note: "Nachname" had already a value, but the combo
does not show it and stays empty. This is the reason why it blanks out
the attribute on save, because the combo can not read the "Nachname"
attribute at loading.

I will answer tomorrow, because I am back on my computer then. Thanks for
your quick response anyway! And yes, I meant Text with autocomplete, which
shows as combobox in 5.1.

I mean, autocomplete text.

It happens if the input type is autocomplete test. I could not test the
other options, because I had to quickly roll back before more data loss
happened than in just a few articles.

I figured the problem out myself now. The problem is, that the strtotime-function of php can not figure out the dateformat "YYYY/MM". So I added a little workaround in the PF_DateInput.php that solves that Problem:

In wikis with chronic you have one page for every day, for example "3. Juli" and also a page for every year, say "2008". To link that pages properly to the semantic dates i have written a little date-parser with the onboard parser functions of mediawiki that simply parses the date-data from "2018/07/03" down to "[[3. Juli]] [[2018]]". But in the case you just give month and year you get "July 2018" as output, which should be transformed "Juli [[2018]]", which is not easy because of the different dateformat for that case.

Semantic Mediawiki understands the "Month YYYY" format, that's not the Problem. But SMW also understands "YYYY/MM". But the datepicker only understands "Month YYYY" and not "YYYY/MM", which should be fixed.

@Yaron_Koren - Exactly, I parse the dates to create user friendly templates that work together with semantic mediawiki. SMW already perfectly understands the dateformat YYYY/MM, your patch managed that the datepicker returns that dateformat, now I need the datepicker to use this format as input, too (if the date-value is already given).

In semantic Mediawiki you just have a Template which holds the date and if you call "Edit with Form" the right datepicker shows the given date. But the PageForms datepicker can not read the new dateformat YYYY/MM, just the old one like "Monthname YYYY".

The datepicker should be able to show its own date. But this does not work if the datefield is filled with a date in the YYYY/MM format. The datepicker only shows the correct date, if the date-field is filled with the old format (Monthname YYYY).

Ok, that patch worked for the output-part of the datepicker. But the Problem now is, that the datepicker still can not parse the YYYY/MM Format.

@Yaron_Koren : The Problem is, that the Dateformat is inconsistent. If you pick day, month, year the format is YYYY/MM/DD, which is perfect. But if you pick just month and year, the format changes to Month YYYY (instead of YYYY/MM). That makes it hard to parse the date, because you never know if the month is a two-digit-integer or a word (it depends on what the user typed into the datefield). And if the Month is a word, it depends on the language how that specific date is named. If the Format would be YYYY/MM then I knew for sure, that the two digits after the first "/" stand for the month.