Oh and as for the dropdown selections. Leaving the status as is only exports active products. To export all product the status needs to be changed to all. Otherwise disabled product will not be exported.
Printable View
Oh and as for the dropdown selections. Leaving the status as is only exports active products. To export all product the status needs to be changed to all. Otherwise disabled product will not be exported.
Are these the four pieces of information used to identify the specific attribute which you are are referring to?
v_products_attributes_id
v_products_id
v_options_id
v_options_values_id
For your convenience here's the complete list of Easy Populate 4.0.35.ZC - 04-29-2016 with attrib patch
Detailed Products Attributes (detailed multi-line) Download
Export csv column names from the Attrib-Detailed-EP file . . .
v_products_attributes_id
v_products_id
v_products_model
v_options_id
v_products_options_name
v_products_options_type
v_options_values_id
v_products_options_values_name
v_options_values_price
v_price_prefix
v_products_options_sort_order
v_product_attribute_is_free
v_products_attributes_weight
v_products_attributes_weight_prefix
v_attributes_display_only
v_attributes_default
v_attributes_discounted
v_attributes_image
v_attributes_price_base_included
v_attributes_price_onetime
v_attributes_price_factor
v_attributes_price_factor_offset
v_attributes_price_factor_onetime
v_attributes_price_factor_onetime_offset
v_attributes_qty_prices
v_attributes_qty_prices_onetime
v_attributes_price_words
v_attributes_price_words_free
v_attributes_price_letters
v_attributes_price_letters_free
v_attributes_required
v_products_attributes_filename
v_products_attributes_maxdays
v_products_attributes_maxcount
While I did not go line for line through the entire list, the four items are correct and the rest look correct.
I think there is a misunderstanding of what I'm trying to accomplish. I am trying to learn how to take a set of products/categories (including their detailed attributes info) from one store and add them to another store. So, as a first step in learning how to do this, for simplicity I tried in the above example to just go ahead and import all the products/categories including their detailed attributes and I failed.
So, maybe it is less confusing if I ask the direct question . . .
What is the procedure for getting a set of products including their detailed attributes from one store into another store?
Export the database of the old store (phpmyadmin), import the database into a new/equivalent (not older) store, upload zc_install for the version of the destination store. Access the new store using zc_install on the path, provide the admin credentials of the old store. Select database upgrade. That is the basic "upgrade" ones site instruction that is probably better described here.
If the other additional information is not desired, then would still suggest a similar process but use an intermediate "site" on which to upgrade the database, then to export the applicable product table data (multiple tables) and import to the new store (replacing existing content).
Otherwise up to the point of detailing the attributes with the extra data, EP4 at least carries over the "basics" of the product when trying to do such a move. The last step requires a bit of shuffling.
Thank you. I apologize for not being clearer, but please allow me to continue to try. I asked, "What is the procedure for getting a set of products including their detailed attributes from one store into another store?"
To further clarify, they are both existing stores and both have existing products. So, I do not want to "replace existing content" nor destroy any content in the 2nd store. For clarity, let's call that store, "Store 2" instead of "new store," since it is not a new store.
Definitions -
Store 1 is the store with the desirable subset of products (many of which have attributes). I think of it as the "Donor store."
Store 2 is the store that wants to sell a subset of Store 1's products. I think of it as the "Recipient store."
What is the procedure for getting the set of products including their detailed attributes from Store 1 into another Store 2?
So, I'm going to stick with describing how one could do this with EP4 at the moment. Another method that comes to mind would be to "simply" export the various attributes related tables and make changes to them to match up with what is available in store 2 and then import the new/revised data. Not what I would consider a quick task.
Regarding EP4. If store 1 has a unique model # for each product and the option names are unique (only one instance of the option name in all of the option names), then the import of the first two files has populated store 2 with all of the attributes of the product from store 1. What is missing though is the detail associated with each attribute. So, to update store 2's attribute details, a file has to be generated such that each of the four primary keys match an existing entry in the attributes table. So, how to accomplish this?
Here's what I see. It is possible at this point to export the detailed attributes from both store 1 (already have) and store 2. Each of these has text versions of the option names and option values names. The model number is whatever it is and the products_attributes_id is expected to be unique to each store.
So what I would do would be to sort the data in both detailed lists on three fields in the same "order" (either ascending or descending but make it the same on both spreadsheets) such that sorted by products_model, then option_name, and then option_value_name.
Then pick the method/location desired, but the goal is to eliminate from the list for store 2 any product that is not in store 1. This would be by a comparison of products_model. For now, also eliminate from store 1 any row that doesn't have a model #. (will have to address that separately because really that product never got uploaded to store 2, but at least the list should be small.)
Then begin moving entire rows as necessary such that the row in store 1 lines up with the row of store 2 by first comparing option names then option value names. Provided nothing "new" has been done with store 2, these should line up exactly.
Then once all have been lined up, copy the primary field data from store 2 over the data of the same field for store 1. Once all four columns are copied, save the file as the csv file to be uploaded and then imported into store 2.
Obviously through this process you'll want to save a backup of the file(s) to minimize any rework. Keep in mind the filenaming convention needed by the plugin.
And with that, the new file when uploaded and imported to store 2 should have store 2 with the same attributes and details of attributes as store 1.
Will do. And FYI I started an issue on github to try to do this programmatically when a detailed import fails so completely. Error handling will be interesting. :p considering as the file is parsed the error(s) are generated. The thought though is that if they don't work out in the end to go back and follow the above process "internally".
How do we get EP4 to export, import and update the sort order for categories, products and attributes display?
EP4 is already exporting, importing and updating these items but just isn't including the various sort order fields.
Please see attached spreadsheet which organizes the problem by showing the Zen Cart database fields that should be included in EP4 export, import and updating.
This is an extension of, What is the procedure for getting the set of products including their detailed attributes from Store 1 into another Store 2?
Attachment 16399
For categories, you would need to use the category related downloads which are not in your list of the spreadsheet.
For attributes, ultimately should state please revisit the instructions, but the sort order at least for option values is in a series of 10 value increments for each individual option value added to the option name. I also see in the import code that there are several sort order import fields that are available for the above orders of concern. The products_attributes sort order is primarily important for the store front as it is the sort order applied there that will determine how ZC default attribute handling is controlled when sort order is applied.
This is conceptually trivial. I just want EP4 to include all the SORT ORDER fields which are associated with some of the fields EP4 is already including. That's it.
Let's review.
EP4 exports, imports and updates certain data related to categories, products and attributes. However,
EP4 DOES NOT export and/or import and/or update the complete set of SORT ORDER fields for categories, products and attributes which control the display sort order of categories, products and attributes in the Zen Cart store.
1. Using EP4 "Filterable Exports:" "Download Type" of "Complete Product" EP4 exports a Full-EPyyyymmmdd-tttttt.csv file.
Among the fields (columns) that are exported is v_categories_name_1
Unfortunately (and mysteriously) the SORT ORDER field associated with v_categories_name_1 (i.e., categories.sort_order) is not exported. Therefore, I want it to be exported so when I use EP4 "input" "full data file" the sort order field associated with v_categories_name_1 is also imported.
2. Using "Attribute Export/Import Options" "Basic Products Attributes (basic single-line)" EP4 exports an Attrib-Basic-EPyyyymmmdd-tttttt.csv file.
Among the fields (columns) exported are v_products_options_type, v_products_options_name_1, and v_products_options_values_name_1
Unfortunately, and mysteriously, the SORT ORDER field associated with these 3 fields (i.e., products_options.products_options_sort_order, products_options_values.products_options_values_sort_order, and products_options.products_options_sort_order) are not exported. Therefore, I want them to be exported so when I use EP4 "input" "attrib-basic-ep" the sort order field associated with v_products_options_type, v_products_options_name_1, and v_products_options_values_name_1 are also imported.
3. Using "Attribute Export/Import Options" "Detailed Products Attributes (detailed multi-line)" EP4 exports an Attrib-Detailed-EPyyyymmmdd-tttttt.csv file.
Among the fields (columns) exported are v_products_options_type, v_products_options_name, and v_products_options_values_name
Unfortunately, and mysteriously, the SORT ORDER field associated with these 3 fields are not exported. Therefore, I want them to be exported so when I use EP4 "input" "attrib-detailed-ep" their associated sort order fields are also imported.
Note: Interestingly, EP4 does export the sort order for products_options (i.e., v_products_options_sort_order) but,mysteriously, not the other sort order fields.
I thought I would just add the SORT ORDER fields to the various areas areas of EP4 code in files:
1. easypopulate_4_export.php
2. easypopulate_4_filelayout.php
3. easypopulate_4_attrib.php
4. easypopulate_4_import.php
Alas, I can't figure out how to do it. So I'm going to have to give up on EP4 unless someone comes to the rescue.
zencart version 155a
getting this error
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
how to solve?
What was being performed?
Version of EP4?
Source of file if occurred during import? (was this an import of a file that was exported but not modified? If modified, with what?)
Is there a debug.txt file in your list of files? What are it's contents (shouldn't have any admin information nor specific database credentials.)
Here is the info
Attachment 16417
The error file says
[12-Jun-2016 07:11:19 Europe/Berlin] Request URI: /zencart/framecraft/newsite/w4reh0use/easypopulate_4.php, IP address: ::1
#1 mysqli_num_rows() called at [D:\xampp\htdocs\zencart\framecraft\newsite\w4reh0use\includes\functions\extra_fu nctions\easypopulate_4_functions.php:84]
#2 ep_4_SBA1Exists() called at [D:\xampp\htdocs\zencart\framecraft\newsite\w4reh0use\easypopulate_4.php:272]
[12-Jun-2016 07:11:19 Europe/Berlin] PHP Warning: mysqli_num_rows() expects parameter 1 to be mysqli_result, boolean given in D:\xampp\htdocs\zencart\framecraft\newsite\w4reh0use\includes\functions\extra_fu nctions\easypopulate_4_functions.php on line 84
ITS A FRESH INSTALL IN ZENCART 155a
It looks like at one time you have installed Stock-By-Attributes and then emptied the table but didn't delete the table. If you don't run SBA, then may I suggest the following SQL to be put into the tools->install SQL patches text box.
Also, may I suggest that you rename your admin folder as it has now been posted for all to see, read, or navigate.Code:drop table products_with_attributes_stock
Thanks for early reply , stock by attributes needed
the admin name is for my local machine , online its different anyway will take care of
Hello, my question is this, but if I want to add products to existing ones, there is a blank template in order to submit the new products? and the id of these products as are placed, in succession to the existing ones? Thank you
The best template is to create one from your own store. Export the full store for example and you can see what information is used to describe your product.
As to the products_id and numbering. If you use the model# then yes the products_id is expected to be the next available products_id basically using the database tables definition of what is next. (autogenerated number) if you use products_id as your unique identifier, then autogeneration only occurs when the selection of blank_new is made in the configuration window and the field is left blank on import. Otherwise the product will take the products_id that is assigned for that row.
It is relatively versatile and has many ways to accomplish the desired task even if there are a few things still on which to improve.
zc1.5.5a upgraded site hosted on a CentOS 6.7 server running php5.3.3
EP4 Config and import error screenshots attached
EasyPopulate-4.0-4.0.35.ZC acquired from github here
https://github.com/chaddro/EasyPopulate-4.0
exported complete products csv for template Full-EP2016Jun13-1301.csv
confirmed categories exist
confirmed syntax for category^subcategory
confirmed date syntax
not using SBA
created single product csv for import ClassesForEveryone.csv
getting errors for character limit of category and sub category on import
tried increasing character limit for these fields in MySQL as suggested in earlier posts from this thread. I still get error like op.
category name and sub category names character count does not exceed limits but I still get error and import fails
What am I missing?
Should this version of EP4 work with zc1.5.5a? If not is there a roadmap for when it will? And or is there a version of EP4 that is known to work with a specific version of ZC1.5x?
Thank you for your hard work on this mod. My client who owns this shop had been using 1.2.5.7 in zc1.3.9h for many years without issue.
Attachment 16429
Attachment 16430
Huh... Hard to believe it, but apparently there was an incomplete thought in the code when trying to add this type of check for both UTF-8 related databases/stores as well as for those not (BTW, highly suggest running the DB2UTF8 upgrade on your clients computer unless they have a specific reason to not use UTF8 and to update the configure.php files, the language file(s), and I think there is one other location that needs to be updated, though the plugin should identify those for you.)
So, in admin/easypopulate_4_import.php
line 1138 change from:
To:Code:if ((function_exists('mb_strlen') && mb_strlen($categories_names_array[$lang['id']][$category_index]) > $categories_name_max_len) || (!function_exists('mb_strlen') && strlen($categories_names_array[$lang['id']][$category_index]))) {
As to operation with ZC 1.5.5.a, it does, though again one of the things primarily expected in ZC 1.5.5.a is that all things database relate to UTF-8 or as applicable utf8...Code:if ((function_exists('mb_strlen') && mb_strlen($categories_names_array[$lang['id']][$category_index]) > $categories_name_max_len) || (!function_exists('mb_strlen') && strlen($categories_names_array[$lang['id']][$category_index]) > $categories_name_max_len)) {
Correction shown here.
And sorry, I may have gotten ahead of myself about the database not being in UTF-8... It would appear that really it is that one or more multibyte related functions are not present which is not necessarily indicative of UTF-8 support. Sorry about that.
I think you might be onto something actually with the UTF8 thing. The product descriptions are full of special character issues after I upgraded to 1.5.5a. The client does use MS Excel even though I've advised them not to. However, in the older version of EP we were able to work out a workflow that allowed them to use MS Excel.
Anyhow when creating the copy of the db I accepted the defaults for encoding and coalition. I'm not even sure what the system defaults are for either. I'm going to try an upgrade explicitly defining these before importing the db and executing the upgrade. I'll post back here when I get there with my findings. Good to know it's expected to work in 1.5.5a. Thanks for the quick response!
There are some filters included/incorporated here as well. There are some Internet instructions about how to "truly" export a csv file from Excel which involves several steps when I last looked at it. Otherwise from report by others it can be done from Excel. When I was doing some testing a long while back the biggest heartache was the date format and converting/setting it to the php format of YYYY-MM-DD (which BTW, is a great sequence to support sorting by date). Anyways, Excel tends to offer date/time in a more "convenient" format for example xx Mon YY or Mon xx, YY.
I do plan to add the ability to switch to tab delimitation from within the admin in the near future, but in the mean time you could modify the variable at the top of admin/easypopulate_4.php to use "\t" instead of ","
A lot of different options, just some things have been left in the background instead of adding all types of "features"
Using Easy Populate 4.0.28 - Beta 01-03-2015. I have over 25K items in my inventory. While attempting to download my complete inventory file I get the error message
[an error occurred while processing this directive]
Refresh the screen with same result. When I go back I find 2 files of different file sizes - 10885815 and 10370426. When looking at these files some of my newly added items with Easy Populate are missing. To get those I must use the filters when downloading. When I download those smaller files everything works ok.
I also cannot use the search to find these newly added items. The wesbsite search for customers works fine. If I want to make a change to the listing I must pick pages and go up or down to find the item.
What is the characterset for your database, in your includes/configure.php, in your includes/languages, etc?
EP4 uses UTF-8, using/having Latin-xxxx or other such character sets may cause the search issue identified.
The "error" is related to processing time. There is a setting in the configuration window for this as well I believe ZC has a similar setting (overrides or attempts to override the php.ini assignment). Because the category is smaller than the entire catalog this is why such "individual" downloads are successful. And yes, a "second" download tends to be created with a separate time stamp in the filename. The missing "newly" uploaded EP4 items from the download is because the new items have a higher products_id than the point at which the timeout occurs and therefore not included in the large single file download.
Another factor of consideration was the extent of content upload.
From the easy populate screen - Internal Character Encoding: ISO-8859-1 DB Collation: latin1. From the file includes/configure.php - define('DB_CHARSET', 'latin1'). From includes/languages, etc. I cannot help because you file not give a file name and I do not know where to look for etc.
I have changed the Script Execution Time to 100000 seconds. No change as the error screen still comes up when downloading the complete inventory file.
The other language file would be either:
Includes/languages/YOUR_LANGUAGE/YOUR_TEMPLATE/locale.php
Or
Includes/languages/YOUR_LANGUAGE/locale.php
Or English in place of YOUR_LANGUAGE in the above order of precedence.
Have you considered converting your database to utf-8 using the plugin db2utf8? Is this something your business target could support or is latin1 required to support operation?
Includes/languages/YOUR_LANGUAGE/YOUR_TEMPLATE/locale.php - not found
Includes/languages/YOUR_LANGUAGE/locale.php - not found
Have you considered converting your database to utf-8 using the plugin db2utf8? Is this something your business target could support or is latin1 required to support operation? - I do not know how to do that.
Here is another post https://www.zen-cart.com/showthread....e-NOT-in-Admin
This is were I first noticed the problem. Thank you!
Another place to try to set the timer for ZC is in configuration->My Store->Admin Set max_execution_time for processes (default is 60).
In ZC forums, typically something like YOUR_LANGUAGE or YOUR_TEMPLATE refers to substitution of the content associated with the words. So if you operate your store in English only the the path would be like includes/languages/english/YOUR_TEMPLATE/locale.php or if a file doesn't exist in the directory name used for your template then the system would fall back to includes/languages/english/locale.php.
Yeah, I saw that thread which was what led me to ask about how the 1400+ items were added.
The plugin db2utf8 is not complex to use. It has instructions and there are no files overwritten. The database should be backed up before using it though.
The files listed above would need to be modified (instructions tell you which). The process is relatively painless and quick.
I changed it to 600 with no luck.
Thank you. I will give it a try.
Well, while I haven't gone back to review the history of development and possible explanation on the topic, I believe one of the reasons the dropdown options were provided in the upper area was to address the export of such a large database considering there is an import method offering a similar breakup (split).
I have seen this behavior (having to export some form of sub-group) needed for other large databases some smaller in total number of product but with an additional language.
Where would this debug.txt file exist? I have searched everywhere with no luck.
I went to my live site and I cannot import I get the following. As you can see "Printers & Printer Parts" is not longer than 50 chars.
Quote:
SKIPPED! - Model: 100323280 - Category name: "Printers & Printer Parts" exceeds max. length: 50
SKIPPED! - Model: 100334815 - Category name: "Printers & Printer Parts" exceeds max. length: 50
SKIPPED! - Model: 100361358 - Category name: "Printers & Printer Parts" exceeds max. length: 50
For me it is not and I do have debug turned on in settings.
For this issue see post 2524
Your host is not supporting part of the multi-byte functionality and when I expanded support to allow continued operation, I left off a comparison which forces that error even for something with a single character.
My OS is Linux with PHP 7, Apache 2 and Mysql Ver 14.14. I have Easy Populate 4. with Zencart 1.5.5a I was unable to import a csv file because I was getting errors for character limit of category - although the characters in that field were less that 15. So I rebuilt PHP and enable mbstring . I restarted mysql and apache but now I cannot access the admin section of Zencart. The front end is okay. I am getting this: "The page you are trying to view cannot be shown because the authenticity of the received data could not be verified." So it has something to do with the way config.php is accessing ssl or is it curl?
Here is how I configure PHP:
-with-gd --with-pdo-mysql --with-zlib --with-openssl --with-curl --with-mysqli --with-apxs2=/var/lib/apache2/bin/apxs --with-jpeg-dir=/usr/ --enable-mbstring
So, seems a few good things/actions being taken because of an accidental lapse in a comparitor in the code that is posted about in the last several pages, but I would say that the issues involved are a little beyond the scope of this particular thread. There's an entire section area about setting up to run a ZC version on particular servers/OSs. It does appear that it could be related to the items identified, but also several others.
May I suggest either starting a new thread or continuing to search either the Zc forum or outside of it to identify a solution to the issue associated with install/setup of the server software.
As I mentioned somewhere, I reinstalled Zencart and was able to access the admin and other functions. I then installed Easy Populate 4. It appears as expected under Tools but when I click on it I get a "Secure Connection Failed" message in Firefox. Tried Chrome with a similar result. It is odd because php and the ssl certificate is working elsewhere on the server. Perhaps there is a directory that is configured with the wrong permission - but I would expect Easy Populate to say so. Very frustrated with this. Would appreciate advice.
Definitely a new "issue" not seen before in my experience.
That said a few things to try.
So you are able to navigate to other areas of the admin and not get a similar error?
Are you able to click the check for upgrade button on the top right of ZC and also not get the same error?
Are there any recent/related log errors in the ZC logs folder? (can post but obscure/rename the provided admin folder name.)
Are you able to access the remove operation or is there no access at all to the screen?
Are there now any server logs associated that identify an "inappropriate" operation? Things that happen on this screen are database lookups, server file reviews, potential database modification of the configuration settings, reachout to the ZC server for version status using either built-in ZC code or if not present a duplication of that code.
Tried re-uploading the files (possibly again I understand)?
I'll have to think of a few other possibilities, but if an error related to the code could be identified, then something more direct could be offered. :/
The update check in Zen Cart works as does everything else. When I click on Tools/Easy Populate it throws a series of this in the main server error logs:
[core:notice] [pid 14902:tid 3086542528] AH00052: child pid 17380 exit signal Segmentation fault (11)
A thought - where does Easy Populate store its keys? In the user's zencart directory, in the mysql database, or elsewhere on the server? When I reinstalled zencart and then Easy Populate I did not remove the keys from the previous configuration. (I was unable to access the admin.) Could this be the problem?
Also deleted Zencart and the mysql database, Reinstalled Zencart and a new mysql database. Then installed Easy Populate 4.0 Same segfault. Is there a manual way to initialize Easy Populate or is there a more recent version?
The only database edit made by installing the files to the server for EP4 is the registration of the admin page as provided by admin/includes/functions/extra_functions/reg_easypopulate_4.php
The next database editing performed is what is done when the install link is selected at the top of the screen once the EasyPopulate v4 tools menu option has been selected. From the sounds of it, this action was previously performed on the database when the error was presented regarding the category name length being too long (an issue identified several times in the last couple of pages with a solution also given).
If the store files were rebuilt on the same database, and EP4 reuploaded, then all of the database data would still be in place to support continued use.
The database install script (run the first time EP4 was installed to whatever database was used) is found in the admin/includes/functions/extra_functions/easypopulate_4_functions.php file. There is also a function that does a remove in the same file. Assuming that nothing in admin/easypopulate_4.php is causing the error on this system before the install/remove code in that file, then the remove option could be put on the url to try to execute the removal code.
That said, there are no files stored to the system by the code other than export of a csv that contains database information or a debug text file when attempting to process information in or out of the database. All settings are stored in the configuration table (with applicable database prefix) other than the registration of admin windows like in the first file mentioned. All initial database modifications are covered in that install function of the file described above. There are two functions adjacent to that one which will "monitor" the location of the temporary file to attempt to not have the admin directory name stored in the database.
If more detailed instruction/description is desired, I'll have to dig deeper, but it would also help to understand more about the history of the current database and if there is anything more direct that can be provided as to the log(s) of issues.
Lastly, I just did an Internet search on "exit signal segmentation fault (11)" and things pointed back to server setup, php.ini, thread/child node behavior, and a number of other things, but typically not the original php code. :/
As to "more recent" the patches identified here in the thread related to the version downloadable from the ZC website have been applied to the github version that I maintain while I continue to work on a few other branches to apply the next set of features.
Thank you for your advice and taking time with this. When I run strace on easypopulate_4.php it throws this error:
write(1, "ERROR: admin/includes/configure."..., 89ERROR: admin/includes/configure.php file not found. Suggest running zc_install/index.php?) = 89
Should I assume that it does not know where the (renamed) admin directory is? configure.php is there in the includes directory. What permissions should it be?
Typical permissions upon install are 644 for the admin/includes/configure.php file, with suggestion to set to 444 to prevent writing/rewriting. EP4 doesn't modify this file and is only pulled for use by including application_top.php which loads the admin configure.php file. Perhaps something is amiss with the file? But this also further doesn't exactly make sense if this plugin is the only admin tool that is causing this issue. :/
One of the suggestions I came across was to tie to the parent process that appears to be causing the issue and as part of that tie to include a back trace logged error to identify where in execution the error is truly occurring. :/
While this may come as a shock to some/many and with considerable thought, today a different plugin that performs the same actions as EP4 has been submitted as well a different plugin with no collaboration to develop or consider as a straight replacement for EP4. As some of the heavy hitting plugins have previously gone with multiple variants, I do not see that such a thing should continue to occur. While I have not performed any testing of this new plugin, I have no doubt that any issues (if they exist) will be rectified. I have already notified the original author of EP4 of my concerns. I am further aware that it doesn't include the SBA added functionality of EP4, but that can and will be addressed separately as well as other developed plugins.
Because that plugin has been so developed and it offers additional fields the ability of which is not built into EP4 at this time, I call to you the user community about the specific need of EP4 although some of the other features identified in that plugin can and were to be added to EP4.
For those long-term Zenners, think back on the history of Stock-by-Attributes and the multiple variants that existed... This history doesn't need to be repeated.
I expect that plugin to be available by the end of the weekend. Meanwhile I probably will submit a final version that incorporates the bug fixes of the last couple of pages and continue to support the community in other ways unless some compelling reason exists for two individuals to support two different plugins that ultimately do the same thing.
Thanks for the heads-up. I'm excited to see it since you seem to be saying the "different plugin" "offers additional fields."
I'm hoping it offers the SORT ORDER fields I had to give up on as explained here
https://www.zen-cart.com/showthread....54#post1312654
Don't know. Unfortunately I had a detailed response for you, but in reply to someone else I lost it and didn't go back to recreate it. One of the sort orders though is already available in the categories import/export if I remember correctly, just not in the products list. As I recall also, one of the desired sort orders to be included/listed in conjunction with other data would have caused a sequencing issue without extensive rewrite for something covered in a separate area that is/was specifically designed to address that aspect.
For more information about the other plugin look through recent posts and maybe even reach out to lankeeyankee. As has come customary of most recent public plugins, the code can be previewed/downloaded from github.
The biggest difference I have seen is 1) good luck writing your own set of code to accomplish larger tasks, 2) get to know your specific import file because you will have to "choose" between various import options based on how the file was generated which may not be a big issue if one always follows the same process for each file, 3) supposedly the export auto_expands to include multiple fields rather than them being considered/added to the filter(s).
Haven't looked deeply at the import process but did seem some limiting factors related to number of fields, so hoping for those that like to otherwise limit the number of fields on which they upload that they can still do that.
One thing that really shouldn't surprise me is that one question has already been asked from the perspective of an action to be "incorporated" and pointed out as a "problem" of EP4, but has not as I have seen it been a requested feature or modification of EP4. Too bad, like many of the other improvements that were going to be made, such an additional option could have been added to EP4 upon request. My plan is to document possible improvements or the planned mods for EP4 in the original developers area. As said before I took this up because it had great promise, was functional, and support could not be provided by the original author because of other commitments. Further other EP products were non-functional out-of-the-box, didn't offer the same breadth of options, and were too rigid in their construct. This plugin has been around for 4 years, although only recently uploaded to ZC and apparently there remain mainy users that don't read the documentation and have gotten their sites into some trouble as a result (mostly related to the CHAR_SET being wrong between EP4 (strictly has been using UTF-8) and the site (possibly likely latin1) which was also something that was going to be addressed, but another no-need at this point).
Floor is still open on the topic of EP4, but other than the absence of SBA related items, which I seriously doubt would be included by the author because of a conflict of interest in their own commercial product, it seems to me to be the same thing just another variant. Such variants are expected to be minimized in and by the ZC community.
Hi
Is the manufactures_info getting the same ID's that manufactures ID table ?
This has been reported here ( well....more or less )
https://www.zen-cart.com/showthread....ML-v-2/page168
After doing some checking , I'm getting different ID's ....
so the $v_manufacturers_id = ($ep_uses_mysqli ? mysqli_insert_id($db->link) : mysql_insert_id()); is getting a higher number
Anyone else with this issue ?
(Note to mc12345678 : in this case, I'm importing the full EP4 file, no books )
Well , the only way I can get this to work is like this :
around line 1668
I guess the record_admin_activity is inserting also, and probably that's the ID that the manufacturer_info gets....PHP Code:
$v_manufacturers_id = ($ep_uses_mysqli ? mysqli_insert_id($db->link) : mysql_insert_id()); // id is auto_increment, so can use this function
if ($result) {
zen_record_admin_activity('Inserted manufacturer ' . addslashes($v_manufacturers_name) . ' via EP4.', 'info');
}
So the mysqli_insert_id($db->link) should be above that zen_record_etc function,,,,
Correct. The collection of the insertid should always be before any potential access of the database, which of course was supposedly already corrected, but apparently not. Will try to modify the location today, but if done earlier rather than later it will be directly in github which has the potential of being incorrectly typed because there is no copy and paste capability when directly entered. The fix path will be posted here for those stil using this.
Even though this new plugin has not adopted the EasyPopulate name, it still accomplishes the same thing and even touts that it is based on the EasyPopulate wiki "guidelines". The additional "features" it adds are available and we're planned on being incorporated into this. All that said, unless there is a valid business reason for the software that is EP4 to remain further updated, it is my consideration for the community for there to be less variants in existence and that all features and operations be consolidated (one goal of some of the changes that have been made to EP4 to allow other such variants to be sunset). Like other plugins of ZC, it will or should remain available, but is less likely to be modified to suit other needs that can be met with the recently released EP variant that is not called EP (personal decision of the creator).
Oh well , got to see that for curiosity, but for me the EP4 plus the books thing, it's fine.
Anyway, with this 2 plugins doing more or less the same thing, I want to public thank you for the work you implemented on EP4.
I think most people don't realize the amount of work it's involved for then to just upload a file, click and have a shop running. And for free.
So, yep, thanks.
Thank you mesnitu,
There are those that have paid to obtain desired functionality and allowed that operation to be incorporated for all to use and there have been conversations that have been had that identified ways that this could be made ever more versatile. Yes, there is or can be a lot that goes into making such a useful tool. As is the case with almost everything ZC, a business need generally births a business solution. Chadder saw this in his line of work and developed EP4 building off of those that collaborated before him and with him.##
I came across this software when trying to find a way to populate the store of a non-profit organization with a list of items provided to me using a spreadsheet. Later, after working with potteryhouse/jeking on Stock By Attributes, having a discussion with someone about the real world difficulty with performing an inventory of attributable stock, and trying to address the lack of attributable stock seen with ZC upon my first install of ZC back in 2011, I incorporated an SBA interface. In parallel and with a great deal of consternation I developed an intermediate plugin that would use the free existing CEON URI rewriter to auto-generate URIs through the use of EP4. I plan to continue to support these two additional features in my own way and to build them off of the new plugin (now available btw).##
Long and short of it, it's unfortunate that outside of this community (and inside of it by some) that ZC is no longer in the top pick of advertised eCommerce sites. The important thing for anyone reading is to take the time to post about an issue, to request a change (preferred over demanding one as so many seem to be doing these days), explain the why, etc... Mesnitu you did this in discussion of bookx and while you did the grunt work, a way to merge the functionality of it with EP4 was found and made. The same is true for the new software that it will be able to incorporate the features of the bookx plugin as well as the operations recently inquired about. ##
There are many that have left ZC to come back because of the difficulty experienced, lack of functionality, etc... with other product. The core developers have made a number of changes for the current (and future) version to try to give ZC a face-lift (a significant reason that "reviewers" suggest other such applications) and continue to incorporate new features, but it is through community input either by those that need something or those that have a vision that improvements can be made. The code issue identified above has existed since January 3rd, 2015 with the issue of version 4.0.28 when the zen_record_admin_activity function was first incorporated into EP4 to expand functionality to operate under ZC 1.5.4+. I would like to think that if someone had identified this earlier that it would have been commented on, discussed, or corrected for others to benefit and perhaps I did receive a side comment about it which got locally corrected and thought to have been applied for all. I'll provide my thoughts on correcting the condition in a separate post.
Has anyone had any success with DUAL Pricing v2 with EP4.0.35.ZC and ZC 1.5.5a. I have added to my_admin\includes\languages\english.php:
define('EASYPOPULATE_CONFIG_CUSTOM_FIELDS', 'products_price_w'); //Easy Populate, as indicated in the instructions but have not had any success with import and exporting with EP4.
EP4 page in ZC indicates on the right of the screen under Custom Products Fields: Dual Pricing Mod: TRUE.
Thanks
The EP4 instructions do not reference the specific constant (which if attempted above is incorrect) but instead the configuration screen area where custom fields can be entered (and not require a permanent override as attempted above). The same text of products_price_w could/would be used there to export/import. But be advised that there are a few issues with the current version of EP4 as documented over the last couple of pages.
The dual pricings mod referenced on the right side refers to options_values_price_w as found in the products_attributes table.
Thank you for your prompt reply but obviously I am in over my head here and am not clear with your response. More detailed instructions would be greatly appreciated that is of course that the dual price mod will work with the current version of EP4.
No problem. If the products_price_w field is in fact in the products table (appears like it should be based on the name), then with EP4 installed, goto configuration->Easy Populate then locate the the listing for User identified fields. In the right side of the screen, add products_price_w and update the field.
Now where products are exported (mainly the full export) the field will appear, and will also be "read" for import.
The caveat to this method is that anyone having admin access to those settings could modify the list of additional fields to import/export to/from the products table.
Easy Populate 4.0.35.ZC - 04-29-2016
Zen Cart 1.5.5a
Database Patch Level: 1.5.5
v1.5.5a [2015-01-01 05:44:52] (New Installation-v155a)
v1.5.5a [2015-01-01 05:44:52] (New Installation-v155a)
Im can not get my attributes to show on my products.
uploaded Complete products OK
uploaded Basic products attributes OK and showing in attributes conntrol
when i upload the detailed product attributes vie the Browes button i get File uploaded successfully:
But the attributes dont show on product.
if i upload via the import button i get File Import Completed with issues. & SKIPPED! - Attribute Entry on : - Not Found!
please help.
First, hopefully you have applied the various patches/modifications identified over the last 7ish pages (a lot of other conversations intermixed).
Secondly, upload places the files on the server. Import is what tries to push the product to the database.
In a default install, product_model is the primary key used to match the import record to the product. If the selected primary key is not found in the import file for the specific row, then the row is not imported unless the selected primary key option supports that type of import.
More to follow in a moment.
Sorry, had to reread the post to be sure that I was going to provide information that would help, but didn't want to delay you getting started with the above.
So after upload of the products file (file to appear in the section regarding full uploads), that file needs to be imported if it adds or modifies products. Provided a row has a matching primary key in it (settings of primary key are in the configuration menu for EP4), then the row will be imported.
Then once a product is present in the database with the desired primary key, the attributes basic file can be imported.
Import of the detailed attributes can then be performed after that. Again the primary key is important.
Thank you so much. Worked like a charm.
No problem, glad that helped. EP4 was designed with the intention of not "interfering" with any other EP variant, so the constant that was attempted was not picked up because it was for a different variant. For what it's worth and as it appears that you have just started using ZC, I might suggest transitioning to a newer application that reportedly performs the same actions as this code. Reason being is that at least I don't intend on continuing to modify this plugin to address anything other than errors within its described/intended use/operation and to cause two different variants of the same application to exist. This one tends to be "easier" to modify, but perhaps is not as informative (requires reading and understanding the instructions) while the other is easier to use as a store owner, but more intricate for making changes.
I had plans to take this to a more robust state, but have other things to which I can devote my time/interest because that effort has been done independent of EP4.
Im now getting
File Import Completed.
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.
and multiple variants of the same attribues
19 10.8cm x 10.8cm Tiles 12 Tile Mural Size: 43.2cm x 32.4cm
20 10.8cm x 10.8cm Tiles 6 Tile Mural 45.6cm x 30.4cm
20 10.8cm x 10.8cm Tiles 6 Tile Mural 45.6cm x 30.4cm
20 10.8cm x 10.8cm Tiles 6 Tile Mural 45.6cm x 30.4cm
Where are the multiple variants being displayed/presented?
What is the format of the import file? Is it comma separated for all of the data? (ie used Open Office as suggested in the early post(s) of this thread?) what was the filename? Complete content of the first couple of lines (obscure any specific business sensitive information if there is any and identify that it was obscured).
Just an update. The problem I had was - as you suggested - to do with configuration errors elsewhere on the server and not with Easy Populate 4.0. Principally it had to do with PHP with which I had missed a final step of linking libraries when I reinstalled it. The circuitous route to realizing that led me to discover and fix other things which were not quite right on the server. So, though it was a frustrating experience, I finally managed to upload a csv of over a thousand entries with Easy Populate 4.0. Thank you for your work on this program and for your advice.
Just an update. The problem I had was - as you suggested - to do with configuration errors elsewhere on the server and not with Easy Populate 4.0. Principally it had to do with PHP with which I had missed a final step of linking libraries when I reinstalled it. The circuitous route to realizing that led me to discover and fix other things which were not quite right on the server. So, though it was a frustrating experience, I finally managed to upload a csv of over a thousand entries with Easy Populate 4.0. Thank you for your work on this program and for your advice.
I may have worked a way around my problem and stopped the multiple variants of the same attribues.
i was using open office. make attribues and delete the old ones and upload, save as Attrib-Basic_EP using edit filter setting. long winded but work a couple of times now. May have to learn to back up every time i upload.
Ummm. Thing is the attribute basic filter for import will not process if the file is named with the underscore just before EP... instead the file will be treated as a full upload. As said before there is a patch to be applied for attribute importing that may apply to your issue otherwise.
I have just uploaded the CSV file that Easy Populate made for me. Two issues;
still dropping all directories if there are no products in that folder
&
it does not save the tax class value. After the upload both the Products Price Net & Gross are the same value.
I've gone back to review the past reported posts you've made to try again to understand what is meant by "dropping directories", what I understand you to reference is categories (not directories). As to "dropping categories", I'm not sure I understand what is happening to be able to provide further guidance (though I wish to so that the issue/understanding can be resolved).
As far as the tax class "value"... The process uses the tax class name as entered in the database (it does not generate a new one automatically) to look up the tax_class_id and then to assign the tax_class_id to the product upon import. If the tax class name that is in the import file does not match the tax_class_name in the database, then no "change" will be made to the tax_class_id "field". Although I didn't search deeply for this aspect, but because the products_tax_class_id exists in the product table, if you know add the tax_class_id into your import file (field: v_products_tax_class_id) and add products_tax_class_id to the user defined fields in the configuration menu, then these values should be updated/output when such is desired to be provided/addressed.
I assume that the display of the same values for net and gross is abnormal for the store's current setup? Meaning that if you manually set a tax class to a product then entered a price in either field that the other field does update to reflect the with/without tax price? (Just one of those checks to be sure that the software is setup as expected and not that this program has caused something, especially since this type of "test" is something I would do if I were "in front" of the computer screen.)
Back to my understanding of the "dropping directories" issue and other discussion from before. The Categories Only (with metatags) addresses the data specific to a category. It's category description, it's category name, the image associated with the category, etc... In a way it has nothing to do with the product that is in that category, just the category itself. When reviewing product associated with a category, the category_1 field (or similar number) is populated with the category "tree" for that product and is expected to be provided in the language related to the number (in this case 1). The branches of the tree are made by using the carat (^) symbol (character between () is the ^). So if you had a product like a t-shirt that is in the shirts sub-category which is in the men category then the category listing could be something like: men^shirts^t-shirt and that would populate the product into that category. If the category(ies) didn't exist, then they would be created with the parent being the category to the left of the referenced category.
With regards to using the dropdowns at the top of the screen. If nothing is done with the status dropdown, then only active product will be exported which is the same for the next selection of active. Then there is the inactive product and lastly all product. The filters only adjust what is exported when clicking the export button next to that group of dropdowns. Those filters do not affect the clickable links that are below the dropdowns.
Bloody hell you have written a lot. I will take a copy, read it tonight and get back to you.
Not worth the effort to send a hate message.
The first bit about the missing ‘Tax Class’ and ‘products Price’ my own stupid fault and I have fixed that.
Sorry for the missing understanding. It is terminology that I used when I was a Network manager here in the UK.
I did a backup of my store and with problems beyond my control I had to re-build my store and used that backup to populate my new store.
When you go admin->catalog->CATEGORIES / PRODUCTS – TOP you are presented with column titles of ‘ID’ ‘Categories/Products’, ‘Model’, ‘Price/Special/Sale’, ‘Quantity’, ‘Status’, ‘Sort’ and ‘Action’.
If you have anything written in ‘Categories/Products’ and value in ‘Quantity’ for example 63 of 63, then all of the ‘Categories/Products’ are backed up so that when you need to upload the backup all is put back so you will get ‘Categories/Products’ and value in ‘Quantity’ 63 of 63 and all is well.
However, if you have one product ‘Out of stock the ‘Quantity’ for the ‘Categories/Products’ will display 62 of 63. Then after a backup and you want to use that backup, the ‘Out of Stock’ product is not there and the value in ‘Quantity’ will be 62 of 62. Therefore, the ‘out of stock’ product or then products will be lost (not backed up).
Also, if you have ‘set up’ the drill down of ‘Categories/Products’ for example Shoes->color->blue->sizes but do not put any products under sizes, then the ‘Categories/Products’ sizes is not backed up, so that when you use your backup the ‘Categories/Products’ sizes will not be there.
I hope this helps you.
So, issues described that remain a problem are on the store front, and store front only?
One thing before possibly describing what's going on, again want to say that EP4 is not exactly a backup tool... It's original purpose appears to have been to make import of bulk product such as those provided by a "vendor" easy and quick, then it changed a little to make it easy to manipulate the data in the database in a bulk manner (increase/decrease all prices by a certain amount), but not strictly as a backup tool (there are other more dedicated programs to do that). So, that PA made. :)
The export of the "Full product data" will include all active (v_status = 1) and inactive (v_status = 0) product. The same is true if using the dropdowns at the top of the screen provided the last one (status) is set to "All".
On import, all rows that meet the primary key criteria (default: products_model) will be imported. Based on the settings in the admin configuration->Easy Populate 4 at the setting Make Zero Qty Products Inactive: When uploading, make the status Inactive for products with zero qty (default: false). If this has been changed to true, then on upload of the out-of-stock product, the product will become deactivated and the total quantity of product per category will decrease.
Now, the default for that setting is false, which means that product with zero quantity are to be uploaded and remain "active" to the store visitor(s). Mind you, there is one "issue" discussed over the last couple of pages that relates to populating some other areas of the database (still need to write the other two solutions I have considered for "restoring" from that situation) such as manufacturers. The described issue though seems to be something a little different.
See if setting the Make Zero Qty Products Inactive option to false resolves your issue, otherwise need to find out more about your products table I think. If it does not resolve the issue, could you (maybe again?) post the settings you have for EP4?
Sorry but you are correct, very new to ZC, which new application do you suggest I transition to.
Thanks,
The only time that a product is removed from the database when using EP4 is if the status is set to 9 for the product. Otherwise, whatever is in the file and meets the criteria to be imported will and the total quantity of items currently in the database will not be reduced (unless the status was set to 9 for a product).
zc 1.5.5a EP4.0.35 many mods
I've very very noob on this. I've installed and configured the mod in my test site and seems in order to my untrained eye.
I've exported my db and it shows up in my admin/temp folder with filename FUll-EP2016Jul18-xxxxxx (x being numeral)
The file opens in Open Office Calc (which I'm also noob to but have some basic exp with other spreadsheets)
What I want to do is add/populate Meta titles, words, descriptions for existing individual products. No other changes. I see the appropriate columns in the spreadsheet.
I've read the readme, install notes and the wiki but I'm still unclear...
1. Do I delete the columns from the spreadsheet that I am not changing or do I leave them. (ie if I have only model number and meta text columns, and meta on/off columns will I end up overwriting the entire kit and caboodle.)
2. And, if deleting the columns that aren't being changed is ok, what name would I call the new file I make with the meta info. ( I see some sample naming conventions for featured and other type files but not for this particular example)
The instructions were written with a slight air of ambiguity about the specific columns because of the way EP4 can be modified and that then the instructions would be "wrong". The first guidance is as you have done, try to see what the code will do if setup to have "just" what you want. Recently a lot was done to only modify the fields of a record that were included in the file. Regarding main products and categories only the products and/or categories in the import file are touched by the code. Uploading product x will not delete products y and z nor modify their data...
As to the filename. The filename is like a configuration setting. Files named one of the "special" filenames are treated uniquely, any other filename is processed as a full import. The important part of the filename is everything up to and including -ep when read from left to right. Best to leave that part unchanged (capitalization does not matter) and as desired/necessary to modify anything/everything after that and leave .csv at the end (extension).
I am running 1.5.5
I have successfully uploaded many products using EP4
I first created one item with all the attributes/options needed.
The exported list of options for this item is 98 lines long.
I changed the model number to one that needs the options loaded.
After I uploaded the attributes/options for this item it give me the message that the file was imported
But none of the attributes/options are displaying on the item
I have tried both Basic and Complete versions of the attributes file downloads as the basis for my uploads.
Any suggestions please!
These are the same for about 2000 of my items
I really don't want to have to Key these in manually.
Nevemind... I had to add the code changes to make it work.
Since I have to create an upload file with 98 attributes per item, it's faster to use the Copy function in the attributes manager.
This had been a total waste of time!
Sorry that there were difficulties in getting this version to work as desired. Regarding repeating attributes, copy and paste tends to work rather quickly. That said, there is not always just a single solution to all issues. There certainly are ways to dip and dive and get the in program copy method(s) to accomplish the desired task, but 1) glad you got it to work, and 2) glad you found a way to get your desired result.
Some of the strength of this/this option is more on repeating these types of modifications on a routine basis as in from a vendor that routinely provides attributable data, or if there is a need to perform some type of mass modification and doing so with a SQL statement doesn't seem easy/feasible, want to have some presentable document to show what the status was/should be after import, want to work off-line, etc... weakness(es)? Requires getting familiar with at least one new application if being used one time, is prone to user error in content modification, and repetitive information must be copied in some way rather than clicked through. (sorry last one is a stretch. :P)
I have a problem:
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
and this:
When executing:
SHOW COLUMNS FROM products_with_attributes_stock
MySQLi error 1146: Table 'instates_Vrsfnwp9bt9b1kjesfn908.products_with_attributes_stock' doesn't exist
I attempted an upload and it says: File uploaded successfully: filenam.csv BUT no products are added. I did a test.... Downloaded the entire csv, deleted a product in the admin then uploaded the entire csv without editing.
Any help would be appreciated.
Zencart version 1.5.4, linux server all other requirements seem to be "ok" on my servers.
In your removal of Stock By Attributes you did not remove at least the define for the products_with_attributes_stock table which means you have files still on your system.
Besides revisiting your previous install of SBA to identify all of the files that should be removed or restored, to move forward with EP4 you would want to goto tools->developers toolkit, then search for: TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK then should find it in at least two locations one in the admin/includes/functions/extra_functions file and the other where it looks something like:
Code:define('TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK', 'products_with_attributes_stock');