EasyPopulate 4.0 Support Thread

[mc12345678]

Regarding the import of multiple categories for products, just done a 1000 line import and subsequently discovered errors in the csv that created unwanted categories.

Is there a switch to prevent the creation of new categories/only allow products to be assigned/linked to existing categories?

When I upload a file the column v_categories_name_1 always has a category listed. I've never had a problem with wrong categories. If you have a category for example under men's shoes then sneakers your product category would look like men's shoes^sneakers

I have two languages and in some products the second column for ES had the category name EN so it created those as new categories, as per design.
So if there is no switch to prevent this, I'll add one to prevent this in future.

Unfortunately, even with the above added information, there are still characteristics that are not identified. For example, did the file itself contain multiple rows that caused the generation of linked product or did the product already exist within the database and the file contained additional rows of data where the category didn't/no longer existed and would become new? There are also considerations to factor in especially with multiple languages such as why was the additional field present to include the new (linked product generating) category?

As has been the case as long as category linking has been incorporated, the control of this has been in the management of the original data. A single column is used as the primary key, having two records in the file that match that primary key offers an opportunity for "undesired" data to be import/modified. Not including the category column would prevent the generation of linked categories though would prevent that file from being used to import new product because of the absence of a category. Could something be added to the file to mark or indicate the need to process or exclude a row, sure. But if editing the file to include or otherwise flag a row to do something special, why have the row in the file to begin with instead of an additional file needed to perform that particular action?

The above is a little bit of an explanation of why such hasn't been previously developed and some of the issues or ways to work around them. Can a switch be added to prevent the generation of linked categories? Yes. So can one to use only the first row of data encountered, the last row, or anywhere in between. That bit of a facetious statement comes from trying to see the benefit and/or how adding such a feature would help others (with minimal further explanation/engagement). I made a mistake already and was concerned that there was an issue with the use of language_code versus language_id; however, the above says that it was all within a given language identifier (language_code), but in this case two languages were included and specifically a single field had data that was not desired to be at least "fully" included/considered. Interested in further understanding the situation so that can figure out incorporation in addition to responding to the items that were recently brought up.

[torvista]

For example, did the file itself contain multiple rows that caused the generation of linked product or did the product already exist within the database and the file contained additional rows of data where the category didn't/no longer existed and would become new?

The products already existed.
The categories already existed.
The import was to link the products to multiple other categories.


The problem-causing rows had the same category name (EN) in both the EN and ES column.
As that EN category-name did not exist in spanish, a new category was created having the same name in both languages.

I mainly use DBIO, which does not have category imports. That uses a command column for optional functionality, like expressly allowing creation or not.

[marcopm]

So I am happy to say that finally the Unknown CSV Delimiter issue was solved.
I don't know why I didn't try this before...
At first, since this was an upgraded website and had previous versions of EP (1.2....), there was a temp folder in the root and I left it there, changed in the EP4 configuration to false under Uploads directory Admin/Catalog.
Now I decided to move it to the Admin folder and changed the configuration to True and the Unknown CSV Delimiter indication turned to a "CSV ," indication.

Thank you so much for posting this solution!
I had the same problem ("Unknown CSV Delimiter" error although everything looked good to me) and initial setup.
Luckily I found your post, it would have taken me quite a long time to realize it otherwise, since the error message is quite misleading in this case.

[mc12345678]

Thank you so much for posting this solution!
I had the same problem ("Unknown CSV Delimiter" error although everything looked good to me) and initial setup.
Luckily I found your post, it would have taken me quite a long time to realize it otherwise, since the error message is quite misleading in this case.

The real fix can be found in this post: https://www.zen-cart.com/showthread....80#post1385080
Changing the setting to access files off of the admin directory has its benefits, but for some that would mean they would have to provide that path name to another vendor. Again, unfortunately it had been developed to be too protective.

[retched]

I'm running in to the following error.

I am running ZC1.5.7d and Easy Populate 4.0.37.13 - 05-03-2021.

