My answer is based on say a "fresh" install where numbers are not being "recycled"... no, Zen Cart would not specifically have a problem with numbers not being consecutive.Quote:
Originally Posted by greybeard_it_guy
Printable View
My answer is based on say a "fresh" install where numbers are not being "recycled"... no, Zen Cart would not specifically have a problem with numbers not being consecutive.Quote:
Originally Posted by greybeard_it_guy
I should have added though, remember that the "world" (wide web) "knows" your product by specific products_id.Quote:
Originally Posted by mc12345678
Note that skipping a products_id is similar to deleting a historic (old) product. Generally speaking ALWAYS skipping a number would in a way effectively reduce the possible number of product in half, but, unless you have more than 49,999,999,999 of the maximum possible 99,999,999,999 products ever to be in the store (not necessarily all at once), this shouldn't be an issue. :)
I've just gotten the file ready to import about 40 products. It uploads fine and says it imported okay - no specifics. But the products are not importing. It has been a while since I've done this but what in the world could I be missing? All have product module numbers. I got all fields etc.
Let's revisit some basics and also get some info...Quote:
Originally Posted by delia
Version of EP4, is it the latest as published to this forum or from github and what is the reported version for that?
What is the filename for the file?
If looking at the file list for import, is there a reported problem for the delimiter or is the csv delimiter reported as expected? (likely a comma)
What is the setting in the configuration for the import language override.
What "ending" is used for the header of fields that are language dependent such as the v_products_name or v_categories_name?
version 4.0.37.13 - I downloaded from github but this appears to be what is in zc plugins. It does say there's a new version so I'm confused on this point.
updated_products-2021-05-10.csv
excel file - taken from exported original file. It has been majorly changed however
no reported problem
settings are default - no changes
and yes fields have the 1 on it
If default new install, then in the configuration options change the import override to something other than language_code_only...Quote:
Originally Posted by delia
As to the version response issue, I did not update the internal version to be 4.0.37.ZC so the ZC site's 4.0.37.ZC is "newer" than 4.0.37.13 based on the method used to compare. I have some more updates to push and will get this right in that submission.
making that change means the import worked. Thank you but why have a default that won't work?
Ahem.. It does work... When language dependent fields contain the appropriate information.Quote:
Originally Posted by delia
There are now four options in that list: language_id, language_code, language_id_only, and language_code_only.
Choosing either of the first two offers a preference... The preference is whatever is selected, but if it doesn't exist then the other is used. The two options ending in only will pull information from the import file *only* from the language dependent fields that have that identifier.
So.. It is now possible that an import file could have for example v_categories_name_1 and v_categories_name_en or it could contain either of these. But, the question becomes, when importing the file, which field should be used? Ideally, they would both contain the same information, but we all know that is not going to happen consistently. We also know that former users of this plugin have become accustomed to the _1 style. For those that have upgraded from a previous installation (say 4.0.36 where this feature was first initiated), the default was language_code even though that was not fully implemented throughout. Again, the idea was if _en existed then it would use that field, but if not, then it would attempt to use _1.
What really should have happened is that some level of notification be made about the situation. I thought that I had something for this situation, but based on the above report that does not appear to be true. Even after the extensive testing that I did, it seems I missed a portion of user response. Further it looks like I set the default export to use the 'id' so that leads to the issue you (and likely others experienced).
I previously had the import default to language_code so that if a file happened to use _en then it would offer preference to that field. Then in my testing, I realized that if one chose to delete the _1 column and had language_id set, it would still try to populate with the content of the field ending in _en.... Had some options... 1. Only "choose" between the two fields when both fields are present and ignore the other field if only one is present, 2) add a second set of options where data is populated only from the field type designated and to allow the preference with fallback option to continue/exist or 3) leave it alone and advise people to delete all occurrences of a field if it is not to be updated (I obviously didn't like this option because I didn't keep it that way).
For long time users, I expected that the configuration information and guidance would be helpful enough to change that setting as necessary, it was my goal for new users to be exposed to the language_code (though keeping/making the default export as language_id doesn't do that in the least).
So, like said a little before, need to provide another update, good feedback on the issue thank you.
Although not yet set in stone, my initial thought for this is to modify the default export to the language_code and keep the default import as language_code_only... Feedback/input?
I prefer default to simply work out of the box with a default cart. I appreciate the addition of languages but I have had only one client in 20 years who used more than just English and the one I did have ended up getting rid of it due to changes years ago. I don't know what the best situation is but the simpler the better always.
Fresh install of current latest version of EP says "NOTE: A NEW VERSION OF THIS PLUGIN IS AVAILABLE". I couldn't get the LOG_PLUGIN_VERSIONCHECK_FAILURES setting to work and I didn't have time to look at it further. The only thing I did notice is that the comment in easypopulate_4.php on line 102 references an old version number, but obviously this is not the root cause of the issue.