Yes, the "new" way is how EP4 operates. If the "carat" is not desired, there are ways to change it, but the carat (^) is the default character.Quote:
Originally Posted by MSRWebMaster
Printable View
Yes, the "new" way is how EP4 operates. If the "carat" is not desired, there are ways to change it, but the carat (^) is the default character.Quote:
Originally Posted by MSRWebMaster
Thanks mc1234678! Much appreciated.
Hi, I am having a little problem with EP4.
I have ZC1.5.6c, installed from that version, not upgraded. I also have Ultimate URLs and Dynamic Filter installed.
EP4 is installed, and I have imported a bunch of products, no problem, all worked great. It is when I have come to add some attributes that the problem has occurred. I have created a one line/product file for ease of testing, I upload & import the file and I get the following 2 error messages at the top of the page:
1. File Import Completed with issues.
2. 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
Then at the bottom of the page the error is listed thusly:
SKIPPED! - Primary key: v_products_model:bcard - Not Found! Unable to apply attributes.
The product does exist, it has a master category assigned correctly, and I have opened the file in Notepad++ and checked for any tabs, and also made sure the file is converted to UTF8.
Here is the contents of the file (which is named "attrib-basic-ep-test.csv"):
Can anybody shed any light on this?Code:v_products_model,v_products_options_type,v_products_options_name_1,v_products_options_values_name_1
bcard,1,First Name,TEXT
Just a guess here, maybe v_products_model should be v_products_id?
I added a field to the product, and I want to add the value of this field through the batch table, which files do I need to modify？
Where do I need to modify this plugin and add this field
Product table fields desired to be exported and imported that are not part of the base code are addressed in the user defined field in configuration->easy populate v4. Simply add the field's name into the text box. If multiple are used, then separate them by a comma. This is covered in the instruction.Quote:
Originally Posted by jiji2018
Quote:
Originally Posted by Pingfah
Really, really sorry for not responding sooner. I have no reason, only excuses.Quote:
Originally Posted by amiablesoul
While there is a lot of good information in the above post and as a result I would like to say that the issue is fully on the code, I have come to realize that there are a few things possibly missing and as a result I am asking questions to try to gain information not to doubt anything provided.
So the below are in no particular order but each could be either the single cause or in combination with other things.
As pointed out by amiablesoul, there is an option in the software to change the primary_key from the default products_model to products_id. It is also possible that the error message is incomplete and inaccurate identifying the desire to use the products_model instead of properly identifying that the products_id is the item to be found. This issue is corrected in an upcoming release.
The statement about "converting to UTF8" does not identify in what program the conversion was made. If Excel was used to specifically save the csv data as utf8, then it is a "known" issue that it adds a BOM character to the beginning of the file and that actually will cause the field to not be readable. Please, for those that wish to blame this software, there simply are too many ways that data can be incorrectly provided to be able to then evaluate all of the possibilities (and still not identify how the data was incorrectly formatted) instead of following recommended processes or just keeping it simple. In fact I have yet to find a way to discover by review of the import file whether the csv file was generated by Excel or other programs such as Open Office or similar consistently. Yes, there are occasions where a character may be found that signifies the data coming from Excel, but even those are addressed in this code by converting such characters to standard utf8 equivalent.
As part of the processing of the data, a message was generated indicating that there was a problem with the sql statement. This program generates a debug log of its own in the associated import/export file. The contents of that file may be helpful in determining the cause/issue.
Another thing which is suggested in the start of the instructions is to basically initially work with unedited data. This will help step through the process that works in your environment to consistently get the desired results. So. Suggestion would be to export some amount of data, open it with your preferred editor, save it with a new filename and no changes and then attempt import (after upload) of that data. Then review the results. If there are issues, then would suggest simply reimporting the original file to validate operation.
So, what appears correct? I see that the filename matches the expected format to support processing the attributes correctly. I "see" the proper columns and what appears to be correct dividers between data; however, the issue may be with other data inserted by the conversion that is not visible but instead is electronic data not displayed as visible characters. I do see that text is not bounded by quotes, though this is not required it can have an effect *if* that internal text had special characters in it as well... (meaning in this case it does not appear to be an issue)
There doesn't appear to be any spaces in any of the headings nor field data, but that would require review specifically of the file itself.
So... while there may be some initial "setup" of concern, perhaps can see that there are a lot of ways things can go wrong, but reproducibility of it going right is actually easy.
I added fields in the background, but the batch table still cannot be imported.Quote:
Originally Posted by mc12345678
Is there a need to modify the program elsewhere?
Attachment 18792
Attachment 18793
If the field `products_family` exists in the product's table and the row contains the primary key that has been chosen, then import of that data should work or a message is provided about it not working.Quote:
Originally Posted by jiji2018
To further test, I would recommend exporting one or more product that already have information in that field to see that it is exported and to provide a sort of example.
There is no other code modification necessary to support that in an otherwise functional system.
This field is exported but cannot be importedQuote:
Originally Posted by mc12345678
The import did not prompt any errors, but there was no value in the database.Quote:
Originally Posted by mc12345678
Attachment 18794
If not I would expect some reason to be provided. Perhaps the CSV file is not formatted properly, perhaps the primary key used (default is products_model) is listed for more than one product such that an update is not going to the correct product. In this case would suggest changing the primary key to products_id.Quote:
Originally Posted by jiji2018
And after the file was uploaded to the server, the file was then imported? (upload places the file on the server, import processes the file to push the content to the database.) this part has been misunderstood by some before.Quote:
Originally Posted by jiji2018
The import did not prompt any errors, but there was no value in the databaseQuote:
Originally Posted by mc12345678
Attachment 18795
Is this set up correctly?Quote:
Originally Posted by mc12345678
Attachment 18796
That looks correct to support import by products_model. Might suggest changing the primary_key to products_id, exporting then updating the products_family field for the items with the appropriate products_id. Note, that if you are wanting to add new product, I recommend the use of new_blank as the promary key. Then new product that do not have a products_id will be given one.Quote:
Originally Posted by jiji2018
I installed this plug-in, you can try, see where the problem is, I want to through the batch scale, batch import keywords.Quote:
Originally Posted by mc12345678
I added custom fields and the content could not be imported
https://www.zen-cart.com/downloads.php?do=file&id=1357
What does new_blank and primary_key mean, I do n’t quite understand?Quote:
Originally Posted by mc12345678
In process of moving from Oscommerce to Zen Cart. Part of process is using Easy Populate to export default Zen Cart product database to use as spreadsheet template. Installed EP 4.0, shows up in tools, but when I try to export I get an immediate 500 error. Same thing happens no matter what option I try. We do have the zen cart directory set up below the top level domain but pretty sure I've put temp directories for EP to copy to.
Thoughts?
Zoom
Check the logs directory for myDebug-adm related files to see what is going on. May be a permissions issue of the folder used as a destination, may be something else.Quote:
Originally Posted by zoomnbyu
I believe you were asking about the differences between new_blank and products_id, but I'll describe both.Quote:
Originally Posted by jiji2018
In order to identify a single product in the database, there must be some field that contains information specific to that product. That is a generic description of a primary_key. It is possible for a table/product/object to be identified by a combination of fields to identify a unique field or primary_key for that thing.
The primary key is most important when importing. This way the field can be used to match up with the item in the database. Zen Cart does not require products_model to be unique, so it is possible that two product could have the same products_model. But, every product is given a products_id.
By providing the products_id and the data to be updated, that product can receive the desired update. But, the database normally manages products_id assignment such that a historical product remains a part of the database in some way.
So there came a request by someone to allow the generation of a product by assigning a products_id and there also was a desire to just be able to create product without being worried about a unique products_model. So, a method was developed to allow product management specifically by products_id such that if the products_id were empty on import, that row of data would be ignored just like it is when working with products_model as a primary_key. But... then there was the concern of how to create a new product without knowing the latest/next products_id... So, the use of a blank entry as the products_id identifier seemed like the right way to go and it had to be specifically set...
So now, if the primary_key is set to blank_new, for any product that has the products_id field, if the products_id field is empty, a new product will be attempted to be created. If the primary_key is set simply to products_id, then a blank entry for products_id field will cause that row to be ignored.
Ty for the quick reply. Below is the log text and I'm probably missing something obvious. The xxxx is just my paranoidly covering the admin folder name.
[18-Jan-2020 14:11:49 America/Chicago] Request URI: /zen-cart/xxxxxxxxxx/easypopulate_4.php?export=full, IP address: 68.15.228.173
#1 require() called at [/home2/tsantoro/public_html/zen-cart/xxxxxxxxxx/easypopulate_4_export.php:92]
#2 include_once(/home2/tsantoro/public_html/zen-cart/xxx/easypopulate_4_export.php) called at [/home2/tsantoro/public_html/zen-cart/joinT-mtL-Buses/easypopulate_4.php:286]
--> PHP Warning: require(/home2/tsantoro/public_html/zen-cart/xxxxxxxxxx/includes/modules/easypopulate_4_filelayout.php): failed to open stream: No such file or directory in /home2/tsantoro/public_html/zen-cart/xxxxxxxxxxx/easypopulate_4_export.php on line 92.
[18-Jan-2020 14:11:49 America/Chicago] PHP Fatal error: require(): Failed opening required '/home2/tsantoro/public_html/zen-cart/xxxxxxxxxxxx/includes/modules/easypopulate_4_filelayout.php' (include_path='.:/opt/php56/lib/php') in /home2/tsantoro/public_html/zen-cart/xxxxxxxxxxx/easypopulate_4_export.php on line 92
The software is admin related meaning it belongs in the admin directory (possibly installed some of the files in the catalog side). The files sought were not found and why the 500 error. The export directory can be on the catalog side if so desired, but the other files still need to be in the admin. :)Quote:
Originally Posted by zoomnbyu
Ok, found some missing files. Loaded those but still getting 500 error with log below.
[21-Jan-2020 14:08:59 America/Chicago] Request URI: /zen-cart/index.php?main_page=product_info&cPath=2_19&products_id=22, IP address: 68.15.228.173
#1 define() called at [/home2/tsantoro/public_html/zen-cart/includes/languages/english/meta_tags.php:17]
#2 require_once(/home2/tsantoro/public_html/zen-cart/includes/languages/english/meta_tags.php) called at [/home2/tsantoro/public_html/zen-cart/includes/languages/english.php:635]
#3 include_once(/home2/tsantoro/public_html/zen-cart/includes/languages/english.php) called at [/home2/tsantoro/public_html/zen-cart/includes/init_includes/init_templates.php:55]
#4 require(/home2/tsantoro/public_html/zen-cart/includes/init_includes/init_templates.php) called at [/home2/tsantoro/public_html/zen-cart/includes/autoload_func.php:48]
#5 require(/home2/tsantoro/public_html/zen-cart/includes/autoload_func.php) called at [/home2/tsantoro/public_html/zen-cart/includes/application_top.php:170]
#6 require(/home2/tsantoro/public_html/zen-cart/includes/application_top.php) called at [/home2/tsantoro/public_html/zen-cart/index.php:26]
--> PHP Warning: define() expects at least 2 parameters, 1 given in /home2/tsantoro/public_html/zen-cart/includes/languages/english/meta_tags.php on line 17.
Looked at the referenced meta_tags.php file and all that's on line 17 is keywords.
This is an indication of an incorrect modification of that meta_tags.php file.Quote:
Originally Posted by zoomnbyu
A default version of that file has the following for that line. Note the comma and associated single quotes are important:
This issue is not related to EP4 but instead management/installation of the base Zen Cart software.Code:// Custom Keywords
define('CUSTOM_KEYWORDS', 'ecommerce, open source, shop, online shopping, store');
Thanks for the feedback. Will check comma's and such. One question if you know, why would EP care about keywords for a database dump?
Thanks
There is the possibility for every product and category to identify the keywords that will be present when a page is visited. To make that entry easier by way of mass population, EP4 offers that capability. The alternative is to allow Zen Cart to determine what keywords are presented or to manually enter them through the admin.Quote:
Originally Posted by zoomnbyu
Thing is though as far as I can see in the EP4 code, with a proper installation of Zen Cart followed by a proper installation of EP4, there is no reason that the catalog side meta_tags.php file should even be accessed. So I'm not sure why the above error even happened from the admin side...
I am trying to do an import using easy populate, but for some reason I am getting this error. i did just upgrad to php 7.3 o that might have something to do with the error. If someone could assist me that would be great
- Zencart 1.5.6
- Module Easy Populate 4.0.36.ZC
- Php 7.3
I believe the file in question might be Admin/easypopulate_4_import.php
error
HTML Code:MySQLi error 1364: Field 'categories_description' doesn't have a default value
When executing:
INSERT INTO categories_description SET
categories_id = 3759,
language_id = 1,
categories_name = 'Battery Straps'
See if application of the following three commits get you there:Quote:
Originally Posted by chadlly2003
https://github.com/mc12345678/EasyPo...c8a42551c6d37c
https://github.com/mc12345678/EasyPo...3d2ce914c2b183
https://github.com/mc12345678/EasyPo...d745b7e83045a2
The cause is that ZC has not had a default value for new categories, but previous mysql servers (lower versions) have been "ok" with that. But that is no longer the case, and unfortunately a feature I'm trying to add is not to completion so a new version has not been published.
not sure if this was the best way to solve the issue but
I went to the terminal and edited the cnf file
change this sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
to this
sql_mode=
If I do NOT include a v_status column/value in the imported csv, it will default to 0 and set the product's status to OFF (Disabled) upon import.
Am I correct in my understanding?
And, am I missing a setting that will default any import to 1/ON/Enabled? Or do I have to ensure a v_status value in the csv?
Thanks.
To try to answer factually, would need to be sure to have some context. I have an idea of an expectation, though...Quote:
Originally Posted by MSRWebMaster
To help with the context, I could use a few pieces of information:
What version of EP4 and/or download date from what source?
Zen Cart version?
Are these new, existing, or a mixture of both product in the file?
What has a test of omitting that column shown/done?
I would think (haven't gone to search the code) that for imports it would be possible to provide a default value that is overridden by the imported file having a "replacement" column record. Or there is always the possibility of adding yet another configuration setting or similar.
This is true. I have found that you must include the v_status column with a value of 1.Quote:
Originally Posted by MSRWebMaster
To possibly provide some form of improvement, the questions previously asked still stand and are applicable here as well.Quote:
Originally Posted by keith z
EasyPopulate V4 - Version: 4.0.36.ZC with zen-cart-v1.5.6c
Import error:
I tried this code from this patch https://github.com/mc12345678/EasyPo...n_import_patchCode:MySQLi error 1364: Field 'categories_description' doesn't have a default valueWhen executing:
INSERT INTO categories_description SET
categories_id = 2,
language_id = 1,
categories_name = '1/12 SCALE FURNITURE'
MySQLi error 1366: Incorrect integer value: '' for column 'products_sort_order' at row 1
When executing:
INSERT INTO products SET
products_model = 'J0844MH',
products_type = 1,
products_price = '108.19', products_image = 'J0844MH.jpg',
products_weight = 0.6,
products_discount_type = 0,
products_discount_type_from = 0,
product_is_call = 0,
products_sort_order = '',
products_quantity_order_min = 0,
products_quantity_order_units = 0,
products_priced_by_attribute = 0,
product_is_always_free_shipping = 0,
products_tax_class_id = 0,
products_date_available = NULL,
products_date_added = '1970-01-01 10:00:00',
products_last_modified = CURRENT_TIMESTAMP,
products_quantity = 7,
master_categories_id = 2,
manufacturers_id = 1,
products_status = 0,
metatags_title_status = 0,
metatags_products_name_status = 0,
metatags_model_status = 0,
metatags_price_status = 0,
metatags_title_tagline_status = 0
but import page did not load
I probably did not edit easypopulate_4_import.php correctly, the patch is different to the full file (not a full file)
maybe someone can edit code for easypopulate_4_import.php and send me link (attached file)
Import file:
Code:
v_products_model
v_products_image
v_products_name_1
v_products_description_1
v_products_url_1
v_specials_price
v_specials_last_modified
v_specials_expires_date
v_products_price
v_products_weight
v_last_modified
v_date_added
v_products_quantity
v_manufacturers_name
v_categories_name_1
v_categories_name_2
v_categories_name_3
v_categories_name_4
v_categories_name_5
v_products_type
J0844MH
J0844MH.jpg
George Washington Double End Desk - mahogany- 1:12 scale
<p>The George Washington Double ended desk knee hole ,called a partners Desk hole desk has 3 drawers on each side with a single long drawer in the centre. There are 3 faux drawers on either end. The 8 legs are fluted and the drawers are decorated with a ######## bead molding around all sides. the top of the desk has a shelf at both ends. The desk measures 3 inches high x 6 inches wide x 2 and is available in a mahogany finish.</p>
108.19
0.6
########
########
7
JBM Miniatures
1/12 SCALE FURNITURE
All 1/12 SCALE FURNITURE
1
J0844MH
J0844MH.jpg
George Washington Double End Desk - mahogany- 1:12 scale
<p>The George Washington Double ended desk knee hole ,called a partners Desk hole desk has 3 drawers on each side with a single long drawer in the centre. There are 3 faux drawers on either end. The 8 legs are fluted and the drawers are decorated with a ######## bead molding around all sides. the top of the desk has a shelf at both ends. The desk measures 3 inches high x 6 inches wide x 2 and is available in a mahogany finish.</p>
108.19
0.6
########
########
7
JBM Miniatures
1/12 SCALE FURNITURE
1/12 SCALE FURNITURE BY ROOMS
STUDIES
1
When following that link, on the right side of the screen are three dots. At least in Microsoft edge when clicking on the three dots a dropdown menu is presented which includes to view the file. That takes you to: https://github.com/mc12345678/EasyPo...e_4_import.phpQuote:
Originally Posted by vandiermen
From there you can get the "Raw" file which is just the text of the file that can then be copied and pasted as appropriate. That location is: https://raw.githubusercontent.com/mc...e_4_import.php
And there is a short explanation of navigating GitHub. :)
But understand that any other changes/tweaks that may have been applied and are not in the file at that point/location will be overwritten if this file is used in its entirety instead of just incorporating the changes that were shown in the original link.
As far as the data being entered, the v_categories_name columns don't look right... Where populated they have the same language in each column. EP4 uses the _1, _2, etc... flag as a language identifier. An item that is in a sub-category is identified by separating the parent category from its child category with a carat (^), so the second entry looks like in v_categories_name_1, the entry should be: "1/12 SCALE FURNITURE^1/12 SCALE FURNITURE BY ROOMS^STUDIES" so that the product would be associated with the studies category that is a child of the 1/12 scale furniture by rooms category that is a child/sub-category of 1/12 scale furniture.Quote:
Originally Posted by vandiermen
I assume this file was collected from some other variation of Easy Populate and was not generated directly from EP4.
I, for the first time since EP came out, wanted to try and circumvent adding products from the admin and tried adding a product to a downloaded Full EP file a specific category. I left the product id empty since it hadn't been created yet, and it didn't import. Is there a formula to add NEW products using EP by adding them to a current spreadsheet?
There "is" though it depends on what setting you have for the primary id (assuming using a more recent version of EP4 that offers a selection). If you have the selection, then blank_new as the setting will create a new product when the products_id is left blank. If you choose products_model (the default/classic primary key) then a new product is made when there is a new products_model that hasn't existed. For products_id as a key, then a new product is created if a products_id is used that didn't previously exist noting that a row of data with a blank products_id will be ignored.Quote:
Originally Posted by Carbonless
At any time if a primary key is used and that product already exists in the database and not specifically deleting data, then when that row is processed for adding/updating if the category is different than what already exists that row of data will be linked to the original product and the data of the original product will be updated to the row being read.
[/HTML][/HTML]HTML Code:[HTML][HTML][QUOTE=mc12345678;1367176]There "is" though it depends on what setting you have for the primary id (assuming using a more recent version of EP4 that offers a selection). If you have the selection, then blank_new as the setting will create a new product when the products_id is left blank. If you choose products_model (the default/classic primary key) then a new product is made when there is a new products_model that hasn't existed. For products_id as a key, then a new product is created if a products_id is used that didn't previously exist noting that a row of data with a blank products_id will be ignored.
At any time if a primary key is used and that product already exists in the database and not specifically deleting data, then when that row is processed for adding/updating if the category is different than what already exists that row of data will be linked to the original product and the data of the original product will be updated to the row being read.[/QUOTE]
hmmm... I do have the primary key as model and entered the model as NEW PRODUCT! - Model: blank_new | | 1 | einsteins- | Colombian | Not just t | | | | | 55 | 6 | 0 | 25 | 1 | 1 | 0 | 1 | | | 0 | Coffee | Coffee^Pre | --none-- | 1 | | | | | | | | |
No product yet that I can fine. I will experiment some further. Thank you!
Although the data returned from that view can be difficult to decipher, it appears that a new product was added that has the products_model of 'blank_new'. If the columns line up to what I might expect, this new product is expected in the sub-category Pre under the category Coffee. Though it may also be that the product has been added to the category of Coffee even though that category has sub-categories. In a standard store, this will cause problems on the front end if the product is active. Some sort of modification to the applicable header_php.php file would be necessary to support product and categories both co-existing and active. The easier way to offer help would be to provide the first line along with the line in question from the csv file.Quote:
Originally Posted by Carbonless
Hi,
I'm using the Attrib-Basic-EP file to try and get my attributes loaded. I have used the tool to load a number of products and am now using the Attrib-Basics-EP file I exported as a template to populate (it does have some good entries as my store does have some products with attributes already). Before editing and adding more, I thought I would test the update. The upload of the exported file, unchanged, returned the message:
MySQLi error 1054: Unknown column 'p.products_model' in 'where clause'
When executing:
SELECT * FROM products WHERE (
p.products_model = '1392')
I see the syntax error in that products was not referenced as 'p', but the upload has created the SQL as p.products_model. Is this a bug?
Note, I originally tried this with products_id still the primary key. However, I have changed products_model to be the primary key and still get the same error.
Running ZC 1.5.6c on PHP 7.3
It is a bug resulting from streamlining the code a little where the query operating against a single table did not use a table name alias and reference to the desired field did include the table alias.Quote:
Originally Posted by gohealth
In the file admin/easypopulate_4_attrib.php
At line 29, if you change:
To:Code:$query ="SELECT * FROM ".TABLE_PRODUCTS." WHERE (" . $chosen_key_sql . ")";
That issue will be addressed for either/both primary key choices.Code:$query ="SELECT * FROM ".TABLE_PRODUCTS." p WHERE (" . $chosen_key_sql . ")";
BTW, thank you for the identification and research performed. Apologies for the discrepancy. I'll be updating github when I get a chance and also search for other queries that might have been generated the same way of using a single table and not using a table alias.
Thanks for the update. That makes sense. I made the change and had some further issues that I can't debug. The update didn't complete at all (says 'waiting for website.com...' at bottom left for about a minute then goes to a blank screen on 'admin/easypopulate_4.php' page) so I reverted back my code change in case I stuffed it and ran it again. Same error in the log file regarding the missing reference, but i also noticed the message at the top of the screen "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". Noting, that I did a simple "Basic Products Attributes" export, did not touch the file (has just a single model in it) and then did the import. So, not sure there is a TAB in the untouched 'export' file (in other words, I did't add it or allow Excel/Open Office open the file).Quote:
Originally Posted by mc12345678
Any thoughts? No debug file produced.
Thanks,
Chris
How many records are supposedly included (that plays a factor in the software timing out after running for a period of time).Quote:
Originally Posted by gohealth
The error message about checking for tabs is/was a issue that has been identified as common and is not the cause 100% of the time. In fact, the export/import test is one of the recommended actions in troubleshooting something like this.
Now, as to why the screen went blank, again the size of the file plays a factor, as well any sorts of timeouts set for execution, and then there is also an option attempted to be used by the software to keep processing alive; however, some systems do not support it and the "whitescreen" may still occur.
For actions complete, should be able to review the admin activity log at least in part to see what the last operation was that completed in using this plugin.
Note, it is also possible that the raw data has some issues that may need addressing.
Thanks for the update. Unfortunately, I just have the single row (that was extracted via the export), so don't think it would be a filesize or timeout issue, or an issue with the data as it has come from the export.Quote:
Originally Posted by mc12345678
Let me do another few tests and see what i can find.
Cheers,
Chris
Actually, in absence of response I went through and identified the issue(s). I've also made some other updates to improve the basic attribute import operation. I'll be pushing the updates shortly, just need to finish something else within the next 20 minutes or so.Quote:
Originally Posted by gohealth
I've updated the master branch with the correction to the above identified issue and a few other things identified while reviewing that file. There are certainly additional improvements possible and some more alignment with other existing code that can be done.Quote:
Originally Posted by mc12345678
Note that the update does change the first option value sort number from what was a 1 to now a 0 when dealing with the basic attribute update. Also, while others hadn't really explained what issue they had with sort orders, but I found that in an update situation that the sort order was only incremented by one instead of by 10 as expected. I have corrected that issue so that when performing a basic attribute upload of existing option values within an option name group that the sort order is incremented by 10 with 0 being the first sort order.
I've also added a few "screen" notifications to try to address a few potential issues (no primary key field included in the upload file for example) that ideally will not occur, but inevitably may... Also added the ability to reassign an option name to a new products_option_type and a few associated modifications.
Thanks for the quick turn around. I'll try and figure out how to access this branch and the changed files and give it a try. I'm might need to message you to figure out how to get the latest code changes you have made.Quote:
Originally Posted by mc12345678
Thanks again...
Https://github.com/mc12345678/easypopulate-4.0 should take you to the master branch. From there, on the right side of the screen is a green button allowing download of the zip file which includes all of the latest updates. While to fix this issue I only modified the admin/easypopulate_4_attrib.php file, there may have been a few updates included that I had not yet pushed.Quote:
Originally Posted by gohealth
I appreciate the feedback. Sometimes don't know a problem exists until someone says something.
Trying to import some attributes and it's not working, how could I spit out the SQL to try to manually run it? I've tried about 4 of the last build versions...
As with all issues in the forum, a little more information is always helpful.Quote:
Originally Posted by wolfderby
In this case, what type of operation with Attributes, what was the filename being used to import, and because there recently were some issues identified with the basic attribute import, has the latest github version been attempted? Also, depending on the exported file, there may be duplicate data that causes expected changes to be overwritten. But deal with that once more info is made available.
Fyi, the above was something of a two part question/issue. The first associated with the operation of the code, the second associated with the needed sql...Quote:
Originally Posted by wolfderby
To the second part, the complexity of attributes to a product involves a number of sql statements and tables. The tables involved are: products, products_attributes, products_attributes_downloads, products_options, products_options_types, products_options_values, and products_options_values_to_products_options. So the addition/modification of attributes can be involved. The code is expected to address/handle these. There are also some other "helper" tables such as the languages table to identify what languages are installed and further support database population.
Yes I've tried chaddro's and yours. The MC git repo seems to only export 6 products for a basic line import, if I'm recalling correctly. Chaddros' exported all but doesn't see my delimiter for import. Yours seemed runs the import but doesn't actually import the values. I've also tried putting echos and print_r's in the easypopulate_4_attrib.php and I never seem to see them, to the point where I was wondering if the required blocked them, or if cloudflare's caching the file? if I throw an echo in easypopulate_4.php I see it though?Quote:
Originally Posted by mc12345678
At some point I'd like to upload a table header click and sort for the date I have on one of my versions. (:
Ah snap I think I was just messing up the filename on upload. Forgot the prefix!
That at least addresses the import (after upload) portion. What again is/was the issue though with export... is there an issue?Quote:
Originally Posted by wolfderby
So I searched this thread and couldn't find anything on the nose of my issues.
** Imported products display fine, but will not open to product details view when you click on them **
I first created all my store categories.
Then I created some new products
Then exported to get a template
I filled in the template with a bunch of new products
I imported the template
Everything imported fine and reported no errors. I can see the couple hundred items on the back and front ends of the store. When you click on one though it just displays the title of the product instead of going into it. If you click on the Quick view you can see the product and even add to cart but it will not let you view the product any other way.
I had not done attributes yet and thought that might be why they weren't displaying since they are all priced by attributes. But when I assigned attributes, still the same issue. If I create a new product in the back end it opens just fine as it should so it had to be something with the import.
I have compared the products imported with ones I created and no differences when I go into edit them, and I have also tried deleting the attributes and re-assigning, and I've tried disabling the product and re-enabling, still will not open from when you click on the product, only shows the title then the category listings below it.
I'm using ZC 1.5.6c, and Yourstore theme
What version of EP4 is being used? What is being used to generate the csv file? Someone has recently identified having a similar issue where the source file contained character codes that did not convert to utf8 properly and content was not being fully populated. Unfortunately I didn't receive the associated files to be able to review/provide direction, but they resolved it by installing Libre (open source spreadsheet program) and ensuring to save their csv file as utf8 before attempting to upload and then import.Quote:
Originally Posted by eric47905
Could be other things, but would need to know information related to the above to be able to provide more guidance.
Easy Populate 4.0.37.10 - 02-08-2017 - Using Open Office Calc - I did find out what the issue seems to be from someone though. When I import the file the 2nd column v_products_type is changing form a 1 I have entered in to a zero when I re-download the full products list.
It being a zero appears to be causing you not to be able to open the product and in some cases causing ERR_TOO_MANY_REDIRECTS error page when you try to click on certain categories. One such product I deleted and then the category opens without the redirect error, so I re-uploaded just the one product in a file and it stayed as v_products_type of 1 and works fine now when it previously did not.
So the question appears to be why is the upload changing what I have in the cell from a 1 to a zero when uploaded?
And have confirmed that the csv file (intermediate between the spreadsheet and the database) shows a 1 and not a 0?Quote:
Originally Posted by eric47905
Yes, the spreadsheet (.csv, seperated by Coma, Text delimiter double quote) that I am uploading shows a 1 in all cells for the v_products_type. However, when I do a full download with meta tags of all products, the .csv I get shows a zero for the same v_products_type for every product I have uploaded.
I also just downloaded the uploaded file I did to make sure it is still showing correct and it is. Not sure where else I would be able to check it at.
Is the current download for EasyPopulate 4.0 compatible with v157 Stock_By_Attributes?
If by current you mean the github version it is. The use of xxxx_en or similar language codes is not supported yet in all upload types. Use of xxx_1 is still recognized and would be recommended until published to the zen cart downloads section. Once complete, either method will be permitted including if the file had both listed (option to consider one or the other to override if both are present.)Quote:
Originally Posted by jodean
forgive me if I've had this issue before and have forgottent the answer. The zen cart installation is in a folder below a wordpress site in the root. The root htaccess is just the wp with no additions.
Easy populate creates the files in the admin folder correctly. But if you try to download a file, you are sent to the root index. No redirect showing in the url and the url is correct for the actual file/download. I have a version of easypopulate dated july of 2019. Will the github present version fix this issue or am I looking at an htaccess problem? Or can this not work in a folder?
Sorry for the delay in response, wanted to be sure to review the information associated with the download link generation.Quote:
Originally Posted by delia
First of all, the link for the download location was last updated 5 years ago to account for changes in Zen Cart 1.5.5. The link is assembled from information that has been made available as part of the load of Zen Cart (predominantly expected to be in YOUR_ADMIN/includes/configure.php; however, there may be overrride information loaded before that file) Before going into the logic, the question is what path is displayed (even if in the source code of the page) when hovering over the link for the download of a file? If it is a complete path to the same location to which EP4 is writing, then definitely the issue is .htaccess related in some way; however, that too is somewhat questionable.
So the path is generated like so as related to the above description that the temporary directory is assigned to be an admin related directory (EP4_ADMIN_TEMP_DIRECTORY === 'true')
Evaluate ENABLE_SSL_ADMIN, if it is assigned and set to 'true' then attempt to generate an https related url. As of ZC 1.5.5, HTTPS_SERVER was basically removed, but if it is present use it. If not present then use HTTP_SERVER (which in an https environment would be expected to begin with https:). Then because attempting to generate an https path, attempt to add on the web facing sub-folder associated with the admin directory (DIR_WS_HTTPS_ADMIN), which if it does not exist then add on DIR_WS_ADMIN.
Now if ENABLE_SSL_ADMIN !== 'true', then use: HTTP_SERVER . DIR_WS_ADMIN which may be an https: path.
Regardless the choice of ENABLE_SSL_ADMIN, the temporary directory and filename is to be appended to that. Now, if the associated DIR_WSXXXADMIN variable doesn't begin with slash, then it is possible that the path would be generated incorrectly. Or if the associated HTTPXXXSERVER constant also incorrectly ends with a slash a similar issue could occur. Then of course also if DIR_WS_HTTPS_ADMIN is defined but "shouldn't" be and it suggests some other location then that could be problematic.
Lastly as far as the files being located in some sort of folder off of either the catalog or the admin, yes it can. Note that more than likely an .htaccess file or revision to one would be necessary in that admin folder to support download of CSV files. Such a file is included in the download sub-folder: htaccess4AdminTempFolder. Note that the contents of that file are intended to support the download of just .csv and/or .txt files and should *not* on its own replace an existing .htaccess file but be merged to also support download of .csv/.txt files... Because the catalog is not provided an .htaccess file to limit access to particular files, a sub-folder generated off of the catalog does not require an .htaccess file in a default Zen Cart installation.
So again, I suspect that there is an htaccess rewrite issue that is diverting the download path if the problem is being seen only upon clicking the link. If the link is generated to be other than to the associated admin folder, then the problem is within the constants assigned during the load of Zen Cart. With additional information, I may be able to identify the issue, but I haven't had problems causing an alternate folder to be accessed when downloading.
Definitely correct url to the file. The site shows page not found as the page title but displays the the word press installation with page not found which is just weird. I tried to edit the page not found to stay in that subfolder but it made no difference. I tried all sorts of things to change the wp code but so far nothing has worked. I agree (and my hosting agrees) that the problem must in the htaccess file in the root. I actually am beginning to believe there are other issues with WP. I didn't install it so no telling. Thanks!
The other part of it may relate to the a possible absence of the .htaccess file to permit download of the csv file(s). E.g. Thinking that if the download is not permitted that "an" error page is set to be presented and that page becomes the wp version as identified at the root. Potentially a number of ways to test. Obviously the admin directory is "accessible", but csv files are by default not on the exception list. Could modify the admin's htaccess to permit csv files and change the temp directory to just /. Then with a csv file located in that directory, download "should" be successful...Quote:
Originally Posted by delia
Could otherwise as permitted show/message the contents of the root .htaccess and I could at least take a look at that and maybe provide feedback.
Easy Populate 4.0.37 (GitHub Newest) for Zen Cart 1.56c - Twitch Base6 now includes:
Product Base Cost: TRUE
Product Model Spoon: TRUE
Product Canada Post Weight Type: TRUE
Product Canada Post Dimension Type: TRUE
Product Canada Post Length: TRUE
Product Canada Post Width: TRUE
Product Canada Post Height: TRUE
Product Canada Post Ready To Ship: TRUE
Also included:
New one click export links along with custom import features for anyone using a store POS or similar business management tool exporting to .csv.
Twitch Wholesale integration will be available shortly.
I am using a 1.5.7 site and installed this mod and have had horrendous results (from my customer).
It appears it is not recognizing the sub categories and dumping all products into the MAIN category which has the sub categories.
Upgraded from 1.5.0 and older version of EZP. Customer is very familiar with using EZP.
Chad - any help would be appreciated!
When you say EZP are you referring to one of the other versions? There is an issue if one doesn't format the categories using the caret (^) or other self selected divider when importing categories... recommend providing an example row of data, ensuring following the instructions and lastly identifying the version currently being used/tried...Quote:
Originally Posted by stellarweb
Customer does not remember what version - and does not remember it saying V4 - just EZ Populate. It was an old 1.5.0 website.
HOpe this helps
HTML Code:status Arcos Manu Number Scan Number Name Jpeg File Cost Tubes Cost X3.5 Retail v_products_model v_products_image v_products_name_1 v_products_description_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_sort_order v_products_quantity_order_min v_products_quantity_order_units v_date_avail v_date_added v_products_quantity v_manufacturers_name v_categories_name_1 v_categories_name_2 v_categories_name_3 v_categories_name_4 v_categories_name_5 v_categories_name_6 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_1 v_metatags_keywords_1 v_metatags_description_1 1 ARC510-00030-01700 ARC510-00030-01700 790524056132 Silver Aluminum Matte ARC510-00030-01700.jpg 1.68 1 1.68 5.88 6.00 ARC510-00030-01700 /p-czech/ARC510-00030-01700.jpg Silver Aluminum Matte ARC510-00030-01700 6.00 0 0 20 1 1 10000 XXXX Beads: Seed-Czech Arcos - 2 hole Taxable Goods 1 0 0 0 0 0 1 ARC510-00030-01710 ARC510-00030-01710 790524056163 Light Gold Matte ARC510-00030-01710.jpg 1.68 1 1.68 5.88 6.00 ARC510-00030-01710 /p-czech/ARC510-00030-01710.jpg Light Gold Matte ARC510-00030-01710 6.00 0 0 30 1 1 10000 XXXX Beads: Seed-Czech Arcos - 2 hole Taxable Goods 1 0 0 0 0 0 1 ARC510-00030-01780 ARC510-00030-01780 790524056231 Copper Gold Matte ARC510-00030-01780.jpg 1.68 1 1.68 5.88 6.00
Quote:
Originally Posted by mc12345678
While the data doesn't come across well formatted, I see the indicators that I expected for it being an older/alternate EP...Quote:
Originally Posted by stellarweb
In EP4 as discussed in the instructions, the suffix '_1', '_2', '_3', etc. relates to the language that is being used... In one or more of the older versions, v_categories_name_1 was the "parent" category, v_categories_name_2 was the first sub-category off of the parent, v_categories_name_3 was the first sub-sub-category, etc...
In EP4 a specific sub-category would be generated by concatenating each of those (that have content) with the carat '^'...
So:
for EP4 would be combined in a single field (v_categories_name_1 or (when using the most recent version) v_categories_name_en) to:Code:v_categories_name_1 v_categories_name_2 v_categories_name_3 v_categories_name_4 v_categories_name_5 v_categories_name_6
shirt long-sleeve no-buttons
shirt^long-sleeve^no-buttons
Where the language_id for the store is 1... While not fully implemented across all import file types, the language_code is now supported to instead use '_en' as the suffix for English instead of the language_id (_1).
A way to accomplish that concatenation if the columns were say g, h, and i with the data starting in row2, then I would go to the next/last v_categories_name_X column, insert a new column, then use something like:
Now of course I wouldn't expect that there would be a "series" of information followed by an empty space then another with data (say _1 and _3 having data, but _2 not having data)...Code:=IF(G2<>"", G2, "") & IF(H2<>"", "^" & H2, "") & IF(I2<>"", "^" & I2, "")
After I got the result, then I would copy that function down to the last row, then copy the contents in that column for all product and paste special that text into the appropriate column representing the language_id and delete the other v_categories_name_X columns including the one that was created to support this effort...
Basically, EP4 supports multiple languages which older types did not appear to do so and the categories/sub-categories are identified as between each ^.
This is also why it is important to not introduce spaces before/after each category. " shirt" is different than "shirt" and results in category creation/population to the "applicable" category....
zen 1.56c with many modules
easy populate downloads one field funny, as in the data base (products_barcode varchar(32))
when i upload it back it uploads whats in the file.
tried to upload file but exceed quota, but here is some of what is in the file
v_products_barcode
7.34995E+11
7.34995E+11
7.34995E+11
7.34995E+11
7.34995E+11
7.34995E+11
7.34995E+11
7.34995E+11
At some point in modifying the exported data, it appears that the spreadsheet being used stopped considering the text provided as text and started treating it like a number... it then considered the number to need to be displayed in exponential numbers... therefore when the spreadsheet was saved to a csv file, the file then contained exponential numbers...Quote:
Originally Posted by jimmie
This all happened outside of EP4 and specifically in the spreadsheet being used... you'll likely have to go back a few exports to find the original values that were brought into your spreadsheet program. In the future treat this field as a text field and don't let your spreadsheet program convert it to a number...
my steps were, open ep, choose manufacturer, than export, than download to computer, than open in excel. than i copied some rows pasted them here.
"Looking" at them in excel is why the numbers are converted to the scientific notation that was posted... Again, this is not something that was done in EP4. EP4 generates the CSV file that was downloaded. If it is looked at with your favorite plain text editor just after download and before ever being edited with Excel or Open Office then will see the number(s) in their entirety and not shortened.Quote:
Originally Posted by jimmie
There are plenty of ways to request that numbers be treated as text when either importing a file or reviewing the content.
Jimme,Quote:
v_products_barcode
7.34995E+11
7.34995E+11
7.34995E+11
7.34995E+11
7.34995E+11
7.34995E+11
7.34995E+11
7.34995E+11
I had the same issue with UPC codes, it's a pain.
Here is how I solved it.
I added UPC before every code in the database, so instead of this -> 697666007421 in the db it was this -> UPC697666007421
Then i used php to remove the UPC when it's displayed on the front end.
It's a workaround but solves that issue.PHP Code:str_replace("UPC","",$upc['products_upc'])
In Excel, to "format number fields as text instead of scientific notation", select the entire column, press CTRL+1 (or CMD+1) and change the format to Text
https://www.excelhow.net/convert-sci...-in-excel.html
https://www.extendoffice.com/documen...n-to-text.html
Hello, I'd like to make sure that this plugin fits my use case before proceeding.
We have existing categories on our ZC 1.5.5e site, to which we need to add 125 or more products. Do I understand that with this plugin, I can put the 125 products into an appropriately formated / column header CSV, and mass import my products in one operation? Thus avoiding the tedious GUI of creating 125 products. Thanks for clarifying.
Absolutely correct. Suggest exporting product from that category (if at least one is already present) to make a good example of how it should look when preparing the new upload. (remember that the csv file has a different appearance than that content loaded into a spreadsheet.)Quote:
Originally Posted by greg_beyer
Is it possible to use UPC field instead of model field to update products using easy populate. If yes what change we need to make in files?
I see you have completed the export CEON URI feature. Is it possible to import CEON URI using EP when adding new products?Quote:
Originally Posted by chadderuski
Help: "500error" occurred in importing "attrib-basic-ep"
For more information, please see
https://github.com/mc12345678/EasyPo...ssue-771334798
"500" errors are a result of either a PHP fatal error (which will be recorded in your site's /logs/myDebug-adm-xxxxxxxx.log files) or a server security rule triggered by something like mod_security (the details of which will be recorded in the server's internal security logs, which your hosting company can access to help you).
https://docs.zen-cart.com/user/troub...ternal_server/
But why do I just import one of the data (Prefix: attrib-basic-ep.). When there is such a problem? Everything else is normal (such as pictures)Quote:
Originally Posted by zswll2
Click on the red part, and the browser will be completely white.
Check your site's /logs sub-directory. You'll have a myDEBUG-adm-{stuff}.log file that identifies the source of the error.
If you choose to post the contents of one of those *-adm-*.log files, be sure to xxx-out the name of your site's admin subdirectory before posting.
As I said earlier, the blank page (the 500 error) is a result of a fatal error triggered on the server.Quote:
Originally Posted by zswll2
lat9 and I have both explained how you can investigate to find the actual error details.
Not so sure that chadderruski created a URI generation on export feature, otherwise I probably wouldn't have gone through with doing so. I would think that it would be possible to do some sort of update on import through Ceon's URI Mapping Manager.Quote:
Originally Posted by jsarwar
Yes, though I didn't make it as easy as I thought I had...Quote:
Originally Posted by jsarwar
Apparently a new notifier needs to be added in to allow further "development" to use an alternate field,..
There are two basic factors involved with details to be captured/handled in what appears to be two files:
admin/easypopulate_4.php : Need to populate 'EP4_DB_FILTER_KEY' with the key name to be used later in import... This is normally read from the database, but it could be pre-loaded in the file load structure or the database could be updated to include the extra option(s).
admin/easypopulate_4_import.php: sometime either within or after this section: switch (EP4_DB_FILTER_KEY) { ... } need to set each of the variables identified within that section to the desired state for your new primary key. I was thinking that a notifier was included to support this, but I don't see it... Obviously could add a set of code directly in that file's section to handle your specific case.
Considering that the UPC "mod" is recognized, there is no need to add an additional custom field to track for export/import, but if the new field was not a pre-recognized field then would need to add it to the list of fields to process.
Of course and has likely been described countless times in here, is there a reason that the UPC code isn't part of the model?
To "pile on" to the rest of the recommendations, please also identify version(s) of software (I figured out/can guess from the image in the github issue that it is most likely Zen Cart 1.5.7x because of the cmd= parameter in the URI path, but even that is not highly specific). More information helps to figure out the issue. Obviously the first thing that would help would be the error log that has been discussed above, then the data within the file or something similar. If I can recreate the issue then perhaps it either can be fixed or prevented.Quote:
Originally Posted by zswll2
Quote:
Originally Posted by mc12345678
In the picture is my website log, can you see any results?
I also looked at the php log and the apache log and found no entries for easyPopulate.
Zen Cart 1.5.7
Easy Populate 4.0.37.10 - 02-08-2017
PHP 7.4Attachment 19336Attachment 19337Attachment 19338
The website log is an access log not an error log, so there is nothing there that helps resolve the issue. What about the first two lines of the import file? also, generally a way to evaluate operation of EP4 as compared to the file being imported is to export a file and then immediately import it again without editing... If there is no problem with that process then the problem is in the file that is attempted to be uploaded and imported after it was edited.Quote:
Originally Posted by zswll2
I'll try a simple file in a similar environment and see what happens. Current environment appears to be Zen Cart 1.5.7 (although rev b has been issued), PHP 7.4 with EP4.0.37.10
Model number is as item number or SKU which is always different than UPC/barcode of products. I already tried to work by changing EP4_DB_FILTER_KEY it did not work therefore I seek for help in this forum. Can you please provide the codes changes or updated file to work with upc?
Thank you.
Quote:
Originally Posted by mc12345678
As you said, I only export and import, not edit. When importing, the browser is blank. I check Network and find POST 500.Quote:
Originally Posted by mc12345678
I checked the website error log and there was no relevant error message at the same time.
Attachment 19341Attachment 19340
Latest log
Website log:
Attachment 19342
error log:
Attachment 19343
Fresh install of 1.5.7b with Edit Orders, Clone Template, TY Package tracker, & Shopping Cart Reminder mods
php73
Haven't used EP4 since version 1.5.6c
Does this mod work with 1.5.7b? I gone back thru the last couple of years of comments, looks like one person installed with errors but no direct resolution posted.
Anyone have this functioning on 1.5.7b?
Sure do, works a good as ever.Quote:
Originally Posted by Carbonless
Quote:
Originally Posted by zswll2
Unfortunately, and I have no idea how it got there, but there is an extra period at the end of line 160 of admin/easypopulate_4_attrib.php. This does cause a mydebug log to be generated (if your system is properly setup to log myDebug logs) that reads like so:Quote:
Originally Posted by zswll2
To fix the issue change:Code:[DATE TIME TIMEZONE] PHP Parse error: syntax error, unexpected '.' in /filepath_to_admin/easypopulate_4_attrib.php on line 160
[DATE TIME TIMEZONE] Request URI: /admin/index.php?cmd=easypopulate_4, IP address: IP_ADDRESS
--> PHP Parse error: syntax error, unexpected '.' in /filepath_to_admin/easypopulate_4_attrib.php on line 160.
to:Code:$products_options_values_sort_order = $products_sort_order_start;.
Code:$products_options_values_sort_order = $products_sort_order_start;
Quote:
Originally Posted by Carbonless
Just as well in reviewing the issue that was previously discussed/corrected about using the basic attribute import, see: https://www.zen-cart.com/showthread....36#post1376036Quote:
Originally Posted by jeking
Have found a few minor things to correct addressing some of the more strict PHP usage, but functions.
Apparently, I had started the development of considering an alternate primary key, but had not completed it. I am incorporating the below changes (outside of specific code for products_upc) into the distribution to allow further use/development of an alternate primary_key. Note that I may have missed something and would appreciate input on improvement. I do know that for example the detailed attributes handler still uses the v_products_id column primarily for import although there are messages that relate to the primary key being something else as well...Quote:
Originally Posted by jsarwar
Anyways, I am providing the needed file changes in reverse order from the bottom of the file to the top so that regardless additional changes personally made at least there is a chance that the instruction can be followed. I am using 4.0.37.10 against which to reference.
So starting in admin/easypopulate_4_import.php at line 1647 adding the code in green:
Line 1601:Code:if (!in_array($chosen_key, array('v_products_id', 'v_products_model'))) { $chosen_key_sub = $chosen_key;
if (strpos($chosen_key_sub, 'v_') === 0) {
$chosen_key_sub = substr($chosen_key_sub, 2);
}
$sql = $db->bindVars($sql, ':' . $chosen_key_sub . ':', (!empty(${$chosen_key}) ? ${$chosen_key} : ''), $zc_support_ignore_null);
}
$result = ep_4_query($sql);
Line 1190:Code:if (!in_array($chosen_key, array('v_products_id', 'v_products_model'))) { $chosen_key_sub = $chosen_key;
if (strpos($chosen_key_sub, 'v_') === 0) {
$chosen_key_sub = substr($chosen_key_sub, 2);
}
$sql = $db->bindVars($sql, ':' . $chosen_key_sub . ':', (!empty(${$chosen_key}) ? ${$chosen_key} : ''), $zc_support_ignore_null);
}
$result = ep_4_query($sql);
Line 269:Code:if (!in_array($chosen_key, array('v_products_id', 'v_products_model'))) { $chosen_key_sub = $chosen_key;
if (strpos($chosen_key_sub, 'v_') === 0) {
$chosen_key_sub = substr($chosen_key_sub, 2);
}
$sql = $db->bindVars($sql, ':' . $chosen_key_sub . ':', (!empty(${$chosen_key}) ? ${$chosen_key} : ''), $zc_support_ignore_null);
}
$result = ep_4_query($sql);
In admin/easypopulate_4_import.php add the notifier that will be needed to execute the code by making the following change(s) of adding the code that is in green (with the switch statement beginning at/near line 98):Code:if (ep4_field_in_file($chosen_key) && !in_array($chosen_key, array('v_products_id', 'v_products_model'))){ if (!in_array($chosen_key, array('v_products_id', 'v_products_model'))) {
$chosen_key_sub = $chosen_key;
if (strpos($chosen_key_sub, 'v_') === 0) {
$chosen_key_sub = substr($chosen_key_sub, 2);
}
$sql = $db->bindVars($sql, ':' . $chosen_key_sub . ':', $items[$filelayout[$chosen_key]], $zc_support_ignore_null);
}
}
$result = ep_4_query($sql);
In admin/includes/functions/extra_functions/easypopulate_4_functions.phpCode:switch (EP4_DB_FILTER_KEY) {
case 'products_model':
$chosen_key = 'v_products_model';
$chosen_key_sql = "
p.products_model = :products_model:";
$chosen_key_sql_limit = " WHERE (products_model = :products_model:) LIMIT 1";
break;
case 'blank_new':
case 'products_id':
$chosen_key = 'v_products_id';
$chosen_key_sql = "
p.products_id = :products_id:";
$chosen_key_sql_limit = " WHERE (products_id = :products_id:) LIMIT 1";
break;
default:
$chosen_key = 'v_products_model';
$chosen_key_sql = "
p.products_model = :products_model:";
$chosen_key_sql_limit = " WHERE (products_model = :products_model:) LIMIT 1";
$zco_notifier->notify('EP4_IMPORT_DEFAULT_EP4_DB_FILTER_KEY_DATA', EP4_DB_FILTER_KEY, $chosen_key, $chosen_key_sql, $chosen_key_sql_limit);
break;
}
$zco_notifier->notify('EP4_IMPORT_AFTER_EP4_DB_FILTER_KEY');
beginning at line 494 where the function ep_4_remove_product is initially defined, modify it to include the below content in green:
In admin/includes/modules/easypopulate_4_featured_ep.php at line 36:Code:function ep_4_remove_product($product_model) { global $db, $ep_debug_logging, $ep_debug_logging_all, $ep_stack_sql_error, $zco_notifier, $zc_support_ignore_null;
$project = PROJECT_VERSION_MAJOR.'.'.PROJECT_VERSION_MINOR;
$ep_uses_mysqli = ((PROJECT_VERSION_MAJOR > '1' || PROJECT_VERSION_MINOR >= '5.3') ? true : false);
$sql = "SELECT p.products_id FROM ".TABLE_PRODUCTS . " p";
switch (EP4_DB_FILTER_KEY) {
case 'products_model':
$sql .= " WHERE p.products_model = :products_model:";
$sql = $db->bindVars($sql, ':products_model:', $product_model, $zc_support_ignore_null);
break;
case 'blank_new':
case 'products_id':
$sql .= " WHERE p.products_id = :products_id:";
$sql = $db->bindVars($sql, ':products_id:', $product_model, 'integer');
break;
default:
$sql_add = " WHERE p.products_model = :products_model:";
$zco_notifier->notify('EP4_FUNCTION_REMOVE_PRODUCT', $product_model, $sql_add);
$sql .= $sql_add;
unset($sql_add);
$sql = $db->bindVars($sql, ':products_model:', $product_model, $zc_support_ignore_null);
Code:$sql = $db->bindVars($sql, ':products_model:', $items[$filelayout['v_products_model']], $zc_support_ignore_null); $sql = $db->bindVars($sql, ':products_id:', $items[$filelayout['v_products_id']], $zc_support_ignore_null);
if (!in_array($chosen_key, array('v_products_id', 'v_products_model'))) {
$chosen_key_sub = $chosen_key;
if (strpos($chosen_key_sub, 'v_') === 0) {
$chosen_key_sub = substr($chosen_key_sub, 2);
}
$sql = $db->bindVars($sql, ':' . $chosen_key_sub . ':', $items[$filelayout[$chosen_key]], $zc_support_ignore_null);
}
$result = ep_4_query($sql);
The above changes are captured at: mc12345678/EasyPopulate-4.0 at v4.0.37.11 (github.com)
Create a new observer file:
admin/includes/classes/observers/class.easypopulate_4_default_ep4_db_filter_key_observer.php
with the following contents:
Then add an autoloader to implement the above code:Code:<?php/* This is an observer class to take action when the ep4_db_filter_key is processed/determined.
It is expected to set the variables needed within EP4 to support an alternate primary key.
*/
class ep4_db_filter_key extends base
{
public function __construct()
{
$attachThis = array();
$attachThis[] = 'EP4_MODULES_FILELAYOUT_CHOSEN_KEY';
$attachThis[] = 'EP4_IMPORT_DEFAULT_EP4_DB_FILTER_KEY_DATA';
$attachThis[] = 'EP4_FUNCTION_REMOVE_PRODUCT';
$this->attach($this, $attachThis);
}
public function updateEp4ImportDefaultEp4DbFilterKeyData(&$callingClass, $notifier, $ep4_db_filter_key, &$chosen_key, &$chosen_key_sql, &$chosen_key_sql_limit)
{
if ($ep4_db_filter_key == 'products_upc') {
$chosen_key = 'v_products_upc';
$chosen_key_sql = "
p.products_upc = :products_upc:";
$chosen_key_sql_limit = " WHERE (products_upc = :products_upc:) LIMIT 1";
}
}
public function updateEp4ModulesFilelayoutChosenKey(&$callingClass, $notifier, $emptyArray, &$chosen_key)
{
if (EP4_DB_FILTER_KEY == 'products_upc') {
$chosen_key = 'v_products_upc';
}
}
public function updateEp4FunctionRemoveProduct(&$callingClass, $notifier, $key_value, &$sql_add)
{
if (EP4_DB_FILTER_KEY == 'products_upc') {
global $chosen_key, $chosen_key_sql, $zc_support_ignore_null;
if (in_array($chosen_key, array('v_products_id', 'v_products_model'))) {
return;
}
$sql_add = $chosen_key_sql;
$chosen_key_sub = $chosen_key;
if (strpos($chosen_key_sub, 'v_') === 0) {
$chosen_key_sub = substr($chosen_key_sub, 2);
}
$sql_add = $db->bindVars($sql_add, ':' . $chosen_key_sub . ':', $key_value, $zc_support_ignore_null);
}
}
}
admin/includes/auto_loaders/easypopulate_4_ep4_db_filter_key.php
Then to possibly "pull it together" in:Code:<?php
/* loads and instantiates observer class within the admin file structure
*/
$autoLoadConfig[0][] = array(
'autoType' => 'class',
'loadFile' => 'observers/class.easypopulate_4_default_ep4_db_filter_key_observer.php',
'classPath' => DIR_WS_CLASSES,
);
$autoLoadConfig[180][] = array(
'autoType' => 'classInstantiate',
'className' => 'ep4_db_filter_key',
'objectName' => 'ep4_db_filter_key_obs',
);
admin/includes/extra_configures/
create a file, perhaps named: easypopulate_4_ep4_db_filter_key.php
While I have not tested the above, it appears that it will have the desired effect. What it will do, by the "last" file is assign the filter key (primary key) to be products_upc which is then used/evaluated in the import process. Because that key doesn't exist within the basic structure, the default code is executed. Initially there are default values applied, but then a notifier is called to allow some modification at that point.Code:<?php
/* This hard codes the filter_key designation which will override the database setting for the same variable.
The intent is to force EP4 to use the following EP4_DB_FILTER_KEY setting.
Doing so is intended to treat the defined variable as the primary key when exporting and importing data.
Upon successful use, the associated database field could be updated to recognize this variable. */
define('EP4_DB_FILTER_KEY', 'products_upc');
Within the observer, the suggested key is evaluated and if it meets the desired value, the variables $chosen_key, $chosen_key_sql, and $chosen_key_sql_limit are each set to what appear to be valid values for this situation where the upc is expected to be either actually or at least desired to be handled as a unique key/value... If the database does not contain unique data, then importing data matching a key that is non-unique will cause all such similar to be updated and not just the first one found, this is along the lines of having linked product in multiple categories.
If that seems to work as desired (again note that only able to update based on products_upc if the admin/includes/extra_configures file is still in place and/or the define is "active"...), then can update the configuration key to have an additional value available from which to select so that you can better control the primary key that is being used. To add the products_upc option to the configuration selector run the following sql:
The above sql statement doesn't update the configuration_description text to include information about what that selection does, but understand that there is no code currently incorporated about supporting a "blank" value for the products_upc when products_upc is set as the primary key...Code:UPDATE configuration SET set_function = 'zen_cfg_select_option(array(\'products_model\', \'products_id\', \'blank_new\', \'products_upc\'),' WHERE configuration_key = 'EP4_DB_FILTER_KEY';