You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The verification of the custom fields is offered in admin/easypopulate_4.php where if the field is in the products table then it is added to the fields array. This process could be used to allow custom fields to come from other tables as well, if the table was identified in the custom fields entry.
To do this, would recommend a separator be used (ie colon ':') between the table and the field, then if a field is entered without a table it would default to the products table, or products could be used/identified as applicable.
While this could be incorporated, the downstream affect/change needed still needs to be evaluated in making it happen. For example two tables may not relate to one another on any primary key, but may relate to each other through some intermediate table. Without reference to the intermediate table/primary key, subsequent sql could provide conflicting information/sql error. Additionally, if there is an intermediate table, it may have another factor associated with it to provide a unique row such as a language identifier, etc... So some "growth" to be understood before just willy nilly adding the ability have other tables involved.
The text was updated successfully, but these errors were encountered:
The verification of the custom fields is offered in admin/easypopulate_4.php where if the field is in the products table then it is added to the fields array. This process could be used to allow custom fields to come from other tables as well, if the table was identified in the custom fields entry.
To do this, would recommend a separator be used (ie colon ':') between the table and the field, then if a field is entered without a table it would default to the products table, or products could be used/identified as applicable.
While this could be incorporated, the downstream affect/change needed still needs to be evaluated in making it happen. For example two tables may not relate to one another on any primary key, but may relate to each other through some intermediate table. Without reference to the intermediate table/primary key, subsequent sql could provide conflicting information/sql error. Additionally, if there is an intermediate table, it may have another factor associated with it to provide a unique row such as a language identifier, etc... So some "growth" to be understood before just willy nilly adding the ability have other tables involved.
The text was updated successfully, but these errors were encountered: