Well, hiding or displaying a piece of text is all the button is supposed to do. Except that this text should also contain many HTML input elements (check boxes and text entries) that the user can then operate to specify the Diagram he wants to create. I guess the text block in that gets opened is just more damaged than was easily visible in the revisions compare. The problem with that particular compare is that nearly everything changed because it was messing with indentation, so that you can no longer see which of the things that matter were changed.

I see that some other sections contained < characters in their text (as part of HTML code to be shown to the user, which is now converted to HTML code that is actually interpreted by the browser. These are now all corrupted as well. E.g. leading to a false Diagram in the 'Embedding' section, which only intended to show how to embed a Diagram.

I don't think there is an alternative to displaying actual < characters in the text of the aricle; If I write "write the diagram between less than div greater dan less than /div greater than tags" no one would understand it. Text containing such characters must remain editable, as they always have been. The current submission system is badly broken. It should not of its own accord replace escape sequences such as &lt; by the characters they stand for; the very reason the text would contain the escape sequence is that the plain character would be harmful in that context.

I can imagine that it is necessary for correct display in the edit boxes that characters with HTML significance must be escaped in those boxes. And that this escaping has to be reversed on submission, so that in the end texts that were not modified remain the same in the database. But if this was done correctly it should not lead to the observed effect, because & itself is a character with HTML significance, and would be escaped as &amp;. So the combination &lt; in a text in the database should appear as &amp;lt; in the edit boxes, and on submitting be converted back to &lt;. Not to <.

I replaced the less than sign in the text with the words "less than", and I replaced some less than and greater than signs in your JavaScript with String.fromCharCode(60) or String.fromCharCode(62). But when I click on your "Start Design Wizard" button, all it does is hide or display a block of text. Looking at the source code for the page, I don't see any structural problems with the JavaScript. But I am too unfamiliar with your code to tell whether there might be a bug.

H. G., Try switching to the Text format. Your HTML will still work, but it will not use CKEditor, and it will not run the functions that undo its formatting.

OK, I tried that, but it makes no difference. I even tried switching JavaScript off during the edit, so that I am sure nothing can be done to the text in the browser client. I replaced the offending < by &lt;, and after I resubmitted the page still has a < at that place (as seen in the Page Source).

The problem must be in the PHP script that processes the submitted form.

H. G., Try switching to the Text format. Your HTML will still work, but it will not use CKEditor, and it will not run the functions that undo its formatting.

Just for the record. I have watched twenty engine vs engine games, and there were no crashes, there were no bugs and the games were fun to watch. You deserve all the praise!

Fergus Duniho wrote on 2022-12-08 UTC

H. G., give me the revision number for when it worked and for when it was completely destroyed, and I will look into it. In the meantime, you may revert it to the revision that last worked.

Well, when recalling old revisions the Design Wizard button never seems to do anything, so I guess it only works in the context of a real page. There is one problem that sticks out when I try to edit the current page, though: it has a < character in the text of the Notes section near the end, which the CkEditor sees as the start of a HTML tag (and consequently completely messes up the indentations, as this imaginary tag is never closed). Originally this < character was embedded in the text as the HTML escape &lt;.

If I look at the page source, that same < is also in it in unescaped form, and my first guess is that this is what cuts off most of the Design Wizard when it gets opened. (Initially it is on the page in display:none style to hide it untill the button gets pressed.)

The (spontaneous) replacement of the &lt; by < occurred from revision #7441 to revision #8100.

I would hate to lose the edits that I have made since then, though, especially since it is likely not possible to edit it through the usual form without the same corruption occurring again too. If we are lucky repairing the latest version might just be a matter of restoring the < to its original &lt; form. But to be able to do that the submission script would have to be repaired, otherwise it would just replace it back on submission.

H. G., give me the revision number for when it worked and for when it was completely destroyed, and I will look into it. In the meantime, you may revert it to the revision that last worked.

The insert statement does not include the timestamp. It relies on MariaDB using the current_timestamp() function to fill in the value. So, I'm not sure why multiple revisions would have the same timestamp.

Help!

I edited the Interactive Diagrams article to describe the new 'background' parameter, and this completely destroyed the Design Wizard in the Notes section (which I did not touch). What happened, and why?