Regarding the Japanese language pack:

Is that for the catalog side, the admin, or both?

After installing the Japanese language pack was the default language changed/modified? Or perhaps better asked is what language settings were modified?

Is the default English language still present? Is it considered language_id of 1? (should be able to see this information on the main screen of tools->Easy Populate v4).

There is a slightly more up-to-date version at https://github.com/mc12345678/EasyPopulate-4.0) where there were some changes to some of the language processing; however, please answer the above questions to ensure successful support. There may still be something needing modification.

The error message is indicating that at some point in trying to match the record with a database entry that a variable substitution is not being made for the "phrase" ```
':products_model:'

enginarat:

OK. I took a chance and successfully installed that on a test folder running on Zen-cart 1.5.6b. Working just fine HOWEVER I only needed this to get Google Base exports (just like in EP Advanced 3.0.3). Any hope that Google Base Export soon to be added to 4.0, too? Thanks.
Sorry that I missed this post.

What is needed from the database to support that functionality? I thought that much of it was already present or avaulable once the desired data was exported. A sample of the field headings and an associated row would help identify this.

Please enclose in code brackets. (before pasting, press the # button in the message box toolbar to create the code tags and then paste between them.)

Thank you for your quick reply.

1.The Japanese language pack is for the both side.
I didn't change the data base by SQL.
I changed default language from the main screen.
I intend to remove the Japanese language pack and test again.

2.After installing the Japanese language pack, I changed the default language to Japanese.
English language is still present and it's language_id is 1. I didn't touch about English.
----------the information on the main screen of tools->Easy Populate v4---------------
Easy Populate 4.0.37.6 - 02-08-2017
Installed Languages
2-ja: Japanese
1-en: English
Default Language: 2-Japanese
Internal Character Encoding: UTF-8
DB Collation: utf8

3. I will try https://github.com/mc12345678/EasyPopulate-4.0 .

4. I think this message is regarding ':products_model:', but I don't know how to solve it because of my limited ability.

I will try what I can.
Thank you.

hanachi:

4. I think this message is regarding ':products_model:', but I don't know how to solve it because of my limited ability.

Sorry, ':products_model:' had become a face mark.

hanachi:

Sorry, ```
':products_model:'

It  had done the same thing to me as well. :)

Ok, so I haven't reproduced the issue yet. I need to figure out how the installed version is/was 4.0.37.6, but from chaddro's distribution...

I do see that at least from the GitHub location I posted, as long as the exported file has v_products_model as a field, then it should do the substitution that seems to be missing.  

Another question: in configuration->EasyPopulate V4, What is the setting for EP4_DB_FILTER_KEY? This is the setting that identifies whether to use products_model, products_id or new_blank as a setting.

Does the issue still occur if the default language is returned to English, but the language pack is installed?

1.About the version of EP4:
I downloaded EP4 from https://github.com/mc12345678/EasyPopulate-4.0 and verified with former installed EP4 that occured the error.
I found they are same 4.0.37.6 of EP4.
I remember I got an error by using EP4 v4.0.35.ZC.2 and I found EP4 at https://github.com/mc12345678/EasyPopulate-4.0, so I
tried EP4 4.0.37.6, because it is later than EP4 v4.0.35.ZC.2.

2.About Another question:
in configuration->EasyPopulate V4->Import/Export Primary Key .... value is products_model
And I confirmed EP4_DB_FILTER_KEY is set products_model at the database "configuration".

3.Does the issue still occur if the default language is returned to English, but the language pack is installed?
Yes. I tried to set the default language to English without remove Japanese language Pack.
There is same error occured.

4.I delete Japanese from Localization -> Languages and tested , but the language pack is removed.
There is no error occured!!
About the Japanese language Pack, there are no SQL query included.
The Japanese language Pack only include language folder, email folder, and template(only buttons images).

5.I delete Japanese from Localization -> Languages and tested , but the language pack is installed.(I put the Japanese language Pack again)
There is no error occured!!

I think there is some conflict when add new language at Localization -> Languages

Thank you.

Sounds like some good investigation.

To ensure that the issue appears "corrected", the new languages_id for Japanese though now is 3 correct?

In the additional testing, was a new export file created after reinstalling the language pack? And do the fields of the japanese language have the current/new languages_id?

Before, English was 1 and japanese was 2. Because japanese was removed and then readded, I would expect japanese to now be 3.

If the problem continues with a new export/import, I will take a look at duplicating the issue even though I can't read Japanese. I took some lessons many years ago, but that was conversational not "business".

1.About the new languages_id for Japanese
Yes, Absolutely 3.

2.Latest testing
After readded new language "Japanese" from Localization -> Languages, I made a new export and import.
No error occured!!

I still not have perform another testing, but seems to be able to avoid the error.
I can't understand there is what kind of difference between languages_id 2 and 3.
Any way I will continue test and report to you here.

You already have advanced programming skills and sense of responsibility, just add a bit "love of Japanese", I think it's not difficult to use Japanese in business.

Thank you

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".

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.

Is the 1.56B version supported?

jiji2018:

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.

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.

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.
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.

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?

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?

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.

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

Thank you.

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!

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/function.fgetcsv.php#62759
3. https://qiita.com/uedatakeshi/items/e33765c6b3e26a57c237

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.

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/function.fgetcsv.php#62759
3. https://qiita.com/uedatakeshi/items/e33765c6b3e26a57c237

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.