EasyPopulate 4.0 Support Thread

[hanachi]

The error still occur when CSV file include Japanese.

When I export CSV file include Japanese at Tools->EasyPopulate 4,
Bottom of the table, there displayed File Name, Size,Date & Time,Type etc.
Type of exported file displayed "CSV Unknown Delimiter".
If the exported CSV file doesn't include Japanese then displayed "CSV ,".

When I import CSV file include Japanese then error occur,
and if it doesn't include Japanese then no error occur.

Does it relate to parse a csv file include Japanese ?
Does it relate encoding Japanese ?

My php.ini has the following two lines.
"mbstring.language = Japanese".
"mbstring.internal_encoding = UTF-8".

[mc12345678]

May recommend that in the configuration settings that you try a different export delimiter? Then export again with Japanese.

It appears that the default comma is selected which is what a CSV file (Comma Separated Values file) should have. There has been some extra code added to attempt to identify the separator in the file to support easier import; however, if the delimiter (separator) is not consistent or appears to be different between rows, then the import will also not work.

Put another way, prior to trying to import a file, a small test is performed against the file to see if overall it is likely to be able to be processed. Exporting a file with a delimiter other than a comma may provide different results.

I'm not yet sure if the php.ini settings are an issue or not. Provided those settings are acceptable for php, then I don't think they are a problem.

Though not specifically stated, it does seem that the same process as before has been used: export data, attempt to import the unmodified data. If I am wrong there, please say so.

[jiji2018]

Is the 1.56B version supported?

[mc12345678]

Is the 1.56B version supported?

Nothing about the Zen Cart software has changed through the 1.5.6 sub-versions that affect the operation of the version available from github. There were some changes that were incorporated for the increased strictness of php versions and database strictness.

The issue being discussed relates to one of the languages that has been identified over the years as being problematic. The languages seen to be an issue have been Japanese and Russian. Those that have been able to support them do not appear to have provided back the solution that worked for them. Hanachi may be able to resolve that at least for Japanese to where the solution can be documented in the instructions.

[Speak394]

zen version v1.5.6b

I have easy populate version 4.0.30 on one of my sites that is zen version 1.5.4. I have a new site using v1.5.6b and I installed easy populate 4.0.36.ZC. I downloaded my products from the earlier version and uploaded on the new site and new version of easy populate. Here is the error I am getting.

In admin on zen 1.5.6b I am not seeing any products up loaded. I am seeing products on catalog side, but no catagories, products are only viewable if you choose all products.

What am I missing. Is the old version of easy populate compatible with the new version? Is something amiss with zen 1.5.6b.

I did notice that the new version of easy populate calls for installing a EASYPOPULATE_4_CONFIG_TEMP_DIR and says to install in /public_html/ but when installing in 1.5.6b it says confirguration file calls for this to be in admin.

Looking for help, love this plug in and has been very helpful in the past. I have over 2,000 products and do not want to add them one by one.

[mc12345678]

zen version v1.5.6b

I have easy populate version 4.0.30 on one of my sites that is zen version 1.5.4. I have a new site using v1.5.6b and I installed easy populate 4.0.36.ZC. I downloaded my products from the earlier version and uploaded on the new site and new version of easy populate. Here is the error I am getting.

In admin on zen 1.5.6b I am not seeing any products up loaded. I am seeing products on catalog side, but no catagories, products are only viewable if you choose all products.

What am I missing. Is the old version of easy populate compatible with the new version? Is something amiss with zen 1.5.6b.

I did notice that the new version of easy populate calls for installing a EASYPOPULATE_4_CONFIG_TEMP_DIR and says to install in /public_html/ but when installing in 1.5.6b it says confirguration file calls for this to be in admin.

Looking for help, love this plug in and has been very helpful in the past. I have over 2,000 products and do not want to add them one by one.

Ok, couple of things here... One, really if you have a new site that is being built off of an older site, the database from the old site should be updated instead of just moving product around at least in a maintaining information consistently perspective.

Then, there is that newer operating systems and the newer environment is becoming more stringent about processing. There has been an "issue" with EP4 integration with ZC for a long time where adding a new category doesn't assign a category description and that ZC doesn't assign a default category description value. Therefore, the database throws an error basically and the product is not inserted into a new category but instead into the "zero" category which is the root of the store.

