Comments/Ratings for a Single Item

The problem comes from the "Visibility" switch which automatically directs to the WYSISYG mode.

The line for the WYSIWYG option was making it selected if the format was HTML. This was incorrect, and I changed to be selected if the format is WYSIWYG. I also put back the unconditional call to switchFormat(), because it was needed to call up CkEditor for HTML or WYSIWYG mode.

@Fergus: No, the pop-up has disapeared but the trouble is still there!

The problem comes from the "Visibility" switch which automatically directs to the WYSISYG mode.

What is in the first section of the page survives but the rest is strongly affected. An html block describing an ID diagram is either completely screwed or simply erased if it was in the Notes section (as I had laid my pages).

I think something should be done especially if this is path to follow when an author wants his/her page going from a Work-in-Progress to a Submission-to-be-reviewed. Or is there another way of doing it?

To my understanding, going to "Edit Metadata for this page" automatically switched to WYSISYG, and then it affected html. So not only in the Notes section, everywhere on the page, so an ID description could not survive. I worked it out by saving my html in a buffer text before, then copying it back after changing the Metadata.

I'm going to check if that has changed now.

When wanting to change the metadata using "Edit Metadata for this Page" (in order to pass a page from "Your Work in Progress" to "Your Submissions awaiting review"), as soon as "Send" is pressed, one gets this pop-up:

I stopped the pop-up by deleting the line that runs switchFormat() unconditionally. It will now run only when someone changes the format.

And even if Cancel is selected, the result is that all text inside the Notes section of the page is DELETED!

I didn't see that happen in my tests.

@Fergus: please have a look at this.

When wanting to change the metadata using "Edit Metadata for this Page" (in order to pass a page from "Your Work in Progress" to "Your Submissions awaiting review"), as soon as "Send" is pressed, one gets this pop-up:

WARNING: WYSIWYG mode may replace some characters with HTML entities, which may corrupt query strings in URLs. Do you still wish to use it?

And even if Cancel is selected, the result is that all text inside the Notes section of the page is DELETED!

Can you correct this please

Thank you

@Fergus: is it possible to open "Edit Metadata for this Page" WITHOUT erasing what has been put into the Notes section of that page?

This is really annoying

Thanks

Aaaaarrggg

Yes it looks simple. Thanks Bob, I didn't know that (not sure it is explained somewhere).

But...

But when I go to the Metadata, I get a warning that it will go to WYSIWYG mode. I cancel. But, anyway it screwed all my ID!

I understand that opening Metadata is empting the Notes section. This is where I had written the codes of the ID.

Why it is like that?

I guess when a new page is made it goes into 1). How then does it go to 2)? Is it in the hand of the author, as it should be in my opinion? But I don't see no button or anything else to do this.

It's fairly simple: go to Edit Metadata (for each page), and change the Visibility from Private to Members-Only.

@Editors

I would like to understand how it works now with submissions.

Two categories have been created and separated, which is a very good thing:

1. Your Works-in-progress
2. Your Submissions awaiting review

I guess when a new page is made it goes into 1). How then does it go to 2)? Is it in the hand of the author, as it should be in my opinion? But I don't see no button or anything else to do this.

This afternoon I have completed 8 pages (with GC presets) that should go from 1) to 2).

On the contrary, I have 1 page (Exachess) which has been put in 2) whereas it is not at all finished, it is in-progress and should be in 1). I have posted a comment weeks ago for this, but nothing has changed.

So, I would like to understand how it works.

It seems that, since about one week ago, the short description of a newly submitted game is not stored.

Okay, that should be fixed now. I ran a test, and the short description got filled in.

It seems that, since about one week ago, the short description of a newly submitted game is not stored. I submitted two games in this week, and both don't show the description (and I'm sure I didn't forget to enter one).

Try it again. I added some code to translate values to integers when integer values are expected.

Fergus, you were able to see proper sql error messages in the logs before; can you get those to print in the helper function?

I think we use 0 for infinite/indeterminate.

Since some days I can't create a new game page. After filling out the form and clicking on "step2" it only says:

"adding item entry..."

but nothing happens. The game page doesn't show up in my unreviewed submissions. Clearing the browser cache didn't help.

BTW: what should I enter in the "Rows", "Cols" and "Cells" fields of the form if I want to post a chess variant on an infinite board or on a board whose number of cells/squares can change during the game?

Editors can do it with the editlink.php script, but we currently have no script for letting authors do it. So, add a comment to your page about what you want the description to say, and someone will add it for you.

update test

How can I edit the description of a page already created? I mean the description that shows in the listings of pages.

Specifically I want to add a description to Square Attrition Chess so that it does no longer show the bold "Missing description".

Ah ha! That must be it; the name I was trying to use was "Handicapped Almost Chess", which is 23 characters, if I counted right. Thanks!

Looking at the PHP error log for errors on the relevant script today, I got this:

[20-Dec-2022 06:20:55 UTC] PHP Fatal error:  Uncaught PDOException: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'LinkItemID' at row 1 in /home/chessvariants/public_html/index/membersubmission2.php:382
Stack trace:
#0 /home/chessvariants/public_html/index/membersubmission2.php(382): PDOStatement->execute()
#1 {main}
  thrown in /home/chessvariants/public_html/index/membersubmission2.php on line 382
