Comments/Ratings for a Single Item

It seems that multi‐capturing two‌‐square leapers are oddly popular as knight enhancements: this game has the multi‐capture apparently mandatory for when going to Alibaba destinations, but still allows leaping otherwise; Larry Smith's Li Qi replaces knights with ‘Young’ Chu‐shogi lions, which cannot move back to the starting square, to match its planar linepieces; and ofc H. G.'s Mighty‐lion Chess replaces one knight with a full Lion.

I wonder why?

For some reason it is not possible to edit this article through the [edit content] link editors will see at the bottom of the page. That is, you get to the edit form, but when you press the 'Send' button nothing happens. I had no such problems with oter articles.

The problem is that the Notes section includes some TEXTAREAs of its own, and when the first one closes, it closes the TEXTAREA the Notes HTML is being displayed in.

The problem is that the Notes section includes some TEXTAREAs of its own, and when the first one closes, it closes the TEXTAREA the Notes HTML is being displayed in.

I had some problem using textareas in the editor for comments as well, a few days ago; it completely messed up the comment display, and I had a hard time recovering from that, as the edit/reply/view links at the bottom were also clipped off. So this seems a general problem. Is there any solution to it? I suppose this article is in the database, and not in a separate file that I could edit through WinSCP.

Perhaps the script displaying the edit form for submissions can be made to 'disarm' any text it fills the edit boxes with by substituting something else for the word textarea? Inconvenient, of course, as you would have to restore that every time you edit. But better than not being able to edit at all. Perhaps substitute by texxtarea, and make the reverse substitution when the form gets submitted?

I tried using htmlspecialchars for the form and htmlspecialchars_decode for inserting into the database, but something went wrong with the Game Courier forms on the page. So, I reverted things back. I'll try it again later in case I did something wrong.

If you want to, you can edit the database directly. I emailed you information on how to do that.

I don't think the problem is how it is encoded in the database. What matters is how it is presented to the client browser. There cannot be any /textarea tags within the recalled text, or the submission form would not be correctly displayed. When presenting the existing text to the user for editing these must be deleted or replaced by something harmless, or everything following it would not be considered as belonging in the editable area. If that 'something harmless' is something the user would never want to be in the text, it could be automatically substituted back for /textarea when the server receives the submission form, before it stores it in the database.

Anyway, I edited the database to temporarily disarm the textarea tags in the Notes section (by replacing those with texxtarea) so that the article can now be normally edited. I inserted the Interactive Diagram in the Setup section, but the textareas are still disabled. I wonder what to do next. I could put in two smaller Interactive Diagrams configured to be game viewers for the specified sequence of moves on the page itself. But those would not work when JavaScript is disabled. So perhaps I should just put back the textarea tags, and leave it at that?

Yes, just put them back.

Since your own edits also broke the Game Courier forms, I figured it might not be my use of htmlspecialchars and htmlspecialchars_decode. I determined the problem to be that CkEditor was putting extra whitespace in front of each line, and this was affecting how it processed the variable passed in the TEXTAREA. So, I modified Game Courier to remove the whitespace from each line of this variable. Then I used htmlspecialchars on the appropriate variables before displaying them in editmsitem.php, and I used htmlspecialchars_decode on them before copying them to the database in editmsitem2.php.

But one problem remained. The Game Courier forms included lots of extra whitespace before each line of text in the TEXTAREA. To eliminate this, I wrote a function to trim whitespace off each line of text in a string, and I used this function on the data before sending it to the database in editmsitem2.php. This will have the extra advantage of saving space in the database. However, this will make difficulty for PRE text, but I figure PRE text is no longer as useful as it once was, since most people don't use text-based browsers like Lynx, and because CkEditor reformats text, it makes using PRE text difficult anyway.

Unless people believe there is a need to still accommodate PRE text, I'll start making these same changes to other scripts for editing page content.

I made the appropriate changes to the scripts for editing your own page. I figured that if someone really wants to use PRE with lines that begin with whitespace, the whitespace can be enclosed in a NOBR or SPAN tag to keep it from being trimmed off.

That is no good. PRE tags are typically used for no other reason than to preserve indentations. The CkEditor adds such tags in WYSIWYG mode when you select 'formatted text' in the 'layout' pulldown. (I am guessing the English names, as I see them in Dutch; it is the control left of the question mark.) What you have done would cause every existing submission that relies on it to get utterly destroyed upon editing. And what about JavaScript embedded in the page? The CkEditor doesn't add any whitespace there; it is smart enough to only do that in HTML code where it knows the whitespace will be ignored.

