changed content not saved?

Hello,

we’re using MODx 0.9.5 and it seems that quiet often changes in the content aren’t saved. We don’t have a clue why this happens? Cache is disabled.

Olaf

Please download the latest SVN Trunk build and see if the problem persists. It is effectively 0.9.6.

ok i will see what i can do..we’re currently in a heavy big-deadline live prototyping session, so i don’t know if it’s smart to upgrade this production-site to 0.9.6 yet, but i will try to make some time to test it on a staging-environment and see if i can reproduce the problem

Olaf

i tested with a 0.9.6 rc1 version i had already installed...and the same behaviour appeared. It seems to have something to do with multiple WYSIWYG TV-fields assigned to a page, and the combination of only images in the WYSIWYG-fields. I suspect it has something to do with focus of the rich-text fields, because when i click on an image and the select save it seems to go better.

Olaf

Quote from: olafmol at May 14, 2007, 10:08 AM

i tested with a 0.9.6 rc1 version i had already installed...and the same behaviour appeared. It seems to have something to do with multiple WYSIWYG TV-fields assigned to a page, and the combination of only images in the WYSIWYG-fields. I suspect it has something to do with focus of the rich-text fields, because when i click on an image and the select save it seems to go better.

What are the TV input and output settings? Are these Image TV types with a separate resource browser button, or just Textarea types where users go to the resource browser from within the RTE?

rich textfields mainly

This has bothered me too with 0.9.5 and now with 0.9.6-RC.

TVs won’t get (never?) saved if user won’t actually type something to a TV text field. I mean a situation like... if user just clicks on a TV text field and selects someting he has already typed before and submitted to the field on other document (eg. saved form data feature in Firefox).

@olafmol: I didn’t have luck reproducing this, but then again, I don’t use the RTE’s (TinyMCE, FCK, etc.) very often myself. A bug report to track this specific issue would be wonderful...

I can say this will be gone with 0.9.7, which is getting a major manager overhaul in addition to the rewritten core engine. The problem is likely because the onchange event must be fired for any TV form input to change the state of a documentDirty variable. This flag tells the manager if anything has changed in the page that needs to be saved.

Quote from: OpenGeek at May 15, 2007, 09:40 AM

The problem is likely because the onchange event must be fired for any TV form input to change the state of a documentDirty variable. This flag tells the manager if anything has changed in the page that needs to be saved.

Yes! That explanation makes sense to me, and this is something that has been bugging me for a long time now. This happens consistently when selecting pre-entered text (from a browser’s autotext dropdown) in any type of TV, including regular text fields, in every post-0.9.5 version of MODx that I have tested.

At least this implies that a workaround would be to select the previously-entered text but then also enter a space in the field and then delete it again (or something quick and easy that would dirty the variable). Another option would be to have a bogus checkbox TV that just exists to become dirty (check or uncheck it just to make sure that changes are made). I assume that the dirty var is JavaScript, and if the browser doesn’t register a change when selecting autotext a true fix may involve a complete rewrite of that code (which is already in the works for 0.9.7 anyway).

Will the 0.9.7 manager rely more on back-end validation instead of JS?

Quote from: ZAP at May 15, 2007, 10:47 AM

I assume that the dirty var is JavaScript, and if the browser doesn’t register a change when selecting autotext a true fix may involve a complete rewrite of that code (which is already in the works for 0.9.7 anyway).

Correct, it is Javascript code, and that has been mostly rewritten already.

Quote from: ZAP at May 15, 2007, 10:47 AM

Will the 0.9.7 manager rely more on back-end validation instead of JS?

Well, it makes extensive use of AJAX-based form-validation through a set of AJAX connectors that are responsible for interacting with the data, so yes to back-end, and no to instead of JS...