Edit error: Sorry, the form could not be submitted. Please try again.

demoncleaner · 2014-10-31 08:41:13

Thank´s Uli and Grüße nach Köln!

I think I could narrow it down now pretty well (eh or better to say – solve it) by setting up another instance of my buggy textpattern installation and going back and forth deleting and restoring things.

First of all – at least for me – it is not a problem of any plugin. Also smd_macro has got nothing to do with it.

In my case I found out that it was a hidden character in a headline which I copy and pasted from a pptx file. The hidden character was just a linebreak but clashes the whole writing-and-saving-system it seems.

You cannot see it in the database but when deleting the last character of the headline it seems to do nothing. Pressing again the backspace-key deletes then the last letter. Undoing both steps and repeating just the first “ghost”-delete solved my problem.

Which would be an explanation why people think that it went away after some time like “nothing happened”.

Shouldn´t textpattern kick out all types of styling and hidden characters somehow when copy and pasting stuff?

I am really curious what you think about that and if there is any relation to the origins of the appearance of this error message on other peoples txp installations.

Last edited by demoncleaner (2014-10-31 08:41:41)

Bloke · 2014-10-31 09:51:28

demoncleaner wrote #285293:

smd_macro has got nothing to do with it.

Phew!

Shouldn´t textpattern kick out all types of styling and hidden characters somehow when copy and pasting stuff?

If it’s in the body field then no, it leaves it exactly as you type (or paste). The Title is sanitized to create the url-title but pretty much everything else is left verbatim so if there are rogue characters in the stream which trip up the AJAX save process then we’ll need to find out what they are.

Do you have a backup of the DB that contains the post with the rogue character in it? If you could export that record from phpMyAdmin and mail me the resulting .sql file with the relevant row from the textpattern table, along with a hint of which header you found it on, I can try to isolate the character code and see if there’s anything we can do in the save process to circumvent the issue in future. The rogue newline is probably not being escaped properly and is therefore breaking the Javascript.

Thanks.

kees-b · 2014-10-31 10:00:58

demoncleaner wrote #285293:

In my case I found out that it was a hidden character in a headline which I copy and pasted from a pptx file. The hidden character was just a linebreak but clashes the whole writing-and-saving-system it seems.

You cannot see it in the database but when deleting the last character of the headline it seems to do nothing. Pressing again the backspace-key deletes then the last letter. Undoing both steps and repeating just the first “ghost”-delete solved my problem.

Which would be an explanation why people think that it went away after some time like “nothing happened”.

Interesting find! As our content is copy/pasted from all kind of sources this could have occurred to us too. But…. After the problem showed up in one article it persisted for quiet some time, and in all articles. Or did you mean that by: …clashes the whole writing-and-saving-system it seems.?
All new articles in our site were saved fine but at a second edit the popup jumped up. Problem disappeared (twice) after some/many days.

Anyway it has not happened again recently…

kees

Last edited by kees-b (2014-10-31 10:07:18)

demoncleaner · 2014-10-31 10:48:17

After I dropped the post in this thread I realized that even pasting the headline with rogue characters in my text editor (sublime text 2) the hidden character is still there and shows the same behavior as in phpmyadmin. So it seems it is pretty hard to deal with it even in other programs. But maybe that info is not surprising for you.

I have a backup of the buggy table and it is on its way to you with some explanation.

demoncleaner · 2014-10-31 10:49:41

Kees, it happened in all articles. Eventhough the bad boy was hiding in one title of one specific article only.
So your description of its behavior was identical to what happened here.

Last edited by demoncleaner (2014-10-31 10:56:38)

Bloke · 2014-10-31 11:57:30

demoncleaner wrote #285307:

I have a backup of the buggy table and it is on its way to you

Thank you very much. Pulling out my trusty hex editor, the rogue character is the Unicode representation of a newline. The hex sequence E2 80 A8 is to blame, representing \u2028. And we’re not alone. Apparently \u2029 is also problematic.

