EasyPopulate 4.0 Support Thread

[gernot]

An addition here, just to indicate the importance of setlocale() before the use of fgetcsv():
1. http://static.zend.com/topics/multibyte-fgetcsv.pdf
2. http://php.segmenta.ru/manual/en/fun...tcsv.php#62759
3. https://qiita.com/uedatakeshi/items/...c6b3e26a57c237

Perhaps it would be worthwhile to expose the desired setting of setlocale() to users so that they can choose/experiment both at export and import with the choice if their locale settings (either on the PC or in Zen Cart) are not ideal for CSV export/import.

[mc12345678]

An addition here, just to indicate the importance of setlocale() before the use of fgetcsv():
1. http://static.zend.com/topics/multibyte-fgetcsv.pdf
2. http://php.segmenta.ru/manual/en/fun...tcsv.php#62759
3. https://qiita.com/uedatakeshi/items/...c6b3e26a57c237

Perhaps it would be worthwhile to expose the desired setting of setlocale() to users so that they can choose/experiment both at export and import with the choice if their locale settings (either on the PC or in Zen Cart) are not ideal for CSV export/import.

Good information, thank you gernot. I haven't taken the opportunity yet to review the details. Do you have suggestions on information placement? Are you also thinking that it should be something "customizable" from within the EP4 configuration?

Sorry could come up with a number of questions, just trying to get an idea of ways thought that this could be applied best to/for users (from you or others with interest) and best to minimize issues out-of-the-box.

[gernot]

Hi mc12345678,
The PDF file link is quite enlightening.
I was thinking maybe, if I understand EP4 correctly, a fairly user-friendly way would be to have an editable field in the "Upload EP file" section, and another in the "Filterable Exports" section.
Not sure how feasible it is to display the current used Locale information there, that could well give users a hint in case something goes wrong.
Aside: does EP4 handle BOM or only BOM-free CSV files?

[mc12345678]

Hi mc12345678,
The PDF file link is quite enlightening.
I was thinking maybe, if I understand EP4 correctly, a fairly user-friendly way would be to have an editable field in the "Upload EP file" section, and another in the "Filterable Exports" section.
Not sure how feasible it is to display the current used Locale information there, that could well give users a hint in case something goes wrong.
Aside: does EP4 handle BOM or only BOM-free CSV files?

There is no additional processing performed to address a BOM, so would say BOM free. If can identify some resources that identify how to detect a BOM, then it could be relatively easily incorporated as a check. Otherwise, I've generally tried to stay away from asking the user to "know" the condition of the file and "remember" whether it needs to be specially treated or not at least on a case by case basis. Otherwise, the thought has been that some sort of "routine" is established for processing.

As to the "location(s)" upload puts the file on the server, import is where the file is processed and where the setting most likely applies, though by that point the upload may have occurred moments ago or at some point in the distant past... For those cases the file may need to be again downloaded and reviewed before again importing...

As far as exporting (filterable exports) seems I still need to review those links to see how it plays in the export process.

As for displaying in the information area on the right, if it can be detected, it can be displayed. :) so a definite consideration to show over there. Then it's just a matter of offering a control other than end users hard coding information to adjust/modify the setting for use in EP4.

[gernot]

Ah, of course, fgetcsv is only on import... silly me.
As for BOM, yes, apparently an issue when creating CSV files with, say, Microsoft Excel.
Example of detecting BOM (UTF-8) and removing it (first three bytes if they exist) to get to BOM-free UTF-8N:
https://qiita.com/PET_HAL/items/fd1364513f81562671b6
Also in the fgetcsv PHP manual page:
https://www.php.net/manual/en/function.fgetcsv.php
For BOMs for UTF-16 also:
https://github.com/fezfez/parsecsv-for-php/issues/23
Even PHP6 people are trying to get rid of BOM issues, heh:
https://bugs.php.net/bug.php?id=22108

[mc12345678]

As a fellow community forum member, I wanted to provide some information to those using this in particular regarding the product type of music. Those that use the music product type or have repurposed it should know that the current plan for this product type as of about 4 hours ago is to fully remove it from Zen Cart 1.5.7 and beyond. I have not seen where a reason for its removal has been explained.

The pull request on github where this is initially slated to be removed is at: https://github.com/zencart/zencart/pull/2691

Perhaps the best place to discuss the importance of the product type is where its removal has been accepted by one of the core developers: https://github.com/zencart/zencart/issues/2596