I just did a fresh install (with some mods for a custom product type). (Had problems with the install until I hit the "Install EP4" link but that's another problem :)).

I managed to get the files to be created however, I tried to import the file that was just created and was thrown this error.

[28-Apr-2022 03:13:10 America/New_York] PHP Fatal error:  Uncaught Error: Call to undefined function mysql_query() in E:\xampp\htdocs\yyyy\easypopulate_4.php:819
Stack trace:
#0 E:\xampp\htdocs\yyyy\index.php(11): require()
#1 {main}
  thrown in E:\xampp\htdocs\yyyy\easypopulate_4.php on line 819

[28-Apr-2022 03:13:10 America/New_York] Request URI: /yyyy/index.php?cmd=easypopulate_4, IP address: 127.0.0.1
--> PHP Fatal error: Uncaught Error: Call to undefined function mysql_query() in E:\xampp\htdocs\yyyy\easypopulate_4.php:819
Stack trace:
#0 E:\xampp\htdocs\yyyy\index.php(11): require()
#1 {main}
  thrown in E:\xampp\htdocs\yyyy\easypopulate_4.php on line 819.

So here's where things get weird... I found the line that was referenced and it's part of a block that is testing for mysql vs. mysqli. For some reason, EP4 isn't seeing that mysqli should be used. (I'm running PHP 7.4.20.) I tried everything at this point... hell, I even tried setting line 62 to always true using:

$ep_uses_mysqli = TRUE; 

But... either way, after the page refreshes... the script resets itself to FALSE. (I can tell because I added the following to the "tests" under Configuration Settings on line 717(-ish):

echo "Are you using MySQLi?: " . ($ep_uses_mysqli ? "TRUE" : "FALSE") . '<br />'; 

Before I try to import a CSV file this line tests TRUE. But afterwards and the page refreshes after an import attempt, this line sets itself to false. I am lost as to why that is or how to fix it. (Again, hardcoding this test to TRUE somehow sets it back to false :/)

Any help would be appreciated.

[retched]

:snip:

This attached post can be ignored. Evidently, I copied over code from an older EP4 that was always reverting $ep_uses_mysqli to FALSE. And it override the hard setting. Everything is working swimmingly for now.

[mc12345678]

This attached post can be ignored. Evidently, I copied over code from an older EP4 that was always reverting $ep_uses_mysqli to FALSE. And it override the hard setting. Everything is working swimmingly for now.

Glad it has been sorted... I had looked through many portions of code and couldn't find what would have caused it in the above described version...

[DanMickle]

Easy Populate is working great for me, with the exception of 1 issue. I can not get it to update the metatags_keywords_1 field. I am able to use EP4 to toggle the status (0/1) on the other Metatag fields (v_metatags_products_name_status,v_metatags_title_status) fine. It just seems to be the field where I can enter longer text that is the issue (metatags_keywords_1, metatags_description_1).

We recently upgraded to 1.5.7d and made sure all themes and modules are updated. I am able to manually enter the information for each item, and it does show when I download the store from EP4.

Any thoughts on where to start?

Thanks in advance for any help/thoughts.

Dan

[mc12345678]

Easy Populate is working great for me, with the exception of 1 issue. I can not get it to update the metatags_keywords_1 field. I am able to use EP4 to toggle the status (0/1) on the other Metatag fields (v_metatags_products_name_status,v_metatags_title_status) fine. It just seems to be the field where I can enter longer text that is the issue (metatags_keywords_1, metatags_description_1).

We recently upgraded to 1.5.7d and made sure all themes and modules are updated. I am able to manually enter the information for each item, and it does show when I download the store from EP4.

Any thoughts on where to start?

Thanks in advance for any help/thoughts.

Dan

See if the content at or further referenced back in the following post resolves the issue and please post back: https://www.zen-cart.com/newreply.ph...eply&p=1381450

[DanMickle]

I went back through those threads and tried a few changes (language ID/Code, etc.) but they did not resolve the issue. I double-checked to make sure the "use products metadata" was enabled as well.

I did also verify because I thought I may have been mistaken when I first attempted a product update. I am able to update the following correctly (as well as the other standard fields):

v_metatags_products_name_status v_metatags_title_status v_metatags_model_status v_metatags_price_status v_metatags_title_tagline_status

however

v_metatags_title_1 v_metatags_keywords_1 v_metatags_description_1

will not update.

Maybe I am missing something in the past posts, so I am going back through them again. Thank you for taking the time and suggesting the post to start with.