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

EasyPopulate 4.0 Support Thread

Sticky

Views: 733,386

Results 1,121 to 1,140 of 3,671
30 Aug 2013, 9:35 AM
#1121
mc12345678 avatar

mc12345678

Totally Zenned

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

EasyPopulate 4.0 Support Thread

scubasteve:

I am having two issues with getting the v_products_description_1 field to update.

  1. It seems to load on a completely new product but when I try to update it does not change.
  2. I also have issues with it truncating the field at random lengths. I have queries that search and replace all special characters with their HTML friendly equivalent which seemed to help in some instances. These are MEMO fields in Access 2007 and when I export I always go into the export spec file and make sure the field is set to MEMO and has a width of 8000 characters or so.

The text files look good and import the other fields like quantity and call the correct values. I'm currently working trying to update the Manufacturer: Charles Industries on my https://www.navigatorschoice.com site with is v1.5.0 but have the same problems with https://www.scubastevesmarine.com which is v1.5.1.

I have attached the file I'm importing currently. A link to one of the items is http://www.navigatorschoice.com/index.php?main_page=product_info&cPath=46_78_209&products_id=1527, it updated successfully the quantity to zero and product is call to 1. But the description should have had some red text added to it which didn't update.

Any assistance with these issues is appreciated.

I've been thinking about this the last couple of days, but unfortunately haven't been at the right computer long enough to download and review your sample file.
I'm curious though about the lack of updating description 1 after originally uploading it.
What file type is/was used to originally insert it and then what filetype is/was used to try to update it? What type of modification was attempted? Was it just an attempt to add html color coding? (If so, I can't remember if there are tag filters in this plug-in and if there are whether those tags missing are the ones "needed/desired".

Unfortunately there is also an added complexity of all of the substitutions needed for the Access 2007 conversion.

A little more description/clarity is needed (ie. about where all of this "work" is occurring and tests done to possibly determine the cause of the random truncation. Anything consistent about the text file that is updated in relationship to the truncation point? Etc...)

30 Aug 2013, 7:49 PM
#1122
feznizzle avatar

feznizzle

Totally Zenned

Join Date:
Apr 2010
Posts:
900
Plugin Contributions:
0

Re: EasyPopulate 4.0 Support Thread

I need to:

  1. Move products to new categories.
  2. Delete the old categories

Moving did not seem to be a problem, I just changed the "v_categories_name_1" reference. HOWEVER... when I did this, all the products showed up as LINKED. @#%$!!!

Just as annoying, there appears to be no way to delete the old categories, short of going manual.

Grrrrrrrrrrrr! Are there any paid mods out there that are worth a look? I'd pay a grand without batting an eye for a simple way to edit my db en masse.

1 Sep 2013, 11:16 PM
#1123
scubasteve avatar

scubasteve

New Zenner

Join Date:
Oct 2005
Posts:
54
Plugin Contributions:
0

Re: EasyPopulate 4.0 Support Thread

mc12345678:

I've been thinking about this the last couple of days, but unfortunately haven't been at the right computer long enough to download and review your sample file.
I'm curious though about the lack of updating description 1 after originally uploading it.
What file type is/was used to originally insert it and then what filetype is/was used to try to update it? What type of modification was attempted? Was it just an attempt to add html color coding? (If so, I can't remember if there are tag filters in this plug-in and if there are whether those tags missing are the ones "needed/desired".

Unfortunately there is also an added complexity of all of the substitutions needed for the Access 2007 conversion.

A little more description/clarity is needed (ie. about where all of this "work" is occurring and tests done to possibly determine the cause of the random truncation. Anything consistent about the text file that is updated in relationship to the truncation point? Etc...)

Original file type that was upload was a text file. I don't think this is the issue as the scubastevesmarine.com site was originally uploaded with Advanced Easy Populate 3.0.3 (tab delimited text file) and the Navigatorschoice.com was originally loaded with this version of EP4 a csv text file. They both experience the same issue.

Of course both sites now use EP4 and a csv text file. I have developed a search and replace code in Access to change all the special characters to their HTML equivalent to fix the issue with special characters causing a problem if loaded as the special character and not HTML. I have experienced copyright symbols, etc causing problems with loading of long memo text. Simple but long replace function that works effectively at cleaning up all the special characters. I'll put the code at the end of this post in a quote.

As for what I'm modifying it would be just uploading the complete descriptions now that I have figured out a way to resolve the special characters issue in a manner that is efficient for fixing 14,000+ items. The file I attached is adding new text which is highlighted in red. Essentially the same thing just a small sample that is easy to work with. I could manually do this for these but it really wouldn't address the issue of 100's or 1,000's of items that need to be updated, which is the real issue.

The products all contained in a Access 2007 database for each website 14,000 in on and 4,000+ in the other. All the queries build export tables to update various fields on the website. As I indicated above the description field is "cleaned" of special characters. For a description update the file exported would typically have the v_product_description_1 field at the end of the table to make the file specification in Access easier to deal with in setting the export field to a Memo field and setting the character length to a sufficient length to capture all the characters in the field for each product (I have tried differing lengths 8k, 10k, 12k all produce same import results). I have also tried loading just the description field alone with the only other field being product_model, same results.

The necessity to clean the special characters comes from the supplier whose data files send the HTML code mixed with special characters as opposed to their HTML equivalents. I have never had issue with the ACCESS 2007 export file function other than with this field. The csv files it creates function properly on any other import except for the description field.

One other thing it seems the fields while random seem to cut off around 400 or so characters if I recall correctly.

I appreciate any assistance you can provide. Let me know if there is anything else I could provide to assist in troubleshooting the issue. Thanks again.

ACCESS 2007 REPLACE SPECIAL CHARACTERS FUNCTION:

unction DescSpecCharToHTML(v_products_description_en) As String

Dim fdesc_nospec As String

fdesc_nospec = Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(v_products_description_en, Chr(34), """), Chr(145), "‘"), Chr(146), "’"), Chr(147), "“"), Chr(148), "”"), Chr(153), "™"), Chr(174), "®"), Chr(169), "©"), Chr(96), "`"), Chr(44), ","), Chr(176), "°"), Chr(39), "'"), Chr(126), "~"), Chr(153), "™"), Chr(133), "…"), Chr(252), "ü")

DescSpecCharToHTML = fdesc_nospec

End Function

1 Sep 2013, 11:24 PM
#1124
scubasteve avatar

scubasteve

New Zenner

Join Date:
Oct 2005
Posts:
54
Plugin Contributions:
0

Re: EasyPopulate 4.0 Support Thread

Also here are the EP4 settings if they might help with resolving the issue:

Upload Directory: MY_ADMIN_UPLOADS
Verbose Feedback: TRUE
Split Records: 4000
Execution Time: 120
Convert Curly Quotes: No Change
Convert Char 0x92: No Change
Enable Products Metatags: 1
Enable Products Music: 0

Custom Products Fields
Product Short Descriptions: FALSE
Product Unit of Measure: FALSE
Product UPC Code: FALSE
Google Product Category: FALSE
Manufacturer's Suggested Retail Price: FALSE
Group Pricing Per Item: FALSE
Exclusive Products Mod: FALSE

User Defined Products Fields:

Installed Languages
1-en: English
Default Language: 1-English
Internal Character Encoding: UTF-8
DB Collation: utf8

Database Field Lengths
categories_name:32
manufacturers_name:32
products_model:32
products_name:100

2 Sep 2013, 1:29 PM
#1125
waterbender avatar

waterbender

New Zenner

Join Date:
May 2010
Posts:
84
Plugin Contributions:
0

Re: EasyPopulate 4.0 Support Thread

Hi,

Been using the Advanced Easy Populate on v1.3.9. Does anyone know if it will still work in v1.5.1?
Is Easy Populate 4.0 better? What is the difference? This is beta version, is it still unstable and subject to testing?

2 Sep 2013, 2:30 PM
#1126
mc12345678 avatar

mc12345678

Totally Zenned

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

Re: EasyPopulate 4.0 Support Thread

waterbender:

Hi,

This is beta version, is it still unstable and subject to testing?

Sorry, for not being able to answer the rest of your questions, but as I understand it, this is to be published soon as an actual Zen Cart plug-in, but the author has had some other priorities above doing that. I would say that the only unstable part I have observed is the user knowing what the program will do based on the data provided and it's current limitations. (Ie, documentation does not have great depth... Yet.)

One thing that seems to be relatively different from other versions of easy populate is that it depends on the product model field to perform all of its actions. Subject to testing? Well isn't every plug-in? It does seem that those new to it go through a sort of initial testing phase as they become familiar with the file naming requirements, the interaction of the various files (what needs to be imported to get from nothing to a product priced by newly created attributes for example). Beyond that, I can't say that I have used the other versions identified. To me, the code of this plug-in is relatively straight forward so if there is something to be done with it like to rearrange or add onto, its not terribly difficult to find where to put it.

I do know there is some development being done to better support multiple languages, but not sure where that is at in development.

2 Sep 2013, 2:43 PM
#1127
scubasteve avatar

scubasteve

New Zenner

Join Date:
Oct 2005
Posts:
54
Plugin Contributions:
0

Re: EasyPopulate 4.0 Support Thread

waterbender:

Hi,

Been using the Advanced Easy Populate on v1.3.9. Does anyone know if it will still work in v1.5.1?
Is Easy Populate 4.0 better? What is the difference? This is beta version, is it still unstable and subject to testing?

Advanced Easy Populate is not compatible with 1.5.1 as I understand it. Which is the reason I made the switch recently. It required me to make some changes to the files the EOREOR record is no longer required. The files are CSV instead of tab-delimited. You must upload the files prior to import and split them if necessary instead of streaming the import. I found this to be much faster than Adv EP. Overall I think this version is as good or better. It does everything I need it to do. I'm having a small issue with the long text description field but that may be unique to my situation. Still trying to figure that out. One of the changes with Categories is using the ^ symbol instead of ~ to delimit the categories. Overall once I got used to the changes I like this version a little better than Adv EP. You can install EP4 in 1.3.9h and use them both if you haven't upgraded to 1.5.1 yet while you transition.

2 Sep 2013, 2:53 PM
#1128
mc12345678 avatar

mc12345678

Totally Zenned

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

Re: EasyPopulate 4.0 Support Thread

scubasteve:

Original file type that was upload was a text file. I don't think this is the issue as the scubastevesmarine.com site was originally uploaded with Advanced Easy Populate 3.0.3 (tab delimited text file) and the Navigatorschoice.com was originally loaded with this version of EP4 a csv text file. They both experience the same issue.

Of course both sites now use EP4 and a csv text file. I have developed a search and replace code in Access to change all the special characters to their HTML equivalent to fix the issue with special characters causing a problem if loaded as the special character and not HTML. I have experienced copyright symbols, etc causing problems with loading of long memo text. Simple but long replace function that works effectively at cleaning up all the special characters. I'll put the code at the end of this post in a quote.

As for what I'm modifying it would be just uploading the complete descriptions now that I have figured out a way to resolve the special characters issue in a manner that is efficient for fixing 14,000+ items. The file I attached is adding new text which is highlighted in red. Essentially the same thing just a small sample that is easy to work with. I could manually do this for these but it really wouldn't address the issue of 100's or 1,000's of items that need to be updated, which is the real issue.

The products all contained in a Access 2007 database for each website 14,000 in on and 4,000+ in the other. All the queries build export tables to update various fields on the website. As I indicated above the description field is "cleaned" of special characters. For a description update the file exported would typically have the v_product_description_1 field at the end of the table to make the file specification in Access easier to deal with in setting the export field to a Memo field and setting the character length to a sufficient length to capture all the characters in the field for each product (I have tried differing lengths 8k, 10k, 12k all produce same import results). I have also tried loading just the description field alone with the only other field being product_model, same results.

The necessity to clean the special characters comes from the supplier whose data files send the HTML code mixed with special characters as opposed to their HTML equivalents. I have never had issue with the ACCESS 2007 export file function other than with this field. The csv files it creates function properly on any other import except for the description field.

One other thing it seems the fields while random seem to cut off around 400 or so characters if I recall correctly.

I appreciate any assistance you can provide. Let me know if there is anything else I could provide to assist in troubleshooting the issue. Thanks again.

Okay, so there was a communication issue. My question was basically what is the name of the file that you are uploading to your database? (Provided as examples even though the capitalization and length of the filename may not be correct for this plugin: Basic, Full, Advanced, Attributes, etc...)

In order to identify why the description block as reported here will not update even though a new/revised line of data is provided, it is important to know some of the other details besides those from the screen:

scubasteve:

Also here are the EP4 settings if they might help with resolving the issue:

Upload Directory: MY_ADMIN_UPLOADS
Verbose Feedback: TRUE
Split Records: 4000
Execution Time: 120
Convert Curly Quotes: No Change
Convert Char 0x92: No Change
Enable Products Metatags: 1
Enable Products Music: 0

Custom Products Fields
Product Short Descriptions: FALSE
Product Unit of Measure: FALSE
Product UPC Code: FALSE
Google Product Category: FALSE
Manufacturer's Suggested Retail Price: FALSE
Group Pricing Per Item: FALSE
Exclusive Products Mod: FALSE

User Defined Products Fields:

Installed Languages
1-en: English
Default Language: 1-English
Internal Character Encoding: UTF-8
DB Collation: utf8

Database Field Lengths
categories_name:32
manufacturers_name:32
products_model:32
products_name:100

For example, I don't think that having the model name and description 1 fields in the attributes file will result in a change to description 1.
If however, an applicable/appropriate filename is being used, then there is probably yet some special character in the data. Might do some sort of check for characters to be allowed in the text of the field after all of the substitutions. Also, look through your CSV that is to be manipulated using a standard text editor/viewer to verify that the text is not cutoff there at/after each save. May even want to save the file with a different name as you work from step to step so that you can run a text compare to see what changes between the two.

I'm still a little unclear as to at what point in the process the text of description 1 gets truncated. Is it from the export by access where the information is treated as a memo of tens of thousands of characters, or is it upon import to Zen Cart, or is it somewhere in between (ie, change something about the file?)

2 Sep 2013, 3:28 PM
#1129
waterbender avatar

waterbender

New Zenner

Join Date:
May 2010
Posts:
84
Plugin Contributions:
0

Re: EasyPopulate 4.0 Support Thread

scubasteve:

Advanced Easy Populate is not compatible with 1.5.1 as I understand it. Which is the reason I made the switch recently. It required me to make some changes to the files the EOREOR record is no longer required. The files are CSV instead of tab-delimited. You must upload the files prior to import and split them if necessary instead of streaming the import. I found this to be much faster than Adv EP. Overall I think this version is as good or better. It does everything I need it to do. I'm having a small issue with the long text description field but that may be unique to my situation. Still trying to figure that out. One of the changes with Categories is using the ^ symbol instead of ~ to delimit the categories. Overall once I got used to the changes I like this version a little better than Adv EP. You can install EP4 in 1.3.9h and use them both if you haven't upgraded to 1.5.1 yet while you transition.

Thanks for these helpful info, mc12345678 and scubasteve.

A few more questions:
"You must upload the files prior to import and split them if necessary instead of streaming the import."
- Do you mean I have to upload the file and then click import? Where do I upload the file? Is there a limit on the number of products?

"I'm having a small issue with the long text description field but that may be unique to my situation."
- I use long description regularly. What issues are you experiencing?

Can someone show me a sample files with all the necessary field titles? These are the fields I use in advanced easy populate. Are they totally different now?
v_products_id (How do I use products_id as the unique primary index in EP4?)
v_products_model (If products_id can be the primary index, can products_model field still be used?)
v_products_type (Do I still put "Product - General" in this?)
v_products_image
v_products_name_en
v_products_description_en
v_products_url_en
v_specials_price
v_specials_date_available
v_specials_expires_date
v_products_price
v_products_weight
v_products_date_available
v_products_date_added (Is there a specific date format to follow in EP4?)
v_products_quantity
v_products_quantity_order_units
v_products_quantity_order_min
v_products_quantity_mixed
v_products_qty_box_status
v_manufacturers_name
ptc_categories_index_path (You said ^ is used instaed of ~)
ptc_categories_destination_path
ptc_categories_linked_path
v_tax_class_title
v_products_status
EOREOR (If this is no longer required, what do we use instead?)

3 Sep 2013, 12:11 AM
#1130
scubasteve avatar

scubasteve

New Zenner

Join Date:
Oct 2005
Posts:
54
Plugin Contributions:
0

Re: EasyPopulate 4.0 Support Thread

waterbender:

Thanks for these helpful info, mc12345678 and scubasteve.

A few more questions:
"You must upload the files prior to import and split them if necessary instead of streaming the import."
- Do you mean I have to upload the file and then click import? Where do I upload the file? Is there a limit on the number of products?
Yes, Easy Populate 4 is in the Tools Menu just as AEP similar interface for uploading files. No limit that I know of, I have over 14,000 items in one store. I can't load all those at once so anything I do updating all products I split into 4,000 items per file. I believe the default is 2,000. This is changed in the Configuration menu item for EP4.

waterbender:

"I'm having a small issue with the long text description field but that may be unique to my situation."
- I use long description regularly. What issues are you experiencing?
See my previous posts on page 112 and 113 of this thread. Hoping someone can figure out what the issue is, I'm stumped.

waterbender:

Can someone show me a sample files with all the necessary field titles? These are the fields I use in advanced easy populate. Are they totally different now?
v_products_id (How do I use products_id as the unique primary index in EP4?)
v_products_model (If products_id can be the primary index, can products_model field still be used?)
v_products_type (Do I still put "Product - General" in this?)
v_products_image
v_products_name_en
v_products_description_en
v_products_url_en
v_specials_price
v_specials_date_available
v_specials_expires_date
v_products_price
v_products_weight
v_products_date_available
v_products_date_added (Is there a specific date format to follow in EP4?)
v_products_quantity
v_products_quantity_order_units
v_products_quantity_order_min
v_products_quantity_mixed
v_products_qty_box_status
v_manufacturers_name
ptc_categories_index_path (You said ^ is used instaed of ~)
ptc_categories_destination_path
ptc_categories_linked_path
v_tax_class_title
v_products_status
EOREOR (If this is no longer required, what do we use instead?)

v_products_name_en now v_products_name_1
v_products_description_en now v_products_description_1
v_products_url_en now v_products_url_1
anything with an _en ending is now _1, metatags fields come to mind as other fields where this is an issue.

Date format hasn't changed. 9/14/2012 0:00

I don't believe you update these category fields below anymore for the product category I use v_categories_name_1 (format... Top Category^Sub Cat1^Sub Cat2). I used to load categories separately with sort orders, not sure if you can do this in EP4. I haven't tried to play around with updating sort orders on categories.

ptc_categories_index_path (You said ^ is used instaed of ~)
ptc_categories_destination_path
ptc_categories_linked_path

There is no replacement for EOREOR the field goes away under EP4, took me awhile to realize that.

You can do a complete download which will have all the field names as an example. EP4 can also be installed with AEP3.0.3 without conflicting then you can remove AEP3.0.3 before upgrading your site to 1.5.1.

3 Sep 2013, 12:22 AM
#1131
scubasteve avatar

scubasteve

New Zenner

Join Date:
Oct 2005
Posts:
54
Plugin Contributions:
0

Re: EasyPopulate 4.0 Support Thread

mc12345678:

Okay, so there was a communication issue. My question was basically what is the name of the file that you are uploading to your database? (Provided as examples even though the capitalization and length of the filename may not be correct for this plugin: Basic, Full, Advanced, Attributes, etc...)
Here are some of the filenames:
Added Products Export.csv
Specials Prices with Description Export.csv
zzCharles Products Update Export.csv
Export Description Update HTML.csv

mc12345678:

In order to identify why the description block as reported here will not update even though a new/revised line of data is provided, it is important to know some of the other details besides those from the screen:

For example, I don't think that having the model name and description 1 fields in the attributes file will result in a change to description 1.
If however, an applicable/appropriate filename is being used, then there is probably yet some special character in the data. Might do some sort of check for characters to be allowed in the text of the field after all of the substitutions. Also, look through your CSV that is to be manipulated using a standard text editor/viewer to verify that the text is not cutoff there at/after each save. May even want to save the file with a different name as you work from step to step so that you can run a text compare to see what changes between the two.

I'm still a little unclear as to at what point in the process the text of description 1 gets truncated. Is it from the export by access where the information is treated as a memo of tens of thousands of characters, or is it upon import to Zen Cart, or is it somewhere in between (ie, change something about the file?)

The description gets truncated during the import to Zen Cart. The text files being exported are not the issue as far as containing all the description. I don't load descriptions with attributes. Only with a special price change, normal price, quantity and weight updates. I also believe I have tried it with only model and description so the only thing being updated was description.

When I dissected a couple of products the place where it truncated had no special character, it is very strange. I'm going to try again with a description only update. If that doesn't work I'll try updating all descriptions to NULL and reload them and see if that works. I'll let you know how that turns out.

3 Sep 2013, 12:51 AM
#1132
waterbender avatar

waterbender

New Zenner

Join Date:
May 2010
Posts:
84
Plugin Contributions:
0

Re: EasyPopulate 4.0 Support Thread

scubasteve:

I don't believe you update these category fields below anymore for the product category I use v_categories_name_1 (format... Top Category^Sub Cat1^Sub Cat2). I used to load categories separately with sort orders, not sure if you can do this in EP4. I haven't tried to play around with updating sort orders on categories.

So does anyone know how to import using products_id instead of products_model?

My next questions are how to import product categories and attributes.

For product categories, the fields in advanced easy populate are shown below. What about the fields in EP4?
c_categories_index_path
c_categories_destination_path
c_categories_image
c_sort_order
c_categories_status
cd_categories_name_en
cd_categories_description_en

For attributes, the example file is confusing because it is quite different from that of advanced easy populate. Do we not use the id of option names and id of option values? Am I right that we still have to create the option name and option value before importing attributes using EP4?

Regarding your issue with product description getting truncated, it can also happen in advanced easy populate. This is usually caused by non-standard quote marks, apostrophe or any unusual symbols.

3 Sep 2013, 1:00 AM
#1133
mc12345678 avatar

mc12345678

Totally Zenned

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

Re: EasyPopulate 4.0 Support Thread

waterbender:

Thanks for these helpful info, mc12345678 and scubasteve.

A few more questions:
"You must upload the files prior to import and split them if necessary instead of streaming the import."
- Do you mean I have to upload the file and then click import? Where do I upload the file? Is there a limit on the number of products?

"I'm having a small issue with the long text description field but that may be unique to my situation."
- I use long description regularly. What issues are you experiencing?

Can someone show me a sample files with all the necessary field titles? These are the fields I use in advanced easy populate. Are they totally different now?
v_products_id (How do I use products_id as the unique primary index in EP4?)
v_products_model (If products_id can be the primary index, can products_model field still be used?)
v_products_type (Do I still put "Product - General" in this?)
v_products_image
v_products_name_en
v_products_description_en
v_products_url_en
v_specials_price
v_specials_date_available
v_specials_expires_date
v_products_price
v_products_weight
v_products_date_available
v_products_date_added (Is there a specific date format to follow in EP4?)
v_products_quantity
v_products_quantity_order_units
v_products_quantity_order_min
v_products_quantity_mixed
v_products_qty_box_status
v_manufacturers_name
ptc_categories_index_path (You said ^ is used instaed of ~)
ptc_categories_destination_path
ptc_categories_linked_path
v_tax_class_title
v_products_status
EOREOR (If this is no longer required, what do we use instead?)

I can only answer some (maybe several, but not all of the questions.)

To have the data captured in the database, yes the file must exist on the server. Either it is uploaded by your favorite ftp program or from within the admin panel for easy populate 4.
Essentially, the number of products is really based on your servers; however, EP4 provides a split function that will make chunks out of a large file based on the settings you have the flexibility to change.

As to the issues with the long text description that are being experienced by scubasteve, there is still some investigation about the data. Essentially as I understand the situation, Access 2007 contains much of the data to be processed in scubasteve's situation; however, once that data is exported and at some point imported into ZC, there are characteristics about the description field that are not carried over. Although the data is initially "filtered" to some extent, I'm thinking that regardless of using EP4 or not that there would be an issue if the data were just copied and pasted into a SQL editor or even directly into ZC (that something would be modified either to make it work or to prevent a change.) As said, a bit unique situation. Others use this plug-in and are able to update the description1 field without issue.

Currently, the mandatory field is product_model, but if it were changed to the product id, then some other work would need to be done to properly address using it the product id, as the primary field. Yes if changed the product model would still be usable as a field. In fact any field that is already in the database would still be usable, but the code may need some updates to handle the specific field(s).

3 Sep 2013, 1:25 AM
#1134
kevin205 avatar

kevin205

Totally Zenned

Join Date:
Dec 2012
Posts:
607
Plugin Contributions:
0

Re: EasyPopulate 4.0 Support Thread

Is there a way to add a "User Defined Products Field", to the Detailed Products Attributes (detailed multi-line) export?

Do not care about importing it. Only as a reference on Detailed Products Attributes export!

3 Sep 2013, 2:50 AM
#1135
mc12345678 avatar

mc12345678

Totally Zenned

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

Re: EasyPopulate 4.0 Support Thread

scubasteve:

Here are some of the filenames:
Added Products Export.csv
Specials Prices with Description Export.csv
zzCharles Products Update Export.csv
Export Description Update HTML.csv

The description gets truncated during the import to Zen Cart. The text files being exported are not the issue as far as containing all the description. I don't load descriptions with attributes. Only with a special price change, normal price, quantity and weight updates. I also believe I have tried it with only model and description so the only thing being updated was description.

When I dissected a couple of products the place where it truncated had no special character, it is very strange. I'm going to try again with a description only update. If that doesn't work I'll try updating all descriptions to NULL and reload them and see if that works. I'll let you know how that turns out.

Okay, so EP4 is based heavily on using the right "product" at th right time, with the right information. Off the top of my head, I can't remember if it will properly handle just any old filename, but if you are wanting to updated information that wold be provided in a full export, then the start of the filename needs to closely match the same. Basic filename. (Typically anything up to and including EP4, also the capitalization is important as well.)

When stating that there was no special character, does that mean didn't "see" a special character or was that by bit/byte inspection to verify that each character was an expected alpha-numeric character or end-of-line, etc...? State that becauuse, just because don't see it, doesn't mean it's not there.

3 Sep 2013, 3:08 AM
#1136
mc12345678 avatar

mc12345678

Totally Zenned

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

Re: EasyPopulate 4.0 Support Thread

waterbender:

So does anyone know how to import using products_id instead of products_model?

My next questions are how to import product categories and attributes.

For product categories, the fields in advanced easy populate are shown below. What about the fields in EP4?
c_categories_index_path
c_categories_destination_path
c_categories_image
c_sort_order
c_categories_status
cd_categories_name_en
cd_categories_description_en

For attributes, the example file is confusing because it is quite different from that of advanced easy populate. Do we not use the id of option names and id of option values? Am I right that we still have to create the option name and option value before importing attributes using EP4?

Regarding your issue with product description getting truncated, it can also happen in advanced easy populate. This is usually caused by non-standard quote marks, apostrophe or any unusual symbols.

Code change to deal with product_id.

Regarding categories and the like, ZC was built on a basic process, so yes need to have option names and values in place before assigning attributes. Yes, do not have to use the database number (category id or other designated number) to add and associate items, but do need to be sure spelling and capitalization are equivalent. From much of what I've recently been seeing, people would prefer to have the product-id and maybe keep with the option description to do the linking.

Anyways, it really is best to simply export a file of the desired type to see the structure. It is much easier to see than to describe and yes the instructions are lacking, but if you can look/get past that I would say that for the most part it is rather intuitive with little specific database knowledge. Can't remember where I saw it recently, but cases where language is referenced I thought the number corresponded to the number of the language in one of the database tables. It does not necessarily mean English, German, or Dutch for example, but that area is spposedly one that is being worked on to make it more multi-language friendly.

But, basically, yes multiple files can get uuploaded to build to a final database; however, once some backgrond data is in place, fewer fields need updating and therefore fewer files get updating.

3 Sep 2013, 3:16 AM
#1137
mc12345678 avatar

mc12345678

Totally Zenned

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

Re: EasyPopulate 4.0 Support Thread

Kevin205:

Is there a way to add a "User Defined Products Field", to the Detailed Products Attributes (detailed multi-line) export?

Do not care about importing it. Only as a reference on Detailed Products Attributes export!

Sorry Kevin, been trying to be sure to give some feedback to those things I was able, so as not to cause something to slip through the cracks. Lots of good conversations and questions:

So as for yours, would follow the export code and in particular the detailed report section. I think there are three rows/data areas that need updating to incorporate the desire data in the export. Essentially has to be captured in the data stream (array variable) and has to be pulled via the SQL which I think takes the other two entries. The code is pretty straight forward if you go down the rabbit hole.

3 Sep 2013, 3:20 AM
#1138
kevin205 avatar

kevin205

Totally Zenned

Join Date:
Dec 2012
Posts:
607
Plugin Contributions:
0

Re: EasyPopulate 4.0 Support Thread

mc12345678:

Sorry Kevin, been trying to be sure to give some feedback to those things I was able, so as not to cause something to slip through the cracks. Lots of good conversations and questions:

So as for yours, would follow the export code and in particular the detailed report section. I think there are three rows/data areas that need updating to incorporate the desire data in the export. Essentially has to be captured in the data stream (array variable) and has to be pulled via the SQL which I think takes the other two entries. The code is pretty straight forward if you go down the rabbit hole.

Is easypopulate_4_export.php handling the export? Would other files get involved to achieve this task?

Thank you for helping.

3 Sep 2013, 3:33 AM
#1139
waterbender avatar

waterbender

New Zenner

Join Date:
May 2010
Posts:
84
Plugin Contributions:
0

Re: EasyPopulate 4.0 Support Thread

It looks like I can adapt most things except product_id. Some guy said that we can add products_id as a custom field under User Defined Products Fields. Once I done that, will I be able to use products_id as the primary index instead of products_model? Or do I still mess with codes?

3 Sep 2013, 3:41 AM
#1140
mc12345678 avatar

mc12345678

Totally Zenned

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

Re: EasyPopulate 4.0 Support Thread

Kevin205:

Is easypopulate_4_export.php handling the export? Would other files get involved to achieve this task?

Thank you for helping.

Yeah the export file actually does the export, the main file (like without export or import) is a sort of "controller" to pull the files together. There are a few odds and ends that may be handled by the other files, but the meat of the exporrt is in the export file.