changed content not saved?

Not aware of any fix for this, but just came back from vacations... check Bugs&Support page, should be in there if there is something.

If the bug is not filed yet, please add it, it would be great !
Thanks

Thanks for your reply!
It’s already there: http://modxcms.com/bugs/task/890
Howevery, it says: Severity: low, and IMHO it’s a rather severe bug. The URL’s in every URL-type TV on a page breaks whenever that page is edited, even if the TV’s themselves aren’t touched. That’s pretty inconvenient for the editors

I think it’s not a very high severity bug because you can use the TEXT TV instead of URL. This assumes however, that people know about the bug before they deploy.

At the moment there are 152 out of 266 tasks marked as ’Bug Report’ in the tracker, which itself is not very visible. 94 of those bug reports are marked ’Unconfirmed’.

Most other TV-related bugs are rated ’Medium’.

Can anyone confirm if 0961 resolved these issues?

I’m still having these issues with 0961

Now, there’s a lot of different issues discussed here regarding the changed content not being saved, so please try and be more specific about what exact problem you are experiencing, details of your environment, things you’ve tried from the suggestions, steps to reproduce, etc. Otherwise, it’s not going to help us resolve it.

This has been an issue for me since the etomite days... I have always used firefox while in the manager, mainly it happens on fields where auto-complete takes over. If the input is in the auto-complete history I type it in fully and hit tab a few times. This works about 80% of the time. Sometimes it does not and I have to log out of the manager and try again. This only happens to me on TV’s edited from the manager, QuickEdit has never given me a problem.

This may be related to the issue of the save / edit / delete buttons needing to be clicked multiple times to trigger the action, I am not a coder, but these two click together for me.

Okay, trying to be more specific. Bearing in mind that I don’t really understand any of this stuff, this is what phpinfo gives:

PHP 5.1.2
Apache Version: Apache/2.0.58 (Unix) mod_ssl/2.0.58 OpenSSL/0.9.8d DAV/2 PHP/5.1.2 mod_jk2/2.0.2

MySQL 4.0.18

Plus loads of other info that means nothing to me...

MODx 0.9.6.1 rev 3118 (although it was also a problem on 0.9.6).

In terms of browsers:

Firefox 2.0.0.11 on Windows XP
Firefox 2.0.0.11 and Safari 2.0.4 on Mac OS X

(Same problems for all these browsers.)

So, what’s happening is that, as others have said, TV values are not being saved in some, apparently-random circumstances, when entered through the manager. Sometimes this is when auto-complete takes over, but it also happens when I just enter a value in certain TVs. For me, this has happened for plain-text fields and for dropdown menus, although removing the default value from the dropdown seemed to help. It’s never happened to me with a rich-text TV. Using quick edit always solves the problem.

I haven’t tried the hack that ZAP suggested on manager/processors/save_content.processor.php, because that seemed to be referring to a previous release, and I’m not confident enough that I’m not going to screw things up.

I’m not sure I’m adding anything new here to what everyone else is saying, and if it’s going to work fine in 0.9.7, I can probably deal with using quick edit.

@fruitwerks: It sounds to me as if you’re exactly describing the problem with the Manager’s dirtyvar JavaScript BEFORE 0.9.6.1. In the latest version, this code has been removed completely, so I don’t think that you can have the same autocomplete-related issue anymore. Basically when a field was filled by the browser’s autocomplete function the JavaScript didn’t register that it had been changed and thus didn’t updated the info upon saving. The autocomplete problem can be resolved by either applying the hack that I posted earlier (which just disables this JS) or updating to 0.9.6.1.

However, if you’re seeing a similar problem (TV values not saving) and you’re using 0.9.6.1 then this is a new and different issue. There are some posts related to this which seem to indicate that MySQL strict mode might cause something similar, and disabling it might resolve the issue. So it would be useful to know whether your MySQL installation is in strict mode and then we can see if perhaps the new SQL queries that were added in 0.9.6.1 might be problematic in this context.

The issue of needing to click the buttons (especially the bottom bar buttons) more than once for them to work is separate (although I can see how you might think the two were related).

Good info.. I am using 0961, so let me look at my MySQL settings...

mysql-5.0.44
php-5.2.4_p20070914-r2
apache-2.0.58-r2

sql_mode is not set... so strict mode is not enabled.

The db for this site was created by Etomite, but from what i understand, almost all of the structure has been replaced. So may not be important. I do have another site on the same server running 0961 - but I do not have many TV’s on there and I can’t say that I have had this issue on that site.