I am going to make reference to a "previous" discussion. The instructions suggest exporting a file of the type that is desired to be used for import... Why? This way one can see what is already in the database. Knowing what the output is like and having some level of familiarity of the item(s) in the store, one *should* be able to see or through some level of testing identify the effect of the various fields...
Mind you, I was going to ask how the issue was being evaluated... When saying that the page wasn't created, it helps to understand what "page" was being expected... I will note in relation to the latest post that the status field does not allow/prevent a product from appearing in the admin's products/categories listing... It *does* in general prevent the product from appearing on the catalog side (which, based on the above conversation, is likely what was being reviewed).
Now, as for the custom fields, access to the data stored and the ability to modify that data is what is provided. EP4 doesn't know what that data is, how it is used, or what basic value(s) it should contain. The instructions both in the plugin fileset as well as on the admin configuration page do indicate/suggest that when populating the configuration settings that the fieldname should be used, not v_fieldname. With the custom field information populated, exporting information associated with products should show that field name in the header of the file and (where information is provided for the field) it should appear in the resulting csv file. Again, how it is then used, populated, etc... that is up to the needs/expectations of the field and code that processes that field.
Put another way, EP4 provides (direct) access to data in the database. In some cases, the Zen Cart standard database field handling is incorporated (products_id is an integer, products_name is text, etc...) but there are also things that are not enforced on purpose so that the tool can be used in various configurations with minimal modification. For example, EP4 doesn't prevent a product being added to a category that has sub-categories... While that is a situation *normally* discouraged because of some of the still current core code design, it is not a requirement for store operation and further can be made possible.
Anyways, hope at least some of the above helps.
BTW, to what setting was the configuration option (language_code_only) changed?



... its supposed to be a 1 to turn on that status.
Reply With Quote