Long story short, for now apply this patch (identified in post #2961)posted a few pages back) to your ZC 4.0.36.ZC version and likely the above issue will be resolved.

As to where to put the export files. The program allows setting the folder anywhere desired; however, recommends the admin first to provide at least one level of protection of the data (admin folder and associated .htaccess). Remember this program is importing data in a file directly to the database. Attempts should be made to maintain that data as known information and only edited by trusted sources. There are configuration options for EP4 to choose to use the admin (true/false) and then a place to fill in the foldername. If though, the foldername leads to the admin or a sub-folder of the admin, then the admin's foldername portion will be removed from the storage location and the storage location identified as being in the admin. The idea of this change was to not store the admin's folder name either directly or indirectly in the database, there is nothing about a default install of Zen Cart that puts it in the database, so why should this plugin?

I'm working on an update, I have a working version, but I don't like *why* it works the way it does. The solution doesn't follow previous patterns and I'm trying to only change it in a way that can be easily duplicated and at least for now is consistent. I'm looking at doing a bit of a rewrite soon, but that is to modify the code orientation and reusability not its operation.

[Pingfah]

Hi all,

I cannot seem to find how to mark the products as Virtual using Easy Populate 4. Can anybody point me in the right direction?

[mc12345678]

Hi all,

I cannot seem to find how to mark the products as Virtual using Easy Populate 4. Can anybody point me in the right direction?

This is through the use of the User Defined Products Fields area of the configuration menu. Would need to at least add the field products_virtual to the export/import list. Then the import file will need v_products_virtual in it to match. As usual would recommend after adding the field products_virtual to the user defined list to then do a test export and review the results before performing an import with that field.

[Pingfah]

Perfect, I didn't even realise it had this function, but that worked flawlessly.

Thank you.

[gernot]

Hello Hanachi,
At the suggestion of mc12345678, I'm also testing the EP4 module now, to see if we can get to the bottom of the error you are experiencing.
At the moment, with mostly demo data on my site, I could not recreate the error, despite most categories and many product names and descriptions having Japanese translations. I can both export (complete products (with metatags)) to CSV and import the exported CSV file without trouble.

• My platform: GNU Debian linux x86_64 "sid/unstable"
• PHP verson: 7.3.6-1
• MySQL/MariaDB version: 10.3.16-MariaDB-1 Debian 10
• Web server: nginx 1.14.2
• Zen Cart: 1.5.6c
• Easy Populate version (downloaded and installed today):
  

  Easy Populate 4.0.37.9 - 02-08-2017

I must admit I do not know how closely my Japanese language pack (adapted from 1.5.1jp) matches yours. I too have language_id for Japanese set to 3 (English is 1), since I too uninstalled the language and reinstalled it at some point. Default language is English. So here some locale information:

• OS Locale:
  

  # locale -v
  LANG=en_US.UTF-8
  LANGUAGE=
  LC_CTYPE="en_US.UTF-8"
  LC_NUMERIC="en_US.UTF-8"
  LC_TIME="en_US.UTF-8"
  LC_COLLATE="en_US.UTF-8"
  LC_MONETARY="en_US.UTF-8"
  LC_MESSAGES="en_US.UTF-8"
  LC_PAPER="en_US.UTF-8"
  LC_NAME="en_US.UTF-8"
  LC_ADDRESS="en_US.UTF-8"
  LC_TELEPHONE="en_US.UTF-8"
  LC_MEASUREMENT="en_US.UTF-8"
  LC_IDENTIFICATION="en_US.UTF-8"
  LC_ALL=

• locale settings in ADMIN/includes/japanese.php
  

  $locales = array('ja_JP.UTF-8', 'ja_JP', 'ja', 'Japanese_Japan.932');
  @setlocale(LC_TIME, $locales);
  mb_language('Japanese');
  mb_internal_encoding("UTF-8");
  mb_http_output("UTF-8");

If that gives you anything to go on, that would be great. Also, would be nice to get a bit more of an idea of the data you are having trouble with. Maybe you can send a tiny sample file with description. Then I can try to duplicate your category/product registration in my Zen Cart and see if the export is the same. And also check if I can import such a file (assuming duplication does not show any differences that could explain the error).

Cheers!