Custom user fields not saving after Joomla 3 to Joomla 5 migration

  • Posts: 70
  • Thank you received: 1
  • Hikashop Business Hikashop Essential
1 week 3 days ago #373107

-- HikaShop version -- : 6.5.2
-- Joomla version -- : 5.3.4
-- PHP version -- : 8.3.33

We have recently migrated a website from Joomla 3 to Joomla 5 and upgraded HikaShop Business to version 6.5.2.

When editing a customer through the HikaShop administrator area, values entered into the following custom user fields are not being saved:

Field ID 29: e_CopyMinderKey
Field ID 37: e_Product
Field ID 41: e_MSValid

The customer record appears to save successfully and no error is displayed. However, the values disappear when the page reloads and remain NULL in the database.

We have checked the field definitions in #__hikashop_field. All three fields:

* Use field_table = user
* Are published
* Have backend editing enabled
* Are not read-only

The physical columns also exist in #__hikashop_user:

e_CopyMinderKey — text, NULL allowed
e_Product — text, NULL allowed
e_MSValid — text, NULL allowed

The field names and physical database column names match exactly, including their case.

We tested this against HikaShop user ID 1209 / Joomla user ID 10333.

Before saving:

e_CopyMinderKey = NULL
e_Product = NULL
e_MSValid = NULL

We then entered values into all three fields through the HikaShop customer edit screen and saved the record. A direct database query afterwards showed that all three values were still NULL.

The relevant query was:

SELECT
user_id,
user_cms_id,
user_email,
e_CopyMinderKey,
e_Product,
e_MSValid
FROM #__hikashop_user
WHERE user_id = 1209;

There are no related PHP, HikaShop or database errors in Joomla’s everything.php log. The save completes and redirects/reloads normally.

The database columns currently use utf8mb3_general_ci, although the values we tested were ordinary text and dropdown/radio selections.

The field configurations are:

Field 29:

* Table: user
* Name key: e_CopyMinderKey
* Type: text
* Published: Yes
* Backend: Yes
* Read-only: No

Field 37:

* Table: user
* Name key: e_Product
* Type: singledropdown
* Published: Yes
* Backend: Yes
* Read-only: No

Field 41:

* Table: user
* Name key: e_MSValid
* Type: radio
* Published: Yes
* Backend: Yes
* Read-only: No

Could you please advise:

1. Is there a known issue in HikaShop 6.5.2 affecting custom user fields after migrating from Joomla 3 to Joomla 5?
2. Are mixed-case legacy column names such as e_CopyMinderKey still supported?
3. Is there a database migration or field resave process that needs to be run?
4. Is there a particular request handler or HikaShop file we should inspect to see why these fields are being excluded from the update?
5. Could an administrator view override created under the old HikaShop/Joomla installation cause the fields to display but not be submitted or processed?

Thanks

Please Log in or Create an account to join the conversation.

  • Posts: 86081
  • Thank you received: 14189
  • MODERATOR
1 week 3 days ago #373112

Hi,

Thanks for the very detailed report, it made this quick to pin down. You found a real bug in HikaShop and it is directly linked to the Joomla 3 to Joomla 5 migration. I reproduced it here with a field named e_CopyMinderKey and I've fixed it.

The cause is the capital letters in the field name key. When HikaShop prepares the data of a record before writing it, it normalizes the column names to lower case, so e_CopyMinderKey is passed as e_copyminderkey. Under Joomla 3 that made no difference, since MySQL column names are not case sensitive. But since Joomla 4, Joomla's updateObject() compares the name you give it with the columns of the table letter for letter, and silently drops anything that doesn't match exactly. So the column is simply left out of the UPDATE query: no error, "Successfully Saved", and the value still NULL. That is why it started the day you migrated.

To answer your questions:

1. Yes, now confirmed, and it affects any custom field with an uppercase letter in its name key, on the user, address, order and product tables alike.
2. They are supported again with this fix. HikaShop has been forcing new field name keys to lower case for years, which is why only fields created on your old installation are affected.
3. No migration or resave is needed. Note that creating a new record was already saving these fields correctly, it is only the update of an existing record that was losing them.
4. It was in checkFields() in administrator/components/com_hikashop/classes/field.php, at the line that lowercases the column name.
5. No, your view overrides are not involved here. Just download the install package of the latest version of HikaShop on our website and install it on yours and you'll get the patch for this.

Please Log in or Create an account to join the conversation.

Time to create page: 0.053 seconds
Powered by Kunena Forum