I have installed ClassExtender, created the table for the extended user data and activated the plugin. The extended fields and input form appears when editing users but when we attempt to save the input all appears fine but, the data is not stored in the extended table. There is nothing in the error logs to indicate what the problem may be.
Give a man the answer, and he’ll only have a temporary solution. Teach him the principles that led you to that answer, and he will be able to create his own solutions in the future.
Is the ExtraUserFields plugin enabled (activated)? Just right-click on it in the tree to check.
Thanks Bob, but if it wasn't enabled I wouldn't have the fields available to fill in and know it wasn't saving. After several sleepless hours last night the only thing I can think of doing between having the data saved to the ext_users_data table and not saving was tinkering with the table collation setting on one of my 'lookup' tables for building a drop-down list for an extended user field to try to show French accents rather than some odd ASCII rendering of their values. I don't know if this would make the difference between saving the data or not. I'm a bout to attempt to reset things back as they were. Watch this space as they say.....
Give a man the answer, and he’ll only have a temporary solution. Teach him the principles that led you to that answer, and he will be able to create his own solutions in the future.
The only other thing I can suggest is to make sure the names (as in <input name="some_name") in the Tpl chunk exactly match the field names in the custom DB table. You've probably done that already.
A character set issue could be a cause, but it's kind of a long shot. SiteCheck would tell you if there's a mismatch.
It might also be mod_security if there is a field name in the extra fields that mod_security doesn't like.
The only other thing I can suggest is to make sure the names (as in
Thanks again Bob.
After another day of head banging I can't say I'm any further along. I did run SiteCheck which picked up a few things but nothing relevant to my current problem.
At least I have worked out a plan B which will get my client off my back until I get the 'ExtraUserFields' plugin behaving as it should. I used the same Tpl chunk so there are no conflicts with the field names in the custom DB table.
I can't say it has all been a wasted effort, just frustrating, as I am gaining a renewed understanding of Modx and PDO which has to say the least become very rusty over the past few years. The path to Bob's Blog is becoming 'very deep and wide' and my copy of MODX The Official Guide is getting well worn! I, for one really appreciate all the effort you have put into these projects.
Jim
Give a man the answer, and he’ll only have a temporary solution. Teach him the principles that led you to that answer, and he will be able to create his own solutions in the future.
Thanks for the kind words. I'm sorry I couldn't be more help.
No problem we will get it in the end, and your Disgustingly Foolproof Bread is half bad either!
Give a man the answer, and he’ll only have a temporary solution. Teach him the principles that led you to that answer, and he will be able to create his own solutions in the future.
I had a chance to get back to this one today and I have found the problem. I had five SuperAdmin-like users that I didn't want in the extended table. This caused an id match error, in fact the data was being updated just five entries further down the table. Sometimes we can't see the forest for the trees!
Thanks to all for their help and input.
Give a man the answer, and he’ll only have a temporary solution. Teach him the principles that led you to that answer, and he will be able to create his own solutions in the future.
