I don’t think that should matter, actually. If the RTEs are all working properly (no JavaScript errors), then it should be updating the content in the text field that hosts it, and if it does that then MODx should receive it as a POST variable and save it. Are you doing exactly the same thing as what I outlined above, or am I testing something different?
we’re doing exactly the same....
Olaf
btw, where do you put the closing bracket? if i change the code as you propose i get a PHP error...
Note that I commented out the first if statement and added a second one (that would always be true). Perhaps you didn’t comment out the original one? I left it there just so it would be easy to go back to it if there were a problem.
And I think I have the same issue but what is strange is that it’s with the 0.9.6 release.
What happens is, TVs erratically don’t get saved. From one document to another, a different TV doesn’t get saved from the manager while updating the value is OK with QuickEdit... this is really puzzling and frustrating
Strangest of all is, only one install exhibit this behavior (and the install is on the same server my other installs are located).
I’ll try your fix ZAP, and report...
.: COO - Commerce Guys - Community Driven Innovation :.
MODx est l'outil id
.: COO - Commerce Guys - Community Driven Innovation :.
MODx est l'outil id
-
☆ A M B ☆
- 24,524 Posts
I just installed the latest SVN, rev 2853, on a localhost MAMP that has never given trouble before, and TVs are not getting saved when saving a document. I’ve looked at the save_content.processor.php file, and it appears to have several modifications from what is described in the fix here. Any suggestions?
I was having the same problem and this fix appears to solve it (thanks!
). But I’m also having the issue Shuriken mentions (URL TV’s get corrupted whenever the page they’re in is edited), and that problem is still there. I suppose nobody happens to know a fix for that..?
Thanks for MODx - I love it!
