Zen Cart Logo
Forums / Addon Admin Tools / EasyPopulate 4.0 Support Thread

EasyPopulate 4.0 Support Thread

Sticky

Views: 733,117

Results 1,261 to 1,280 of 3,671
16 Nov 2013, 02:37
#1261
nick02895 avatar

nick02895

New Zenner

Join Date:
Apr 2009
Posts:
13
Plugin Contributions:
0

EasyPopulate 4.0 Support Thread

mc12345678:

Couple of things. You say, still uses utf8. I understand that 1.5.x does, but does 1.3.8?

Also, state unable to "install mbstring because not your server", does that mean you do not have access to the php.ini file as it shouldn't take much to activate it,and it is probably already "installed" just not active.

Thanks for following up with me.

I don't know that 1.3.8 does or doesn't. From what I've read to convert to utf8 there is a procedure which replaces charset in English.php to include utf8. Mine has that.
Also in phpadmin there is a change to the structure to utf8, my already has that. I have to assume that somewhere in the upgrade to 1.5 my charset was changed to utf8.

I cannot find the php.ini file on this server. This server is very restrictive with limited access. I guess I may be able to create one and make my own settings, but if it's working I will leave it.

Looks like the mb_internal_encoding() just checks utf8 and if not then easypopulate4.php restricts the input.

16 Nov 2013, 03:00
#1262
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,908
Plugin Contributions:
2

Re: EasyPopulate 4.0 Support Thread

nick02895:

Thanks for following up with me.

I don't know that 1.3.8 does or doesn't. From what I've read to convert to utf8 there is a procedure which replaces charset in English.php to include utf8. Mine has that.
Also in phpadmin there is a change to the structure to utf8, my already has that. I have to assume that somewhere in the upgrade to 1.5 my charset was changed to utf8.

I cannot find the php.ini file on this server. This server is very restrictive with limited access. I guess I may be able to create one and make my own settings, but if it's working I will leave it.

Looks like the mb_internal_encoding() just checks utf8 and if not then easypopulate4.php restricts the input.

Certainly. Wasn't sure if it was your host, or if you were helping someone with their installation. Who are you with? The host company should be able to help. I realize all of the conditions you listed. I would have to at this time defer the discussion of that factor to chadderuski if he's still out there. :). I have not looked at that. Aspect of the code yet and what affects if any there would be of working with the plug-in without that function. I know that when I installed this locally, I chose to enable mbstring on my local install. Glad you have all of the other "upgrades". Thought it was important to discuss for others that read. The forum.

21 Nov 2013, 00:19
#1263
scottj avatar

scottj

New Zenner

Join Date:
Aug 2011
Posts:
36
Plugin Contributions:
0

Re: EasyPopulate 4.0 Support Thread

chadderuski:

If this mod only adds fields to the products table, then you should be able to use the User Defined Products Fields to add these to your import sheet. After installing the MAP mod, look at the products table or sql you used to modify the table for the field names. Then add these under the Configuration > EasyPopluate 4 :: User Defined Products Fields.

Separate the fields with a comma, but do not add spaces, for example: field1,field2,field3
Do not add quotes either.

Your sheet will then export with columns for these fields as: v_field1, v_field2, v_field3

Let me know how that works for you!
-chadd

This is regards to the MAP Pricing mod. I followed your instructions by setting User Defined Field = v_map_enabled (which I confirmed in my SQL db as the correct field name). I download FULL-EP and it doesn't show up. I upload a CSV with a single record to test and I get the following output (but no change to the db or the product record):

Import Results

Filename: MAP_UL.csv

UPDATED! - Model: 806-1206 | 1 |

Finished Processing Import File

A "1" enables it, a "0" disables it. I'm trying to fully convert away from the old EP version which I had modded to do this. I've had no problems in the past uploading metatag fields with EP4.0 so I'm not sure if I'm missing something? There's no debug error found. I confirmed I can go into the product record manually and change it successfully. Any ideas? Thanks!
Scott

21 Nov 2013, 11:55
#1264
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,908
Plugin Contributions:
2

Re: EasyPopulate 4.0 Support Thread

scottj:

