EasyPopulate 4.0 Support Thread

[viperofthepitstorm]

My main problem it seems is that I can`t delete the csv to start over again it just keeps reappearing and I have tried deleting it from the temp file in the cpanel as well to no avail. The images problem is secondary until I can remove the old csv that seems to overide the new one.

[viperofthepitstorm]

Bump any ideas.

[chadderuski]

My main problem it seems is that I can`t delete the csv to start over again it just keeps reappearing and I have tried deleting it from the temp file in the cpanel as well to no avail. The images problem is secondary until I can remove the old csv that seems to overide the new one.

SPH: Thanks for stepping in and trying to help. You've given Viper some very good information... and I agree that his images folder is FUBAR'ed.

Viper: Use your FTP program to manually delete the file from the server. If your website was moved from another server, you may not have file permissions to delete. You can also log into your cpanel (or equivalent) and delete files from your server that way. If all else fails, call your host and have them delete it!

Secondly. Follow EP4's file naming conventions, and do not use spaces in your file names.

Third: Create a DIFFERENT temporary directory on your server, and change EP4 to this directory through the admin. There is NO WAY that EP4 will read from your old directory.

And Finally: In order for EP4 to properly link your images, you have to includes the path to the file UNDER the images folder.

If you want your image to appear on your server under: /images/all/fubared/up/my-picture.jpg

Then your entry in EP4 under the image column is: /all/fubared/up/my-picture.jpg <<== FILE EXTENTIONS ARE A MUST!

This would be obvious if you followed my earlier instructions and manually edited and linked an image through the admin, then exported that product.

I have a serious concern with your use of ".au" in the file path. A preceding "dot" in a file/folder name on linux makes it hidden. I have never tested EP4 with hidden file structures. This is absolutely unnecessary if you secure your server properly.

-chadd

[viperofthepitstorm]

I have a serious concern with your use of ".au" in the file path. A preceding "dot" in a file/folder name on linux makes it hidden. I have never tested EP4 with hidden file structures. This is absolutely unnecessary if you secure your server properly.

-chadd[/QUOTE]

I had a developer create the store not me so what your saying is new about the hidden files. I will contact my host provider and get them to delete the csv since Ive tried doing it via cpanel and ftp to no avail. Thanks for the help this is all new and some very interesting info.

[easy3dsource]

First off, thanks for updating easypopulate to work with ZC 1.5!

