Custom Field creation seems to be failing

-- HikaShop version -- : 2.6.4
-- Joomla version -- : 3.6.2
-- PHP version -- : 5.6.16

I have a Product which requires a Custom Field ( "Item" ).

Whenever I create a new Custom Field, the form asks me for a column name but then HikaShop doesn't use it. I wind up with a database value in that field with a name similar to "customtext_256_17_26_45" and no fields are added to the "cart product" or "order product" database tables at all.

The creation process appears to be stopping the setup before completing but not throwing an error. However a field I created earlier in the site's history worked properly.

If I manually add columns to the aforementioned tables, the value I provide is not carried into the cart whenever the Product is added to the cart.

Any suggestions?

Hello,

Can you provide some screenshots like these of :
- Your Custom field listing (Item)



- Your Custom field Configuration



Note : That's we don't recommend to manage your data directly in your data base, you have a risk to create some side effects...

Awaiting news from you.

Regards

I don't tweak the databases manually on live sites, but I do examine them carefully during development to learn how they should operate, and occasionally modify/insert a value and restore the table afterwards if an interface is obviously displaying missing or irregular information. In this case, a little tweaking on my dev site turned up the answer.

It turns out that the Custom Field type "Custom Text" is literally behaving as if it only inserts text, despite accepting a Regular Expression Check for input values. Since this type of item actually expects no input, it does not create any data fields in any tables in which to store it, and thus does not accept the provided custom field Column Name value. I was previously using the field to create a dynamic input list, one where the options depended upon the value of an existing Characteristic list.

Because the Custom Text type of Custom Field does not look for input, I've been forced to create a second Custom Field to receive the output from my own Custom Text interface, and then forced to use CSS to hide that second Custom Field from the viewer. This solution has worked - the javascript supplied value of the second Custom Field is added to the Cart Product and stored with the Order Product.


Because I have two more sites that could make use of similar behavior I would like to suggest a few changes to HikaShop to make it simpler:

A) remove the input Regular Expression Check from the Custom Text type, perhaps add a note that Custom Text supports no custom written input.

add a Custom Field Type for a Hidden input field, and possibly include the option to hide any Custom Field's Label display.

Hi,

Thank you for your feedback.

a. We'll do that for the next version yes.

b. I don't see why this would be necessary. If you want a hidden input, then it means that you're a developer because you're adding stuff to that hidden input. In which case, you could as easily have a normal "text" field and hide it with CSS.
Hiding the label could be an option but then, why not simply leave the label empty in the custom field ?

re: a) You might consider removing the Column Name field for Custom Text as well. As far as I can tell, it is not used either.

re: b) 'm just suggesting an explicit way to support the adding of hidden input fields, fields which others might use to include some predetermined but non-user-friendly data into the records regarding specific products rather than, as I am doing with increasing frequency, as a target for javascript. Another reason to do so is that recent javascript implementations seem to be policing CSS masked fields for security purposes: input fields with "display:none" are not reliably submitted or validated, so that data hidden by CSS is not surreptitiously inserted. I don't know if this is Javascript or JQuery doing this, but we've seen it several times in the past year. Also, using the CSS command "visibility:hidden" keeps the empty white space in the layout that the field would have used. It's just a great deal of hassle compared to a supported hidden input type.

Hi,

Thank you for your feedback. We'll consider it.