22 Nov
2011
22 Nov
'11
9:40 a.m.
On Mon, Nov 21, 2011 at 10:37 PM, Ashtar Communications
<ashtarcommunications(a)gmail.com> wrote:
Marius,
Thank you for the response. Answers to your questions follow.
On Mon, Nov 21, 2011 at 12:06 AM, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
Hi Aaron,
On Fri, Nov 18, 2011 at 11:37 PM, Ashtar Communications
<ashtarcommunications(a)gmail.com> wrote:
It is both. In view mode, $doc.display() returns one long paragraph of
text with wiki syntax embedded but no line breaks. Viewing the object
in the object editor, the box renders the WYSIWYG data as a plain text Hi,
I am having difficulty locating the source of an error where the
contents of a TextArea property for a custom class object on a page
ends up rendering in a WYSIWYG box as wiki syntax (as in, displaying
the actual code in one long paragraph). "Corrupt" is probably not the
right word for this, as I'm sure it's something I'm doing wrong...
Simple explanation:
1) User clicks a button to add a new instance of a class to the page,
which also enters the Inline Editing mode. User pastes content into a
WYSIWYG editor and saves the page. After save, the TextArea property
shows up correctly in view mode with $doc.display(), with headings,
formatting, etc...
2) Something happens - I cannot yet reproduce it, but I'm sure the
user is doing something.
3) The object starts displaying the property as a single block of text
with embedded wiki syntax, mostly what looks like custom parameters
containing the formatting info, such as:
(% class="MsoNoSpacing" %) (%
class="tagChar" style="font-size: 12pt;" %)
Is this the text displayed in view mode or the value of the TextArea
property as seen when editing the page with the Object editor? I'd
like to know the value from the Object editor.
box with the same long paragraph - but with a large
number of ~ escape
characters which do not appear in view mode.
This is an important detail. It looks like the WYSIWYG editor is
submitting wiki syntax instead of HTML, but I don't see how can this
happen because the editor converts the input wiki syntax into HTML
before it is loaded and overwrites the value of the replaced plain
text area. So if you see the content properly rendered inside the rich
text area then you know that the editor will output HTML and not wiki
syntax when you save the page.
For objects which are not "corrupted" the WYSIWYG data appears in the
object editor as wiki syntax with parameters, but with no escape
characters and embedded line breaks - these objects look fine when in
view mode.
When in Inline mode, clicking on the delete button fails to delete the
object. Instead, it just returns me to view mode with the object still
Well, I tried to reproduce this but I couldn't. The delete button
submits the inline form if you don't stop the click event and so you
are taken to the preview mode, not the view mode. Using:
-----8<-----
#set($delurl = $doc.getURL('objectremove',
"classname=Sandbox.Test&classid=$objectNumber&form_token=$services.csrf.getToken()&xredirect=$doc.getURL()"))
{{html}}<input type="image" onclick="Event.stop(event);
location.href='$delurl'" value="Delete" title="Delete"
src="$xwiki.getSkinFile('icons/silk/cross.gif')" />{{/html}}
----->8-----
I'm taken to the view mode and the specified object is deleted. None
of the remaining objects are corrupted.
etc...
Even in inline edit mode, the contents of the WYSIWYG box have been
replaced with this block of code, which does not appear with the
actual formatting - just the raw code.
Looking into the page history, there is a version of the page saved
right before the property becomes "corrupt." So something must be
happening to trigger the conversion of the TextArea content into wiki
syntax, which then gets saved over the original data.
The pages the user is using have multiple objects of the same class,
all displaying their TextArea properties in a table. The majority of
the time, it displays perfectly. This only applies to some objects on
the page - though sometimes all objects on a page will simultaneously
exhibit this behavior.
The pages also contain buttons to create a new object, as well as a
button to delete each object individually.
I have one reliable method of producing this error. I used to have the
"delete this object" button display while in Inline Edit mode -
clicking it while in that mode would cause to entry to "convert." I
How can the deleted object become corrupted? I suppose you are
referring to the other objects of the same type from the same page.
Which one gets corrupted? All? Always all?
present. Clicking on the delete button in view mode
will successfully
delete the object, however.
I have seen all the objects on the page become corrupted
simultaneously, but it is not always all. On some pages, there are
several dozen objects, but only 1 or 2 will be corrupted at a time.
Thank you, this is good to know.
I mean that when I am in inline mode and press the delete button, I am
sent back to view mode, but the object is not deleted. Instead, the
contents of the object now appear “corrupted” in both view and editing
modes. Sometimes, it seems that objects other than the one I tried to
I don't see how the delete button could trigger a page save so I don't
understand why by simply clicking the delete button the object(s)
become corrupted. In your case, I would investigate what causes the
page to be saved when the delete button is clicked in 'Inline form'
edit mode.
suppressed the button from displaying unless in view mode, which
removed this cause of the error - but there is still some other
mechanism for generating the same behavior.
Here's an example of the delete button code which I can use to cause
similar behavior:
#set($delurl =
"/xwiki/wiki/$doc.getWiki()/objectremove/$doc.getSpace()/$doc.getName()?classname=Sandbox.TestClass&classid=$obj.getNumber()&xredirect=$doc.getURL()")
Unrelated to your problem, you should never build the URL manually.
Use instead $doc.getURL($actionName, $queryString).
<input
type="image"
onclick="location.href='$delurl'"
value="Delete"
title="Delete"
style="float:right;"
src="/xwiki/resources/icons/silk/cross.gif" />
Any ideas on what's happening?
What do you mean when you say that the "entry" is "converted" when
you
click on the delete button. AFAICS the delete button doesn't submit
the inline form (so any changes will be lost) and it redirects to view
mode after the object is deleted. Are you saying that the TextArea
properties are corrupted as soon as you end up in view mode after the
object has been removed? If so, then you should see in the history
that the revision that deleted the object also modified the TextArea
properties. I doubt it.
Are you using the browser back button or the edit menu to go back to
inline edit mode after deleting an object? I'm pretty sure you are
using the back button in order to not loose unsaved changes made
before clicking the delete object button. If so, then you could be
experiencing http://jira.xwiki.org/browse/XWIKI-7028 .
delete are also corrupted. Once I am returned to view
mode, I am using
the edit menu to return to inline mode – but the contents of the
TextArea are corrupted immediately, regardless of which mode I am in.
When I compare the page history between the version where everything
was fine and the next version, where entries are corrupt, it shows the
“New Value” in green text as a single block of text, and below that,
the red strike-through text for “Previous Value” – both New and
Previous have the entire contents of the TextArea – but the “previous”
value contains line breaks and doesn’t have ~ escape characters. The
revision is not tied to the deletion of an object – it is occurring
even for revisions where no object was being deleted and other changes
were being made. For example, I have examples of pages where a new
object was added, text was pasted into the WYSIWYG editor and the
changes saved, and the version history records both the addition of a
new object, and “corrupt” changes made to other objects on the page
without the user doing anything with those objects.
I am now having some difficulty reproducing this error on demand, even
with the delete button. Since the delete button has been removed from
the inline view, it is also not the sole cause of the objects becoming
corrupted. That is, users are continuing to report objects corrupted
seemingly at random, despite the absence of a delete button.
I do not think I am experiencing the same bug as the
link you gave. I
can reproduce that one (#7028). Using chrome, if I view the page, go
to inline mode, save and view, then click back in the browser, it
returns to inline mode, and the contents of all the WYSIWYG TextArea’s
render as a block of HTML code.
However, the bug I am seeing is different – instead of HTML code, the
TextAreas are rendering as a block with wiki syntax. I’m also pretty
Indeed, XWIKI-7028 is different.
sure that I am not using the back button, and still
seeing the
contents of the TextArea being replaced. This appears very similar but
still different in some way from #7028.
Something else that may help shed light on the problem. On pages where
corruption is a problem, I am periodically receiving errors similar to
the following when attempting to save the
page:Sandbox.TestClass_2_TextArea: Exception while parsing HTML
You should check the server logs when you see this error message
because they should tell you the cause of the problem. This error
occurs when the HTML output of the WYSIWYG editor cannot be converted
to wiki syntax.
The page then refuses to save changes and stays in
Inline mode. I have
seen several JIRA listings for similar bugs, but they all appear
slightly different. As far as I can tell, the TextAreas do not contain
embedded links, and several of the JIRA bugs are listed as fixed.
Could this be related to the content of the data being
pasted into the
TextArea? It is coming directly from Word, and contains URL’s, though
none of it is in wiki syntax.
It can. Are you using the paste button from the tool bar or are you
pasting directly into the rich text area? It is recommended to use the
paste button because it cleans the pasted rich text before inserting
it into the rich text area.
For example, I just tried the following (using Chrome,
though I have
seen similar behavior in FF):
1) Page has 4 objects, each with a WYSIWYG TextArea, all displaying
correctly.2) Select “Inline” from the Edit menu3) Immediately click
“Save and View” – this throws the above exception in red at the bottom
I can't reproduce this. I even tried clicking on the save button
before the editors are fully loaded. It might depend on the value of
those text area properties.
of the page. The contents of the objects on the page
now display in
the wysiwyg editor in inline mode as “corrupt”4) Click “Cancel” – this
returns me to view mode, everything is normal.5) Close browser. Reopen
– repeat, this time, nothing happens. No error, no corruption –
despite going through the exact same steps.
The exception does not appear to be thrown on a consistent basis – I
have had users edit a page on one computer and receive an error,
leaving them unable to save the page. I then opened the page on a
separate machine, and successfully edited and saved the page with no
error.
Baffled,
Me too. I can't help much if I'm not able to reproduce..
Marius
aaron
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users