[20-Dec-2022 06:23:56 UTC] PHP Fatal error:  Uncaught PDOException: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'LinkItemID' at row 1 in /home/chessvariants/public_html/index/membersubmission2.php:382
Stack trace:
#0 /home/chessvariants/public_html/index/membersubmission2.php(382): PDOStatement->execute()
#1 {main}
  thrown in /home/chessvariants/public_html/index/membersubmission2.php on line 382

If this was you, your group names were too long. Their maximum length is 16 characters.

Fergus would probably know straight away what the problem is.

If I knew straight away what a problem was, I probably would have fixed it already. Problems are normally unexpected and require investigative debugging to figure out.

Is there some problem with the Post Your Own Game page? When I enter game information and press the 'Step 2' button I get nothing but a blank page with the text '$personid is CroydThoth' (my username) at the top.

For me this appears to work normally. But it might depend on what exactly you entered as data in the first step. Fergus would probably know straight away what the problem is. However, I happen to be working on an enhanced copy of the submission pages, and I put some additional diagnostic output in those that could be helpful for determining which path exactly you take through the script, and thus where it might run aground. So if you want you could try to submit through this page, and tell me what is printed in that case.

[Edit] I did discover a flaw in the submission2.php page: the <LABEL> tag for the format SELECT is not closed. This cannot cause the effect you describe, though. But it had the nasty consequence that any mouse click on the page would scroll it back to get the SELECT in view.

Is there some problem with the Post Your Own Game page? When I enter game information and press the 'Step 2' button I get nothing but a blank page with the text '$personid is CroydThoth' (my username) at the top.

Apologies if this is a duplicate comment, pressing 'Post' didn't seem to work the first time.

I also use WYSIWYG mode for submitting comments. My only reason for using HTML is when I want to embed active elements (like Interactive Diagrams) in the submission. Links, images, pre-formatted text and such are all supported in WYSIWIG mode.

In general I find the indentation enforced by the CkEditor in HTML mode helpful. Apart from HTML it also appears to understand embedded JavaScript, and the nice layout prevents errors. I thought that ending 'solo tages" like IMG or BR with /> was actually the HTML 5 standard, so you can hardly blame the editor that it enforces that.

Only very rarely the mangling of whitespace by the Ck Editor backfires. One case was for posting Interactive Diagrams: the definition of those must be given as text within a HTML tag pair (like DIV or TD) which normally ignore leading whitespace in their content. So the Editor indented the definition line, while the original Diagram script expected the definition lines to be left-adjusted. So I had delete all leading whitespace from the Diagram definition before saving each time I edited a submission containing a Diagram. I quickly got tired of that, so I just had the routine in the Diagram script that parses the game definition strip the leading whitespce. (As well as trailing BR tags, which tend to appear there when you copy-paste from HTML Page Source.)

I think the only reason we are discussing this issue is that we now have identified a second (quite rare) case where the adding of leading whitespace backfires: text within TEXTAREA tags. Apparently this is a blind spot of the CkEditor: it does recognize PRE tags, and knows it should not mess with the layout there. But it appears to not do the same thing for TEXTAREA, while it should: this is another context where the text between tags should not be messed with.

While I see plenty of reasons why one could want to use pre-formatted text in submissions through PRE tags, I only see very few for TEXTAREA. The Play-Test Applet uses a TEXTAREA for pasting an existing Interactive Diagram into it (so you can convert it to GAME code, or get a table with verbal descriptions of the moves. But it starts out empty. But it appears that invoking Game Courier as a game viewer would be another application, and the first and only article I so far encountered that did this was Asylum Chess.

Logical solution would be: (1) Make Game Courier strip the leading whitespace the CkEditor added, so that it no longer matters (like I did for the Diagram). (2) Fix the Ck Editor so it treats TEXTAREA the same as PRE (not adding any whitespace). (3) Let the submission script delete leading whitespace only between TEXTAREA tags. This cannot be too hard. (4) Let the submission form test whether the page being edited contains TEXTAREA tags by itself, and only in that case suppress the use of the CkEditor. The text input fields of the form have the standard editing capabilities (which you have to rely on when JavaScript is switched off, as the CkEditor is a JavaScript program).

I think we should keep the current WYSIWYG editor unless we find a better one. It is what I generally use. For quoting people and typing responses, often with formatting, I think it's the easiest and most intuitive of the methods. Mangling whitespace is a potential issue, but it doesn't seem to manifest much in practice.

I made a slight tweak to how the Text format works. It used to put PRE tags around any text. It will now put PRE tags around the text only if the text does not contain any HTML tags. This will allow the Text format to be used for entering HTML without CKEditor. Note that it could already be used to enter HTML, but that HTML would appear within PRE tags.

If you want to mix in HTML without including P tags around paragraphs, Markdown will let you do that. Since HTML works in any browser without translation to another format, HTML mixed in with another format still works.