I don’t know if it’s something I’m doing wrong or a quirk with ClassExtender but every time I run a (CE) update it wreaks havoc and I get a load of “User not found, or no data exists for those fields” errors popping up on the front-end where normally it would show the custom (screenName) field I created using CE. The solution usually requires several rounds of deleting and reinstalling and reentering all the values for the CE fields. It’s hugely frustrating and a time drain. I don’t even want to install the latest 2.3.3 update at this point.
Is there a specific process for updating CE that I’m not understanding?
No. It either wipes the extended field(s) of its value or it replaces the value with the name of the placeholder for that field. For example: [[+firstName]]. So I have to manually reenter the value for each field.
So it looks like something gets overwritten on the update. Most likely the class files or maybe a chunk.
Do you use the chunks “MyExtUserSchema” and “MyExtraUserFields” for schema and manager input fields? Do they still contain your custom content after the update?
The class files are stored in core/components/classextender/model/extendeduser (with the default settings). These are files like “userdata.class.php” and “mysql/userdata.map.inc.php”. Do they still contain your custom content after the update or do they get replaced/deleted?
(These class files are used to represent your custom database table ext_user_data as a class in PHP.)
Do you use the defaults for “Package Name”, “Table Prefix” etc. or do you use custom values?
I’m still a bit confused. So if the database table ext_user_data (and its content) still exist, why do you have to reenter values?
If the class files get overwritten, then it might be necessary to parse the schema again. But the data shouldn’t be lost.
I do use the “MyExtUserSchema” and “MyExtraUserFields." Yes, they remain intact after updating.
The class files you mention look to be defaults, at least I don’t see any custom content that is from anything I’ve done.
No custom Package Name.
As for a prefix, I use a “ce” prefix with the [[!setUserPlaceholders]] snippet e.g. [[+ce.firstName]] as recommended by @bobray to avoid any potential conflict with the Profile extra I also use. Beyond that I have not altered the table prefix.
As for reentering the form values I do it because they always get wiped after updating. That is the major crux of this entire problem. I wish I knew why it happens but I don’t.
There was a bug in previous versions (< 2.3.3) that disabled the plugin after upgrades. Could that have contributed to your problem? There was also a bug where the autoloader could load the wrong class file, but I don’t remember the details of that one. Those are both fixed in 2.3.3.
Well, I would certainly like to update to v2.3.3 but I’m hesitant to do so at the moment in case I have the same issue as before.
Up to now (prior 2.3.3) the only way I’ve been able to get things working again after upgrading the plugin and running the Extend modUser file was to delete the ext_user_data table then rerun Extend modUser. Assuming it worked on the first try (it doesn’t always) then I have to reenter the values for all of the CE extended fields that got wiped clean. If I didn’t have so many extended fields it wouldn’t be so tedious but at the moment I just don’t have the energy to try. I will at a later time.
You only need to run Extend modUser file again if you are upgrading from a version < 2.0.
I think I may see your problem. The properties of the SetUserPlaceholders snippet are overwritten when you upgrade. That wipes out your placeholder prefix so the snippet is trying to set the placeholders with no prefix.
The easiest solution is usually to include any properties you’ve changed from their defaults in the snippet tag (before you upgrade):
[[!setUserPlaceholders?
&prefix=`ce`
]]
Another option is to create your own custom property set for the snippet.
Hi @bobray . I added &prefix=ce to all the [[!setUserPlaceholders]] calls a while ago on your recommendation I use a prefix to avoid some conflicts I was having at the time with other plugins.
I think this would only affect the back-end (MODX manager).
A problem with the autoloader would probably explain the problem. If MODX doesn’t know the custom class, it can’t load the data.
In the file .../extendeduser/mysql/userdata.map.inc.php, there should be a PHP representation of the <object> in your schema with all the custom fields you defined.
So you intentionally deleted your custom database table with all the data in it?
Don’t do that. If you really have to recreate the table (which I doubt is necessary), rename the old one and then either copy the data into the new table (with SQL) or rename it back.
As for the table I’ve tried duplicating/renaming it on numerous attempts but it hasn’t been a viable workaround for me, just more of the same. That’s what eventually lead me to try the nuclear option of deleting the table and regenerating a new one via the plugin. Believe me, I don’t want or like deleting it but when nothing else works you do what you gotta do.
The second one is not really a form. It’s a progress report and reminder of your values. It shouldn’t have a submit button and the “inputs” should be read-only.