Indiscriminately destroying the existing explicitly requested layout when you happen to load and resubmit an article for making an innocent change elsewhere basically makes the submission form unusable. In particular, I could no longer use it to replace a static setup image by an Interactive Diagram without running a large risk to irreversibly damage the page. And this holds for all editing jobs by CVP editors.

Please revert this as quickly as possible. The adding of whitespace can be annoying in exceptional circumstances. (E.g. I had to adapt the parser of the Interactive Diagram to remove the leading whitespace, as the Diagram's definition is within HTML tags.) But it is not nearly as bad as removing whitespace in the far more common case where the user explicitly requested it. It is far easier to delete whitespace you don't want than to add whitespace that got erroneously deleted, as you would not always know exactly how much whitespace there originally was, and where. The most important property of an edit function is that when you activate it, alter nothing, and save, that you have not altered anything, and certainly not anything essential.

I think the best solution to the addition of leading whitespace in textareas that are used as input for Game Courier is to have Game Courier itself strip off such whitespace. Just as I have done for the Interactive Diagram.

PRE tags are typically used for no other reason than to preserve indentations

But is that an appropriate use for them? Please point me to a page that does this, so that I have a better idea of what you are talking about.

And what about JavaScript embedded in the page? The CkEditor doesn't add any whitespace there; it is smart enough to only do that in HTML code where it knows the whitespace will be ignored.

It hasn't harmed your interactive diagram on this page. It does not remove all whitespace. It removes whitespace only from the beginning and the end of each line, and then it adds a newline character at the end so that lines do not run into each other. Losing whitespace at the beginning and ends of lines should not change how any JavaScript works. I guess the issue here is that CkEditor might not reformat the JavaScript when someone is editing it. I ran a test on this, and CkEditor properly formatted the JavaScript even though whitespace had been removed from the lines in the database. So, this doesn't seem to be a real concern.

Indiscriminately destroying the existing explicitly requested layout when you happen to load and resubmit an article for making an innocent change elsewhere basically makes the submission form unusable.

One of the problems is that CkEditor does this anyway. Stripping off whitespace undoes some of the damage and keeps things more uniform.

In particular, I could no longer use it to replace a static setup image by an Interactive Diagram without running a large risk to irreversibly damage the page.

I don't know all the details about how interactive diagrams work, but the one on this page seems fine, and it has had whitespace removed from each line. Maybe you could make sure that static setup images do not rely on whitespace at the beginning or end of lines.

It is far easier to delete whitespace you don't want than to add whitespace that got erroneously deleted, as you would not always know exactly how much whitespace there originally was, and where.

You can check an earlier revision to find out exactly how much whitespace needs to be preserved, and you can use NOBR or SPAN tags to preserve it. Also, deleting whitespace is not an easy job when CkEditor keeps indenting the HTML code. So, I'll disagree on what's far easier.

The most important property of an edit function is that when you activate it, alter nothing, and save, that you have not altered anything, and certainly not anything essential.

If I could figure out how to get CkEditor to behave that way, it would help a lot. Since it doesn't behave that way, it helps to rein things back in by trimming off excess whitespace.

I think the best solution to the addition of leading whitespace in textareas that are used as input for Game Courier is to have Game Courier itself strip off such whitespace. Just as I have done for the Interactive Diagram.

As I already described in my prior comment, there was another issue. The TEXTAREAs looked bad due to excess whitespace that was caused by how CkEditor formats the HTML by putting extra whitespace at the beginnings of lines.

PRE tags are typically used for no other reason than to preserve indentations

But is that an appropriate use for them? Please point me to a page that does this, so that I have a better idea of what you are talking about.

Dagger Chess uses pre tags for board diagrams. Napoleonic Chess has some of the rules pre formatted, although it could be done better.

Since these are both HTML pages, they are unaffected by how member-submitted pages are saved to the database. In general, I would like to encourage people to replace ASCII diagrams with images and PRE formatted text with HTML formatted text.

However, I have just made the use of CkEditor, htmlspecialchars, htmlspecialchars_decode, and my trim_lines function dependent on $useshtml being true. This should make it easier to edit pages originally done entirely as PRE text.