Thank you very much. Problem solved.
Printable View
Thank you very much. Problem solved.
Thank you very much. Problem solved.Quote:
Originally Posted by mc12345678
I've installed EP4 onto Zen Cart 1.5.7b and it mostly works fine, however unlike previous versions I could upload subcategories from a CSV. This version is only uploading everything to the top level so for instance I want: Shoes > Blue > Nice Blue Trainer. But I am getting instead is Shoes > Nice Blue Trainer.
I am using the category headings of v_categories_name_1, v_categories_name_2, v_categories_name_3 and so on but everything is being uploaded into v_categories_name_1.
Can anyone help with this?
Thanks, Rich
Yes. If you have used some other version of Easy Populate, then likely it did not support multiple languages... the number that follows the underscore represents a language at least in cases where "true" text is involved. To use sub-categories, the relationship is presented using a carat (^). So for the above, Shoes^Blue^Nice Blue Trainer to represent the product to be in the main category of Shoes, the sub-category of Blue and then within that sub-category to dig deeper into the sub-category of Nice Blue Trainer.Quote:
Originally Posted by RichBarnett
This "difference" is described in the instructions.
Sorry, I didn't explain myself properly.Quote:
Originally Posted by mc12345678
So the previous version that I used was on an older website. I am now building a completely new website so there is no history or connections to older versions, it's a completely different database.
So, if I use the older website I can use v_categories_name_1, v_categories_name_2, v_categories_name_3 to create subcategories. On the new website, it only recognises v_categories_name_1 and nothing more. How can I get it recognise v_categories_name_2, 3 and so on?
Thanks, Rich
And perhaps I did not explain myself, but in addition to that I would like to ask for some information.Quote:
Originally Posted by RichBarnett
A few questions first:
1) In exporting a copy of what is currently in the database (full export or by use of the dropdowns along the top to target a smaller grouping), how do the headings associated with v_categories_name appear? Do they contain _1, _2, and/or _3?
2) How many languages are installed to this new site?
3) In the upper right corner of the EP4 window, what are the designations for the language(s)?
4) What is an example of information populated in v_categories_name_1 for the uploaded file?
5) What version of EP4 is being used on the two sites?
To try to explain what is likely incorrect based on the recent response, I (mis)understood that where a product was to be placed into a sub-sub-category of Nice Blue Trainer, that v_categories_name_1 was populated with Shoes, v_categories_name_2 with Blue and v_categories_name_3 with Nice Blue Trainer. Because the problem described (all items appearing in just the "first" category) and "older/other" versions of Easy Populate (not EasyPopulate V4) acting this way, I *assumed* that the older site was using such an older (non-EP4) version.
I haven't been told of any issues with multiple languages and product being attempted to be entered into sub-categories by use of the language_id (1, 2, 3, etc). If such a problem exists, I would really like to resolve it. Not being told about such a problem doesn't mean it doesn't exist. Ideally we can get to the issue(s) and resolve whatever needs to be addressed.
Thank you for your response and sorry to sound thick.
In response:
1) So in EP4 the CSV export only offers v_categories_1 - this is installed on the new website. On the old website EP0 is used and exports a CSV with the headings v_categories_1, v_categories_2, v_categories_3 and so on up to 7.
2) Only English.
3) Just English
4) Shoes for instance below:
v_categories_name_1 v_categories_name_2
Shoes Size 6
Shoes Size 5
5) I've taken the latest version of EP4 for the new website. The old website uses just Easy Populate from several years ago.
Thanks, Rich
No problem. The questions were asked to help ensure that we are/would be on the same page.Quote:
Originally Posted by RichBarnett
Okay, so... If English is the only language that is used, then when working with fields that are language based such as "v_categories_name" the _1 that follows will assign the data to the language that is identified as having a language_id of 1... In a standard default install of Zen Cart that will be English.
So, to identify the category name information for English in a standard install, that data will go into the column that is titled v_categories_name_1. For a products_description, the v_products_description_1 column will be populated with the description to be presented in English.
So... How are sub-categories handled? Well, for English, all information has to be placed under the v_categories_name_1 column, but somehow the main category has to be identified to have a sub-category.... This is done by listing the main category separated by something and then followed by the sub-category of that main category. In a default EP4 installation, that dividing character is the carat (^) (shift 6 on a Standard US based computer keyboard).
For your example, the category information to put a product in the sub-category of Size 6 under Shoes, then the information in the field (column of v_categories_name_1) would be:
Shoes^Size 6
For the product that is to be in Size 7 of Shoes:
Shoes^Size 7
Now if you had a category that was a sub-sub-category, then something like:
Shoes^Blue^Size 6
Would place the product of that row into the Size 6 sub-category of the Blue category that is in the Shoes category....
Such above information would also be displayed in the output file if product were exported.
As to "several years ago", EP4 has been around for a long time thanks to the work of several others before me (as can be seen by going to the first post of this thread). This version though works differently than others have worked.
Does that help at all?
If you look back through this thread (use a search in the forum or perhaps even better from your favorite internet search tool) for say CONCATENATE, then there are instructions provided throughout about how you can "convert" an existing import file from the way that/those versions of Easy Populate operated to how EP4 works.... I know that I have provided such instruction multiple times but haven't gone back myself anytime recently to locate the posts...
For an example in say cell Y2:
=IF(N2<>"", CONCATENATE(M2,"^",N2),M2) & IF(O2<>"",CONCATENATE("^",O2),"") & IF(P2<>"",CONCATENATE("^",P2),"")
That would combine four cells together into a single cell where all of the content is combined as "expected". That result could then be copied to your v_categories_name_1 field....
Well, that has just worked superbly!Quote:
Originally Posted by mc12345678
Thank you for your extensive and comprehensive responses on this! Really appreciated.
Best, Rich
Excellent! Now, thing is though that if this new site wasn't restored back to before the "problem" import *and* if it is not (re-)designed to support product in categories with sub-categories, then need to take action to basically remove linked product from those "parent" categories.Quote:
Originally Posted by RichBarnett
At the moment I forget the detail, but it is covered in the instruction about reassigning the master_categories_id using the status value of 7.
If it was just a development site (recommended for initial testing) then restoring the database should be easy.
No, that's all fine as I'm taking the opportunity to re-design my categories so I'm not taking a straight copy. Everything is being uploaded in stages and is working well so far.
I am getting error when importing my database.
[03-Feb-2021 02:08:08 UTC] Request URI: /cart/zcadmin/index.php?cmd=easypopulate_4, IP address: .
#1 sizeof() called at [/home/encoredance1/public_html/cart/zcadmin/easypopulate_4.php:661]
#2 require(/home/encoredance1/public_html/cart/zcadmin/easypopulate_4.php) called at [/home/encoredance1/public_html/cart/zcadmin/index.php:11]
--> PHP Warning: sizeof(): Parameter must be an array or an object that implements Countable in /home/encoredance1/public_html/cart/zcadmin/easypopulate_4.php on line 661.
The usual questions:Quote:
Originally Posted by donhorn
- when did this start?
- when did it last work properly?
- what software changes have occurred on your server lately? eg: php versions
- what version of Zen Cart?
- what version of EP4?
- etc.
receiving the same messages:
fresh ins tall 1.5.7b
EP 4 master from gibhub
no changes PHP 7.4 ( but also same message in 7.3)
( installed into a fresh install, no update but empty, no demo shop)
Hope this is also same as Donhorn, so we can figure out what this is :D
( i hope mearly a typo in the files, but still i can't find them)
Greetings
kerneheimer
Quote:
Originally Posted by DrByte
Problem is... the current github version of admin/easypopulate_4.php doesn't contain the word sizeof which in the previous report of the issue was identified as being on line 661...Quote:
Originally Posted by kernheimer
Line 661 currently reads:
<?php
That's all.
Forgive me, ( to much dyscalculatic ( serious) and english not quite my first... what do i need to change to avoid the bug rappot?
thanks for your help!
Quote:
Originally Posted by mc12345678
Macht nichts. Sie sollten der Software von: https://github.com/mc12345678/EasyPopulate-4.0 benutzen. Es gibt ein versionnen autocheck, Sie deaktivieren muessten. Normalerweisse, hat webchills information daran.Quote:
Originally Posted by kernheimer
you are totaly cute! i can speak and read fluendly german and even grew up there a big time of my childhod, but I really am very Dutch :D :D
thanks so much, Danke :D sehr herzlichen dank.
Quote:
Originally Posted by mc12345678
Thank you for your understanding.Quote:
Originally Posted by kernheimer
I guessed that German might be understood. I should have asked, but wanted to help quickly.
If you have translations for the plugin, please feel free to add on github.
I would love to try to translate to Dutch, ( we don't have a good 1.5.7. version yet, i'm working on it also) but i need to understand what you meen with the version check beeing disabled. I have no idea where to look for that.
Quote:
Originally Posted by mc12345678
The statement was made based on using the German provided version of Zen Cart. In the German provided Zen Cart the version check option is disabled/removed.Quote:
Originally Posted by kernheimer
With the removal of the version check software in the German Zen Cart, older versions oF EasyPopulate V4 would generate errors because it does try to check the US/Canada Zen Cart site for newer versions.
I know I wanted to make EP4 easier for use when installed. I need to look to see if I did anything to make it easier. Otherwise, I know I have seen some discussion in the following forum group about how to use this version of EP4 with the ZC provided by webchills: https://www.zen-cart-pro.at/forum/fo...-Easy-Populate
So, question is does it work now or are there still problems?
The store admin accidentally deleted a complete product category and asked me to fix this. The latest database backup available is three weeks old, so instead of restoring the complete database, I figured I could use EasyPopulate to
1) Export the category after restoring the backup. I intend to do this on a local copy of the website (xampp) that I currently have runnin because of a recent upgrade after years of not working with Zen Cart.
2) Import the export file into the live site.
I never worked with EP before so I tested it first on the locally running site by
1) Creating an export of a product category. This seems to work.
2) Deleting said product category. This obviously works.
3) Importing the export. This does not work. The bar at the top displays "File Import Completed," but the import report at the bottom says
To make things simpler, I created a new category of 1 level with only one product. I exported this category, then deleted the product (but kept the category), then tried to import with the same result. The export file looks like this:Code:Import Results
Filename: Full-EP2021-02-14-093948.csv
Finished Processing Import File
Updated records: 0
New Imported records: 0
Errors Detected: 0
Warnings Detected: 0
Memory Usage: 5638888
Memory Peak: 6571048
Execution Time: 0 seconds.
I use ZC version 1.5.7b and the latest EP from the github link from the plugins page.Code:v_products_model,v_products_type,v_products_image,v_products_name_2,v_products_description_2,v_products_url_2,v_products_name_8,v_products_description_8,v_products_url_8,v_specials_price,v_specials_date_avail,v_specials_expires_date,v_products_price,v_products_weight,v_product_is_call,v_products_sort_order,v_products_quantity_order_min,v_products_quantity_order_units,v_products_priced_by_attribute,v_product_is_always_free_shipping,v_date_avail,v_date_added,v_products_quantity,v_manufacturers_name,v_categories_name_2,v_categories_name_8,v_tax_class_title,v_status,v_metatags_products_name_status,v_metatags_title_status,v_metatags_model_status,v_metatags_price_status,v_metatags_title_tagline_status,v_metatags_title_2,v_metatags_keywords_2,v_metatags_description_2,v_metatags_title_8,v_metatags_keywords_8,v_metatags_description_8
"","1","","test","beschrijving","","test","description","","","","","9.92","0","0","0","1","1","0","0","","2021-02-14 09:39:04","0","Anemoontje","pakketjes","pakketjes","19","1","0","0","0","0","0","","","","","",""
Thanks in advance for any help!
So first thing is that the product (at least as shown in this one record) does not have a products_model assigned to it. Not a requirement in all situations, but in a default install, products_model is the primary key. Blank means don't do anything with it. Appears would be good to have notification of that situation/issue.
So... what can be done to at least restore the product? Go back to the original state of the database and as far as EP4 is concerned, adjust the configuration settings to use the primary key of products_id. Then export the product within that category to use that data for recreation of the product to have the exact same products_id that it previously had. *NOTE* this is one place where care and understanding about the condition and status of the destination database must be taken and known. You don't want to *also* mess up a product that already exists.
Now, as to the true "recreation" of the category (which appears to be the original intent), will also need to export category files in addition to the product files provided above.
The process followed so far is expected to simply create the place holder for the category. But the category will have nothing really in it. No category description for example. Further, because there are at least two languages involved, will want to be sure that the appropriate information is carried in each of the languages within the category...
Thank you for your quick reply! Setting the primary key to product_id makes everything work as expected. I will have to check whether problems arise with existing product_ids. Not sure whether ID's are recycled, but if not there should not be a problem because the source DB is a backup of the destination DB. I will continue on this tomorrow.
Thank you for the tip about recreation of the categories too. I didn't figure that would be necessary.
v1.5.7b PHP7.3 Easy Populate 4.0.36.ZC (mc12345678 version)
I have 1 issue below, as well as one question below.
I am receiving similar myDEBUG errors as the one indicated on previous page relating to line 661 - thrown when generating a Full EP request - the file is produced no problem at all so it appears it is not detrimental to function - my error however refers to a number of instances and different line numbers as per example below (truncated the error log - it continues further alternately with errors in line 655 and 651 - so is the fix the same for the different lines as it is for 661?;
QUESTIONCode:[16-Feb-2021 17:00:09 Australia/Sydney] Request URI: /dazzlers/index.php?cmd=easypopulate_4, IP address: 121.45.84.235
#1 sizeof() called at [/dazzlers/easypopulate_4.php:281]
#2 require(/dazzlers/easypopulate_4.php) called at [/dazzlers/index.php:11]
--> PHP Warning: sizeof(): Parameter must be an array or an object that implements Countable in /dazzlers/easypopulate_4.php on line 281.
[16-Feb-2021 17:00:10 Australia/Sydney] Request URI: /dazzlers/index.php?cmd=easypopulate_4, IP address: 121.45.84.235
#1 require(/dazzlers/easypopulate_4.php) called at [/dazzlers/index.php:11]
--> PHP Warning: Use of undefined constant ORDERSEXPORT_LINK_SAVE1 - assumed 'ORDERSEXPORT_LINK_SAVE1' (this will throw an Error in a future version of PHP) in /dazzlers/easypopulate_4.php on line 605.
[16-Feb-2021 17:00:10 Australia/Sydney] Request URI: /dazzlers/index.php?cmd=easypopulate_4, IP address: 121.45.84.235
#1 require(/dazzlers/easypopulate_4.php) called at [/dazzlers/index.php:11]
--> PHP Warning: Use of undefined constant ORDERSEXPORT_LINK_SAVE1B - assumed 'ORDERSEXPORT_LINK_SAVE1B' (this will throw an Error in a future version of PHP) in /dazzlers/easypopulate_4.php on line 606.
[16-Feb-2021 17:00:10 Australia/Sydney] Request URI: /dazzlers/index.php?cmd=easypopulate_4, IP address: 121.45.84.235
#1 require(/dazzlers/easypopulate_4.php) called at [/dazzlers/index.php:11]
--> PHP Warning: Use of undefined constant ORDERSEXPORT_LINK_SAVE2 - assumed 'ORDERSEXPORT_LINK_SAVE2' (this will throw an Error in a future version of PHP) in /dazzlers/easypopulate_4.php on line 607.
[16-Feb-2021 17:00:10 Australia/Sydney] Request URI: /dazzlers/index.php?cmd=easypopulate_4, IP address: 121.45.84.235
#1 require(/dazzlers/easypopulate_4.php) called at [/dazzlers/index.php:11]
--> PHP Warning: Use of undefined constant ORDERSEXPORT_LINK_SAVE3 - assumed 'ORDERSEXPORT_LINK_SAVE3' (this will throw an Error in a future version of PHP) in /dazzlers/easypopulate_4.php on line 608.
[16-Feb-2021 17:00:10 Australia/Sydney] Request URI: /dazzlers/index.php?cmd=easypopulate_4, IP address: 121.45.84.235
#1 sizeof() called at [/dazzlers/easypopulate_4.php:655]
#2 require(/dazzlers/easypopulate_4.php) called at [/dazzlers/index.php:11]
--> PHP Warning: sizeof(): Parameter must be an array or an object that implements Countable in /dazzlers/easypopulate_4.php on line 655.
[16-Feb-2021 17:00:10 Australia/Sydney] Request URI: /dazzlers/index.php?cmd=easypopulate_4, IP address: 121.45.84.235
#1 sizeof() called at [/dazzlers/easypopulate_4.php:661]
#2 require(/dazzlers/easypopulate_4.php) called at [/dazzlers/index.php:11]
--> PHP Warning: sizeof(): Parameter must be an array or an object that implements Countable in /dazzlers/easypopulate_4.php on line 661.
[16-Feb-2021 17:00:10 Australia/Sydney] Request URI: /dazzlers/index.php?cmd=easypopulate_4, IP address: 121.45.84.235
#1 sizeof() called at [/dazzlers/easypopulate_4.php:655]
#2 require(/dazzlers/easypopulate_4.php) called at [/dazzlers/index.php:11]
--> PHP Warning: sizeof(): Parameter must be an array or an object that implements Countable in /dazzlers/easypopulate_4.php on line 655.
[16-Feb-2021 17:00:10 Australia/Sydney] Request URI: /dazzlers/index.php?cmd=easypopulate_4, IP address: 121.45.84.235
#1 sizeof() called at [/dazzlers/easypopulate_4.php:661]
#2 require(/dazzlers/easypopulate_4.php) called at [/dazzlers/index.php:11]
--> PHP Warning: sizeof(): Parameter must be an array or an object that implements Countable in /dazzlers/easypopulate_4.php on line 661.
[16-Feb-2021 17:00:10 Australia/Sydney] Request URI: /dazzlers/index.php?cmd=easypopulate_4, IP address: 121.45.84.235
#1 sizeof() called at [/dazzlers/easypopulate_4.php:655]
#2 require(/dazzlers/easypopulate_4.php) called at [/dazzlers/index.php:11]
--> PHP Warning: sizeof(): Parameter must be an array or an object that implements Countable in /dazzlers/easypopulate_4.php on line 655.
[16-Feb-2021 17:00:10 Australia/Sydney] Request URI: /dazzlers/index.php?cmd=easypopulate_4, IP address: 121.45.84.235
#1 sizeof() called at [/dazzlers/easypopulate_4.php:661]
#2 require(/dazzlers/easypopulate_4.php) called at [/dazzlers/index.php:11]
--> PHP Warning: sizeof(): Parameter must be an array or an object that implements Countable in /dazzlers/easypopulate_4.php on line 661.
Can this plugin produce the complete url for images rather than the shortened version (e.g. earrings/clip-on-earrings-527.jpg is produced but needs to be https://www.dazzlerscliponearrings.com.au/images/earrings/clip-on-earrings-527.jpg) this is required so I can create a Google Merchant Center feed - if it can, then how can I make any mods to get this result?
cheers,
Mike
Quote:
Originally Posted by mc12345678
Quote:
Originally Posted by mc12345678
Please see the first sentence of the above first post, then please follow the link in the second post (yes, written in what I would say is broken German as I seriously doubt it had all of the correct grammar and words).Quote:
Originally Posted by shags38
As to the full path to images, the question would be does it need to be autogenerated to have that or could it be generated after download as part of providing the file to the associated service?
Currently, there is not a full auto-generation step in the code, but it could be incorporated. Recommendation would be to produce an additional field in the file so that the data of the original field could still be properly used.
Ohh, and lastly, would recommend changing the folder name for your admin and as necessary/appropriate may need to do the same in your store's .htaccess if you have generated one and it contains the current admin folder name in it.
Your broken German is a lot better than mine :smile: I went to your GitHub and downloaded your latest version - thanks for that.Quote:
Originally Posted by mc12345678
So your post encouraged me to research how I could add the 'prefix' of the first section of the url to make the image url complete - perservered and found a solution on StackOverflow - so I learned something very valuable - so no need for the full url to be generated by the plugin for just this purpose.
cheers,
Mike
p.s. hopefully others may find this useful - how to add full url to generated 'part' image url
here is the process I used in the original download Excel file;
1. select all cells in column with image url
2. in Home go to 'format cells' in graphic at top towards the far right
3. click for dropdown box to show then click format cells in drop down box
4. in box that appears click on custom
5. at RH site in the empty box below the word 'type' simply type the full url minus the part that is already generated in this format "https ://www.your_full_ url_ segement_ to_ADD_ to_generated_product_url"@ - (url segment in " followed by @ - no space) and click OK
6. that code should now be in all entries making a complete url - that code will remain in 'custom' for future use
for OpenOffice Calc
1. select all cells in column with image url
2. in menu tabs select 'format cells'
3. in box that appears on LH side click User Defined
4. in the empty box near the bottom simply type the full url minus the part that is already generated in this format "https ://www.your_full_ url_ segement_ to_ADD_ to_generated_product_url"@ - (url segment in " followed by @ - no space) ... then click OK
6. that code should now be in all entries making a complete url - that code will remain in 'user defined' for future use (note that when used again it will automatically show up as 'text' but you need to scroll up and select 'user defined' then click OK (otherwise it simply adds text and not in the right format)
Quote:
Originally Posted by shags38
Did your export file have anything populated in the v_products_url_1 field? I notice it looks like your sites use one of the SEO urls .... do you use Ultimate?
Note that v_products_url_1 has nothing to do with a site having a URI rewriter. That field represents the uri that one chooses to have displayed with the product and is a field that is manually entered in the product's information page. Further that field is language dependent meaning one could provide a link to an english version of a site page for when displaying english or whatever page is desired for each other language supported by the site...Quote:
Originally Posted by shrimp-gumbo-mmmhhh
As far as export of the uri generated by a rewriter, if it uses zen_href_link to generate the uri, then it should be possible to retrieve the current uri when exporting the associated data while the configuration switch is turned on. The switch is to provide the uri for the product/category.
Again, short answer, all sites have the availability of v_products_url_, not just those with a uri rewriter. A uri rewriter will not force content to exist in that field. Further, remember that a field that ends with an underscore and a number represents a field that is language dependent and that the number represents the language_id for that language.
Thank you for the explanation!
Line #605 : "orders-full-ep"=>ORDERSEXPORT_LINK_SAVE1,
Line #606 : "orders-fullb-ep"=>ORDERSEXPORT_LINK_SAVE1B,
Line #607 : "orders-noattribs-ep"=>ORDERSEXPORT_LINK_SAVE2,
Line #608 : "orders-onlyAttribs-ep"=>ORDERSEXPORT_LINK_SAVE3
I am getting: --> PHP Warning: Use of undefined constant ORDERSEXPORT_LINK_SAVE3 - assumed 'ORDERSEXPORT_LINK_SAVE3' (this will throw an Error in a future version of PHP)
for these variables.... when I do a search through the ZC code I do not see them being called or used elsewhere.... do you think I could assign them some nominal value just to get them to not give a warning without something breaking?
--> PHP Warning: sizeof(): Parameter must be an array or an object that implements Countable in /home/account/public_html/admin/easypopulate_4.php on line 655.
It looks like $files is an array so why is it still getting the warning?
if ($dirhandle = opendir($upload_dir)) {
$files = array();
for ($i = 0; $i < sizeof($files);
okay, maybe the constant errors would be fixed by putting those in the
/home/account/public_html/admin/includes/languages/english/easypopulate_4.php
????
Quote:
Originally Posted by shrimp-gumbo-mmmhhh
Looks like not using the version updated on github (have a few minor things to complete so that all language dependent imports will support the language designation (_en) instead of the old method of language_id "_1"). The location is: https://github.com/mc12345678/EasyPopulate-4.0. None of the described issues occur in that version.Quote:
Originally Posted by shrimp-gumbo-mmmhhh
Thank you! Will pull from there.
Just an update. Changed Specials Price to Null and the other error messages I received are gone. Works Great!
Updated records: 467
New Imported records: 35726
Errors Detected: 0
Warnings Detected: 0
Memory Usage: 152789664
Memory Peak: 153206360
Execution Time: 574 seconds.
Would I be able to have these records load in more than just a second layer directory structure? Meaning could I have a main> posters> super heros> batman and have all those categories created on the load?
Thank you!
If your question is: is it possible to upload a product to a category structure that doesn't already exist and if so, does it matter how deep the category structure is? Then the answer is yes it is possible and no it doesn't really matter how deep. I mean, I'm sure there is some super long text iimitation...Quote:
Originally Posted by shrimp-gumbo-mmmhhh
For your category structure, the field: v_category_name_1
Would contain: main^posters^super heroes^batman if the first category is called main, a sub-category off of there being posters that has a sub-category of super heroes that has a sub-category of batman. Now.... NOTE capitalization, extra spaces and any other characters between each carat (^) are used in evaluating the category relationship. So Batman is different from batman from BATMAN. This is something covered in the readme.
Note also that when a category is created it has an empty description until the associated category data is imported.
I have found a couple of issues.
1) If not able to insert into the products table then a csv file should be created of items that were not able to be inserted. There should also be a note noting number of products issues in the outcome note and noting file to look at.
2) If not able to insert into the products_description then the record should be deleted from products and a csv file should be created of items that were not able to be inserted. There should also be a note noting number of products_description issues in the outcome note and noting file to look at.
3) If not able to insert into the meta_tags_products_description is not able to be inserted into then a csv file should be created of items not loaded meta_tags to be worked on. There should also be a note noting number of meta_tag issues in the outcome note and noting file to look at.
Thank you!
Did you happen to scroll down the screen after performing an import?Quote:
Originally Posted by shrimp-gumbo-mmmhhh
To what file(s) are you referring when stating "noting file to look at"? At the completion of each import, there is some level of information provided. If an "insert" fails, that basically is a problem with the data that has been provided which for the most part likely can not be identified as "successful" or flagged for failure... Meaning, one may have to identify what has been successful to identify what didn't work.
As far some of the processes, it is possible that a message is not provided for one or another issues, for example I know that on a product import where products_model is the primary key, if the products_model field for a row is blank, there is no notification about any issue... Is it a problem? I say no, but that's because an empty products_model in that situation is expected and supposed to be skipped... I state some of that to try to further identify the expectational differences between early and experienced users.
Thanks for your work on this. I realize this is not a paid job and these are just my suggestions for whosoever may want to update this module to make it more excellent.Quote:
Originally Posted by mc12345678
Hello, yes I did scroll down the screen but this should really be spit out into a file with success and fail notices for each product.
"noting file to look at" if there was a file that contained those errors (it does not currently exists).
Hmmm... you cannot test to see if a sql insert was successful or not? Sorry, so easy to do with languages I have worked with just thought it would be easy in php also.
Thank you for having this working for us currently!
What is the setting you have under configuration->Easy Populate 4->'Debug Logging'? Has it been changed from the default of true?Quote:
Originally Posted by shrimp-gumbo-mmmhhh
If it is still set to true, then look at your list of files under 'This contains any other file. They will be processed like a full data file.' (The word They changes to this if there is only one file)
If there were "sql" errors while importing the data then there should be a file "ep_debug_log.txt" in that list. In that file is the query/queries that caused errors. Based on the associated information, the issue(s) should be locatable.
As far as logging the text that appears below the list of files, that is something that can be done using the EP4 function: write_debug_log_4($string) where $string is the text to be logged into the debug log.
So for example in admin/easypopulate_4.php towards the end where:
echo $display_output;
is present, then could add:
write_debug_log_4($display_output);
If want to make it dependent on the debug logging setting from above, then:
May also then want to incorporate the 'specials' data within the area below that with:Code:if (EASYPOPULATE_4_CONFIG_DEBUG_LOGGING === 'true') {
write_debug_log_4($display_output);
}
Remember this is open source so you can do with it what you will and while it has been made available for free download/use, it doesn't mean that there hasn't been some sort of funding by someone to someone at some time. Thankfully Chad Deruski did an outstanding job many years ago with development of so many features and options. As I understand it was developed to support his line of work and then at some point made available for others. He still makes an appearance once in a while.Code:if (strlen($specials_print) > strlen(EASYPOPULATE_4_SPECIALS_HEADING)) {
echo '<br />' . $specials_print . EASYPOPULATE_4_SPECIALS_FOOTER; // specials summary
if ((EASYPOPULATE_4_CONFIG_DEBUG_LOGGING === 'true') {
write_debug_log_4($specials_print . EASYPOPULATE_4_SPECIALS_FOOTER);
}
}
Note though that you will need to clear that debug file periodically to prevent eating drive space.
Oh and as far as "testing" the SQL, sure two additional lines and some other potential "switch" could be added to the query in the extra_functions file, to perform a transaction that gets reverted, or explained, or an alternate store could be used/tested rather than one's live store (this is a preferred situation so that zero damage is done to one's live store).
I have a question about deleting products. My client does not use model numbers, so I've got the "Import/Export Primary Key" set to "blank_new".
In my csv:
v_products_model is left empty
v_products_id is 326001
v_status is 9
When importing this file, I get: NOT FOUND! - Model: 326001 - cant delete...
I tried setting "Import/Export Primary Key" to "products_id" and got the same thing.
I don't understand why it doesn't delete the product with 326001 as the id. I did confirm the product exists by looking in the database.
Good question, looks like may need some more information. Seems that the code being used may be a little dated, there had been an update to revise the text response to indicate the primary key setting (in this case would expect to see 'v_products_id' instead of - Model). Sure the update is/was in the language files to an extent, but...Quote:
Originally Posted by jeking
So, information that may further help now that I've looked over the current processing "plan".
- Version number (and/or date downloaded) identified with the software?
- Any observer(s) listening to EP4_IMPORT_FILE_EARLY_ROW_PROCESSING that may have modified what could then be the global variable $continueNextRow to be set to a falsey value?
- Is debug logging turned on in the configuration settings? If so (default) then there should be some record in the generated debug .txt log in the EP4 main screen towards the "bottom" of the list of files. That is unless the admin/includes/functions/extra_functions/easypopulate_4_functions.php is old enough (pre Oct 3, 2016) to still have the typo of write_debug_log($string) instead of write_debug_log_4($string).
- Is there more than one product being deleted in the file, and does at least one other product delete successfully (presumably an earlier listed product)? For that matter is there more than one row of data in the file other than the header row?
I did see an updated version was available *after* to posted.Quote:
Originally Posted by mc12345678
Easy Populate 4.0.36.ZC - 07-05-2016
No observers added.
Debug logging is on but the log file is dated 2/2/2021
I only had on product in the file as I was testing before doing them all (200)
I have since deleted the products via phpMyAdmin but will continue testing with test product(s) as needed.
Well, on the "used phpMyAdmin" to delete product, understand that EP4 uses the ZC zen_remove_product function which removes *A LOT* of data and even files from the server. Simply removing product from the products table does not clean up the site the same way.Quote:
Originally Posted by jeking
I'll take a look at what that version does/did as far as processing, but I may also suggest looking at the ZC logs folder to see if there was an issue logged there as one of the actions is to unlink photos and while I wouldn't expect that to be a problem in a setup ZC site, it wouldn't be the first time that I've seen a problem crop up because of that even if the operation is prefixed to prevent generating an error.
As for the potential of generating a debug log entry, I rushed in my review. A log entry would only be made if a variable hard coded in admin/easypopulate_4.php had been changed to true. That issue leads me to consider making a change to allow setting that through the configuration menu by adding an option choice to the existing debug logging variable.
My guess for the issue (as still need to look back at that version) is that the remove product code wasn't updated to handle the alternate key. A work around to that would be to temporarily assign a products_model to those product being deleted (using the same blank_new or products_id setting) then change over to products_model and import a file with those product to be deleted and having those temporary products_model values... The model could be the products_id if models are not otherwise being used or have some sort of "prefix"/"suffix" that would ensure uniqueness...
I can update to the current version and try again. Your theory makes a lot of sense. I wish my client would use Model Numbers, but that's another story.Quote:
Originally Posted by mc12345678
"used phpMyAdmin" - yes, and good point. I removed the products from all of the tables in which I found the product_id.
Maybe you could make model numbers for them and then upload and then update that field to null after that?
MC12345678 .... seems like you mentioned to me somewhere that this EZ4.0 could load attributes.... can it also load attribute pictures?
I had an interesting thought for a change in the code.... when you first create a category you assign that product's picture to that products category picture.
Thank you!
Quote:
Originally Posted by shrimp-gumbo-mmmhhh
Sorry, I forgot that ZC attributes don't have pictures.... I guess I am thinking of a mod I saw?
What?Quote:
Originally Posted by shrimp-gumbo-mmmhhh
https://docs.zen-cart.com/user/admin...tribute-images
Note, some tables use product_id, some products_id. Again, an operation best left to zen_remove_product.Quote:
Originally Posted by jeking
Also, I got a little wrapped up in the details, but in the making of a products_model for product deletion, if trust that the products_model to be assigned represents a product to be deleted, then all to be deleted could be made the same products_model and then when using the older ZC version, could upload just one product with that same products_model to have it delete. All items with that products_model will be sought and "destroyed".
It can load the *path* to the pictures, but pictures are not "loaded" to the store via EP4. The detailed attributes import file would be used to identify to the store the path to use to identify the attribute picture(s).Quote:
Originally Posted by shrimp-gumbo-mmmhhh
Certainly possible, though also may make it difficult to track down which category/categories need "updating". I mean, ideally, before uploading a file that would generate a category that category would actually already be fully identified and either ready for upload or already fully exist. Some don't even use the category picture(s) so that feature may not be of significant value to those. That said, I'll look to see what options are or can be made available at that point in the code to support that possibility if desired.Quote:
Originally Posted by shrimp-gumbo-mmmhhh
Quote:
Originally Posted by shrimp-gumbo-mmmhhh
Definitely with DrByte on this one. Not sure where or what led to disbelieving that attributes can have images. Certainly there are possibly issues with templates and/or configurations, presence of images where the path expects, problems in one's includes/configure.php file, etc... but the system supports their existence.Quote:
Originally Posted by DrByte
Quote:
Originally Posted by mc12345678
Great news! I understand what you are saying between load and point to....
My live site which is 1.5.7c actually does not have the swatch image available option..... I do see this option in my new test site though.
I'm back, my client made the same mistake in importing so I have the same problem.Quote:
Originally Posted by jeking
This time I am using version: Easy Populate 4.0.37.12 - 12-24-2020'
"Import/Export Primary Key" is set to products_id
I'm importing a csv file with just one row. Only difference is the v_products_id is now 326004
When I import, this is the result:
Import Results
Filename: Full-EP20-Book1.csv
Finished Processing Import File
Updated records: 0
New Imported records: 0
Errors Detected: 0
Warnings Detected: 0
Memory Usage: 50819040
Memory Peak: 87319616
Execution Time: 0 seconds.
Even though no error was mentioned, I checked anyway and found no error log.
If those items are already in the database it will just update them....
But I'm using a v_status of 9, shouldn't that delete them?Quote:
Originally Posted by shrimp-gumbo-mmmhhh
So as you can tell I'm trying to get to a point to release a new version here in Zen Cart. Unfortunate "history" is that I began a "sub-version" by increasing the wrong version identifier (.37). At any rate, here is what I've found.Quote:
Originally Posted by jeking
The attempt to delete a product will not execute if:
1. obvious: The identifier from within the main key doesn't exist anywhere in the database (E.g. products_id = 5001 but there is no record with products_id = 5001)
2. Less obvious and not so sure that was intentional, looking into it: the item in question is not populated in ALL of the products table, if the products_id is not in the products_to_categories table with a matching/associated categories table record to the record in the products_to_categories table...
Now, how this may have been possible? Well, I had found (testing solution as much as possible) that if I attempted to import product with a v_categories_name_(language_code) instead of the traditional/historic v_categories_name_(language_id) that the product would not be placed how/where it was expected. While I haven't yet uploaded all that I did yesterday to resolve this, I want to make a consistent approach to the operation.
For more "power" users I have/had started to implement a process where it was possible to import with either the language_id (1, 2, 3, etc..) or the language_code (e.g. en, de, es, etc...). At a point, I realized the possibility that someone may import with one but not the other, or "worse" import with both fields populated... So I created a "preference" option (language_id or language_code) such that if both were provided then the method indicated as a preference would be the one that would "dominate". I later discovered though that I had also incorporated that if only one of those fields/columns were included and not the one that was preferred, then the remaining column would cause changes. So... I've added two additional options such that import could/would be limited to the style designated (language_id_only or language_code_only). In this way, regardless the columns present, only the column(s) ending with that designator will be processed.
Now, in this exercise I also found a number of issues with how Zen Cart 1.5.7 "limits" operations... For example, if a product was assigned to categories_id of 0 and not linked elsewhere, then it was extremely difficult to relocate it. It couldn't be moved (Move said something about not placing it in the same place that it was along with some other information). The products link manager identified that it didn't have a master category set, but then wouldn't offer/allow any other category to be set because it seems that it wasn't yet linked to anything else (sort of defeats the purpose of using the link manager if can't establish another link). I think what I ended up doing was copying the product as a linked product and placed it in some other category (that didn't have sub-categories) and then went through one or another process to delete the product from the top category (categories_id of 0).
Now as far as the data indicating 0 action performed for all rows, the "primary" issue that might cause that report is that the desired/expected primary key field is empty in such a way that no action is to be taken (e.g. not set to blank_new and a delete action isn't performed or there isn't sufficient fields to encourage/do anything) with the secondary being as commented out in the code that in some way the associated category may not be found. I found on my test site that I too was having difficulty using any other primary key than products_model. For me I found the reason was that I had hard coded the primary key (EP4_DB_FILTER_KEY) in admin/includes/extra_configures to be something not in the standard list and without an observer to handle it.
So, what to do? There's options... Possibly the "easiest" assuming that action is quickly taken is to assign a products_id, categories_id into products_to_categories that points to a category that exists for the products_id in question. Alternatively the sql query in admin/easypopulate_4_import.php at/around lines 256-258 be changed from/to something like:
from:
to (untested):Code:TABLE_PRODUCTS . ' as p, ' .
TABLE_PRODUCTS_TO_CATEGORIES . ' as ptoc,' .
TABLE_CATEGORIES . ' as subc ';
$zco_notifier->notify('EP4_IMPORT_PRODUCT_DEFAULT_SELECT_TABLES');
$sql .= "WHERE
p.products_id = ptoc.products_id AND
ptoc.categories_id = subc.categories_id AND ";
In this way, if there is/was a database problem with the other tables, if the item appeared in the products list, then it would at least be identified as being in the database. Note that commas in particular places have been removed, that additional text has been added as well (along with appropriate spacing to prevent text incorrectly being joined together and to remove constraints in the WHERE to ensure a satisfactory LEFT JOIN. I don't yet know what/if any other issues might result from this query change where information will be collected about product that do not have a matching or do not have an appropriate category.Code:TABLE_PRODUCTS . ' as p LEFT JOIN ' .
TABLE_PRODUCTS_TO_CATEGORIES . ' as ptoc ON (p.products_id = ptoc.products_id) LEFT JOIN ' .
TABLE_CATEGORIES . ' as subc ON (ptoc.categories_id = subc.categories_id) ';
$zco_notifier->notify('EP4_IMPORT_PRODUCT_DEFAULT_SELECT_TABLES');
$sql .= "WHERE ";
Note also, that the upcoming version update is being tested on PHP 8.0 and updated where necessary to address the associated additional strictness.
That's a lot of digging, thanks! I'm not comfortable testing the untested code on this live site. But I do understand the problem much better. I'll get back with my client with some options for him. I'll try again to convince him to use Model Numbers.
Model number won't specifically resolve the issue and is not specific to causing the observed response(s).Quote:
Originally Posted by jeking
Does the store perhaps use products_sku and applied a suggested implementation that was posted earlier in this thread? Basically, if search for EP4_DB_FILTER_KEY to see if it is used outside of the core files in the root of the admin, the extra_functions folder of the admin and/or the admin's modules folder.
Note for others, the plan is/was that if an alternate filter option were desired/to be used, then it be added to the selection list in the configuration menu. The earlier "add-on" was just that, an additional set of code to show that it could be possible and how it might be implemented.
The store does not use EP4_DB_FILTER_KEY nor products_sku. I appreciate the suggestions though. I'll remove them manually again.Quote:
Originally Posted by mc12345678
Long story behind this, but if I were to import into the products table with product_id that were not consecutive, would that be a problem? In other words, I might import product_id 5442, skip 5443, and then next use 5444.
Would Zen Cart have a problem with these gaps in the product_id?
My answer is based on say a "fresh" install where numbers are not being "recycled"... no, Zen Cart would not specifically have a problem with numbers not being consecutive.Quote:
Originally Posted by greybeard_it_guy
I should have added though, remember that the "world" (wide web) "knows" your product by specific products_id.Quote:
Originally Posted by mc12345678
Note that skipping a products_id is similar to deleting a historic (old) product. Generally speaking ALWAYS skipping a number would in a way effectively reduce the possible number of product in half, but, unless you have more than 49,999,999,999 of the maximum possible 99,999,999,999 products ever to be in the store (not necessarily all at once), this shouldn't be an issue. :)
I've just gotten the file ready to import about 40 products. It uploads fine and says it imported okay - no specifics. But the products are not importing. It has been a while since I've done this but what in the world could I be missing? All have product module numbers. I got all fields etc.
Let's revisit some basics and also get some info...Quote:
Originally Posted by delia
Version of EP4, is it the latest as published to this forum or from github and what is the reported version for that?
What is the filename for the file?
If looking at the file list for import, is there a reported problem for the delimiter or is the csv delimiter reported as expected? (likely a comma)
What is the setting in the configuration for the import language override.
What "ending" is used for the header of fields that are language dependent such as the v_products_name or v_categories_name?
version 4.0.37.13 - I downloaded from github but this appears to be what is in zc plugins. It does say there's a new version so I'm confused on this point.
updated_products-2021-05-10.csv
excel file - taken from exported original file. It has been majorly changed however
no reported problem
settings are default - no changes
and yes fields have the 1 on it
If default new install, then in the configuration options change the import override to something other than language_code_only...Quote:
Originally Posted by delia
As to the version response issue, I did not update the internal version to be 4.0.37.ZC so the ZC site's 4.0.37.ZC is "newer" than 4.0.37.13 based on the method used to compare. I have some more updates to push and will get this right in that submission.
making that change means the import worked. Thank you but why have a default that won't work?
Ahem.. It does work... When language dependent fields contain the appropriate information.Quote:
Originally Posted by delia
There are now four options in that list: language_id, language_code, language_id_only, and language_code_only.
Choosing either of the first two offers a preference... The preference is whatever is selected, but if it doesn't exist then the other is used. The two options ending in only will pull information from the import file *only* from the language dependent fields that have that identifier.
So.. It is now possible that an import file could have for example v_categories_name_1 and v_categories_name_en or it could contain either of these. But, the question becomes, when importing the file, which field should be used? Ideally, they would both contain the same information, but we all know that is not going to happen consistently. We also know that former users of this plugin have become accustomed to the _1 style. For those that have upgraded from a previous installation (say 4.0.36 where this feature was first initiated), the default was language_code even though that was not fully implemented throughout. Again, the idea was if _en existed then it would use that field, but if not, then it would attempt to use _1.
What really should have happened is that some level of notification be made about the situation. I thought that I had something for this situation, but based on the above report that does not appear to be true. Even after the extensive testing that I did, it seems I missed a portion of user response. Further it looks like I set the default export to use the 'id' so that leads to the issue you (and likely others experienced).
I previously had the import default to language_code so that if a file happened to use _en then it would offer preference to that field. Then in my testing, I realized that if one chose to delete the _1 column and had language_id set, it would still try to populate with the content of the field ending in _en.... Had some options... 1. Only "choose" between the two fields when both fields are present and ignore the other field if only one is present, 2) add a second set of options where data is populated only from the field type designated and to allow the preference with fallback option to continue/exist or 3) leave it alone and advise people to delete all occurrences of a field if it is not to be updated (I obviously didn't like this option because I didn't keep it that way).
For long time users, I expected that the configuration information and guidance would be helpful enough to change that setting as necessary, it was my goal for new users to be exposed to the language_code (though keeping/making the default export as language_id doesn't do that in the least).
So, like said a little before, need to provide another update, good feedback on the issue thank you.
Although not yet set in stone, my initial thought for this is to modify the default export to the language_code and keep the default import as language_code_only... Feedback/input?
I prefer default to simply work out of the box with a default cart. I appreciate the addition of languages but I have had only one client in 20 years who used more than just English and the one I did have ended up getting rid of it due to changes years ago. I don't know what the best situation is but the simpler the better always.
Fresh install of current latest version of EP says "NOTE: A NEW VERSION OF THIS PLUGIN IS AVAILABLE". I couldn't get the LOG_PLUGIN_VERSIONCHECK_FAILURES setting to work and I didn't have time to look at it further. The only thing I did notice is that the comment in easypopulate_4.php on line 102 references an old version number, but obviously this is not the root cause of the issue.
Cause of this is the discrepancy between the Zen Cart plugins reporting: 4.0.37.ZCQuote:
Originally Posted by swguy
and the internal software (admin/includes/modules/easypopulate_4_version.php) reporting: 4.0.37.13
4.0.37.ZC > 4.0.37.13 and therefore there is a "new" version, though it is the same software between the two.
Maybe I'm missing something, but I think there's a problem with version 4.0.37.13.
I cannot upload a 6MB file. The local php.ini is set to 16MB as shown: https://prnt.sc/13d0r6k
I don't know where the 2MB limit is coming from. This site had the previous version and we were able to upload files over 2MB.
The new version now takes into account the maximum file upload size of configuration->maximum settings: MAX_FILE_UPLOAD_SIZEQuote:
Originally Posted by jeking
Well, there I have it. Thanks for pointing that out.Quote:
Originally Posted by mc12345678
Hi Guys,
Just installed the latest EP4 from GITHUB on ZC v1.5.7b.
I checked the log files and found this warning.
I have searched the threads but couldn't find anything that directly relates.
Can you advise on how to fix the issue.
Many Thanks. :)
[08-Jun-2021 18:38:27 Australia/Melbourne] Request URI: /***/index.php?cmd=easypopulate_4, IP address: ***
#1 require(/home/***/***/***/easypopulate_4.php) called at [/***/***/***/***/index.php:11]
--> PHP Warning: Use of undefined constant EASYPOPULATE_4_CONFIG_IMPORT_OVERRIDE - assumed 'EASYPOPULATE_4_CONFIG_IMPORT_OVERRIDE' (this will throw an Error in a future version of PHP) in /***/***/***/***/easypopulate_4.php on line 686.
When say that "installed" the latest update, please elaborate.Quote:
Originally Posted by webmanstudios
While I recognie that it appears that the above will occur upon initial software placement and before the install is complete (something I need to address), that issue should go away after the software is fully installed. Meaning that the log will not be generated any more.
hi mc12345678, :)
I just checked the log folder and yes the errors have stopped.
Thank you for your reply. :)
I use product IDs that are a mix of letters and numbers. Totally not consecutive and have never run into a problem.
I'm sorry if this is mentioned somewhere in this post, but I can't find it.
I want to use EP to upload products to multiple SUB-categories.
So for example ... a comic book...same book needs to go into two sub categories...
The book: Marvel Comics - Captain America
By Publisher (Main top level Category)
Marvel (Sub-Category)
By Title (Main top level Category)
C (Sub Category)
I can't figure out how to do this, or IF it can be done, using the columns in the exported file.
Thanks in advance.
Each row of data will be placed in the category to which that row is assigned. A category is made of the root category followed by each sub-category of the previous category separated by a carat (^). So primary category of Marvel with a sub-category of Captain America would be represented by Marvel^Captain America. The category is placed in the column for your language identifier. A default install would use v_categories_name_1 or v_categories_name_en depending on your settings.Quote:
Originally Posted by LilleyPadGifts
To place a product in multiple categories, copy the row that is to contain the information about the product to a row below the previous and change the category name. Note, the last row that applies to the product will contain the data that will be inserted/updated associated to that product.
Something is not correct about the above statement or the system to which this is applied has been modified as compared to a default install of a standard Zen Cart installation.Quote:
Originally Posted by keith z
In a default Zen Cart installation, a product id is identified in many tables as an integer with up to 11 numbers.
My thought is that the term products ID in the above paragraph is in reference to a product model which is defined as a text (character) string and DOES support a mix of numbers and letters.
If I'm wrong, please let me know.
Thank you so much!
I edited my little test file and it tells me it imported ... but nothing is there.
I haven't worked on a zen site in so long... but its coming back to me S L O W L Y lol
Here is the sheet file ...
https://docs.google.com/spreadsheets...it?usp=sharing
Thank you so much!Quote:
Originally Posted by mc12345678
I edited my little test file and it tells me it imported ... but nothing is there.
I haven't worked on a zen site in so long... but its coming back to me S L O W L Y lol
Here is the sheet file ...
https://docs.google.com/spreadsheets...it?usp=sharing
I have done everything I can think to do.... I still get the errors below. I have categories set and created some that didn't exist. Still get the same error.
SKIPPED! - v_products_model: 2064 - No category provided for this new product
SKIPPED! - v_products_model: 2064 - No category provided for this new product
SKIPPED! - v_products_model: 1697 - No category provided for this new product
SKIPPED! - v_products_model: 1695 - No category provided for this new product
SKIPPED! - v_products_model: 0147 - No category provided for this new product
Please see this post: https://www.zen-cart.com/showthread....18#post1380718Quote:
Originally Posted by LilleyPadGifts
I made a mistake when setting the "new" defaults for this new version. I had good intentions, but...
I have read and re-read that post a million times just in the past few hours. I don’t understand where in the thread it tells us what to do for this issue when we have everything set as it should be. :(Quote:
Originally Posted by mc12345678
I have read over every thread that has this error mentioned. I hate that they make us put our questions all in one thread … it’s too hard to follow answers and important information.
the only thing I saw with a “fix” was a issue from years ago where they belittled the guy for asking for help and not reading. I AM reading and still don’t understand what the fix is.
Understand the frustration.Quote:
Originally Posted by LilleyPadGifts
So, because I know that an issue was introduced in the latest version, lets try to be sure that we are both on the same page. Could you ppost the settings for configuration->easy Populate 4. Obscure whatever you feel necessary. Its not important at the moment to know if you store your files in the admin or not, for example.
Then could you also include the headeing designation(s) for at least your category(ies) column(s) of the file being imported.
To also address the "belittlement", if it was myself, that usually includes a statement indicating some level of past or related history with the individual and in part to encourage growth... e.g., have previously worked with someone where they asked several questions that were explicitly written out in instructions of other modules. Once pointed out they say something like: ohhh! I didn't even think to look there.... and then the same "style" of issue occurs here with this plugin... so... yes, sometimes have to have "tough love" to help one through. We're already past that when I described the category separation. Because of the way it was asked, I had no qualms with offering the info that is/was in the instructions. :)Quote:
Originally Posted by LilleyPadGifts
I'm not sure if this is what you're asking for... but here is the link to my Google Sheet. The one I'm using is the tab that starts with COPY OF FULL....Quote:
Originally Posted by mc12345678
https://docs.google.com/spreadsheets...it?usp=sharing
As far as the other part of my comment ... I must have deleted part of it. I don't know who it was that responded to the person, but they told him that the reason he was getting that error is because he left the category column blank. That isn't the case for the issue I'm having. I have the categories filled in.
Access to that file is behind some sort of "permissions" based system. Reading it would only provide half of the picture. The other half is in the settings requested above.Quote:
Originally Posted by LilleyPadGifts
Try again please ... thought I had changed setting but guess I didn't give it time to save.Quote:
Originally Posted by mc12345678
So I've looked at the file. Nothing particularly "stands out"... Even with it formatted as it is.Quote:
Originally Posted by LilleyPadGifts
For the third and final time, though. Please provide the settings that are in the admin under configuration->Easy Populate 4. I can not help you if you don't help to make it possible to help you. If not providing that information, please explain why or what is not understood. Again, with the same comment.
Wow...Forgive me for not automatically knowing what you were talking about ....I thought I was giving you the info you asked for when I gave you access to the google sheets link... and I only saw it mentioned once.Quote:
Originally Posted by mc12345678
I have images of what the settings are in Admin/Config/Easy Populate. If this isn't what you are asking for please let me know. Obviously, I'm not PURPOSELY withholding information to get the help I need and am asking for.
Attachment 19617Attachment 19618
Perhaps also read the ever more detailed description at the post a little further down from that: https://www.zen-cart.com/showthread....38#post1380738Quote:
Originally Posted by mc12345678
That is exactly what was needed to close the loop.Quote:
Originally Posted by LilleyPadGifts
As previously (perhaps confusingly?) described (or attempted) in the above linked post, but reworded here:
In the list of configuration settings, starting from the top of the settings, please see the fourth option down that has the Title of: Import Language Override... For the file that was made available to peruse... Literally, change the setting to ANYTHING other than the current setting of language_code_only.
The file shows language related fields to be using the XXXXX_1 style...
If you click on that admin->configuration->Easy Populate 4 setting and look on the "right side" of the screen (bottom if using a mobile device): _1 references using the language_id whereas if it ended with the two letter abbreviation for the associated language (_en, _es, _de, etc...) then it would be fine.
But, by this particular setting being set to language_code_only, then the only language related fields that are recognized are formatted like v_products_name_en, v_categories_name_en, etc... (for english)... Again, I have apologized now at least twice already for my mistake and will again as necessary, but to resolve the problem occurring where a "categories name" can not be found (right now it is searching for v_categories_name_en), either the file must have a column with v_categories_name_en (or whatever language is being imported) or change the setting of the above to literally anything else...
Does this version allow for custom fields to be added?
As is/built, yes it still supports custom fields that are part of the products table. Haven't yet added the ability to cross reference fields within other tables. Additional code could be added (notifiers are used) to address other desired options.Quote:
Originally Posted by LilleyPadGifts
Quote:
Originally Posted by mc12345678
ok thanks.
I made the change in admin like you mentioned, uploaded the same file and it created the categories and sub cats but nothing the actually products. Didn’t create the page for them or anything.
Going to attack it again in the morning with a fresh brain but wanted to get this out here incase it’s something I’m just missing with a easy fix …. Please please please oh please :(:unsure:
Figured it out .... Status column ... nothing tells us what should be there. I read a post that said Enable/Disable. So I put Enable in that column :blush: ... its supposed to be a 1 to turn on that status.Quote:
Originally Posted by LilleyPadGifts
Is there a link to exactly how the custom fields work? Not sure if I'm going to need them at the moment, but I need the option for the other stores.
Thanks for your help!
I am going to make reference to a "previous" discussion. The instructions suggest exporting a file of the type that is desired to be used for import... Why? This way one can see what is already in the database. Knowing what the output is like and having some level of familiarity of the item(s) in the store, one *should* be able to see or through some level of testing identify the effect of the various fields...Quote:
Originally Posted by LilleyPadGifts
Mind you, I was going to ask how the issue was being evaluated... When saying that the page wasn't created, it helps to understand what "page" was being expected... I will note in relation to the latest post that the status field does not allow/prevent a product from appearing in the admin's products/categories listing... It *does* in general prevent the product from appearing on the catalog side (which, based on the above conversation, is likely what was being reviewed).
Now, as for the custom fields, access to the data stored and the ability to modify that data is what is provided. EP4 doesn't know what that data is, how it is used, or what basic value(s) it should contain. The instructions both in the plugin fileset as well as on the admin configuration page do indicate/suggest that when populating the configuration settings that the fieldname should be used, not v_fieldname. With the custom field information populated, exporting information associated with products should show that field name in the header of the file and (where information is provided for the field) it should appear in the resulting csv file. Again, how it is then used, populated, etc... that is up to the needs/expectations of the field and code that processes that field.
Put another way, EP4 provides (direct) access to data in the database. In some cases, the Zen Cart standard database field handling is incorporated (products_id is an integer, products_name is text, etc...) but there are also things that are not enforced on purpose so that the tool can be used in various configurations with minimal modification. For example, EP4 doesn't prevent a product being added to a category that has sub-categories... While that is a situation *normally* discouraged because of some of the still current core code design, it is not a requirement for store operation and further can be made possible.
Anyways, hope at least some of the above helps.
BTW, to what setting was the configuration option (language_code_only) changed?
Zen Cart 1.5.7
Easy Populate 4.0.37.13 - 05-03-2021
PHP 7.4 FastCGI
Exported a Complete Products download type file of one of my categories; used it for the template of a new CSV file.
I've tried importing both the original file that I exported, and the new CSV file that I made. The files are uploaded, but when I click the Import button, I'm taken to the Admin main page; no messages are displayed. Nothing is imported and there are no errors in the logs.
The temp directory (in Admin) has the two files in it.
I double checked that all the EasyPopulate files were uploaded.
What might I be doing wrong?