This is regards to the MAP Pricing mod. I followed your instructions by setting User Defined Field = v_map_enabled (which I confirmed in my SQL db as the correct field name). I download FULL-EP and it doesn't show up. I upload a CSV with a single record to test and I get the following output (but no change to the db or the product record):

Import Results

Filename: MAP_UL.csv

UPDATED! - Model: 806-1206 | 1 |

Finished Processing Import File

A "1" enables it, a "0" disables it. I'm trying to fully convert away from the old EP version which I had modded to do this. I've had no problems in the past uploading metatag fields with EP4.0 so I'm not sure if I'm missing something? There's no debug error found. I confirmed I can go into the product record manually and change it successfully. Any ideas? Thanks!
Scott

So, I left this message alone last night, because I didn't quite follow it and also thought perhaps the code author might jump in with an answer.

I haven't worked with that aspect of this plug-in (using the user defined fields; however, it may be helpful to see the "single line" data file for one thing (this would identify the fields that are being attempted to be added). That said, it seems that unless you have created a new file type to be able to upload with a filename prefix associated with MAP_UL, then there are several routines within the plugin that will not be activated. Additionally, it appears that the original code author provided direction related to the new fields being added to the products table. Were the new fields added to the products table or some different table? Also (and not to question your knowledge/understanding) the fields entered into the user defined fields, they are the actual field names that were added, not field1,field2,field3,etc... correct?

On the issue of the filename, it seems like the expectation (if the fields were added to the products table) that import to ZC should have the same prefix as the download file ("full...etc"). (Sorry at the moment have forgotten what the exact prefix is.)

Any of that help?

21 Nov 2013, 20:51
#1265
scottj avatar

scottj

New Zenner

Join Date:
Aug 2011
Posts:
36
Plugin Contributions:
0

Re: EasyPopulate 4.0 Support Thread

mc12345678:

So, I left this message alone last night, because I didn't quite follow it and also thought perhaps the code author might jump in with an answer.

I haven't worked with that aspect of this plug-in (using the user defined fields; however, it may be helpful to see the "single line" data file for one thing (this would identify the fields that are being attempted to be added). That said, it seems that unless you have created a new file type to be able to upload with a filename prefix associated with MAP_UL, then there are several routines within the plugin that will not be activated. Additionally, it appears that the original code author provided direction related to the new fields being added to the products table. Were the new fields added to the products table or some different table? Also (and not to question your knowledge/understanding) the fields entered into the user defined fields, they are the actual field names that were added, not field1,field2,field3,etc... correct?

On the issue of the filename, it seems like the expectation (if the fields were added to the products table) that import to ZC should have the same prefix as the download file ("full...etc"). (Sorry at the moment have forgotten what the exact prefix is.)

Any of that help?

