-
Re: EasyPopulate 4.0 Support Thread
Awesome!
And information is all that is needed, really. This particular site sells parts, all products live 3 categories deep. All categories are structured like this:
Equipment-Type^Manufacturer-List^Model-Number
So my middle category has about 150 duplicate names and there is no way to know which Master they belong to, thus no what to quickly add a description. The real bugger though is that bottom category. Even though there are very few duplicates, that's a list of about 1000 model numbers. Without knowing the parent cats, it's next to impossible to automate the addition of a description, meta info, etc.
I just saw that you put up a solution on GitHub. I haven't tried it yet, but HUGE thanks! I will report back as soon as I have a chance to try it out.
What I was going to do---prior to the new code you just supplied---was export the category table direct from mySQL, then use vlookup over and over until I had it all sorted.
Maaaan that would have been painful. Huge thanks!!!!
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
Feznizzle
Awesome!
And information is all that is needed, really. This particular site sells parts, all products live 3 categories deep. All categories are structured like this:
Equipment-Type^Manufacturer-List^Model-Number
So my middle category has about 150 duplicate names and there is no way to know which Master they belong to, thus no what to quickly add a description. The real bugger though is that bottom category. Even though there are very few duplicates, that's a list of about 1000 model numbers. Without knowing the parent cats, it's next to impossible to automate the addition of a description, meta info, etc.
I just saw that you put up a solution on GitHub. I haven't tried it yet, but HUGE thanks! I will report back as soon as I have a chance to try it out.
What I was going to do---prior to the new code you just supplied---was export the category table direct from mySQL, then use vlookup over and over until I had it all sorted.
Maaaan that would have been painful. Huge thanks!!!!
No problem, as said, the information makes sense from a usability standpoint, but also leads to the potential of users misunderstanding that modifying it the same way as done with the full product data will provide the same results. I'll incorporate it into the master thread so that others can benefit from the change.
-
Re: EasyPopulate 4.0 Support Thread
I have just upgrades to EP4 and having 1 issue and I`m sure it is something I`ve missed.
My main categories are INKJET / TONERS / SOLID INK / RIBBONS / DRUMS etc
When these are clicked inside each are ADVENT / BROTHER / CANON / DELL / EPSON etc
When using the earlier version this was working okay, since the upgrade I still have the main categories however there are no sub categories so all INKJET are all together.
I have checked to make sure the CSV headings are correct so I`m baffled.
Any advice muchly appreciated as it always is.
Mike Smith
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
MCS_Computers
I have just upgrades to EP4 and having 1 issue and I`m sure it is something I`ve missed.
My main categories are INKJET / TONERS / SOLID INK / RIBBONS / DRUMS etc
When these are clicked inside each are ADVENT / BROTHER / CANON / DELL / EPSON etc
When using the earlier version this was working okay, since the upgrade I still have the main categories however there are no sub categories so all INKJET are all together.
I have checked to make sure the CSV headings are correct so I`m baffled.
Any advice muchly appreciated as it always is.
Mike Smith
Take a look at the export of a file related to a category that either has or is a sub-category and also the instructions, both of which would identify that sub-categories are identified by using the carat symbol (^) as the divider between each such sub-category.
-
Re: EasyPopulate 4.0 Support Thread
I used the EP to download a Model/Category and it said Inkjet^Advent as I had only imported the advent CSV file but through the store Inkjet had no sub categories. Sorry if that's not what you meant, you`ve helped a lot over the last few days so you should know that I'm a beginner, this is my last hurdle.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
MCS_Computers
I used the EP to download a Model/Category and it said Inkjet^Advent as I had only imported the advent CSV file but through the store Inkjet had no sub categories. Sorry if that's not what you meant, you`ve helped a lot over the last few days so you should know that I'm a beginner, this is my last hurdle.
In a way that's what I meant, if I understand correctly. (which I'm not entirely sure that I do.)
My thoughts were this. If you already have at least one category that is a sub-category (preferably "manually" generated groups), then export of product (active or all) for that category (or sub-category) using the dropdowns across the top of the EP4 tools/admin screen would reflect the information/way that EP4 would expect the data to be made available to reproduce the same type/style of a product.
Mind you, again, the file generated is UTF-8 and the file normally expected for upload followed by import should also be in UTF-8 format. Further, the expectation is that if you look at the raw csv file using a plain text editor both before and after editing, they should look relatively similar. EP4 does add some extra double quotes (" not ') around information, that at least when using Open Office tend not to be "put back", but that's not necessarily an issue.
Anyways, I don't want to overload, especially if the first couple of things above address the issue (again, assuming I understand correctly)
-
Re: EasyPopulate 4.0 Support Thread
It has to be a EP4 thing because my previous version imports the CSV and the store shows category and sub categories as it should
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
MCS_Computers
It has to be a EP4 thing because my previous version imports the CSV and the store shows category and sub categories as it should
Umm. The proof of the "EP4" thing would be to export the file, then do nothing with it but upload and then import it again. The result should be no change to the site.
Then considering that the upload/import of an untouched file works, the next thing is to modify something about the file and repeat the upload/import. The only thing that should change is what was modified.
EP4 works to generate new categories as well as to add product to existing/new categories. If it doesn't for the particular site, then we need to start talking about information that is provided on the EP4 screen to see what isn't correctly setup, the configuration settings, and/or the details of generating the modified csv file.
If need be, PM me login details.
-
Re: EasyPopulate 4.0 Support Thread
MC thanks yet again you pointed me in the direction to fix it.
In the older version of EP it created 2 columns, v_categories_name_1 and v_categories_name_2
1 had Inkjet in and 2 had Advent in, I deleted the 2 column and changed 1 from Inkjet to Inkjet^Advent, re imported the CSV and it worked a treat.
Many thanks once again buddy, it is much appreciated.. :D
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
MCS_Computers
MC thanks yet again you pointed me in the direction to fix it.
In the older version of EP it created 2 columns, v_categories_name_1 and v_categories_name_2
1 had Inkjet in and 2 had Advent in, I deleted the 2 column and changed 1 from Inkjet to Inkjet^Advent, re imported the CSV and it worked a treat.
Many thanks once again buddy, it is much appreciated.. :D
As discussed in one of the other threads, EP4 uses that number to correspond to a language. Yes, it's a little bit of a puzzle and I've been wanting to change the number to a language, but there were other more important fixes to apply over time. At any rate, if you go multi-language, then you can use EP4 to populate the associated language fields using the applicable v_FIELD_LANGUAGEID. Where FIELD might be something like products_description, category, etc... LANGUAGEID would be the number next to the language that you see on the right side of the EP4 tools screen.
-
Re: EasyPopulate 4.0 Support Thread
I'm in the process of building a catalog with about 25,000 products. Even when the data is segmented into groups of 5,000 products, my spreadsheet (libreoffice) bogs down when all data is present (particularly the html for product description pages).
To make this manageable, I want to upload/insert in stages. First I'll CREATE products by inserting bare minimum info (model, ID, Category, Prod name, qty, status, order units, etc). After that, I'll come back and UPDATE those products by inserting additional data (image, price, description, etc).
The following questions are about working with product files (eg, Full-EP2017Sep26-165412.csv).
Product page creation questions:
1. When creating NEW product pages, can I leave the following columns blank (no data)?
v_products_description_1
v_products_price
v_products_weight
v_date_avail
v_date_added
If not, I'll insert small dummy info to replace during later updates.
2. When creating NEW product pages, can I *delete* columns I don't need at the moment (meta data, specials, etc) to reduce clutter? Or does EP4 freak out if columns it expects don't exist?
Updating product page questions:
3. When updating EXISTING product pages, can I *delete* columns I don't wish to change (category, product name) to reduce clutter? Obviously I'll keep the important ones (model, ID, etc).
4. If I have to keep all columns, can I leave the ones I don't wish to change blank?
-
Re: EasyPopulate 4.0 Support Thread
Sorry for the delay in responding.
So... First thing and I know it doesn't directly help with the local effort of adding product to the spreadsheet, but EP4 offers the ability to split a file that is either exported to the server or uploaded to the server. So you could (later) do updates of existing data by exporting, then splitting then downloading so that when you open the file you aren't "troubled" by too many rows/too much data.
That said, if you haven't downloaded the github version which supports product export without including linked product, then when a set of data is split, there is the possibility, however remote, that a row of data for a product could be in one split file and another... the last one imported wins...
To your questions about uploading new product. The concept of the software is that when working with the main product information, only required fields need to be in the file. For new product that is a primary key and a category. For any field not included, generally speaking it will default to some form of emptiness. For dates, if the date_added field is not included, then it will default to now, whenever now is. If the field is included and it is blank or has a date less than 0001-01-01 00:00:00, then it will be set to that (which should be the default in the database, but that's a different story.) v_date_avail does not default to a now condition, but instead a "blank" condition.
As to product status, if it is not provided then it should default to either off (disabled) or the status default in your database. There is a consideration though as to if a product is uploaded that has 0 quantity and the store is set to deactivate product that have 0 quantity then the product will be deactivated regardless of the condition of the uploaded status. Sort of an EP4 working with ZC condition.
Otherwise, regarding your "plan" for updating. Again, when discussing the main product information (not yet incorporated in attributes and a couple other off-shoots), if you don't want to even possibly change a field, then the field column should and can be omitted. If the field is present, whatever is in that column will be attempted to be pushed to the database. If that means the column is blank, then the data will be removed, if it changed from "up" to "down" then "down" will be what remains...
Now, if I have incorrectly stated these things, such that the software does not operate as I have described, please identify as it more than likely is a mistake.
Now, attributes and category specific changes, I know attributes haven't been further modified to permit import with fields missing, but I think at the moment that category import is the same (operation hasn't been modified to support upload with missing fields).
Again, to your last question, there has not been a setting established to leave a field alone if the field is present but the row data is blank. I don't seem to recall anyone asking for that and I tend to look at it as extra work to blank a field to prevent an update as compared to possibly two different file imports or to leave the data as is. (it's possible in most spreadsheet programs to "lock" a field to prevent editing, so would recommend that route instead personally...)
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
mc12345678
Sorry for the delay in responding.
So... First thing and I know it doesn't directly help with the local effort of adding product to the spreadsheet, but EP4 offers the ability to split a file that is either exported to the server or uploaded to the server. So you could (later) do updates of existing data by exporting, then splitting then downloading so that when you open the file you aren't "troubled" by too many rows/too much data.
That said, if you haven't downloaded the github version which supports product export without including linked product, then when a set of data is split, there is the possibility, however remote, that a row of data for a product could be in one split file and another... the last one imported wins...
To your questions about uploading new product. The concept of the software is that when working with the main product information, only required fields need to be in the file. For new product that is a primary key and a category. For any field not included, generally speaking it will default to some form of emptiness. For dates, if the date_added field is not included, then it will default to now, whenever now is. If the field is included and it is blank or has a date less than 0001-01-01 00:00:00, then it will be set to that (which should be the default in the database, but that's a different story.) v_date_avail does not default to a now condition, but instead a "blank" condition.
As to product status, if it is not provided then it should default to either off (disabled) or the status default in your database. There is a consideration though as to if a product is uploaded that has 0 quantity and the store is set to deactivate product that have 0 quantity then the product will be deactivated regardless of the condition of the uploaded status. Sort of an EP4 working with ZC condition.
Otherwise, regarding your "plan" for updating. Again, when discussing the main product information (not yet incorporated in attributes and a couple other off-shoots), if you don't want to even possibly change a field, then the field column should and can be omitted. If the field is present, whatever is in that column will be attempted to be pushed to the database. If that means the column is blank, then the data will be removed, if it changed from "up" to "down" then "down" will be what remains...
Now, if I have incorrectly stated these things, such that the software does not operate as I have described, please identify as it more than likely is a mistake.
Now, attributes and category specific changes, I know attributes haven't been further modified to permit import with fields missing, but I think at the moment that category import is the same (operation hasn't been modified to support upload with missing fields).
Again, to your last question, there has not been a setting established to leave a field alone if the field is present but the row data is blank. I don't seem to recall anyone asking for that and I tend to look at it as extra work to blank a field to prevent an update as compared to possibly two different file imports or to leave the data as is. (it's possible in most spreadsheet programs to "lock" a field to prevent editing, so would recommend that route instead personally...)
YAHOOO! That bolded out statement is faaaaantabulous!
To be super clear, you're saying that after a product has been added, future uploaded files can (and should) contain only the primary key (for me it's ID) and the column(s) containing data I wish to insert/change?
For instance, I could upload a csv with only two columns of data like so:
v_products_id and v_products_description_1
If so... awesome. This just got really easy. :)
Thank you so much for providing so much info!
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
Feznizzle
YAHOOO! That bolded out statement is faaaaantabulous!
To be super clear, you're saying that after a product has been added, future uploaded files can (and should) contain only the primary key (for me it's ID) and the column(s) containing data I wish to insert/change?
For instance, I could upload a csv with only two columns of data like so:
v_products_id and v_products_description_1
If so... awesome. This just got really easy. :)
Thank you so much for providing so much info!
That's the expectation. If it doesn't deliver that way, please advise. There's a lot of possible columns and I don't think each individual scenario was attempted, but it was all based on a philosophy developed by the needs of those that asked and demonstrated how such feature(s) could be advantageous and make the work easier. :) So, if I lied to you, I'd like the opportunity to either fix the issue or explain why it is the way it is.
-
Re: EasyPopulate 4.0 Support Thread
I uploaded in two passes... worked like a charm, exactly as advertised!
FIRST UPLOAD (created 20k+ products)
I left all column headers from template in place. This file contained most of the real prod data (model, image, price, etc), except page html and meta title/description. Once uploaded, I let EP4 segment before I inserted.
SECOND UPLOAD (updated all the freshly created products)
This file contained only two columns of data, product ID (my control) and html. It worked perfectly, with only one minor problem.
Problem was that the csv was really big (54mb). When I used EP4 to upload, it failed for some reason so I ended up having to use FTP client for upload. Once in, I attempted to split the file using EP4. I have it set to split at 5000 records, so I expected 5 segments (same as first upload above). Ended up with like 100 segments! lol
No biggy. I manually split, uploaded and inserted. My smaller segments went thru without a problem.
Anyway, wanted to follow up and let you know it went smoothly. Today I'll be updating all meta data using the same limited column strategy. I don't anticipate any issues, but I'll report back if any occur.
Thanks a lot, MC. You da man!
-
Re: EasyPopulate 4.0 Support Thread
Great information and glad that it worked so well (mostly) :). While I've added to this plugin, it certainly was built on a concept and with a design of others so I can't take all the credit. :)
Regarding the multi-file split that occurred. Did you happen to look at the contents of one or more of them to see what they held or be willing to try again and see?
I'm curious to find out what conditions were in place to cause that issue.
-
Re: EasyPopulate 4.0 Support Thread
About the split, I'll have to recreate for you.
But I just hit a massive roadblock. I've been at it for 12 hours, head throbbing, ready to smash my puter! :(
I just used EP4 to upload all meta titles, descriptions. Since I had flipped on all the meta statuses I wanted during my first product upload, all I was uploading was three columns of data (ID, Title, Description).
Nothing happened. I mean, meta title/description got inserted... but they didn't show up in page source. So I went to a product via my admin panel and tried to flip meta data on manually. I could see the meta stuff I wanted in Admin, but couldn't make them active.
I'll trouble shoot in the morning, when I can finally think again.
Is it possible I broke something during the initial upload by setting v_metatags_title_status to 1, but then leaving v_metatags_title_1 blank?
To test that possibility out, I'll revert back to before that first big upload. When I repeat the upload, next time it will have all the meta info with it.
But I think I may have actually broken something.... even before the EP4 insertion. The amin itself won't allow me to change meta settings.
Ug. Anyway, I sooooo done for the day. It's miller time. Better yet, it's Makers time!
-
Re: EasyPopulate 4.0 Support Thread
So, Hmmm. Had a chance to reread what was provided above, look through the forum and read some code.
EP4 regarding metatags does still have one requirement which is to include the metatags_title (which you have done) in order to process in metatag information. The next thing for a ZC side, is that the applicable metatag information needs to have a status of 1 (true) in order for ZC to say, yes should display. In between those two is that EP4 needs to know whether it should try to process/export metatag information from the configuration menu.
Based on the provided process I'm thinking the individual status setting did not get set/establish for the records and so the data is present but not displayed?
-
Re: EasyPopulate 4.0 Support Thread
I think you're right.
I just used EP4 to upload, split, then import meta info again. This time I included all meta variable columns, set as I desired (0 for status I didn't want, 1 for status I wished to use).
Went smooth, no issues to report.
Thank you so much for all your help!
-
Re: EasyPopulate 4.0 Support Thread
There are so many places to download, which is the place to download the most current version? Is it the one listed on the first post of this thread, that is dated April 2006 or is that just a beta?
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
cindygordon
There are so many places to download, which is the place to download the most current version? Is it the one listed on the first post of this thread, that is dated April 2006 or is that just a beta?
The location shown in the first post of this thread has generally been kept up with the official current release. However, that said, there is the version that was released to/through ZC available for download here. Updates, new features, etc. Are worked on/distributed through github here. The thing about that version is that the software version tends not to be updated until near submission to ZC so database changes made in it may not appear to need installing until later.
Further, that said, some new features and modifications are being incorporated as they are identified as successful for operation. There are a few branches each with some different features to be verified and incorporated. Perhaps the most innovative is the identification of the csv delimiter and the potential use of the discovery. It is still limited to a base set of delimiters, but at least easier to work with other than the base CSV (Comma Separated Values).
Anyways, hope that helps.
-
Re: EasyPopulate 4.0 Support Thread
The verion I like best is EasyPopulate 4.0
Google "EasyPopulate 4.0" and go to the "EasyPopulate V4 - Zen CartŪ Plugins and Addons" link.
Or search "ep4" on the plugins page.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
linuxguy2
The verion I like best is EasyPopulate 4.0
Google "EasyPopulate 4.0" and go to the "EasyPopulate V4 - Zen CartŪ Plugins and Addons" link.
Or search "ep4" on the plugins page.
Glad you like it and yes the search will reveal the links provided as well as some other related software. The links (or reference to the first post) are all related to the same software.
After my last posting, I confirmed that the location identified in the first post is the same version as distributed by ZC download.
Because of the observed popularity of the plugin and the reference provided in the first post, I had spoken with chadder about how to proceed with revisions. We decided to leave the known location identified as it was, to keep it up-to-date and to independently generate modifications to not disrupt either of those two.
-
Re: EasyPopulate 4.0 Support Thread
Hey MC!
Way back on post #2800, you mentioned adding the ability to export category paths for informational purposes. Then, in the very next post, I was able to find some code on github to get that working.
It was extremely useful to me and, now that I'm building a new site, I'd really like to add that ability in to my EP4 install. Sadly, I cannot seem to find that modification on github anymore.
:(
Any chance you could remind where to find that?
Btw, I have a ZC154e with Easy Populate 4.0.36.ZC - 07-05-2016 installed.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
Feznizzle
Hey MC!
Way back on
post #2800, you mentioned adding the ability to export category paths for informational purposes. Then, in the very next post, I was able to find some code on
github to get that working.
It was extremely useful to me and, now that I'm building a new site, I'd really like to add that ability in to my EP4 install. Sadly, I cannot seem to find that modification on github anymore.
:(
Any chance you could remind where to find that?
Btw, I have a ZC154e with Easy Populate 4.0.36.ZC - 07-05-2016 installed.
Well, I was doing some github "cleanup". In my opinion, there were too many branches and too many side things that either were or should have been in the master thread or should have been consolidated to apply to a single change instead of a spelling change here, a thing there, etc... If you need the specific change that was incorporated into the master thread: https://github.com/mc12345678/EasyPo...9cd7cb277f28d0
Otherwise, there are some other feature modifications and changes being applied (take a look at the Insights->Network to see sequencing and plan for incorporating) but only into the master thread once confirmed functional/non-disfunctional. Working towards issuing a new version based on some of the things pointed out here and some always wished were present features.
-
Re: EasyPopulate 4.0 Support Thread
First, HUGE THANKS! Awesome as always, thanks MC.
Second, I tried to check out Insights->Network but found nothing there. Thought maybe it was because I was looking at your fork, so I backed up and checked the other fork, still no dice.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
Feznizzle
First, HUGE THANKS! Awesome as always, thanks MC.
Second, I tried to check out
Insights->Network but found nothing there. Thought maybe it was because I was looking at your fork, so I backed up and
checked the other fork, still no dice.
Trying not to read anything into the "second". Ie. Did the direct link help get the functionality back that was desired? Perhaps - also under-expressed use of the insight->network portion. May I recommend taking your mouse cursor over areas such as the black dots on any line. Perhaps clicking on one to see what happens. Explore a little more. :) I know, have a job to finish. Be sure to stop and smell the roses once in a while. :)
-
2 Attachment(s)
Re: EasyPopulate 4.0 Support Thread
Yes, your direct link to the code was enough to get the desired functionality working. I was able to export category paths, no problem. Again, thanks.
I guess I'll let the Insights->Network go? I thought you guys were working on "other feature modifications and changes being applied" and you were inviting me to take a look at the plan. To see it, I was supposed to go to the github page for Easypop, click on Insights, then click on Network.
I did that, but found nothing and/or did not understand what I was looking at.
Here are two screenshots to show you what I could see:
Attachment 17465
.
.
.
.
.
.
.
Attachment 17466
-
Re: EasyPopulate 4.0 Support Thread
Unfortunately the "map" of the network didn't come through on those screen shots, but the previous links took me to where I expected you to be and I would guess the lack of the map image is something related to github and screen capture. Regardless, yes the thought was to offer a sort of way to see the upcoming direction(s) of the plugin. Each dot on the line represents a saved change. There is a description that displays when hovering over the dot. Clicking on the dot opens a new window and takes you to the specific commit (change) that was made where you can see both the description, any comments, and the specific code changes to support that change.
Previously I believe you had been able to find that specific change because I had created a separate branch the name of which clearly described the intended change. That branch had multiple commits in it (more than one file was modified and modifications were done online instead of from a computer where more control can be had on how the changes get saved). All of those changes were summarized into the one commit to which I directed you. It can be found in the "dots" before the end of master.
Another reason to send to the network is because there are multiple little branches that I ended up stacking into a single chain. I expect that I will be able to confirm each chain off of the master one by one and then merge that change directly into the master branch. Thus, if you were to go to the last branch, you would see how the software is expected to be configured to reflect as if all changes were incorporated. I have thought of a few changes made that I want to let up on to support how others have likely built off of EP4 and not require them to make changes in support of some upcoming export features. Plus I haven't completed the matching import changes to some of that, so they may get bumped a little. Doesn't do a lot of good if can't import what has been exported. :)
So ignore or not, can do either. I know there was a date related issue that you had identified and I at least attempted to correct, though I'm still testing import aspects (having to be sure I have a backup/restore path for the database before doing that).
Sorry for removing that branch, but like I said was getting too "busy" for my tastes and management of ensuring nothing was left off/out.
-
Re: EasyPopulate 4.0 Support Thread
MC, I'm always supper grateful for the work you do on this mod. So no worries about killing that branch!
I now have a copy of it on my computer. If the category-path export doesn't make it into a future update, I should be able to just slip into my own install using what I now have.
Btw, I opened github in a dif browser and the info you where alluding to popped right up. Sorry about that, sometimes I forget that my dev browser is stripped down!
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
mc12345678
The location shown in the first post of this thread has generally been kept up with the official current release. However, that said, there is the version that was released to/through ZC available for download
here. Updates, new features, etc. Are worked on/distributed through github
here. The thing about that version is that the software version tends not to be updated until near submission to ZC so database changes made in it may not appear to need installing until later.
Further, that said, some new features and modifications are being incorporated as they are identified as successful for operation. There are a few branches each with some different features to be verified and incorporated. Perhaps the most innovative is the identification of the csv delimiter and the potential use of the discovery. It is still limited to a base set of delimiters, but at least easier to work with other than the base CSV (Comma Separated Values).
Anyways, hope that helps.
Thanks for that info!
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
mc12345678
Glad you like it and yes the search will reveal the links provided as well as some other related software. The links (or reference to the first post) are all related to the same software.
After my last posting, I confirmed that the location identified in the first post is the same version as distributed by
ZC download.
Because of the observed popularity of the plugin and the reference provided in the first post, I had spoken with chadder about how to proceed with revisions. We decided to leave the known location identified as it was, to keep it up-to-date and to independently generate modifications to not disrupt either of those two.
Thank you both. I guess I'm not entirely sure which link to use. I will go with ep4 and look for that link in google. I just need to be able to export products from one cart and import them into another. Thanks again!
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
cindygordon
Thank you both. I guess I'm not entirely sure which link to use. I will go with ep4 and look for that link in google. I just need to be able to export products from one cart and import them into another. Thanks again!
It says "beta" but I'll give it a go!
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
cindygordon
Thank you both. I guess I'm not entirely sure which link to use. I will go with ep4 and look for that link in google. I just need to be able to export products from one cart and import them into another. Thanks again!
Couple things about this. Currently language specifiers are by an internal language_id instead or something "more useful" like a language code. So if the source database has previously had a language installed and then removed but the destination has only had the one language then they may have different field identifiers. I'm working on modifying that capability to import using either method with preference of one of them.
The other thing of "concern" is what makes the product unique between the two stores and what issues might pop up by merging the two databases instead of uniquely populating the "new" database.
-
Re: EasyPopulate 4.0 Support Thread
Thanks for a great plugin, I've been using it for years. Recently, I've started merging my shops together and have downloaded a complete csv from "Shop S" to upload to the new "Shop B". I was getting the model number error, which I resolved by simply putting in numbers (I didn't use model numbers in Shop S but DO in the new Shop B). However, now when I import the csv file it imports nothing and there are no errors. I've been searching for an answer but have not found one.
I am using ZC 1.5.5e for Shop B (clean install of both) and 1.5.5a for Shop S (EP update from 4.0.35).
Both shops use Easy Populate 4.0.36.ZC - 07-05-2016 and run PHP Version 5.6.31.
What other information can I provide that would help you to help me? Thanks so much.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
townsend2009
Thanks for a great plugin, I've been using it for years. Recently, I've started merging my shops together and have downloaded a complete csv from "Shop S" to upload to the new "Shop B". I was getting the model number error, which I resolved by simply putting in numbers (I didn't use model numbers in Shop S but DO in the new Shop B). However, now when I import the csv file it imports nothing and there are no errors. I've been searching for an answer but have not found one.
I am using ZC 1.5.5e for Shop B (clean install of both) and 1.5.5a for Shop S (EP update from 4.0.35).
Both shops use Easy Populate 4.0.36.ZC - 07-05-2016 and run PHP Version 5.6.31.
What other information can I provide that would help you to help me? Thanks so much.
If you export a product/category (of products) from Shop B, how do the headings differ from Shop S? Ie. Wondering if the language identifier _X is a factor.
Based on the description of the issue it sounds as if the primary key remains the model # (would otherwise use blank_new to create new product in the new database).
Are you also sure that the chosen model number doesn't already exist and instead of adding product that product is being updated? After import, there should be some level of information provided at the bottom of the screen or else the debug.txt file should contain something.
-
Re: EasyPopulate 4.0 Support Thread
Hey All!
Just a few quick question:
1. With the .htaccess file to edit for "(csv|CSV|txt|TXT)". Admin or elsewhere?
2. I have the admin .htaccess ready to edit, but unsure which portion of that file contents to add my my existing .htacess file.
3. With Custom Product Fields; the MSRP is in green text - how would I obtain any others if needed?
EG: 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: TRUE
Manufacturer's Advertised Price: FALSE
Group Pricing Per Item: FALSE
Exclusive Products Mod: FALSE
Stock By Attributes Mod: FALSE
CEON URI Rewriter Mod: FALSE
Dual Pricing Mod: FALSE
Any assistance would be greatly appreciated.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
AnthonyEnnis
Hey All!
Just a few quick question:
1. With the .htaccess file to edit for "(csv|CSV|txt|TXT)". Admin or elsewhere?
2. I have the admin .htaccess ready to edit, but unsure which portion of that file contents to add my my existing .htacess file.
3. With Custom Product Fields; the MSRP is in green text - how would I obtain any others if needed?
EG: 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: TRUE
Manufacturer's Advertised Price: FALSE
Group Pricing Per Item: FALSE
Exclusive Products Mod: FALSE
Stock By Attributes Mod: FALSE
CEON URI Rewriter Mod: FALSE
Dual Pricing Mod: FALSE
Any assistance would be greatly appreciated.
1. File for csv/txt as provided in the download is only needed to "override" an htaccess file in a folder above that does not already allow csv/txt file downloads. Basically, if you are going to store your import/export files in a sub-directory of the admin, then the file needs to be in that sub-directory.
2.unless you are putting your files directly in the admin directory (instead of as suggested above to put them in a sub-directory), there is no reason to alter the admin/.htaccess file. In fact if the files are stored on the catalog side in a sub-directory, there wouldn't be a need for an htaccess there either for a vanilla install, although would still suggest having one for security purposes. Basically, the point is, there is no reason to open all sub-directories of the admin folder to support csv/txt files when they are only to be in a specific location.
3. The fields in green have specifically been included by previous knowledge/experience. They turn green when the expected "rule" is found. To add additional products table fields, go to the configuration window for EP4 and edit the custom field data entry section. As described in the instructions provide the database field name(s) separated by a comma.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
mc12345678
1. File for csv/txt as provided in the download is only needed to "override" an htaccess file in a folder above that does not already allow csv/txt file downloads. Basically, if you are going to store your import/export files in a sub-directory of the admin, then the file needs to be in that sub-directory.
2.unless you are putting your files directly in the admin directory (instead of as suggested above to put them in a sub-directory), there is no reason to alter the admin/.htaccess file. In fact if the files are stored on the catalog side in a sub-directory, there wouldn't be a need for an htaccess there either for a vanilla install, although would still suggest having one for security purposes. Basically, the point is, there is no reason to open all sub-directories of the admin folder to support csv/txt files when they are only to be in a specific location.
3. The fields in green have specifically been included by previous knowledge/experience. They turn green when the expected "rule" is found. To add additional products table fields, go to the configuration window for EP4 and edit the custom field data entry section. As described in the instructions provide the database field name(s) separated by a comma.
Sorry, I don't follow #1 & 2.
I believe the files are in the catalog, I have replaced the htaccess file in the catalog and replaced it with the one from the installation file. This caused my admin issues.
I'm also not sure what you mean by 'above folder'.
Thanks for replying, I truly appreciate it.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
AnthonyEnnis
Sorry, I don't follow #1 & 2.
I believe the files are in the catalog, I have replaced the htaccess file in the catalog and replaced it with the one from the installation file. This caused my admin issues.
I'm also not sure what you mean by 'above folder'.
Thanks for replying, I truly appreciate it.
Ok. So let's back up and start over.
EP4 has been installed.
Where is the directory to which uploaded files and exported data is stored? Is it in the admin or off of the catalog? (there is setting in the configuration that identifies using the admin side or not. Then a separate field to be populated with the path to the storage location.)
The htaccess file that was provided in the download was for the sub-directory to be used that is/was in the admin directory.
If this path is to the import/export storage location: /my/srvr/public_html/my_folder
Then the folder above would be:
/my/srvr/public_html
ZC does not provide an htaccess file for the catalog side specifically. (sub-folders such as images, extras, etc... yes but not the catalog folder). So are you saying that all of the csv files are being exported/improted from the root of your store and not in a separate potentially protected sub-folder?
-
Re: EasyPopulate 4.0 Support Thread
I do have a question, I see a column says "Delete" if I click delete will that remove the everything from the Database or just remove that file from the list? Need to clean out the list.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
wmorris
I do have a question, I see a column says "Delete" if I click delete will that remove the everything from the Database or just remove that file from the list? Need to clean out the list.
When looking at the tools->Easy Populate V4 admin screen, in the "lower" area showing a list of files, the delete button there relates to just the file itself and nothing about the contents. Be advised that at this time, there is no "are you sure" question when selecting that button. The file is simply deleted.
Also, because the list is generated from what is present, if you have some reason to keep the files, then taking them out of the EP4 directory will shorten the list, but will still require storage and some future review for removal. :)
-
Re: EasyPopulate 4.0 Support Thread
I am on zencart 155e and use Easy Populate 4.0.36.ZC - 07-05-2016.
My default language english has language_id 4 (and I have dutch language_id 2 and german with language_id 5.
When I import something like this, everytime a new option name is created and it is NOT assigned to the product:
v_products_model,v_products_options_type,v_products_options_name_2,v_products_op tions_name_4,v_products_options_name_5,v_products_options_values_name_2,v_produc ts_options_values_name_4,v_products_options_values_name_5
"WOOall83130x18002","5","Kleur","Color","Farbe","Groen","Green","Grün"
help would be appreciated.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
bramf
I am on zencart 155e and use Easy Populate 4.0.36.ZC - 07-05-2016.
My default language english has language_id 4 (and I have dutch language_id 2 and german with language_id 5.
When I import something like this, everytime a new option name is created and it is NOT assigned to the product:
v_products_model,v_products_options_type,v_products_options_name_2,v_products_op tions_name_4,v_products_options_name_5,v_products_options_values_name_2,v_produc ts_options_values_name_4,v_products_options_values_name_5
"WOOall83130x18002","5","Kleur","Color","Farbe","Groen","Green","Grün"
help would be appreciated.
I was recently reworking the import of attributes and noticed that something like this was possible to occur. Original design appeared to consider that all installs would have at least a language_id of 1. Where 1 was the default language. The file admin/easypopulate_4_attrib.php is the one that has the "issue". Now that the problem has been clearly identified as likely to occur, I have the following suggestion, though in the upcoming release it will likely be different because there is
some code consolidation being done to reduce duplication and give the code a little more logical structure.
In admin/easypopulate_4_attrib.php make the following modifications (to suit your store) which are captured in the github commit: https://github.com/mc12345678/EasyPo...d73083136f623a or by replacing the file with the one provided at: https://github.com/mc12345678/EasyPo...e_4_attrib.php
In line 11:
From:
Code:
$language_id = 1; // default 1=english
To:
Code:
$language_id = $epdlanguage_id; // default 1=english or the language_id for your default language
Line 69:
From:
Code:
$l_id = 1; // temporary check - should this be the default language id?
To:
Code:
$l_id = $language_id; // temporary check - should this be the default language id?
Line 107:
From:
Code:
$number_of_elements = count($values_names_array[1]); // all elements count must be the same
To:
Code:
$number_of_elements = count($values_names_array[$language_id]); // all elements count must be the same
Line 141:
From:
Code:
$l_id = 1; // first defined language is main key - mandatory
To:
Code:
$l_id = $language_id; // first defined language is main key - mandatory
Line 208:
From:
Code:
$l_id = 1; // default first language is main key
To:
Code:
$l_id = $language_id; // default first language is main key
Line 241:
From:
Code:
$l_id = 1; // default first language is main key
To:
Code:
$l_id = $language_id; // default first language is main key
Line 316:
From:
Code:
$v_products_model, $v_products_options_name[1], implode(",", $values_names_array[1]));
To:
Code:
$v_products_model, $v_products_options_name[$language_id], implode(",", $values_names_array[$language_id]));
And Line 321:
From:
Code:
$v_products_model, $v_products_options_name[1], implode(",", $values_names_array[1]));
To:
Code:
$v_products_model, $v_products_options_name[$language_id], implode(",", $values_names_array[$language_id]));
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
mc12345678
I was recently reworking the import of attributes and noticed that something like this was possible to occur. Original design appeared to consider that all installs would have at least a language_id of 1. Where 1 was the default language. The file admin/easypopulate_4_attrib.php is the one that has the "issue". Now that the problem has been clearly identified as likely to occur, I have the following suggestion, though in the upcoming release it will likely be different because there is
some code consolidation being done to reduce duplication and give the code a little more logical structure.
In admin/easypopulate_4_attrib.php make the following modifications (to suit your store) which are captured in the github commit:
https://github.com/mc12345678/EasyPo...d73083136f623a or by replacing the file with the one provided at:
https://github.com/mc12345678/EasyPo...e_4_attrib.php
In line 11:
From:
Code:
$language_id = 1; // default 1=english
To:
Code:
$language_id = $epdlanguage_id; // default 1=english or the language_id for your default language
Line 69:
From:
Code:
$l_id = 1; // temporary check - should this be the default language id?
To:
Code:
$l_id = $language_id; // temporary check - should this be the default language id?
Line 107:
From:
Code:
$number_of_elements = count($values_names_array[1]); // all elements count must be the same
To:
Code:
$number_of_elements = count($values_names_array[$language_id]); // all elements count must be the same
Line 141:
From:
Code:
$l_id = 1; // first defined language is main key - mandatory
To:
Code:
$l_id = $language_id; // first defined language is main key - mandatory
Line 208:
From:
Code:
$l_id = 1; // default first language is main key
To:
Code:
$l_id = $language_id; // default first language is main key
Line 241:
From:
Code:
$l_id = 1; // default first language is main key
To:
Code:
$l_id = $language_id; // default first language is main key
Line 316:
From:
Code:
$v_products_model, $v_products_options_name[1], implode(",", $values_names_array[1]));
To:
Code:
$v_products_model, $v_products_options_name[$language_id], implode(",", $values_names_array[$language_id]));
And Line 321:
From:
Code:
$v_products_model, $v_products_options_name[1], implode(",", $values_names_array[1]));
To:
Code:
$v_products_model, $v_products_options_name[$language_id], implode(",", $values_names_array[$language_id]));
As reported in issue #34 of the main repo for this plugin, the above fixes the identified issue. The concept from the above will be incorporated into the main thread for the next release.
-
Re: EasyPopulate 4.0 Support Thread
I've got a question about attribute pricing. A client has this and Dual Pricing installed. The product wholesale pricing works great as that field is in the products table. For the attribute pricing, the field (options_values_price_w) is in the products_attributes table.
I thought I'd try adding it to the configuration anyway. No good:
User Defined Products Fields:
products_price_w: TRUE
options_values_price_w: FALSE
Is there a way to export and then import attribute pricing? Or would that functionality need to be added first?
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
jeking
I've got a question about attribute pricing. A client has this and Dual Pricing installed. The product wholesale pricing works great as that field is in the products table. For the attribute pricing, the field (options_values_price_w) is in the products_attributes table.
I thought I'd try adding it to the configuration anyway. No good:
User Defined Products Fields:
products_price_w: TRUE
options_values_price_w: FALSE
Is there a way to export and then import attribute pricing? Or would that functionality need to be added first?
Good news/bad news...
Good news is that if you have created a detailed attribute file that has the v_options_values_price_w field and the field is present in the database then it will be updated with whatever data has been provided. Also, export of a detailed attribute file should include the field. Bad news is that at the moment, without one additional tweak to the code, if the field is present in the database and is not in the file, then the field will be cleared out...
So, to fix this aspect:
In admin/includes/modules/
Change line 27 from:
Code:
if ($ep_supported_mods['dual']) {
To
Code:
if ($ep_supported_mods['dual'] && isset($filelayout['v_options_values_price_w'])) {
Support of the field can be identified by looking in the "upper" right hand corner should be an indicator about dual pricing and it being shown as true.
-
Re: EasyPopulate 4.0 Support Thread
Oops. Filename is: admin/includes/modules/easypopulate_4_attrib_detailed_ep.php
-
Re: EasyPopulate 4.0 Support Thread
I edited the file as you indicated, added the field in the configuration but not sure this is the result we need.
User Defined Products Fields:
products_price_w: TRUE
options_values_price_w: FALSE
I did an export and the options_values_price_w column is not in the Detailed Products Attributes file.
Did I misunderstand something you said?
-
Re: EasyPopulate 4.0 Support Thread
Too late to edit.....hold on, editing error on my part. Update to come....
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
jeking
I edited the file as you indicated, added the field in the configuration but not sure this is the result we need.
Quote:
Originally Posted by
jeking
User Defined Products Fields:
products_price_w: TRUE
options_values_price_w: FALSE
I did an export and the options_values_price_w column is not in the Detailed Products Attributes file.
Did I misunderstand something you said?
Quote:
Originally Posted by
jeking
Too late to edit.....hold on, editing error on my part. Update to come....
Understand that more is likely to come, but would like to go ahead and cover what has been already "discussed".
So I didn't correct the attempt to use the User Defined Products Fields for an attribute field, which would be why the above "FALSE" occurred, because that field (options_values_price_w) does not exist in the products table. (Sure someone could add it, but it is not the field in question.)
So then the desire is to work with that field which has been identified as working with the module titled "Dual Pricing". As such, in the list of Custom Products Fields, if the options_values_price_w field is identified in the products_attributes table, then a TRUE will be shown. Ie.:Product Short Descriptions: FALSE
Product Unit of Measure: FALSE
Product UPC Code: FALSE
Google Product Category: FALSE
Manufacturer's Suggested Retail Price: FALSE
Manufacturer's Advertised Price: FALSE
Group Pricing Per Item: FALSE
Exclusive Products Mod: FALSE
Stock By Attributes Mod: FALSE
CEON URI Rewriter Mod: FALSE
Dual Pricing Mod:TRUE
With that shown as TRUE, the field is expected to be included in the exported attribute_detailed file and with the correction applied above that same system could process a detailed attribute file that does not have the field and the field would remain unchanged. If the change is not applied, then the field would need to remain present when importing or else the field would become blank for each successfully processed row.
-
Re: EasyPopulate 4.0 Support Thread
Ok, the problem was I didn't notice the installed version was 4.0.28.
I upgraded and now the v_options_values_price_w column is in the file, as expected. I've applied the edit to easypopulate_4_attrib_detailed_ep.php as well.
I'll do a small test before importing to be sure that works as planned and report back if we run into issues.
I love when things work the way they are supposed to!!
-
Re: EasyPopulate 4.0 Support Thread
trying to get EP newest version to work on our site. We originally were able to use it without issue, install went fine etc. I was able to use it to manually move 7k products from our previous site (based on magento) into our new ZC site. Upload seemed to work fine, but after a certain (unknown) point export ceased working. I am guessing this is due to the quantity of products we are working with. However, after we got everything moved up we had a firm install and configure a custom template for us...template is based on simple mods of the base template, nothing terribly fancy or crazy and no core file mods. However, after that they ended up pulling out EP and told us it no longer worked with the current version of ZC. As a test, I took the final site and copied it to a staging domain and tried to install...install seemed to sort of work but it completely broke the CSS for the admin area and didn't seem to work for either upload or download.
I am really wanting to be able to use EP because it's a very handy module to have. Our current site is running on 1.5.5e (haven't updated to f yet). So, after searching this thread and the forum at large and not really finding solid answers I want to know:
1. can we install and get EP working with our site, given the amount of products and template changes? If it helps, feel free to take a look at the current site at https://clearwaterhydraulics.com
2. If we can get this installed and working, is there a way to keep it from breaking the CSS on the admin panel?
3. anything else I should know, that perhaps I am missing here, that needs to happen to get this to install and work correctly?
Any help would be most appreciated!
-
Re: EasyPopulate 4.0 Support Thread
Ok, so, going to say wow... for starters.
Let's try to address each issue separately then get to where you are wanting to get.
First of all, EP4 doesn't care about the store side template. So, the only benefit/issue is how has the database been changed to support the template in regards to product specific data and the tables that might relate (ie. Categories, manufacturers, attributes, etc...)
With regards to how the admin screen of EP4 looks, well, there are some tables that are used and default ZC "references" to things like the admin menu. There is nothing about the EP4 admin display that would affect admin operation/display other than when looking at the EP4 "window". If that has been significantly revised, then there is something that has otherwise been modified that possibly needs to be brought into your install of EP4.
As to product import/export. The amount of data associated with that process is why there are some additional options for both operations. For export there is a series of dropdowns that allow export of smaller groups of data. For import there is a split "utility" intended to take a large file for import and create data chunks that each are manageable. There are some changes that have been made on github which may allow larger import/export files, but this is also dependent on server configuration. It does not address anything else of what has been described above.
To be honest, I'd probably have to have access to the admin area to identify the "css" related issues described as an image of that screen compared to another admin menu would not likely be sufficient to address that aspect.
The instructions do at least lightly describe settings that can be modified to support longer time durations for import/export.
But, the statement that the plugin is not functional for ZC 1.5.5x is untrue. Not compatible with whatever admin templating was done, sure could be that way, but not unmanageable.
-
Re: EasyPopulate 4.0 Support Thread
Hi
Exporting prices, for some reason I can't format either in libre calc or Excel decimal values like this: 11.99, 5.5, etc...
While integers it formats: 17 to 17,00 EUR , etc...
What can I do to go around this ?
I actually never need it, always use the cvs format, to update, but now I do nedd to convert this values to use somewhere else.
Thanks
-
Re: EasyPopulate 4.0 Support Thread
Could you connect the dots a little more?
Export of the file creates a csv file with numbers in it. When using a plain text editor, what do these numbers look like?
Then opening in open office or Libre, how does this display change?
When saving/save as the file (using a slightly modified filename to support comparing) how do the numbers now appear?
Then upload and import of that row, what happens?
In a way it sounds as if the application of use is possibly converting the currency symbols to support the locale, but possibly the import file needs to have a different series of currency symbols. If this is the case, then typically such settings are specific to the cell(s) of the spreadsheet and at least for import to the store, the file should be formatted to the same as the store exports.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
mc12345678
Could you connect the dots a little more?
Export of the file creates a csv file with numbers in it. When using a plain text editor, what do these numbers look like?
In a way it sounds as if the application of use is possibly converting the currency symbols to support the locale, but possibly the import file needs to have a different series of currency symbols. If this is the case, then typically such settings are specific to the cell(s) of the spreadsheet and at least for import to the store, the file should be formatted to the same as the store exports.
They look like ... numbers :)
What I find odd, is that I can't format the decimal numbers either in excel or libre calc
The example bellow shows what happens.
With specials prices, the same thing.
It's a bit odd, isn't ? Can you convert some price like 11.99 to 11.99 EUR in excel / libre calc ?
Code:
4,00 EUR
4,00 EUR
4,00 EUR
4,00 EUR
5.5
5.5
5.5
5.5
Thanks
-
Re: EasyPopulate 4.0 Support Thread
Just to be clear.
The export / import works as desire.
I just want to format in libre cal .
-
Re: EasyPopulate 4.0 Support Thread
I would add another column with a header that doesn't conflict with ZC (best for it not to start with v_) after the price and include the currency there. This way the data doesn't get affected by the added user information, but it still adds value to reviewing the file. The extra field will be ignored on import so won't have an effect on the store.
Hopefully have understood the intent.
If you do want to concatenate two fields (join them) at that point, then there is a function aptly named concatenate to do just that. A yet other column could be created to have that information and would be something like (see help file for associated program): =CONCATENATE('A2',' ','B2') which would take the content of cell A2, put a space after it, then to that add on the contents of B2. If the function is in cell C2, then it could be copied down for the rest of the column and the contents of the cell would become the combination of the two.
After that, I suggest searching the Internet for other useful ways to work with spreadsheets and workbooks to accomplish your desired operation.
Otherwise perhaps I still haven't understood the question. But past experience has been that the file needs to be opened not as read only in order to manipulate cell styles etc...
-
Re: EasyPopulate 4.0 Support Thread
Thanks.
I could do that, but there's a catch: I also need to change the dot to a comma ( for whatever reason we use that currency format).
And even that I can't do.
Haven't tried to use the "find and replace", but that a lot of extra steps , that opens doors to mistakes.
I'm trying to export to a Facebook catalog, and they require that format: 10,50 EUR.
Now, in Zen cart the prices are displayed correctly for my country, with a comma.
Maybe I could change the $row "prices" at export ( using the ep4bookx), to use the country currencies format, but I think that's a class "currencies".
Either way, it puzzles me why I can't format the numbers.
Thanks
-
Re: EasyPopulate 4.0 Support Thread
So there are a couple of options...
Export could be by use of ZC currency style "conversion" as one.
Another is through instruction related to this libreoffice help article: https://help.libreoffice.org/Calc/Ce...urrency_Format
Though the cells may initially be in text or general format and need to be changed to a currency format.
Or by way of "equation" to build/rebuild the values through some sort of operation(s) like find and replace on the column.
Presumably though this is something you'd like to automate rather than have to manipulate on each such transfer. To accomplish that and not to disrupt the normal export process, a new field would be needed in the export file. That is accomplished by "adding" a field to the filelayout for the export type that is to have that field.
Then at some point after the price has been collected from the database, the field for the associated record would need to be "built" to contain your desired text. I don't know if you would be trying to export in every currency supported by the store or just the default currency, but for each such field, would need a filelayout field.
The currency could/would be exported using the $currencies variable/class which is declared in the easypopulate_4.php file. The currency class offers output "modules" to support providing the string version of the currency. Some manipulation may be necessary to append the three letter representation of the currency, but it is all something doable for any of the exports that offer the price of the product.
-
Re: EasyPopulate 4.0 Support Thread
Thanks
After all with a "search and replace" dot by comma does the trick, and then I can format the numbers.
Another question, I now realize that if a products is "linked" ( two categories) , it exports in two different lines. Is there a "simple" way not to do it?
Thanks
-
Re: EasyPopulate 4.0 Support Thread
After flawlessly using EasyPopulate 4 for almost a year, today there suddenly is an error, despite no (obvious) changes having been made to the import file. I am not a coder, and I am not familiar with what this means. This below error suddenly impacts all non-taxable items in my import file. Could anyone offer help how I can fix this? Thank you.
File Import Completed with issues.
An SQL error has occured. Please check your input data for tabs within fields and delete these. If this error continues, please forward your error log to the Easy Populate maintainer
MySQLi error 1366: Incorrect integer value: '' for column 'products_tax_class_id' at row 1
When executing:
UPDATE zenvv_products SET
products_price = '6.65',alt_number = '',product_group = 'ACE Bake Your Own 210-460 g',brand = 'Ace',shop_easy = '',shop_easy_special = '',no_frills = 'N/A',no_frills_special = '',superstore = '5.29',superstore_special = '',wholesale_club = 'N/A',wholesale_club_special = '',walmart = 'N/A',walmart_special = '',loblaws = '4.99',loblaws_special = '',sobeys = 'N/A',sobeys_special = '',save_on_foods = 'N/A',save_on_foods_special = '',base = '5.29',products_base_cost = '4.99',vendor = '',products_image = '20660168.jpg',
products_weight = '0',
products_discount_type = '0',
products_discount_type_from = '0',
product_is_call = '0',
products_sort_order = '-1',
products_quantity_order_min = '1',
products_quantity_order_units = '1',
products_priced_by_attribute = '0',
product_is_always_free_shipping = '0',
products_tax_class_id = '',
products_date_available = NULL,
products_date_added = '2016-01-27 06:44:39',
products_last_modified = CURRENT_TIMESTAMP,
products_quantity = '-1',
manufacturers_id = '3963',
products_status = '1',
metatags_title_status = '0',
metatags_products_name_status = '0',
metatags_model_status = '0',
metatags_price_status = '0',
metatags_title_tagline_status = '0' WHERE (products_id = '31429')
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
mesnitu
Thanks
After all with a "search and replace" dot by comma does the trick, and then I can format the numbers.
Another question, I now realize that if a products is "linked" ( two categories) , it exports in two different lines. Is there a "simple" way not to do it?
Thanks
The modification is simple, unfortunately it was buried in a commit with several other changes, this is something to be implemented in the next version (still doing some testing and want to be sure addressed the same concept(s) in all places not just here or there.
https://github.com/mc12345678/EasyPo...6862661d58438b
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
jkenwell
After flawlessly using EasyPopulate 4 for almost a year, today there suddenly is an error, despite no (obvious) changes having been made to the import file. I am not a coder, and I am not familiar with what this means. This below error suddenly impacts all non-taxable items in my import file. Could anyone offer help how I can fix this? Thank you.
File Import Completed with issues.
An SQL error has occured. Please check your input data for tabs within fields and delete these. If this error continues, please forward your error log to the Easy Populate maintainer
MySQLi error 1366: Incorrect integer value: '' for column 'products_tax_class_id' at row 1
When executing:
UPDATE zenvv_products SET
products_price = '6.65',alt_number = '',product_group = 'ACE Bake Your Own 210-460 g',brand = 'Ace',shop_easy = '',shop_easy_special = '',no_frills = 'N/A',no_frills_special = '',superstore = '5.29',superstore_special = '',wholesale_club = 'N/A',wholesale_club_special = '',walmart = 'N/A',walmart_special = '',loblaws = '4.99',loblaws_special = '',sobeys = 'N/A',sobeys_special = '',save_on_foods = 'N/A',save_on_foods_special = '',base = '5.29',products_base_cost = '4.99',vendor = '',products_image = '20660168.jpg',
products_weight = '0',
products_discount_type = '0',
products_discount_type_from = '0',
product_is_call = '0',
products_sort_order = '-1',
products_quantity_order_min = '1',
products_quantity_order_units = '1',
products_priced_by_attribute = '0',
product_is_always_free_shipping = '0',
products_tax_class_id = '',
products_date_available = NULL,
products_date_added = '2016-01-27 06:44:39',
products_last_modified = CURRENT_TIMESTAMP,
products_quantity = '-1',
manufacturers_id = '3963',
products_status = '1',
metatags_title_status = '0',
metatags_products_name_status = '0',
metatags_model_status = '0',
metatags_price_status = '0',
metatags_title_tagline_status = '0' WHERE (products_id = '31429')
What is the version number/date of the download and/or source of the install? Basically there is expected to be a "converter" that would ensure that the value to be entered is an integer as a '0' and not as a string where false or null become a blank space. This occurs in the latest version for download from the ZC website.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
jkenwell
After flawlessly using EasyPopulate 4 for almost a year, today there suddenly is an error, despite no (obvious) changes having been made to the import file. I am not a coder, and I am not familiar with what this means. This below error suddenly impacts all non-taxable items in my import file. Could anyone offer help how I can fix this? Thank you.
File Import Completed with issues.
An SQL error has occured. Please check your input data for tabs within fields and delete these. If this error continues, please forward your error log to the Easy Populate maintainer
MySQLi error 1366: Incorrect integer value: '' for column 'products_tax_class_id' at row 1
When executing:
UPDATE zenvv_products SET
products_price = '6.65',alt_number = '',product_group = 'ACE Bake Your Own 210-460 g',brand = 'Ace',shop_easy = '',shop_easy_special = '',no_frills = 'N/A',no_frills_special = '',superstore = '5.29',superstore_special = '',wholesale_club = 'N/A',wholesale_club_special = '',walmart = 'N/A',walmart_special = '',loblaws = '4.99',loblaws_special = '',sobeys = 'N/A',sobeys_special = '',save_on_foods = 'N/A',save_on_foods_special = '',base = '5.29',products_base_cost = '4.99',vendor = '',products_image = '20660168.jpg',
products_weight = '0',
products_discount_type = '0',
products_discount_type_from = '0',
product_is_call = '0',
products_sort_order = '-1',
products_quantity_order_min = '1',
products_quantity_order_units = '1',
products_priced_by_attribute = '0',
product_is_always_free_shipping = '0',
products_tax_class_id = '',
products_date_available = NULL,
products_date_added = '2016-01-27 06:44:39',
products_last_modified = CURRENT_TIMESTAMP,
products_quantity = '-1',
manufacturers_id = '3963',
products_status = '1',
metatags_title_status = '0',
metatags_products_name_status = '0',
metatags_model_status = '0',
metatags_price_status = '0',
metatags_title_tagline_status = '0' WHERE (products_id = '31429')
Ok, in the meantime I have exported a category, which worked fine, and tried to import the same category to see if it would accept the data as exported, and it did not. The same error occurred and I am unable to import non-taxable products. Solutions?
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
mc12345678
What is the version number/date of the download and/or source of the install? Basically there is expected to be a "converter" that would ensure that the value to be entered is an integer as a '0' and not as a string where false or null become a blank space. This occurs in the latest version for download from the ZC website.
I have been using Easy Populate 4.0.30 - Beta 06-27-2015 since about March last year, which I got off this site, and it's been fine until today.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
mc12345678
What is the version number/date of the download and/or source of the install? Basically there is expected to be a "converter" that would ensure that the value to be entered is an integer as a '0' and not as a string where false or null become a blank space. This occurs in the latest version for download from the ZC website.
Am I understanding correctly that 4.0.36.ZC would not fix this? Which version would fix this issue then? (It's just that I am puzzled why this would happen all of a sudden, without any changes to the installed Zen Cart version or Easy Populate. Even yesterday I still imported just fine.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
jkenwell
Am I understanding correctly that 4.0.36.ZC would not fix this? Which version would fix this issue then? (It's just that I am puzzled why this would happen all of a sudden, without any changes to the installed Zen Cart version or Easy Populate. Even yesterday I still imported just fine.
Incorrectly understood. 4.0.36.ZC does not have this issue. I'll have to go look at what 4.0.30 was doing, but changes have been made to ensure that the proper datatype would be applied. Things that may have changed and *possibly* brought this to light in that version would be php version on the site has changed, the mysql database version may have changed, or possibly some configuration on the server. The code though has continued to be updated to prevent such issues and to maintain compatibility with its existing breadth of ZC versions.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
mc12345678
Incorrectly understood. 4.0.36.ZC does not have this issue. I'll have to go look at what 4.0.30 was doing, but changes have been made to ensure that the proper datatype would be applied. Things that may have changed and *possibly* brought this to light in that version would be php version on the site has changed, the mysql database version may have changed, or possibly some configuration on the server. The code though has continued to be updated to prevent such issues and to maintain compatibility with its existing breadth of ZC versions.
Do you recommend I update to 4.0.36.ZC at this point and see if that solves the issue?
-
Re: EasyPopulate 4.0 Support Thread
Yeah, "back then", the code simply assigned a "quoted" version of whatever the result for $v_tax_class_id was. In this case, a value of zero, false, or null would result in a pair of empty single quotes. Also "back then", databases would convert this to either an empty value if the field supported it or as should have been the case to convert it to the number type associated to the field. The products_tax_class_id is an integer, so again "back then" it would change that "empty" to a zero and store the zero. Now though (because of whatever background change that occurred at some point) the system reports an error rather than do the conversion.
So, if were #@!! bent on continuing to use that version, search for:
Code:
products_tax_class_id = '".$v_tax_class_id."',
And replace with:
Code:
products_tax_class_id = '".(int)$v_tax_class_id."',
In two places.
But... there are a lot of other fields that were populated that way and would cause a problem too and need either similar updates or better yet, upgrade of the software which doesn't suffer that issue.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
jkenwell
Do you recommend I update to 4.0.36.ZC at this point and see if that solves the issue?
Yup. I sure do. Use of the most up-to-date software compatible with one's operating system is always advised. (sometimes even changing operating systems to ensure the most up-to-date.)
Should be as simple as uploading the files then clicking the update link in the upper right hand corner of the tools->EasyPopulate v4 screen.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
mc12345678
Incorrectly understood. 4.0.36.ZC does not have this issue. I'll have to go look at what 4.0.30 was doing, but changes have been made to ensure that the proper datatype would be applied. Things that may have changed and *possibly* brought this to light in that version would be php version on the site has changed, the mysql database version may have changed, or possibly some configuration on the server. The code though has continued to be updated to prevent such issues and to maintain compatibility with its existing breadth of ZC versions.
I have installed the latest version and it appears that the error has disappeared. Perhaps a change was made on server side that created the error. Thank you very much for your contributions and your help with this issue.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
jkenwell
I have installed the latest version and it appears that the error has disappeared. Perhaps a change was made on server side that created the error. Thank you very much for your contributions and your help with this issue.
Glad that solved the problem for you.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
mc12345678
Glad that solved the problem for you.
I'm very sorry, now a new problem has arisen that was not a problem before. This is with a custom Numinix field. Can you think of a way to solve this?
MySQLi error 1366: Incorrect string value: '\x96 1.99' for column 'loblaws_special' at row 1
When executing:
UPDATE zenvv_products SET
loblaws_special = '31/01/2018 – 1.99'
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
jkenwell
I'm very sorry, now a new problem has arisen that was not a problem before. This is with a custom Numinix field. Can you think of a way to solve this?
MySQLi error 1366: Incorrect string value: '\x96 1.99' for column 'loblaws_special' at row 1
When executing:
UPDATE zenvv_products SET
loblaws_special = '31/01/2018 – 1.99'
Does this occur on export followed by immediate import of the same file, or only after saving the file from the spreadsheet editor?
The cause of this appears to be that the file was stored using latin1, while your store is using or capable of using utf8.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
mc12345678
Does this occur on export followed by immediate import of the same file, or only after saving the file from the spreadsheet editor?
The cause of this appears to be that the file was stored using latin1, while your store is using or capable of using utf8.
No issue with export/import file. I am trying to find out how I can change the Openoffice csv file to utf8, but so far I don't see anything.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
jkenwell
No issue with export/import file. I am trying to find out how I can change the Openoffice csv file to utf8, but so far I don't see anything.
Save as, check the box at the bottom left to edit filter settings, progress forward and then should be shown the current encoding as well as an option to change how it is to be saved.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
mc12345678
Save as, check the box at the bottom left to edit filter settings, progress forward and then should be shown the current encoding as well as an option to change how it is to be saved.
It appears all issues are now resolved. I wouldn't likely have been able to do it without your guidance. Thank you again. Also, if you are the developer of EasyPopulate 4.0 is there a way to "donate"? These mods certainly save a lot of time.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
jkenwell
It appears all issues are now resolved. I wouldn't likely have been able to do it without your guidance. Thank you again. Also, if you are the developer of EasyPopulate 4.0 is there a way to "donate"? These mods certainly save a lot of time.
I am not the original developer of EasyPopulate 4.0, but picked up the reigns from chadderuski at a time when he was no longer able to support at the level he used to and to incorporate changes that would allow this plugin to continue to function. He developed EP4 based off of older code and concepts where such concepts remain relatively central to any variation. I have made/published my share of mistakes (and continue to occasionally do so) but have been taking the input and requests of users to try to further build out the plugin.
I do not know how many other ways it is used or has been modified, but do know that another user has been able to incorporate functionality to support the bookx product type which comes with its own operational requirements. There are also other variations of this module either with a similar name or some other, but they all tend to have a common goal of updating many records of the database in a single operation.
That said, developers and those offering their support tend to have information either in their signature or profile through which one may find a way to offer back something in return for their work and effort. (ie. To buy a cup of coffee.) As an open source forum and program I would like to think that offering support back to Zen Cart and it's primary developers would be considered acceptable as well. I can not speak for everyone on that. I would think though that showing support in any way would be appreciated, whether it is through finance, assistance, or any other legal action/exchange.
-
Re: EasyPopulate 4.0 Support Thread
Is it possible to recognize bold strings? Without using <b> or <strong> ?
I do remember that many years ago, that I did upload CSV file and it recognize those "tags"... But I don't recall if it was me who put them, or the code accept then.
Thanks
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
mesnitu
Is it possible to recognize bold strings? Without using <b> or <strong> ?
I do remember that many years ago, that I did upload CSV file and it recognize those "tags"... But I don't recall if it was me who put them, or the code accept then.
Thanks
Recognize them in what way? What is to be done if "recognized"? If there is a "character" or character sequence that initiates bolding and one that ends it, there is a sort of conversion function that could substitute the html bold character sequence as applicable. Though most csv generating processes remove character formatting so that it is only text. If though there is a utf8 character code for a bolded character then that would be most likely to what you are/were referring. I could be wrong, though the above question also is a little loosey goosey as well. :)
-
Re: EasyPopulate 4.0 Support Thread
I installed my Zen cart thru webhost applications, webhost : Goddady and I can not find the EZ Populate under Admin, and go to Tools -> EasyPopulate 4? I have the newest version installed.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
mc12345678
Recognize them in what way? What is to be done if "recognized"? If there is a "character" or character sequence that initiates bolding and one that ends it, there is a sort of conversion function that could substitute the html bold character sequence as applicable. Though most csv generating processes remove character formatting so that it is only text. If though there is a utf8 character code for a bolded character then that would be most likely to what you are/were referring. I could be wrong, though the above question also is a little loosey goosey as well. :)
I see now that using <strong> ,etc, I get what I want.
Thanks
-
Re: EasyPopulate 4.0 Support Thread
It looks like it is an additional module that I was not aware of
https://www.zen-cart.com/downloads.php?do=file&id=986
Would this be the correct d/l for the current ZEN cart version ?
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
treeoflife
It would be a version that offers some form of Easy Populate operation (though reportedly only operational up to ZC 1.5.1 based on the plugin's download page), but it is not the version applicable to this thread. This thread relates to the EasyPopulate V4, which is applicable for ZC 1.3.9 through 1.5.5x.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
treeoflife
I installed my Zen cart thru webhost applications, webhost : Goddady and I can not find the EZ Populate under Admin, and go to Tools -> EasyPopulate 4? I have the newest version installed.
If the latest version of EP4 (downloadable from here) is "installed" and the above issue is occurring, then I would suggest verifying that the files have been loaded to the correct location. The files (and folders) of the download's admin directory are to go into your (renamed) admin directory. Once they are placed there, then on next navigation of the admin window, an option should appear in the tools menu to initiate access to Easy Populate 4.
As to your install from your host, suggest that you attempt to go through a checkout process to verify that all necessary/applicable files and database options have been applied. Most "auto-installers" (none are written by ZC) seem to miss one or more things. The suggested route is to manually install the software available from this forum website at the home page. That installation though should not effect the ability to install EP4.
-
Re: EasyPopulate 4.0 Support Thread
what I'm using:
zen-cart-v1.5.4-12302014
EasyPopulate-4.0-master
Minimum Order
MSRP_Display_1_for_ZC_4
responsive_sheffield_blue_2.0.templete
ALL was working Great for about 8 months, I've done 2-3 updates per month of almost 4,000 products with this Great Addon.... did a major update of products from a downloaded csv file via EP4 with openoffice cal...
Problem is... On some, only parts of the product descriptions were updated.. most died mid word.. there are NO special characters, No html coding in some that dies and even ones that worked before didn't work this time...
any hints where to start looking for a fix would be Greatly appreciated...
William
Remember if it's not fun, Don't do it...
-
Re: EasyPopulate 4.0 Support Thread
Although stated that using easypopulate-4.0-master, that doesn't provide the version number associated with the install which could be important in relation to what is happening.
My guess though from the provided information is that when importing the single file that contains what looks like ~4,000 rows of data, is that the import timed out and only what had been transferred to that point survived/was written. When such an issue occurs there are several options made available by the software (though some servers may not support all built in options). For one, the import file can be split at a pre-determined number of rows per file. (this is one that is an option that is not so server dependent). The timeout period can be extended for EP4 as well as for ZC; however, some server configurations may not respect the request to extend those durations.
The other possibility is that the content of these descriptions includes characters (however non-special they may be) that need to be escaped such as quoted content. Or perhaps as experienced above the file was not saved as utf8 and therefore some of the character codes while not exactly "special" were incompatible with the character set used by EP4.
Then there is the debug.txt file that may exist in the EP4 file storage directory. If it is present, then at some point since it was last removed there was a problem with an import file. Recommendation would be to download it for temporary keeping, delete the file from the server and attempt to import a "trouble" file and see if it gets generated again. If so, then address that issue.
As to version information again, when in the tools->EP4 window the upper left area should identify a version number. Please provide that for information.
-
Re: EasyPopulate 4.0 Support Thread
Thank you mc12345678... My Bad.... it was the language and utf8.. changed these and everything flowed like it did before. took 54 seconds to update 3,978 items... I truly love this addon ... saves so much work
and the version is:
Easy Populate 4.0.30 - Beta 06-27-2015
Thanks again.......
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
hivtop
Thank you mc12345678... My Bad.... it was the language and utf8.. changed these and everything flowed like it did before. took 54 seconds to update 3,978 items... I truly love this addon ... saves so much work
and the version is:
Easy Populate 4.0.30 - Beta 06-27-2015
Thanks again.......
As was suggested to jkenwell, the version should be updated to 4.0.36.ZC or newer. Upgrade should be as easy as uploading the new files, then when on the tools->easy Populate 4 screen, select the upgrade link in the upper right hand corner and tada...
-
Re: EasyPopulate 4.0 Support Thread
hahaha.. why did I know someone would tell me to "update"... will do it... BUT... after 40 years of working on computers, my motto is: "If it ain't Broke, why fix it".. LMAO The only problems I've had with this fine addon is "My own fault"... hahaha
-
Re: EasyPopulate 4.0 Support Thread
uploading a product broke my site?
i was able to download a product that i entered from the admin page. i have only 1 product in 1 category which is named in both english and chinese. i was able to see category_name_1 in chinese in the csv file.
i then created a simple csv file, removing only a few columns such as item available date, item expiration date, etc. enter both chinese and english item names and descriptions. upload and import.
after that, my new home page is totally broken. "best sellers", "new products", etc are gone. no new product shows up. i then proceeded to upload the same product with v_status=9, and that deleted even the existing product...
i tried empty tables "products" and "product_description" in phpmyadmin, but that didnt do anything.
how do i fix this?
-
Re: EasyPopulate 4.0 Support Thread
Should have been able to also see category_name_2 (or some other number depending on the language installation/removal history).
Perhaps some basic questions in addition to some other information to gather:
Are you using product_model (default) as the primary key (configuration->Easy Populate 4) and was there a model provided in the new upload?
Is/was the products_model (or other primary key if chosen) the same as the original product?
In the setup of your site (including language files) is utf8 or another character set used?
If the original file is imported (not edited but as stored on the server) does the product return to the site?
If the edited file is again uploaded but this time to include the date fields that had been removed and verified to have a different primary key, does the product appear as desired?
Before attempting this for this first time, were there other product in other categories and have they been affected? (ask because that is not fully clear based on the above report of having 1 product in 1 category but then no items appear in the other sub-groups.)
-
Re: EasyPopulate 4.0 Support Thread
Also, what was the source of the download of the program?
-
Re: EasyPopulate 4.0 Support Thread
sorry, i was not clear enough.
i downloaded both ep3 and the language pack from here. both and zen cart are the newest versions.
i just realized that i did not have primary key set. (so the default is products_model.) i did not specify product model (the 1st column). i did have category_name_2 in english (category_name_1 in chinese).
i never specified any character set or utf8. i just set default as chinese on the admin page. the ep4 admin page does show
Internal Character Encoding: UTF-8
DB Collation: utf8
now i set the primary key as "blank_new", added back the columns i deleted but left blank. after importing, i get the product with english title and description, regardless of my browser language... and the home page layout still is messed up, including e.g., 'Categories' shoing up as 'HEADER_TITLE_CATEGORIES', 'privacy policy' shows up as 'FOOTER_PRIVACY'.
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
gdtw
sorry, i was not clear enough.
i downloaded both ep3 and the language pack from here. both and zen cart are the newest versions.
i just realized that i did not have primary key set. (so the default is products_model.) i did not specify product model (the 1st column). i did have category_name_2 in english (category_name_1 in chinese).
i never specified any character set or utf8. i just set default as chinese on the admin page. the ep4 admin page does show
Internal Character Encoding: UTF-8
DB Collation: utf8
now i set the primary key as "blank_new", added back the columns i deleted but left blank. after importing, i get the product with english title and description, regardless of my browser language... and the home page layout still is messed up, including e.g., 'Categories' shoing up as 'HEADER_TITLE_CATEGORIES', 'privacy policy' shows up as 'FOOTER_PRIVACY'.
Those last identified issues are related to definitions existing for the defined language(s) and/or the assignment of a language to its associated language folder. EP4 does not modify the database language assignments, therefore it would appear that the define for the associate language and page has been modified, moved or removed which is unrelated to the import/export of data using EP4.
-
Re: EasyPopulate 4.0 Support Thread
Is there a way to add custom product fields into a NEW table (ie:) zen_products_custom that will work with EP4 import/export?
Thanks
~D
-
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
djdavedawson
Is there a way to add custom product fields into a NEW table (ie:) zen_products_custom that will work with EP4 import/export?
Thanks
~D
Of course there is, though it would require some coding to do. There is/was a plan to add the capability directly into the user defined field of the admin configuration; however, there have been some other things to address before fuly delving into that.
There are notifiers throughout the import and export code that support I think all related operations that are going on. Using/having some sort of relational key one can add observer operations, collect/use/manipulate the data and affect the desired table(s).
My suggestion is to begin working on the export before the import (though thinking about what will be needed to support the import while generating the export).
Also suggest taking a look at what/how mesnitu has incorporated the bookx product type into EP4 by way of the above mentioned notifier/observer interaction. While there are still some improvements in coding that can be applied, he's come a long way with the effort. I also have something at my website that uses the notifiers/observers to integrate Ceon URI Mapping with EP4, but that's a slightly different story. It does, however, apply changes to a different table than the products table.
Now, all of that was said because the question related to a different table other than the products table. If the field(s) in question are in the products table then simply need to add the field (new_field instead of v_new_field) into the user defined field(s) list.
-
Re: EasyPopulate 4.0 Support Thread
Thank you for the quick response.
I will start digging into the export for some ideas and to get a feel for how it's written.
As a related followup question, is there a simple way to change the "User Defined Products Fields" to use v_products_description instead of v_products ?
Thanks Again MC
~D