[Tiki-devel] Wiki: Autosaved drafts have URL-encoded content (was Re: Decoding HTML special characters in page sources)

[Filipus K. <ch...@gm...>]

Hi Jonny,
I confirm the problem you're talking about. But indeed, it is also 
broken in 8.x (as far as 8 beta. It is working in 7.x). Also, the 
problem is URL-encoding, while the issue we were discussing is 
HTML-encoding.

Le 2012-01-05 06:25, Jonny Bradley a écrit :
> Hi Chealer
>
> When you try and use the autosaved version (by clicking "There is an autosaved draft of your recent edits, to use it instead of what is current displayed click here") the previous version comes back url encoded (in wiki or wysiwyg).
>
> It does seem quite fragile as i'm sure i've fixed that at least three times in the recent past...
>
> Seems it's broken in both trunk and 8.x and i was just wondering if it was related to this (sure it worked in 7.x)
>
> Apologies if it's something else, i wasn't really paying attention to commits during 8.x as you know.
>
> jonny
>
>
>
> On 4 Jan 2012, at 20:14, Filipus Klutiero wrote:
>
>> Hi Jonny,
>> how is autosave broken?
>>
>> Le 2012-01-03 10:33, Jonny Bradley a écrit :
>>> Is this what might have broken autosave?
>>>
>>> jb
>>>
>>>
>>> On 30 Dec 2011, at 17:57, Filipus Klutiero wrote:
>>>
>>>> I don't know but I'm not aware of other problems. The problem in
>>>> tiki-editpage.php was already there as of r1324. I think it's just an
>>>> old error specific to the wiki that nobody had gotten to fix.
>>>>
>>>> Le 2011-12-30 11:55, Marc Laporte a écrit :
>>>>> Also, what about all the other text? (articles, blog posts, forum posts,
>>>>> etc.)   Is the format OK?
>>>>>
>>>>> Thanks!
>>>>> On 2011-12-29 7:53 PM, "Marc Laporte"<ma...@ma...>    wrote:
>>>>>
>>>>>> ok, well it's really good that we are doing this early as it gives ample
>>>>>> time to find issues and figure out a solution.
>>>>>>
>>>>>> I don't think profile server can indicate what version but maybe that's a
>>>>>> good idea.
>>>>>>
>>>>>> I am more worried about WYSIWYG issues though... Geoff should give us some
>>>>>> feedback in the coming weeks...
>>>>>>
>>>>>> Thanks!
>>>>>> On 2011-12-29 2:55 PM, "Filipus Klutiero"<ch...@gm...>    wrote:
>>>>>>
>>>>>>> Le 2011-12-29 12:54, Marc Laporte a écrit :
>>>>>>>> Hi Philippe!
>>>>>>>>
>>>>>>>> 1- Fresh install of 9.x on: http://demo.tiki.org/trunk2/
>>>>>>>> 2- I applied the http://profiles.tiki.org/Slideshow_demo
>>>>>>>>
>>>>>>>> 3- I get {img src=&quot;https://tiki.org/dl221&quot;}
>>>>>>>>
>>>>>>> http://demo.tiki.org/trunk2/tiki-pagehistory.php?page=Tiki+Wiki+CMS+Groupware&source=0
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> M ;-)
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Dec 15, 2011 at 10:06 PM, Filipus Klutiero<ch...@gm...>
>>>>>>>   wrote:
>>>>>>>>> Le 2011-12-13 13:02, Philippe Cloutier a écrit :
>>>>>>>>>> Hi,
>>>>>>>>>> we have encoding problems with differences of wiki page versions. The
>>>>>>> page
>>>>>>>>>> data in the database is stored escaped in tiki_pages and
>>>>>>> tiki_history. That
>>>>>>>>>> causes the side by side diff function in wiki page edition preview to
>>>>>>> show
>>>>>>>>>> untouched HTML special characters as modified. It also shows the
>>>>>>>>>> differences in versions double-encoded in page history.
>>>>>>>>>> It seems page content was stored that way since about forever. I
>>>>>>> changed
>>>>>>>>>> the storage format in trunk, but for existing installs a conversion is
>>>>>>>>>> needed.
>>>>>>>>>>
>>>>>>>>>> I made a script to do that this morning. The script must HTML decode
>>>>>>> page
>>>>>>>>>> data, but only when data is Wiki syntax, not when it's HTML. I put a
>>>>>>> check
>>>>>>>>>> for that, but I'm not sure that will work well in all cases (including
>>>>>>>>>> WYSIWYG). Code reviews and testing would be appreciated. Considering
>>>>>>> the
>>>>>>>>>> risk, I reverted my changes in
>>>>>>>>>> http://sourceforge.net/apps/trac/tikiwiki/changeset/39171
>>>>>>>>>> If you can, please locally revert 39171 (which will restore my
>>>>>>> changes) and
>>>>>>>>>> test.
>>>>>>>>>>
>>>>>>>>>> While HTML encoding then HTML decoding is idempotent, HTML decoding
>>>>>>> then
>>>>>>>>>> HTML encoding is not. The conversion script intends to decode HTML
>>>>>>> encoded
>>>>>>>>>> data, but if it decodes data which is not HTML encoded, it could
>>>>>>> slightly
>>>>>>>>>> corrupt data (HTML encoding the result won't necessarily restore the
>>>>>>>>>> original situation). The script archives the previous version of
>>>>>>> pages if
>>>>>>>>>> history is enabled, but previous versions could be lost if history is
>>>>>>>>>> disabled.
>>>>>>>>>>
>>>>>>>>>> I intend to revert r39171 in the next days if no one finds problems
>>>>>>> in it.
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>> I did that in r39206.
>>>>>>>>>
>>>>>>> Thank you Marc. I reproduced this on my trunk. Sorry, I did not think
>>>>>>> about the impact on profiles. I fixed the problem you had in r39346.
>>>>>>> However this is incorrect for Tiki 9 and above profile servers. I do not
>>>>>>> think this is a problem, as an encoding issue importing cannot directly
>>>>>>> cause data corruption. But the ideal would be to act differently
>>>>>>> depending on the version of the profile server. If the profile
>>>>>>> infrastructure has a mechanism to know the remote version, please tell me.
>>>>>>> I did not think about importation and exportation when I committed
>>>>>>> r39206. I don't really know all of Tiki's possibilities in the area.
>>>>>>> There may be more issues of the kind.