Thanks MC will try that. Guessing it is some setting somewhere because was happening before I downloaded IH4. Added IH4 hoping to fix problem but it didn't. Zencart is 1.54 :-)
Thanks for your help. :-)
Printable View
Thanks MC will try that. Guessing it is some setting somewhere because was happening before I downloaded IH4. Added IH4 hoping to fix problem but it didn't. Zencart is 1.54 :-)
Thanks for your help. :-)
I'll also try to take a look at how images are prepped for saving when using ZC 1.5.4 to see if there is anything further, but really my suggestiion in keeping with good filenaming principles, is that the file itself should be stored in all lowercase, no spaces, be named uniquely (folder(s) used as necessary) so that don't overwrite another image or have an image appear as an extra image to another product (see applicable FAQ for images). Then the EP4 file should contain the matching information for the main product image. All subsequent additional images will display as setup for your cart.Quote:
Originally Posted by Amethyst_fairy
The link to the plugin as requestedQuote:
Originally Posted by mc12345678
Well after running all around to get to the file, the instructions (README.txt) provide the instructions necessary to 1) install the plugin (SQL statement needed to be executed) and 2) then the field to be added to the user defined fields section: products_costQuote:
Originally Posted by adb34
This information is now carried from EP4 to the admin and back while using EP4...
So I dug a bit into the code for a default zc install and didn't see anything that renamed a file to be all lowercase. It toys with it for comparisons against strings, but didn't see anything that modifies the string...Quote:
Originally Posted by mc12345678
What did you discover with the test/process used? I know I tried to access the problem images using all lowercase letters and the server responded that the file wasn't there, so also wondering if there is something else installed or otherwise affecting the process (other plugins). Because IH4 is activated and uses the older hash function, I am not able to tell how your previous images were identified to offer further review/comment.
Hello
Newbie here , so i apologize if its something obvious for the gurus.
This is not my first shop, but it is my first zencart.
I have a "clean" install on dreamhost and it is up to date.
I manged to get the plugin working.
When i try to upload i get an error, i searched the forums, but did not find anything similar,
and looking at the logs i see.
But i cant find a way to get thru it.Code:[17-Feb-2016 17:42:44 America/Los_Angeles] PHP Fatal error: 1062:Duplicate entry '2-1' for key 'PRIMARY' :: INSERT INTO misolproducts_description SET
products_id = '2',
language_id = '1',
products_name = 'FORMATO \"REQUISICION\" 500 PZAS',
products_description = 'FORMATO \"REQUISICION\" 500 PZAS',
products_url = ''
==> (as called by) /
please advice. all pointers and suggestions are greatly appreciated.
Well, welcome to Zen cart? (I say that because you've been a member since 2009, but just now making your first post. :)Quote:
Originally Posted by agidi
As such, any time an issue is being described, well there needs to be more of a definition.. And such a description should not require being asked for.
So, that small formality aside, I need more information... A lot more information..
1) ZC version?
2) File name being used for import.
3) File type/fields included.
4) settings in configuration->EP4 (In particular related to what type of primary key is being used.
5) at this point, how many products have been entered/imported and associated products_id.
6) what was used to create/modify the CSV file?
Anything else that can be considered to possibly resolve/understand this issue, perhaps the datafile that is being attempted?
Forgot to also ask, what version of EP4?Quote:
Originally Posted by mc12345678
Thought I posted this over 6 hours ago, but I guess not....
Well, based on the error message content I can tell that not using EP4 version 4.0.32 (or higher)... Other than that, I don't have a specific clue at the moment what is causing this issue. Can only suggest upgrading to the latest ZC version and associated software.
Hello Again,
I have a similar problem, however mine is not related to character length. When importing with EP4, new products are not appearing, yet in Zen Cart in Category/Products, it displays that there are multiple products active yet they don't display. After looking at my SQL Database the new products are there and displaying all the imported data except for "product_name" and "product_description". For example if the new product I imported has products_id 5, there is no data for the two fields in question, obvious why they don't show up in Zen Cart. What am I doing wrong?
Okay, so now that I've gone back to identify what version of EP4 has possibly been installed (assuming still EP4 version 4.0.32 on ZC 1.5.4) the questions posted above apply to this issue as well... What filetype was trying to be populated, what was the filename, what are the headers in the csv file that was imported, and what is the text for one or more of the product that. Are not showing up, what are the admin settings for items such as what the primary_key is (assuming the default being products_model), are these new product or is data being removed from existing product...Quote:
Originally Posted by allmart
In otherwords need enough information to reproduce the issue and/or possibly identify if something in fact was being done incorrectly.
Sorry, Easy Populate 4.0.32 on ZC 1.5.4.
csv file below:
---------------------------------------------------
v_products_model,v_products_type,v_products_image,v_products_name_1,v_products_d escription_1,v_products_url_1,v_specials_price,v_specials_date_avail,v_specials_ expires_date,v_products_price,v_products_weight,v_product_is_call,v_products_sor t_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_1,v_tax_class_title, v_status,v_metatags_products_name_status,v_metatags_title_status,v_metatags_mode l_status,v_metatags_price_status,v_metatags_title_tagline_status,v_metatags_titl e_1,v_metatags_keywords_1,v_metatags_description_1
AR695GR,1,AR695GR.png,Arizona Grapeade 24x680ml Can,24x680ml Can,,,,,17.99,39,0,0,1,1,0,0,0000-00-00 00:00:00,0000-00-00 00:00:00,100,Arizona Beverages Canada,Cans Non-Carbonated,Taxable Goods,1,0,0,0,0,0,,,
---------------------------------------------------
msg after import:
--------------------------
UPDATED! - Model: AR695GR | 1 | AR695GR.pn | Arizona Gr | 24x680ml C | | | | | 17.99 | 39 | 0 | 0 | 1 | 1 | 0 | 0 | 0000-00-00 | 0000-00-00 | 100 | Arizona Be | Cans Non-C | Taxable Go | 1 | 0 | 0 | 0 | 0 | 0 | | | |
--------------------------
filename: Book1.csv
And that's the file in it's entirety? Did that model number previously exist or was that a new product?
No, it is not the file in it's entirety, I just wanted to give a short example. It is a new product.
If you can hang with me just a moment longer, I'd appreciate it. Does the file have the same v_products_model in it more than once? Also, to confirm you are receiving the same error in the debug.txt file as identified on the previous page?Quote:
Originally Posted by allmart
I changed some code to try to allow not having to include a few fields in the import file and I believe that was done incorrectly which is causing the issue identified by you and on the previous page. It is also why I haven't updated the code that is referenced in the first post of this thread. So that I can be sure to ferret out the issue, I would like that information.
Until I resolve the issue created in version 4.0.32, there is an older version that is fully functional (minus the additions made since then) from following the link in the first post of this thread... Your help in this matter is appreciated. I know this tool s helpful to many and am tryiing to make further improvements and keep it functional.
This is the error I found in my log directory:
[19-Feb-2016 08:04:51 America/Phoenix] PHP Warning: Invalid argument supplied for foreach() in /home/content/x/x/x/xxxxx/html/store/xxxxx/easypopulate_4_import.php on line 1908
and no the file does not have the same v_products_model in it more than once.
I will downgrade to the older version as suggested.
Thanks for your help and prompt response.
Please provide the link to the older version, thank you.
Actually, just took a look and thank you so much for looking in the logs directory for that error. The problem on lin 190x is the use of $languages instead of $langcode...Quote:
Originally Posted by allmart
So easiest way to fix this would be to open admin/easypopulate_4_import.php with a plain text editor.
Search for $languages.
Replace with $langcode.
Issue should be resolved.
I'll be updating github momentarily with that change.
Excellent! it works.
Thank you!!!
Thanks for the update. Github has been updated with that code correction for EP4 version 4.0.32.Quote:
Originally Posted by allmart
Just discovered this error after importing a file with a product that already exists:
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
ep_debug_log.txt:
MySQLi error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ':products_name:, products_description = '24x680ml Can', products_url = '' ' at line 1
When executing:
UPDATE products_description SET products_name = :products_name:, products_description = '24x680ml Can', products_url = '' WHERE products_id = 1 AND language_id = 1
The above lines are repeated in the log multiple times for each product_id
Importing new products alone works perfectly.
When posting code, please use the # button in the messagebox toolbar to create [CODE] and [/CODE] tags so that weird things don't appear in the posted message and believe it or not it is actually easier to read the result. But... in this case doesn't matter much.Quote:
Originally Posted by allmart
That would be because on line 1933 iswhile on line 1946 isCode::products_name:
Intention was for line 1933 to have :v_products_name: so that the code might seem clearer to understand. :)Code::v_products_name:
So, again, open admin/easypopulate_4_import.php search for:
replace with:Code::products_name:
and it will/should work.Code::v_products_name:
github is already updated based on the above report.
Fixed...Thanks again!!!
No, thank you. Wish there wasn't a need, but keep the comments coming as identified. While not everything will definitely be included as requested, at least attention can/would be provided. :) Nice to have a fresh set of eyes to offer input.Quote:
Originally Posted by allmart
HI there,
I am trying to work out how to add my products via Easy pop 4, I have added 1 x product with the attributes i require through admin and downloaded the CSV file for the attibutes, I then tried to add another product using the CSV however when i goto import the file it comes up with SKIPPED! - Attribute Entry on Model: dk_0601k0116 - Not Found!. I am only adding the products to the Attrib-Detailed-EP2016Feb24-001019 file, should i be edditing other CSV files as well??
Anyhelp will be fantastic as i have around 2000 products to add with different attributes and through admin will take a very very long time
Thank you in advance
Glenn
Again, welcome to ZC!Quote:
Originally Posted by decalman
So with regards to this issue and the way EP4 works. As you have found/desire, entry of multiple products in a single "swoop" is easier with this plugin. That said, it still "follows" the same process. First the product must exist, and as part of "creating" the product, it must go into a category. Then, to apply attributes, the attribute(s) must exist (attributes basic), then the product is populated with the attribute(s) (attributes detailed). In each step that relates to a product, EP4 generally requires a unique model#; however, with EP4 version 4.0.32, it is possible to relate product by the products_id when the admiin configuration settings are "properly" set. A word of note/caution though is that it also depends on how you plan to use/automate EP4. If your import information will be from a vendor iin the form of some other file, then purely using the model# (or possibly some other field as recoded in Ep4) would be suggested. If the data to be imported will be "self generated" then use of the products_id might be more suitable. For those that don't yet have a model# associated, the same feature can be used to apply one to the product.
Help any?
Thank you sir, makes sense ( Sort of ) So in short, add the attribuets in the basic version then once complete get the advanced attibutes and set my prices?
Not quite based on the error message of the original post.Quote:
Originally Posted by decalman
Add product,
At some point before assigning attributes to a product add attributes (attribute basic)
After product exists in database assign attributes (attribute detailed).
If continuing to experience difficulty with the code not permitting this to occur, please identify current version. Being used of EP4.
Product can be added by any file that doesn't begin with the predefined filenames. The suggested method is to use the full product link to obtain a valid file format then can modify it to suit for upload.
I have zencart 151 with easy populate for 15x.
It works great but I have Canadapost module and would like to add dimensions to my packages.
So I created v_products_weight v_products_length v_products_width v_products_height in my csv.
Run the file:
UPDATED! - Model: Vineco010 | Pinot Grig | 10 | 69 | 69 | 69 |
UPDATED! - Model: Vineco030 | Cabernet R | 18 | 69 | 69 | 69 |
UPDATED! - Model: Vineco034 | Merlot Was | 18 | 69 | 69 | 69 |
Upload Complete
So everything seems ok, but no, the lenght width and height did not update the weight did.
I can see the values in my products sql database. Not sure what I am doing wrong or if easy populate can do this?
Any help would be greatly appreciated.
Not sure when you say easy populate for 15x if you mean this version of easypopulate, or one of the others. If you have EasyPopulate v4 then yes the user defined product fields requested above can be imported (as well as exported) with one minor admin setting adjustment.Quote:
Originally Posted by lukaswlu
In the configuration settings for EP4, there is a user defined field option. Add to it: products_length, products_width, products_height
Try exporting the product information file, for product where this is already defined, the values should be present, for others they will be either blank or 0.
Then on upload of a file with those fields listed, if the fields are present the data ought to be updated/inserted as applicable.
Where do i find this configuration setting for ep4? I have nothing in my configuration menu.
My version just says "Easy Populate For ZenCart v1.5.x"
I think I need to upgrade?
As one who has worked on this version of EP, I am inclined to say yes you do, but... That also is selfish. There are/have been multiple versions of EasyPopulate, each doing something slightly different, or perhaps upgraded for one version of ZC or another. I believe that this one has taken most of the features of other versions and provided a broader product. Could be wrong, certainly have received some suggestions for improved user interface, though this is pretty much a pet project for me. I just happened to see the value and that I could do something to keep it alive and so jumped in.Quote:
Originally Posted by lukaswlu
Anyways, the latest version is available at: https://github.com/mc12345678/EasyPopulate-4.0 or a slightly older version (soon to be replaced by the version referenced left) can be found at the first post of this thread.
EasyPopulate v4 clearly states the version information on the upper left admin screen area when accessed, so I would say that the version obtained is from a different thread/area.
First let me say that this may be my database. I saw a couple of hinky things earlier today, but thought it worth a shot looking for the answer here. If this has been addressed before I apologize. I did search and read, and search and read, and se.. well you get it.
I am using ZC 1.54, EP 4.0. It has worked as expected for everything so this threw me. Adding one attribute to all products in spreadsheet, except 6 that would have been the same with no update.
Uploaded/Imported Attributes Basic, reported "Imported with Issues". I recognized the issues because I had used an old spreadsheet to grab my model numbers and a few of those had been deleted, so no biggie. All others say "updated". None were updated.
Quote:
Originally Posted by fwood
Well, glad to hear that you've been using this for a while. Mind identifying which version of EP4 is/was being used?
Please verify/identify the filename (do not need/nor want the path, just the filename).
Was the "issues" log cleared after addressing the first round of issues/what are the contents of it now (can be scrubbed if necessary, just want to know about the condition of the code).
Perplexed at the same time not being sure if I fully follow the steps taken/verifications made, etc... Hope to resolve quickly though.
Ok I upgraded to the new version and it works perfect, thanks for all the help.
I think my old version was from 2009. 1.2.9???
Glad it works. Mind identifying which version you are currently using?Quote:
Originally Posted by lukaswlu
Sorry, I haven't kept up with the history of each of the different versions to be able to fill in details of the differences or anything. But am glad it's working. Now to just address fwood's issue...
Hi,
How do we bulk import a list of manufacturer using easy populate? What specific field names are needed in the file? Thank you.
From the products table manufacturers_id (auto-generated) which cross references with the manufacturers table on a one-for-one basis, which links to manufacturers_info table on a one-to-many basis primarily because of the different languages available for things like a multilingual manufacturers_url.Quote:
Originally Posted by waterbender
There is a little of this already included, but not the whole thing and with 4.0.32 it is easier to add such info into the operation than before. Basically haven't seen the request really before so hasn't been added fully...
Other than starting with Model No -
1. are there other required fields (as in can I leave some out of the spreadsheet)
2. is there a "mandatory" order for the fields with information to be uploaded
Thank you for any help you may be able to offer.
P.S. we have successfully added the filed for UPC code but there are some others unique to most product lines we would like to include and a csv file with fewer columns would be much less cumberson
Quote:
Originally Posted by wheat
So, for the most part, this somewhat depends on which of the two currently supported versions you decide to download. The primary thread in github for this module has not yet been updated with the latest beta because there had been some issues identified with the changes that were made. The version referenced by the first post of this thread which is EP4 4.0.29 does require some additional fields to remain in place for certain items to be updated and it only supports using Model No. Version 4.0.32 (which in supporting another developer to add bookx product type management has required a few additional notifiers is to soon be updated to 4.0.33) is located by reviewing the last few pages of posts on this thread *should* allow updates for only the fields that are provided when imported and also now also supports the use of products_id and/or products_model, this aspect remains in review and if/when found to be otherwise functional please comment.
Another update to 4.0.33 is expected to help the store operator a little when entering the path to the file storage area. In times past, EP4 would accept storing a path from the store's base file location in the database, regardless of whether it was a path to the admin directory or somewhere else. Unfortunately for EP4, even ZC doesn't store information in the database about the admin directory path, so I saw it necessary to follow the same vein and to identify a way to not add the admin path to the database. At present though, the path could still be entered contrary to direction/request. So, I've found a way to "automatically" rework the indicators when EP4 is accessed but am looking to move that action up to the point of initial data entry instead.
There is absolutely no sequence necessary for the fields that are included other than I believe there should not be any missing field headers between columns... Haven't tried it, don't know what would happen. :) If you happen to have Stock By Attributes installed, I can say that there was some consideration into the sequence of the columns generated for upload to minimize the likelihood of an inadvertent change being made to the data that could cause a bad import, but sequence is still not required.
Now, all *that* said, if you have taken some time to read through the documentation or installed the application, you would have seen that there are some filenames that are "triggers" or do specific actions. For example a specials file causes different operation than a full product file. This has to do with the internal tables and ties between data and the tables. One thing that has made EP4 a bit of a powerhouse is that the queries and data are focused on the task rather than having large queries with lots of data. Your extra product table fields can be added and should be processed as discovered in the data file.
Pretty much the second I hit Post - i realized I had not included version details - my apology - circumstances did not allow me to "fix that"Quote:
Originally Posted by mc12345678
Thank you for your response, it will be helpful.
Wheat
That's no problem, I realize you're shopping around to find the application that works for your situation.Quote:
Originally Posted by wheat
I really look forward to posting this as a plugin although chadder and I have spoken about and begun a more html related documentation. It's been several years now in the making of that and to be honest, with the other questions that still arise routinely, it doesn't seem like it would make much difference as in most cases (I wouldn't necessarily say that those you have asked directly apply) the answer is in the existing documentation.
I have a few things that would help tie the process together like posted in the last couple of pages, but I think that 4.0.33 will be a good kick off point for that. Then the bookx addon will be able to follow suit. It's incorporation is nearly complete, there's just some other things that are being worked on to make it a better middle step between manual entry and bulk upload...
Recommendations on how to get a sample file?
I always love this question.Quote:
Originally Posted by outeredge2
Export something from your database. :) no better sample than what comes out. :)
I am using version Easy Populate 4.0.32 - Beta 12-30-2015. Where does CURRENT_TIMESTAMP get it's value from ? When I leave the v_date_added field blank the product shows "This product was added to our catalog on Tuesday 30 November, 1999." If I export the products in Easy Pop I see 0000-00-00 00:00:00 in v_date_added
Henry
Well, blank is 0, if wanted. Now. As the value that would/should be supported though it may not now be supported because of the rewrite to use bindVars, I'll have to take a look. The other factor to consider though is in fact how to handle having the date field in the file with a blank entry. Btw, what php version is being used in this situation?Quote:
Originally Posted by henry3
Also, although both need to be addressed, was this an insert or an update?
It was on importing a new product. PHP ver 5.5. I would assume if the date is blank in the import file it should default to current date, which is what the code appears to be doing. I assume CURRENT_TIMESTAMP was a Zen Cart global at one time ?
Henry
CURRENT_TMESTAMP actually is a mysql constant. One problem though is that because the field is present, the value of the field overrides the "internally" generated possible value. The other issue is that a "blank" date time should be 0001-01-01 ish. Not all 0's. That was corrected for a different condition elsewhere but not this one.Quote:
Originally Posted by henry3
It's also odd if I put a value 2016-03-01 09:00:00 in v_date_added, it doesn't show up, but the same value in v_date_avail works correctly. If both values are filled, the v_date_avail doesn't import either.
Well a date avail in the past even in a product info page acts "oddly" but when reviewing the history it makes sense... The field is intended to prevent the product from being displayed until the date available has passed then it "clears" the field. I forget if it wipes it or sets it to 0001-01-01 or not. As to the "proper" usage of the populating a date I'll take a look. Was this again an insert evolution or an update? Also, is it sure that the entry hasn't caused or is associated with having a linked product? I'll be ndependently testing either way, but might explain some of what is/was seen.Quote:
Originally Posted by henry3
I was importing new products on my development site. The work around is just to put the current date in v_date_avail and leave v_date_added blank
Ahem... What about the more obvious, don't include the current date field?Quote:
Originally Posted by henry3
If I leave both date fields blank on import the product page shows "This product was added to our catalog on Tuesday 30 November, 1999." The table shows products_date_added 0000-00-00 00:00:00 products_last_modified 2016-03-02 18:53:47 products_date_available 0000-00-00 00:00:00
I didn't say leave the row blank, I said completely don't include the field. The entire column. No column, no data from the spreadsheet to do anything with, default coding takes over...Quote:
Originally Posted by henry3
I deleted both date columns,made a new record, and date added and available still show in the database as all zeros
I believe 4.0.32 has been fixed... A combination of things between using bindVars to generate a string (adds quotes around text) when instead it was occasionally desired for it to not have quotes, blank data in some cases was allowed to be all 0's instead of the ZC "empty date", etc.. The few lines needing to be corrected in the import file have been adjusted... To obtain the specific changes, can goto: https://github.com/mc12345678/EasyPo...13db201c774f5fQuote:
Originally Posted by henry3
I think this was happening to me too. But my situation is a little different cause I'm making changes as you know, so I haven't payed much attention to that, because It's another product type, and didn't know what was doing what.
I actually posted my doubts in bookx thread in #post1304799
But then for some reason things start working, but I read this and looking now at some exports files all I got 0000 too. So I didn't quite understood if this was happening on admin product insert, or in the imports / exports.
As I said, just saying that I've seen this, but it's not very relevant has I'm messing around with ep4 ad database a lot, and haven't tested only this field.
I believe when importing the products ordered qty's are being reset to zero. I used this module a couple months back to import some custom fields and just noticed these were reset and I did not reset them. T compared to a backup from before I did the import and the only different between my active database file and the backup are the fields I imported.
Nope it was a real thing resulting from the switch to using bindVars and not properly incorporating the "alternative" data 1) the constant was being turned into a text statement rather than presented as a sql constant, 2) 0 was entered as the date entered instead of the ZC 0001-01-01 which was a condition of this software from original development. Both situations ought to now be addressed in 4.0.32 or by applying the patch referenced above.Quote:
Originally Posted by mesnitu
Not sure I understand the results that are being described. Ordered quantities as tracked by default ZC are in no way touched or addressed by this plugin. That data is collected from the orders table and there is currently no facility to write to that table or any related table.Quote:
Originally Posted by marcopolo
Now on issues with user defined fields, I was going to look at how the code responds if the user defined field is present, but the field is not identified in the import file just to validate that the row data for that field is not modified, but there is no control if the field is present in the import file and the user has decided to leave the field blank. In that situation the code would work as expected by updating the record to be blank as it is/was in the import file.
So, could use a little more clarification of the perceived issue in order to provide a solution either by code or direction.
I'm using Easy Populate 4.0.30 - Beta 06-27-2015
I define the following fields in admin setting in Easy Populate:
User Defined Products Fields: products_ordered,products_length,products_width,products_height,products_ready_t o_ship
I exported Complete Products (with Metatags) then removed all but either id or model forgot which is required and the defined above and imported back with the defined fields populated as I needed them to be. That's all I did which I believe reset the quantity ordered as I described.
[So, here is what I understand in “date” order and therefore remain perplexed if there is an issue or not:Quote:
Originally Posted by marcopolo
At point A a backup of the database was made.
At point B an export was made, the file modified to only include the primary reference key and user defined fields that were to be updated with whatever was in the import file.
At point C, the import file with the primary key and user defined data fields was imported causing the product identified by the primary key to be updated with whatever was present (or “absent”) in the user defined fields. The data for each field had been updated as desired/requested and all fields were present in the file. This included a field called products_ordered.
At point D (call it today), a comparison of the live database to the backup made at point A shows that everything is the same except for the data that was stored at point C. But the data in the products_ordered field is now zero instead of the quantity identified in the file at point C.
So question(s) are:
1) Did the import file at point C actually include the products_ordered field or not?
1.a) If it did, how do the values identified there relate to what is/was in the database?
2) If you were to again upload just a single row of data that included the products_ordered field and information for that field, what happens to the information of that product and field?
3) When uploading are the user defined fields still present even when the involved import file doesn't have data for the applicable field?
I think it's working now. I just did a quick import test. I'll test further.
Thanks - Henry
Glad that at least appears to have it working. Please do report test result/issues.Quote:
Originally Posted by henry3
OK I just tested to confirm the issue and it DOES delete the products_ordered.Quote:
Originally Posted by mc12345678
Here is want I did to test:
In phpmyadmin I modified the products_ordered for two items entering 100 for each. I saved and verified it was populated.
I then imported a csv file in EP, see below:
v_products_model,v_products_length,v_products_width,v_products_height,v_products _ready_to_ship,v_products_quantity
10,9.5,3.5,3.1,0,5289
20,9.5,3.5,3.1,0,5766
Import was successful but when I went back in phpmyadmin the products_ordered on both items were 0
So indication here is that if a user defined (custom) field is identified in the admin, then if the field is not included in the file it will be treated as being blank and therefore cleared of it's value. Further, until this issue is corrected it would be advised that a custom field not be listed in the admin field unless that field is to be modified by an import...
Yes that seems to be the issue would you like me to test again BUT without the products_ordered field in admin?Quote:
Originally Posted by mc12345678
Just tested again without the products_ordered in admin and it did NOT delete the products_ordered this time so yes confirmed that is the issue.
Quote:
Originally Posted by marcopolo
Looking at a remnant of code in the import file it appears that I had begun adding the protection to prevent the issue you were experiencing. Looks like that needs to be completed/rectified still.Quote:
Originally Posted by marcopolo
The goal being that the custom field could remain populated, but the data not cleared if the field is absent from the import file.
FYI, I believe I fixed the above problem, but still need to upload the changes to github... Wanted to run a couple more tests as well. Did find that the solution for the date/time issue was partially incomplete as I found cases of 0000-00-00 00:00:00 entered for the date_available related field instead of NULL, but at least it doesn't "seem" like it causes a problem by being there... Still to be incorporated/updated regardless of what it "seems". :)
Have pushed version 4.0.33 to github at: https://github.com/mc12345678/EasyPopulate-4.0
Here is the changelog:
Quote:
4.0.33 02-29-2016 Added a filter to prevent custom field entries from being overwritten on import if
the import file doesn't include the field. If the field is in the import file,
but the data for the row is blank, then the data for that field will be cleared. If
the field is not present, then any data that exists for that field will remain
intact whether the admin->configuration->Easy Populate 4->User Defined Fields is
populated or blank.
Added some "folder" functionality to force the selection of the import file being in the
admin directory if catalog was selected and the entered path really points to
the admin directory. This functionality occurs in the configuration window as
well as when accessing EP4 for any operation.
Removed the bypassed code in admin/includes/functions/extra_functions that previously
was used for export formatting. This code was incorporated into a module file
in 4.0.32.
Added notifiers throughout to support extending the code to support other bulk related
data. Specifically targeted bookx.
Corrected the use of importing date_available and date_added as this had been affected
by use of bindVars without consideration of potential values.
Added a .htaccess file that only includes permission for .csv and .txt files based off
of the admin/.htaccess file available from ZC 1.5.4.
Updated instructions to add some additional considerations.
EasyPopulate v4 4.0.33 has been submitted to the ZC forum as a plugin that if accepted can be found at https://www.zen-cart.com/downloads.php?do=file&id=2068
In an upcoming version would expect to add version checking based on that file location.
Thanks for the update. I don't know if anyone else would be interested in having you adding an ISBN to the supported mods. I just copied the code from the UPC mod and used v_products_isbn and inserted it right after the UPC mod. Just a fyi you can also use <FilesMatch "(?i).*\.(?i:csv|txt)$"> in the .htaccess
So I can't recall where I had seen ISBN "incorporated", I thought it was in the german version of the program and I had done some form of research on it to see what was expected/proposed or something and thought that there was some idea to "remove" it, but I certainly wouldn't hang my hat on that. :PQuote:
Originally Posted by henry3
It is the relative "simplicity" of this plugin that has the ability to do so much/save time that has kept me with it. As can be seen it is relatively easy to add other "supported" mods to it. Even without the "support" indication, having the user defined field populated with products_isbn is sufficient to "support" the mod.
Must say "What a GREAT addon.. set up my zen cart with over 4500+ products in under 3 hours converting an xml feed from my supplier.. saved me weeks of work.....
question.. if I need to update product descriptions can I do it with a csv using just the v_products_model and v_products_description_1 ....and have nothing else change in the database???
That has become the expectation (if using version 4.0.33+). Version 4.0.29 may be able to work that way, but I can not recall at the moment. As suggested, backup the database before trying, then if it doesn't work, post here and restore the database. As always suggested such "new process" attempts should be tested on a development site first, then when proven good to use on the live site.Quote:
Originally Posted by hivtop
If it doesn't work, it will not work in a major way that will be obvious, like all product_names being blank. But, other data, like price, quantity, etc. Ought to remain untouched/unmodified.
Do remember that model # must be unique, otherwise the last version of the text will replace any previous for that model #.
The link did not work. Is there another link for the updated download?Quote:
Originally Posted by mc12345678
Absolutely, it's posted several times throughout this thread in the last several pages, if you're familiar with github, then one could find it by following the link on the first page, and the reason that the above link doesn't yet work is that the plugin moderator(s) haven't yet approved EP4 for it's first release as a ZC plugin. All in due time.Quote:
Originally Posted by katrobb
As for a directish link to download that current version, https://github.com/mc12345678/EasyPopulate-4.0.
Just installed the latest version Easy Populate 4.0.33 - Beta 02-29-2016
In admin when I goto Tools/Easy Populate 4
The below error gets logged:
[11-Mar-2016 19:34:24 America/New_York] PHP Warning: in_array() expects parameter 2 to be array, null given in /var/www/zencart/includes/functions/plugin_support.php on line 42
I would expect that to be because the plugin has not received approval yet. Therefore. The code as written for plugin_support receives null when trying to reach that download location and that. Throws off the code... A little surprised that condition isn't directly addressed, but having it logged. Does at least provide the store owner with some information to investigate.Quote:
Originally Posted by marcopolo
Ok thanks for the quick reply, hopefully it gets approved soon it's a great mod!
Had reached out to the software approvers earlier this week, been busy, but is on the list for review (and as necessary comment). I partially expect concern about the query method not consistently using the ZC standard queries, but in a large majority of cases it is so that error handling is "on-screen" rather than in a tucked. Away. File/folder. But hopefully will receive either feedback or see it approved soon.Quote:
Originally Posted by marcopolo
I imagine they are so busy with 1.55! But congrats on getting to the submission phase. Finally be able to take "beta" out of the name!Quote:
Originally Posted by mc12345678
And thanks again for picking up the project and keeping it alive with your additions and support. I would have hated to see it fall to the side since I've been too busy to continue supporting it.
-chadd
Dang straight. :) there actually is a little bit of submission confusion at the moment. It *is* posted in the plugins, but there are a few administrative things to rectify, but all in good time. :) I will say that without either posting a yet more updated version or help from the software team that the version checking portion isn't going to work right at the moment. I expect to hear back on that in the next day or so and will take the next appropriate action.Quote:
Originally Posted by chadderuski
There likely remains improvements on things like instructions that can continue to be improved, but it's gotten this far with what exists. :) glad to see that you're still around. :)
Heard back... Suggestion is to resubmit to the existing location with the update(s) desired/necessary. Current plan is once at an appropriate computer to package up what is now 4.0.33a and submit. Current change is simply to the download location which is https://www.zen-cart.com/downloads.php?do=file&id=2069. Been going through the issues posted in github to see if there is anything that can be addressed relatively quickly as well to maybe offer a real version modification, but for those that have downloaded 4.0.33 and would like to receive notification of an updated version submitted on ZC, open admin/easypopulate_4.php, goto line 84 and change:Quote:
Originally Posted by mc12345678
to:Code:$new_version_details = plugin_version_check_for_updates(2068, $curver);
Otherwise, depending on your version of ZC, an error may get logged as a result of no file data existing on the other end of the query.Code:$new_version_details = plugin_version_check_for_updates(2069, $curver);
I just installed EP 4 into zc 1.5.5, running on my windows pc with xampp. everything works fine until i try to download a generated file in the temp folder. I get this:
https://localhostdir_ws_https_admint...r19-030356.csv
Anyone know why and if there is a fix?
Thanks in advance.
I just installed EP 4 into zc 1.5.5, running on my windows pc with xampp. everything works fine until i try to download a generated file in the temp folder. I get this:
https://localhostdir_ws_https_admintemp/Full-EP2016Mar19-030356.csv
Anyone know why and if there is a fix?
Thanks in advance.
That is intended to be generated by combining several parts of the definitions in the admin/includes/configure.php file (or possibly in the admin/includes/local folder if so used...Quote:
Originally Posted by wtashby
It would appear that DIR_WS_HTTPS_ADMIN is not defined on the admin side and that the page is loaded while using https:
As for use on ZC 1.5.5? Well, hasn't been tested yet, though was just about to do so.. Problem is that the current ZC 1.5.5 setup that I have is experiencing a problem that I have yet to be able to explain but it nearly seems like it is related to a database that I upgraded from 1.3.8 to 1.5.5...
So, it may be that ZC 1.5.5 doesn't have that definition... If that's the case, possibly an easy fix... But more to come in the next day or so...
Temporary solution as posted here is to set ENABLE_SSL_ADMIN to false and as desired for the admin website definition either use or don't use https... Will have to incorporate something as I was really hoping to prep/verify prepped this software for ZC 1.5.5 in its entirety...
This is still being generated even though it is now approved and available in plugins?Quote:
Originally Posted by mc12345678
Approval in the plugins was for up to ZC 1.5.4 and there is no issue when used in that environment.. Had not been tested on ZC 1.5.5. I'll be looking at how this is reproduced and a resolution to maintain functionality for both the current ZC as well as versions before ZC 1.5.5.Quote:
Originally Posted by marcopolo
Oops, right answer to the wrong question.
The patch is available above requiring a change in one line.
I haven't provided the plugin management team with the corrected file. Until I do my part or the above mod is made, the issue will persist
I'm still on v1.5.4
Sorry, perhaps you noticed that I answered the wrong question related to the release of the plugin to the ZC site. I would say that I did a lot which caused the issue, so in my opinion it's on me to correct. The approval team did their part even though some admin issues remain to be completed.Quote:
Originally Posted by marcopolo
As referenced above see post 2285.
Got it I missed that post, I changed it as you outlined to:
and it works now without generating any error log.PHP Code:$new_version_details = plugin_version_check_for_updates(2069, $curver);
Quote:
Originally Posted by wtashby
Perhaps a rehash, but the real why is that in ZC 1.5.5, the admin configure.php "structure" was simplified and the DIR_WS_HTTPS_ADMIN define was removed... It is now expected that the admin "path" will be either all http: or all https: as set in the admin/includes/configure.php file. I have made some code changes and haven't been able to test them yet, but if you could take a look at the master path of https://github.com/mc12345678/EasyPopulate-4.0 and specifically at the admin/easypopulate_4.php file, there is a change made in two lines that ought to correct/address this issue for ZC 1.5.5 and previous supported versions. Again, I didn't get a chance to test it over the weekend, but it looks correct. Would appreciate the feedback incase I don't get to it before another.
For anyone wondering, the issue occurs/occurred in EP4 4.0.33 used on ZC 1.5.5 when the current page was loaded with SSL and the admin was the storage location. I had taken a slightly different approach to this line of code instead of simply observing the settings in the includes/configure.php file in the event that someone had chosen to load their admin (for that page) using SSL even though it wasn't fully enabled, at least the associated file(s) would also then be served using SSL... I have since gone back to a more "custom" method that adheres to the file settings rather than the chosen path at the time of loading the page.
Further it is my plan to submit this modification to the ZC forum which will/should correct a few other minor administrative issues, but it needs to be tested first.. Not going to submit something that just "looks" good...
Zen Cart v1.5.4 (PHP Version: 5.6.17 - MySQL 5.6.29)
Localization -> Languages: Italian/English
Easy Populate 4.0.33a - Beta 02-29-2016
Model/Price/Qty (with Specials)
I export two "v_products_model" and two "v_products_name"
I correct the stocks ("v_products_quantity" and "v_status"
I import the file and i see: "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"
Debug Log: "MySQLi error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'WHERE products_id = *** AND language_id = 3' at line 1
When executing: UPDATE products_description SET WHERE products_id = *** AND language_id = 3"
*** They are different ID
Why ? Any suggestions ?
Regards
Request a little clarification and some additional information.Quote:
Originally Posted by Nightfly66
1) two v_products_model, does this mean two products that have a v_products_model or are there two fields along the top of the export file that have v_products_model as a field?
2) I understand two v_products_name to mean v_products_name_1 and v_products_name_2 are/might be fields though the second number could be other than 2. Please verify this is to what you were referring.
3) When exporting the product, what is/was the admin setting for the primary key, is it products_model, products_id or blank_new?
4) Same question for when importing.
5) What field(s) are in the user defined entry under admin/configuration/ep4?
6) The exported product, were there two or more rows that contained the same data in the v_products_model field? (Ie. either linked product or the same model applied to two different product?)
7) What fields are along the top of the export file?
8) What fields are along the top of the import file?
Almost on second thought, how complete is the above SQL as compared to what was logged?Quote:
Originally Posted by Nightfly66
Other than the products_id being removed, was there anything else that was removed?Code:UPDATE products_description SET WHERE products_id = *** AND language_id = 3
If the answer is no, then the solution is in modifying lines 2006-2009 from:
to:Code:$result = ep_4_query($sql);
if ($result) {
zen_record_admin_activity('Updated product ' . (int) $v_products_id . ' description via EP4.', 'info');
}
The reason for that "issue" is that in permitting the omission of the four fields associated with this section, the omission of all data in that section will result in a query that does not do anything. Because of the multi-language aspect, it is not "easy" to test for the need to run any of the insert/update in this section in advance to have the effort duplicated again within the section. But, if there is no data to be updated, then the query should not be executed. This should be accomplished by the above code change which will skip the update if there is nothing to be updated that relates to that section of the code...Code:if ($update_count == true) {
$result = ep_4_query($sql);
if ($result) {
zen_record_admin_activity('Updated product ' . (int) $v_products_id . ' description via EP4.', 'info');
}
}
I will try to explain better with some examples:Quote:
Originally Posted by mc12345678
1) Each product has a unique code (v_products_model) but each product has a unique code but this code is duplicated for the product name in English and the name of the product in Italian language (v_products_model)
2) I have twice the same product code associated with the same product model one by the name in Italian is the second with the name in English
3/4) I do not have blank fields
5) With earlier versions, I have never had need to enter anything in the User Defined Fields Products
6) There may be some products linked in different categories
7/8) v_products_model, v_products_name, v_status, v_specials_price, v_specials_price, v_specials_date_avail, v_specials_expires_date, v_products_price, v_products_quantity.
All fields are duplicates with the same values. The problem seems to be "v_products_nam"e which is in two languages
Sorry for my English. I hope I was clear in explaining
Regards
One quick, perhaps dumb question. Why did you move from v_category_name_1, v_category_name_2, etc. to using the caret? That, to me just complicates things having to use formulas and such instead of the old way.