Thanks for the reply. The user defined field I added was v_map_enabled (I had a good chuckle... would've been funny had I added "field1") and the new MAP field is located in the products table. As I noted, I know just enough to be dangerous having modded the old EP1.2.5.4 for the MAP field. The contents of MAP_UL.csv test file was simply:

v_products_model | v_map_enabled
806-1206 | 1

As for the file name, this may be the most promising. I don't quite understand all that. I previously attempted to add about 100 new products using the Full-EPxxxx prefix and for whatever reason it deleted all the title/descriptions for the existing 10,000 products. Luckily I had a backup but understandably I've stayed far away from that prefix!

Without any mods I successfully upload metatag data using a CSV file called metatags_UL.csv (which is why I originally added EP4.0 since the old EP doesn't support metatag stuff). Thus I made the assumption, perhaps erroneously, that any file name will work if you just want to upload product fields without "triggering" any of the EP4.0 logic... logic which I readily admit I don't understand. References to it in the instructions were a bit ambiguous for me.

Thoughts?

21 Nov 2013, 21:20
#1266
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,908
Plugin Contributions:
2

Re: EasyPopulate 4.0 Support Thread

scottj:

Thanks for the reply. The user defined field I added was v_map_enabled (I had a good chuckle... would've been funny had I added "field1") and the new MAP field is located in the products table. As I noted, I know just enough to be dangerous having modded the old EP1.2.5.4 for the MAP field. The contents of MAP_UL.csv test file was simply:

v_products_model | v_map_enabled
806-1206 | 1

As for the file name, this may be the most promising. I don't quite understand all that. I previously attempted to add about 100 new products using the Full-EPxxxx prefix and for whatever reason it deleted all the title/descriptions for the existing 10,000 products. Luckily I had a backup but understandably I've stayed far away from that prefix!

Without any mods I successfully upload metatag data using a CSV file called metatags_UL.csv (which is why I originally added EP4.0 since the old EP doesn't support metatag stuff). Thus I made the assumption, perhaps erroneously, that any file name will work if you just want to upload product fields without "triggering" any of the EP4.0 logic... logic which I readily admit I don't understand. References to it in the instructions were a bit ambiguous for me.

Thoughts?

So to confirm, your database has a field name that begins with a v_? Or if you were to look in mySQLadmin would it be map_enabled?

The code automatically adds v_ as part of creating the CSV file.

So, it looks like the only way to get those fields out of ZC is to do a full export. To get them back in, it looks like you don't have to do a full import. At least there is some data loaded without that type of file...

But I think the real problem is that you have already prefixed the field with v_...

21 Nov 2013, 21:24
#1267
scottj avatar

scottj

New Zenner

Join Date:
Aug 2011
Posts:
36
Plugin Contributions:
0

Re: EasyPopulate 4.0 Support Thread

mc12345678:

So to confirm, your database has a field name that begins with a v_? Or if you were to look in mySQLadmin would it be map_enabled?

The code automatically adds v_ as part of creating the CSV file.

So, it looks like the only way to get those fields out of ZC is to do a full export. To get them back in, it looks like you don't have to do a full import. At least there is some data loaded without that type of file...

But I think the real problem is that you have already prefixed the field with v_...

Holy crap, that did it! Isn't it always something simple? I defined the user field in admin as v_map_enabled. I just changed it to map_enabled and it worked. Thank you very very much!

21 Nov 2013, 21:28
#1268
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,908
Plugin Contributions:
2

Re: EasyPopulate 4.0 Support Thread

scottj:

Holy crap, that did it! Isn't it always something simple? I defined the user field in admin as v_map_enabled. I just changed it to map_enabled and it worked. Thank you very very much!

Sorry couldn't help sooner, I didn't have the code available to review. Figured I'd take a quick look since I saw your message.

Regarding the logic of the program, ah it's a program. :) It does many powerful things and has a lot of capability. With regards to losing the description, I think there is a bit of misconfiguration in that it basically requires the description to be uploaded, and so if the description is not in the CSV file, it uploads NULL... NULL on existing data means bye bye.. But it's handles/addresses a lot of ZC options and processes.

27 Nov 2013, 20:48
#1269
su35 avatar

su35

Zen Follower

Join Date:
Oct 2011
Posts:
168
Plugin Contributions:
0

Re: EasyPopulate 4.0 Support Thread

Problem with error message "No category provided for this new product"
I have installed EP4 since last year, it works well until today. Some products were inserted and others got the error message. There is no any difference in the category filed. Is anyone can help?

Attachment 13417

27 Nov 2013, 21:17
#1270
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,908
Plugin Contributions:
2

Re: EasyPopulate 4.0 Support Thread

su35:

Problem with error message "No category provided for this new product"
I have installed EP4 since last year, it works well until today. Some products were inserted and others got the error message. There is no any difference in the category filed. Is anyone can help?

Attachment 13417

So, reviewed the code for this particular error message. It only appears as is if the category identified in the field does not exist as part of the existing category list. When you look at the CSV file using a basic text editor with just those two entries, do you see any displacement of the quotes? The same number of spaces between the first and the second listing? Have you tried copying the category from the successful one to the unsuccessful? Wondering if there might be some other character code that is not "visible" onscreen.

The other thought depends on the editor that you are using and whether it is saving the file as a proper CSV file and therefore if it is not, then when uploaded for import it is not understanding the line of information properly. Just some basic thoughts.

29 Nov 2013, 01:50
#1271
su35 avatar

su35

Zen Follower

Join Date:
Oct 2011
Posts:
168
Plugin Contributions:
0

Re: EasyPopulate 4.0 Support Thread

mc12345678:

So, reviewed the code for this particular error message. It only appears as is if the category identified in the field does not exist as part of the existing category list. When you look at the CSV file using a basic text editor with just those two entries, do you see any displacement of the quotes? The same number of spaces between the first and the second listing? Have you tried copying the category from the successful one to the unsuccessful? Wondering if there might be some other character code that is not "visible" onscreen.

The other thought depends on the editor that you are using and whether it is saving the file as a proper CSV file and therefore if it is not, then when uploaded for import it is not understanding the line of information properly. Just some basic thoughts.

Thanks mc12345678
However, after deleted almost everything, I got the same result. I had dumped the $categories_name_exists on screen, it was null.
Attachment 13423

29 Nov 2013, 02:09
#1272
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,908
Plugin Contributions:
2

Re: EasyPopulate 4.0 Support Thread

su35:

Thanks mc12345678
However, after deleted almost everything, I got the same result. I had dumped the $categories_name_exists on screen, it was null.
Attachment 13423

I am assuming that the correct variable was used for the screen dump, would expect it to not be a "true" value because the error message is displayed. It would be more important to track backwards and see if a value was provided at all for the category and other information to see where/when it "lost" the name.

I haven't used NotePad++, I see that there are no quotes around the text in the string. This could be a problem. I'm not sure that it is causing your problem. Also, considering how much has been removed, there is little that could/would get in the way. I haven't counted the commas, but hope that the right data got to the right place. (BTW, unless you have corrected it, I think that the lack of description used in this upload will cause your description to be erased for that/those models.. )

I'm trying to help, but this is a really odd situation that it is not working for a few cases... :/ If you only have model 64636 in a file, will it add it? (I'm thinking no because the failed row is before the successful row. ) I'm trying to think how to help without having a copy of the file causing the problem. :/

30 Nov 2013, 00:34
#1273
laquilino68 avatar

laquilino68

New Zenner

Join Date:
Nov 2013
Location:
Palm Bay, FL
Posts:
7
Plugin Contributions:
0

Re: EasyPopulate 4.0 Support Thread

can you tell me what the longest field length is for the "v_products_description_1" field is?

Thank you kindly in advance!

05 Dec 2013, 17:59
#1274
linuxguy2 avatar

linuxguy2

Zen Follower

Join Date:
Sep 2013
Location:
Texas
Posts:
315
Plugin Contributions:
0

Re: EasyPopulate 4.0 Support Thread

Thanks for the GREAT plugin. Seems to work ok just need to do more testing in my particular store.

This is an operational nit with oo and Excel but may save some a lot of time.

If you Creating a part name (or any other entry in zc) with a leading zero, as in "078453M" when editing in oo or Excel you must set the appropriate column to "text" .

To do this after you DOWNLOAD the *.cvs file on your local machine first rename it with a *.txt extension before opening with Excel or oo.
When opening file you have the opportunity to change the "General" type to "Text" which you must do for columns you want to retain the leading zero(s) in.
Save as a *.txt file then rename to *.cvs before uploading and Viola! you will retain the leading zero(s)

To do this when you create a NEW *.cvs file on your local machine first save it with a *.txt extension change the "General" type to "Text" for columns you want to retain the leading zero(s) in.
Save as a *.txt file then rename to *.cvs before uploading and Viola! you will retain the leading zero(s)

You can use this special naming convention to group different product lines etc.. in applications like zc and QuickBooks.

08 Dec 2013, 16:26
#1275
100asa avatar

100asa

Totally Zenned

Join Date:
Oct 2006
Location:
Italy
Posts:
636
Plugin Contributions:
0

Re: EasyPopulate 4.0 Support Thread

where I can download this 4.0 version?

08 Dec 2013, 20:02
#1276
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,908
Plugin Contributions:
2

Re: EasyPopulate 4.0 Support Thread

100asa:

where I can download this 4.0 version?

Please see the first post of the thread.

08 Dec 2013, 20:34
#1277
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,908
Plugin Contributions:
2

Re: EasyPopulate 4.0 Support Thread

laquilino68:

can you tell me what the longest field length is for the "v_products_description_1" field is?

Thank you kindly in advance!

From what I have been able to gather, there is nothing about EP4 that specifically limits the length of the field. The field is a text field in the database, the applicable editor may have some limitations or maybe a function that is called, but EP4 doesn't truncate the field length of the description, regardless of the language.

09 Dec 2013, 15:07
#1278
chadderuski avatar

chadderuski

Totally Zenned

Join Date:
Apr 2006
Location:
Dark Side of the Moon
Posts:
986
Plugin Contributions:
0

Re: EasyPopulate 4.0 Support Thread

mc12345678:

From what I have been able to gather, there is nothing about EP4 that specifically limits the length of the field. The field is a text field in the database, the applicable editor may have some limitations or maybe a function that is called, but EP4 doesn't truncate the field length of the description, regardless of the language.

Hi All! No, I did not fall off the planet :p

EP4 does NOT limit field lengths, but it does check the database to see what the size of the fields are and gives you a warning/error message if you go over that length.

I believe that non-critical data gives a warning, but something like a category name generate an error and does not add that record. This is necessary especially when creating category names, or even manufacturer names. With out it, a name the exceeds the length in the database would be truncated and added multiple times (there would be not match when comparing values). Other versions of EP don't do this unless they've fixed it recently.

Multi-byte encoded languages are a bit harder to work with, but should function correctly.

-chadd

09 Dec 2013, 16:38
#1279
any_way avatar

any_way

New Zenner

Join Date:
Aug 2013
Posts:
4
Plugin Contributions:
0

Re: EasyPopulate 4.0 Support Thread

no solution mc123456... relating to my post on 08/24/2013

please answer with a simple yes or no.

09 Dec 2013, 17:37
#1280
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,908
Plugin Contributions:
2

Re: EasyPopulate 4.0 Support Thread

any_way:

hello chadd,

your plugin works fine, is it possible to add "v_products_name" to export file "Model/Price/Qty"?

Output "Model/Price/Qty" like this example:

v_products_model,v_products_name,v_status,v_specials_price,v_specials_date_avail,v_specials_expires_date,v_products_price,v_products_quantity

any_way:

no solution mc123456... relating to my post on 08/24/2013

please answer with a simple yes or no.

Wow... My apologies. I can generate a solution. Not a difficult add in, at least if just want to have the data displayed on the screen. If want the program to use the data, that may take a little more. Below is the changes to show the products name (multilingual potential) for the product model being discussed when doing price quantity discounts. It does not necessarily import that data back into the database. (Haven't looked through the import code, nor did I see that it was expected to import the name.) So this is just for user benefit when updating the other fields.

In admin/includes/functions/extra_functions/easypopulate_4_functions.php

Main code section: function ep_4_set_filelayout

At the case for priceqty: (Add the foreach statement after the first $filelayout and before the next $filelayout... This forces the name to be after the model...)

 case 'priceqty':
  $filelayout[] = 'v_products_model';
  foreach ($langcode as $key => $lang) { // create variables for each language id
   $l_id = $lang['id'];
   $filelayout[] = 'v_products_name_'.$l_id;
  }   
  $filelayout[] = 'v_status'; // 11-23-2010 added product status to price quantity option

in admin/easypopulate_4_export.php find the end of the 'full' routine as shown below, insert the text in red (oops, used php tags... There is no custom coloring for PHP tags so the code area as described) before the //BEGIN: Specials. (This just happens to be a convenient location and is not required to be at that specific point in the code. There is an area lower in the code that addresses the calculations of the priceqty discount; however, after quickly coding this, it seemed like this area still may be preferred. The lower area is heavy in math and affects of performing a discount and not so much in the other "random" data to be exported.

  } // if($ep_dltype == 'full')

  if ($ep_dltype == 'priceqty') {
   foreach ($langcode as $key => $lang) {
    $lid = $lang['id'];
    $sql2    = 'SELECT * FROM '.TABLE_PRODUCTS_DESCRIPTION.' WHERE products_id = '.$row['v_products_id'].' AND language_id = '.$lid.' LIMIT 1 ';
    $result2 = ep_4_query($sql2);
    $row2    = mysql_fetch_array($result2);
    $row['v_products_name_'.$lid]        = $row2['products_name'];
   } // end foreach $langcode
  } //end if ($ep_dltype == 'priceqty')

  // BEGIN: Specials