Couple of things. As a forum member, likely you are a user of the Zen Cart software not just someone that does installations. If you didn't realize it, you have a voice in the current and future operation of Zen Cart. Now, that said, please use your professional voice. Changes, especially large spread ones tend to get made to address the needs expressed by the users. Take the opportunity to express your need for the product type and features that will be affected.

I personally don't think it offers value to indicate indifference or direct acceptance to its removal as I'm sure there are multiple features of Zen Cart that do not directly impact one or more individuals. This is an opportunity for those that use or need the capability or those that can clearly explain the problem of its presence to express their need and importantly *WHY*.

I don't yet know how that would impact this software considering it supports the music product type. I also do not know if some alternate plugin will be developed. I am providing a service message and asking that you as users step up and voice your need for the product type no matter how much you think you may be the only one...

[swguy]

Requests for improvement:
- can we get rid of the mysql_ functions? People should be using mysqli_ at this point. Users needing old functions can just download prior versions.
- similarly, can we get rid of the Zen Cart 1.3 stuff?
- the use of the constant EASYPOPULATE_4_CONFIG_MAX_QTY_DISCOUNTS seems unwise, since users may not know this value. The true number can be deduced by a query:
select count(*) as c from products_discount_quantity group by products_id order by c desc limit 1;
- can we add the discount_price_w field when it exists to the price break discount?

[swguy]

easypopulate_4_export.php line 781 - using round with 2 for the price isn't right - you should look at the currency settings for the cart. Some people use 3 decimal places.

[delia]

Please forgive me if this has already been addressed and feel free to send me to a specific post.

1.5.5f, php 5.6.4, version of easypopulate seems to be most recent.

I have a website that has several addon domains - all have zen cart and all are using this mod. In the addon domains which are in subfolders of the main domain, I can set the download directory to the site's root and it all works. I have had to set the primary domain to the admin folder instead like it's supposed to. No biggie but now that these sites have been upgraded to 1.5.5f, the primary domain does still export the files correctly but when you try to access the files, it says not found and they are there in the correct folder in admin.

I did find an htaccess file I must have put in long ago and removed it (without looking at it) but there is no change. Still can't "find" the file. The htaccess file for admin is not changed - using default 1.5.5f. The htaccess file for the primary domain does include the Ultimate SEO mod and a redirect for ssl.

What am I missing?

[mc12345678]

Please forgive me if this has already been addressed and feel free to send me to a specific post.

1.5.5f, php 5.6.4, version of easypopulate seems to be most recent.

I have a website that has several addon domains - all have zen cart and all are using this mod. In the addon domains which are in subfolders of the main domain, I can set the download directory to the site's root and it all works. I have had to set the primary domain to the admin folder instead like it's supposed to. No biggie but now that these sites have been upgraded to 1.5.5f, the primary domain does still export the files correctly but when you try to access the files, it says not found and they are there in the correct folder in admin.

I did find an htaccess file I must have put in long ago and removed it (without looking at it) but there is no change. Still can't "find" the file. The htaccess file for admin is not changed - using default 1.5.5f. The htaccess file for the primary domain does include the Ultimate SEO mod and a redirect for ssl.

What am I missing?

There's not really a "supposed" to directory, the placement or folder used is as necessary to support the desired functionality. The big change was that the specific location or path of the storage location would not be stored in the database so that the database could not be accessed to determine the folder location of the admin.

So there are two "settings" in the configuration area associated with the storage of the files. One is an indicator of whether the folder location is to be relative to the admin or the catalog, the other is the path from that choice. There is some detection performed upon data entry/selection to try not to store the folder name of the admin folder in the database.

Then, after that, the issues that are likely to occur are related to download depending on where the folder has been set and the path of "permission" (htaccess overlay). This means the htaccess in the folder(s) of and above the location of the storage location affect the ability to download the file. In a typical ZC store, there is no htaccess in the root, so if a folder were created off of the root/catalog of the store, then the file(s) likely could be downloaded without issue. If the folder is off of the admin folder then the admin's htaccess first provides direction with changes needed to be incorporated to support download of csv files.

So, basically, if you are able to create new files by export of data and able to import new files that are uploaded, then if there is a problem with download, the issue is properly providing access to get to the csv file from the Web browser and that is more of a server/permissions setup issue than with this plugin. To provide direct assistance would recommend identifying the server version information, the htaccess for the admin and possibly the htaccess for the images directory. With that information and assuming that uploads/downloads within those two areas work fine, then should be able to suggest a revised version that would work in the EP4 folder being used.