Inserting your article into a fresh 4.5.7 does indeed trigger the Form cannot be submitted behaviour. But what’s baffling is that, as you noted, it occurs on every article even if that article does not contain the rogue character. Basically, the inclusion of that sequence in any article Title in the textpattern table renders saving of any article impossible. Crazy!

This must be a bug in our implementation of AJAX saves and, I suspect, the way our data is sanitized (or not, in this case). I base this assumption on being able to Publish the article fine, while the subsequent Save process is banjaxed. Publishing uses standard POSTing to the server, saves use AJAX.

Thanks for your sleuthing and bringing this to our attention. I’ll see what we can do about it.

jakob · 2014-10-31 13:35:51

demoncleaner wrote #285307:

even pasting the headline with rogue characters in my text editor (sublime text 2) the hidden character is still there and shows the same behavior as in phpmyadmin.

As an aside, Perhaps this Zap Gremlins plug-in for Sublime may help at least in eradicating them. Other text editors also have this command.

wet · 2014-11-01 09:39:07

This issue has been resolved. Thanks for the report.

kees-b · 2014-11-01 20:30:56

wet wrote #285344:

This issue has been resolved. Thanks for the report.

…. this weird one finally solved!

and now I understand too how the issue could disappear ‘automagically’

thanks to all!

kees

admi · 2014-11-05 06:13:18

Bloke wrote #285312:

Thank you very much. Pulling out my trusty hex editor, the rogue character is the Unicode representation of a newline. The hex sequence E2 80 A8 is to blame, representing \u2028. And we’re not alone. Apparently \u2029 is also problematic.

How can those E2 80 A8 representing \u2028 can get into article title? (Sorry, I dont 100% understand the issue.)

ruud · 2014-11-05 08:08:53

admi wrote #285461:

How can those E2 80 A8 representing \u2028 can get into article title? (Sorry, I dont 100% understand the issue.)

Probably because someone copy/pasted text into the article title field.

cmcnair · 2014-12-09 14:24:58

I seem to be experiencing this issue now. It’s been fixed, but the fix has not been released yet, so how do I work around this in the meantime, with the current release? Is there some way to identify which article title or titles has the problem character in it? And how would I correct the problem if I could find it — completely delete the old title, then retype it (no copy / paste) — in the form view?

(As is likely obvious from these questions, I’m not a developer…)

Textpattern CMS

Textpattern CMS support forum

#49 2014-10-31 08:41:13

Re: Edit error: Sorry, the form could not be submitted. Please try again.

#50 2014-10-31 09:51:28

Re: Edit error: Sorry, the form could not be submitted. Please try again.

demoncleaner wrote #285293:

#51 2014-10-31 10:00:58

Re: Edit error: Sorry, the form could not be submitted. Please try again.

demoncleaner wrote #285293:

#52 2014-10-31 10:48:17

Re: Edit error: Sorry, the form could not be submitted. Please try again.

#53 2014-10-31 10:49:41

Re: Edit error: Sorry, the form could not be submitted. Please try again.

#54 2014-10-31 11:57:30

Re: Edit error: Sorry, the form could not be submitted. Please try again.

demoncleaner wrote #285307:

#55 2014-10-31 13:35:51

Re: Edit error: Sorry, the form could not be submitted. Please try again.

demoncleaner wrote #285307:

#56 2014-11-01 09:39:07

Re: Edit error: Sorry, the form could not be submitted. Please try again.

#57 2014-11-01 20:30:56

Re: Edit error: Sorry, the form could not be submitted. Please try again.

wet wrote #285344:

#58 2014-11-05 06:13:18

Re: Edit error: Sorry, the form could not be submitted. Please try again.

Bloke wrote #285312:

#59 2014-11-05 08:08:53

Re: Edit error: Sorry, the form could not be submitted. Please try again.

admi wrote #285461:

#60 2014-12-09 14:24:58

Re: Edit error: Sorry, the form could not be submitted. Please try again.

Board footer