I recently had to do some manual database troubleshooting and as part of the process I ended up installing this version of easypopulate. Prior to that I was using 1.2.5.4 on a ZC 1.5 installation. (With this version I couldn't access easypopulate through the admin menu, but could access it if I added "easypopulate.php" after the admin URL.)

So my problem: I run a shop that sells only downloadable products. I always used easypopulate to upload all products, then in order to keep the downloadable files properly attributed to the products I would manually update the zen_products_attributes and zen_products_attributes_downloads tables of the database by using excel, then uploading via phpmyadmin.

For the sake of my sanity, I always made sure that the last 3 digits of the model number for each product (used in the easypopulate spreadsheet) matched the last 3 numbers of the product_id in the database. This always worked fine, up until recently;

We had to delete some products through the admin (not using easypopulate), in order to keep our model numbers serialized, we adjusted our spreadsheets so that the next new products added just took the place (by way of model number, and product_id) of the deleted products.

Once we uploaded our new spreadsheets, we noticed that easypopulate is skipping product id's; We currently have 238 products, if we upload a new product, we'd like the product id to be 239, but it's currently jumping to 270. After doing a number of tests, I noticed a couple things:

-let's say I upload a test product via easypopulate, and it got assigned the product_id 270
-if i manually delete traces of this product via phpmyadmin then re-upload the spreadsheet it takes the same product_id as before
-if I delete the product through the ADMIN, then re-upload the spreadsheet, it gets assigned the NEXT product_id, in this case, 271.

So what I'm wondering is if zen cart somehow stores the product_id's of deleted products, making them unassignable to new products? This is causing a problem because I'd rather not have a gap in the product ID's (it helps me and my partner maintain the inventory easier).

Once again; what I'm trying to solve here is how to make sure when I upload new products via easypopulate, there isn't a jump in the product_id.... anyone have any thoughts / suggestions on how to make this happen?

Thanks in advance!

[serviscl]

Hello.
I have got a problem with categories name.
My categories include ", " and I can not import via EP4, because character "," always divide :-( it would use a semicolon instead of a comma? Thanks :-)

Excuse My English.

[chadderuski]

Hello.
I have got a problem with categories name.
My categories include ", " and I can not import via EP4, because character "," always divide :-( it would use a semicolon instead of a comma? Thanks :-)

Excuse My English.

Categories Names are split with the carat '^' character, not the comma. Which version are you using? What language? I tested this myself, and the comma was retained in the categories name.

On, or about line 487 of easypopulate_4_import.php

			
$categories_names_array = explode('^',$v_categories_name_1);
$categories_count = count($categories_names_array);

Unless you modified the code, or are using a very old version of EP4, I don't see how EP4 could split the categories name on the comma.

-chadd

[chadderuski]

First off, thanks for updating easypopulate to work with ZC 1.5!

I recently had to do some manual database troubleshooting and as part of the process I ended up installing this version of easypopulate. Prior to that I was using 1.2.5.4 on a ZC 1.5 installation. (With this version I couldn't access easypopulate through the admin menu, but could access it if I added "easypopulate.php" after the admin URL.)

So my problem: I run a shop that sells only downloadable products. I always used easypopulate to upload all products, then in order to keep the downloadable files properly attributed to the products I would manually update the zen_products_attributes and zen_products_attributes_downloads tables of the database by using excel, then uploading via phpmyadmin.

For the sake of my sanity, I always made sure that the last 3 digits of the model number for each product (used in the easypopulate spreadsheet) matched the last 3 numbers of the product_id in the database. This always worked fine, up until recently;

We had to delete some products through the admin (not using easypopulate), in order to keep our model numbers serialized, we adjusted our spreadsheets so that the next new products added just took the place (by way of model number, and product_id) of the deleted products.

Once we uploaded our new spreadsheets, we noticed that easypopulate is skipping product id's; We currently have 238 products, if we upload a new product, we'd like the product id to be 239, but it's currently jumping to 270. After doing a number of tests, I noticed a couple things:

-let's say I upload a test product via easypopulate, and it got assigned the product_id 270
-if i manually delete traces of this product via phpmyadmin then re-upload the spreadsheet it takes the same product_id as before
-if I delete the product through the ADMIN, then re-upload the spreadsheet, it gets assigned the NEXT product_id, in this case, 271.

So what I'm wondering is if zen cart somehow stores the product_id's of deleted products, making them unassignable to new products? This is causing a problem because I'd rather not have a gap in the product ID's (it helps me and my partner maintain the inventory easier).

Once again; what I'm trying to solve here is how to make sure when I upload new products via easypopulate, there isn't a jump in the product_id.... anyone have any thoughts / suggestions on how to make this happen?

Thanks in advance!

If I understand WHAT you are doing, then I can only suggest trying this:

Deleted your items from withing the admin normally, then go to the store manager and "optimize" your databases. Now try to import your data with EP4.

If memory serves me right, MySQL doesn't actually delete record entries when you select "delete". It marks the record location as deleted and you you no longer see the deleted record from within phpMyAdmin. When you optimize the database, it compresses the database and removes all deleted entries.

So it appears there is a slight difference in the way that zencart finds the next available record number and the way EP4 does it.

Hope this helps.
-chadd

[easy3dsource]

If I understand WHAT you are doing, then I can only suggest trying this:

Deleted your items from withing the admin normally, then go to the store manager and "optimize" your databases. Now try to import your data with EP4.

If memory serves me right, MySQL doesn't actually delete record entries when you select "delete". It marks the record location as deleted and you you no longer see the deleted record from within phpMyAdmin. When you optimize the database, it compresses the database and removes all deleted entries.

So it appears there is a slight difference in the way that zencart finds the next available record number and the way EP4 does it.

Hope this helps.
-chadd

I apologize for the delayed response;

I tried your suggestion to optimize the database, but it still didn't correct the way the products were importing.

For the time being, I just skipped a large number of model numbers so that the last 3 digits of the model number remained consistent with the last 3 digits of the ID.