Many thanks MCQuote:
Originally Posted by mc12345678
Printable View
Many thanks MCQuote:
Originally Posted by mc12345678
Good
I appended all categories and would like to add categories to csv, but when I added the file and do import, give me the error described below:
SKIPPED! - Category ID: 1,"","Adapter","","Adaptadores","","","","","","","","0" - Not Found!
And the csv file contains what is described below:
v_categories_id,v_categories_image,v_categories_name_1,v_categories_description_ 1,v_categories_name_3,v_categories_description_3,v_metatags_title_1,v_metatags_k eywords_1,v_metatags_description_1,v_metatags_title_3,v_metatags_keywords_3,v_me tatags_description_3,v_sort_order
1,"","Adapter","","Adaptadores","","","","","","","","0"
I would like a help, thanks.
Categories are added by processing a product file that is identified as a full product type file.Quote:
Originally Posted by jsimoes1997
Details about a category are updated using the categorymeta-epxxxxx type file.
Another way to think about it is that categories exist to support a product. The details of a category are independent of the product.
Ok, I noticed but now I did what I said and added a new product with all the fields and since to create the category has to be with the product I did it but when I mattered it says that it is wrong with the part of not knowing the category.
the error code is described below
SKIPPED! - Model: 270-4373,"1","","SUN PCI GIGABIT FC NETWORK ADAPTER","SUN PCI GIGABIT FC NETWORK ADAPTER","","SUN PCI GIGABIT FC NETWORK ADAPTER","SUN PCI GIGABIT FC NETWORK ADAPTER","","","","","0","0","0","1","1","1","0","0","2019-03-01 00:00:00","2019-02-28 00:00:00","6","SUN","Adapter","Adaptadores","--none--","1" - No category provided for this new product
I would like to know how to do it, Thanks.
The error message seems to indicate that the categories field heading is not provided (v_categories_name_1 or whatever number represents your current language_id).Quote:
Originally Posted by jsimoes1997
Best suggestion to offer if it hasn't been done, is to export one or more product (can select a category to export), then modify the data in the row for your your product to make it unique and reference what you want to import and then import that. From there can trim down fields not needed to get to your preferred process.
Hi All, I am having a slight problem with the price breaks export. I am running version 4.0.36.ZC, on Zen Cart 1.5.5f.
The problem is thus, I have 4 price breaks set up, as well as the base price, for each product. But when I export the price breaks using the Model/Price/Breaks export function, it only exports the first 3, and ignores the 4th price break. There is no column for it in the exported csv file.
I can add products with the 4th price break by manually adding it to the csv file and uploading, it adds all the price breaks exactly as it should, but when exporting the products again, you only get the first 3 price breaks.
Has anybody else encountered this?
There's a configuration setting in configuration->Easy Populate 4 titled Maximum Quantity Discounts that identifies the number of discount columns to be downloaded. The default is 3 which is what you are/were seeing. You can change that to a value of 4 or whatever number is desired.Quote:
Originally Posted by Pingfah
Super, thank you very much indeed!Quote:
Originally Posted by mc12345678
Hi, when I did the import of a file successfully but it says that it has a sql error what I'm doing is with a product of a category then I created a product with another category already created,
I am putting the product id as the primary key and when I enter the new product and the category name even with it already created it gives error.
The data in the file I'm importing is this:
v_products_model;v_products_id;v_products_type;v_products_image;v_products_name_ 1;v_products_description_1;v_products_url_1;v_products_name_3;v_products_descrip tion_3;v_products_url_3;v_specials_price;v_specials_date_avail;v_specials_expire s_date;v_products_price;v_products_weight;v_product_is_call;v_products_sort_orde r;v_products_quantity_order_min;v_products_quantity_order_units;v_products_price d_by_attribute;v_product_is_always_free_shipping;v_date_avail;v_date_added;v_pro ducts_quantity;v_manufacturers_name;v_categories_name_1;v_categories_name_3;v_ta x_class_title;v_status
swTTT;184;1;;SWITCH;TEST 1 FOR PRODUCT;;SWITCH;TESTE 1 DE PRODUTO;;;;;5;5;0;1;1;1;0;0;;2019-03-04 14:28:22;2;CISCO;Test;Teste;--none--;1
swswq;;1;;SWITCH 1;TEST 1 FOR PRODUCT 1;;SWITCH 1;TESTE 1 DE PRODUTO 1;;;;;6;6;0;1;1;1;0;0;;2019-03-04 14:28:23;3;CISCO;Test1;Teste1;--none--;2
The sql error that you are giving me is this:
MySQLi error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')
WHERE
products.products_id=188' at line 8
When executing:
SELECT
products_to_categories.products_id,
products_to_categories.categories_id,
products.master_categories_id
FROM
products
LEFT JOIN
products_to_categories ON (products.products_id = products_to_categories.products_id AND products_to_categories.categories_id=)
WHERE
products.products_id=188
MySQLi error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 2
When executing:
INSERT INTO products_to_categories (products_id, categories_id)
VALUES (188, )
MySQLi error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')
WHERE
products.products_id=188' at line 8
When executing:
SELECT
products_to_categories.products_id,
products_to_categories.categories_id,
products.master_categories_id
FROM
products
LEFT JOIN
products_to_categories ON (products.products_id = products_to_categories.products_id AND products_to_categories.categories_id=)
WHERE
products.products_id=188
MySQLi error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 2
When executing:
INSERT INTO products_to_categories (products_id, categories_id)
VALUES (188, )
I need help!! Its urgent.
Thanks for the time.
If I understand correctly besides that the error message provided does not appear to directly relate to the product being imported, it looks like the particular issue would be addressed by modifying line 1501 from:Quote:
Originally Posted by jsimoes1997
to:Code:'.TABLE_PRODUCTS_TO_CATEGORIES.' ON ('.TABLE_PRODUCTS.'.products_id = '.TABLE_PRODUCTS_TO_CATEGORIES.'.products_id AND '.TABLE_PRODUCTS_TO_CATEGORIES.'.categories_id='.$v_categories_id.')
This area of code has been redone in the next revision.Code:'.TABLE_PRODUCTS_TO_CATEGORIES.' ON ('.TABLE_PRODUCTS.'.products_id = '.TABLE_PRODUCTS_TO_CATEGORIES.'.products_id AND '.TABLE_PRODUCTS_TO_CATEGORIES.'.categories_id='.(int)$v_categories_id.')
Also, what this seems to imply overall is that it sounds like you have product in the main category of the store (not in a sub-category) and have a sub-category in which a product is located). This configuration in a default store can cause display issues.
I say this because without the change provided above, if $v_categories_id is equal to 0, then the issue identified would occur. A $v_categories_id of 0 indicates that the product is assigned to the root of the store. Further have said that in part are dealing with an existing product that is in an existing category; however, an existing category doesn't have a categories_id = 0 because only the root has that. Then there is the issue of the products_id = 188 when the file indicates 184... Perhaps a typo, but important information. The other possible issue seems that the setting to select the primary id may be set to products_model even though the file contains a products_id and the products_model is assigned to more than one product.
Ok, I have exported the cvs file and when I click "Download" I got an "403: Forbidden". It never done this I didn't change anything.
Download of csv files from the stored directory depends on the permissions of that folder and those above it. There is an .htaccess file in the distribution that is configured to support download of csv files. It can be found in the folder that starts with htaccess4... as stated in the instructions that file should be placed in your export/downloads fiolder.Quote:
Originally Posted by wmorris
The cause could be that something above the current folder was changed that prevented download of the files.
I am having this issue with ZenCart 1.56a and EasyPopulate 4. If it matters, my PHP is version 7.1 and MySQL is 5.6.Quote:
Originally Posted by mc12345678
In trying to address the issue, I came across this thread and have installed the v4.0.36.ZC Patch 1 12-29-2018 mc12345678. I didn't know exactly how to use the diff but I found the raw file on github and copy/pasted the entire thing so I think that would be OK?
However I still get an error when attempting an import. From ep_debug_log.txt:
Here are the columns in my CSV:Code:MySQLi error 1366: Incorrect integer value: '' for column 'products_sort_order' at row 1
When executing:
INSERT INTO products SET
products_model = 'BLUFFF_BLKDOV',
products_type = 1,
products_price = '39.95',
products_image = '62802-full.png',
products_weight = 0.085,
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 = '2018-08-09 11:10:00',
products_last_modified = CURRENT_TIMESTAMP,
products_quantity = 15,
master_categories_id = 139146,
manufacturers_id = 0,
products_status = 1,
metatags_title_status = 0,
metatags_products_name_status = 0,
metatags_model_status = 0,
metatags_price_status = 0,
metatags_title_tagline_status = 0
Any ideas on how I can fix this?Code:v_products_model,v_products_image,v_products_name_1,v_products_description_1,v_products_price,v_products_weight,v_products_quantity,v_date_added,v_categories_name_1,v_categories_name_2,v_status
Thanks for your time,
Drew
This issue was fixed in a later push of code when more was done to ensure there was a "sanitizer" for every field being populated.Quote:
Originally Posted by imacamper
I'm nearly inclined to suggest installing the latest version on GitHub. I'm looking at a couple of additional tests to verify that it will be possible to import language related information using the two character language code. The existing method uses the numeric language id.
Change lines 1039 and 1190 of admin/easypopulate_4_import.php from:
to:Code:$query = $db->bindVars($query, ':products_sort_order:', $v_products_sort_order, 'string');
Code:$query = $db->bindVars($query, ':products_sort_order:', $v_products_sort_order, 'integer');
Thank you very much. That has solved my issue.Quote:
Originally Posted by mc12345678
Cheers,
Drew
Hi everyone. I'm a happy user with EP4 and am curious if this can be done: convert inventory items that were originally general over to music. So I've updated the "show music" genre in the admin. I've updated my inventory by: changing type from 1 (general) to 2 (music) , added the music fields to my database, and then uploaded the database with no errors. But when I go into the inventory, the music fields are not showing. It's weird: if I create a new music inventory item, all of the music fields are on my screen to enter. My thinking is that once you have created a product under "general" it cannot be converted to "music" If that's wrong, any suggestions would be really appreciated.
Some more information is needed to help through this situation.Quote:
Originally Posted by mrmcastle
ZC version?
EP4 version?
When saying that have changed the products_type from 1 to 2, please explain how/where.
Does the export of a manually entered music product look the same as an export of one entered using EP4? Is this what you are talking about when looking at "inventory"?
What custom field import filter(s) are applied as found in the configuration screen for EP4?
As to product types, well, the general thought is that product product types should not be changed at least after the product has been created and is part of the store. It doesn't mean that they can not be changed. The issue centers around some of what you are seeing. How to populate the other data related to the product if the product type is now x and what to do with the old/unrelated data when the product type has changed? For example if a music product is converted to a product general product, won't there now be fields associated with the music product type that are populated but not used?
Sorry, that's a lot of info I forgot to mention. I'm using ZC 1.51 and EP 4.0.24 I know these are older versions but the site is working fine and you know what they say... if it ain't broke don't fix it. I don't take credit cards... send my buyers to Paypal which is very secure so I'm not really too worried about all the security issues mentioned in the forum. (Please let me know if I my thinking is wrong on that).
When I enter a new item manually using the Product-Music category, the screen looks like the attached picture A. So after modifying my inventory (using a spreadsheet and then filling in those music fields) I assumed they would show up like that picture, with those fields now displaying the info. Instead, the music data from EP4 goes nowhere. If I go into category and look at the items I've updated using EP4, those 3 fields are not there. I am assuming that after I change product type from 1 to 2 and then fill in all of the music fields (artist, recording company, genre) they should show up, but nothing. I just did an export from EP4 and those fields I updated with the music infor are not there. It's weird because after I import them in, it shows those fields as having been added on the confirmation screen.. but I guess they are not.
Let's take a step back to see where the issue really is.
First consider a product that was manually entered in the admin as a music product.
If you export that record, is all of the desired music related information in the export?
If you modify some music related aspect of that one product and upload a file that has just the headers and that one product, then import the file back into the database, does it get updated with the new information?
Yes to all. I exported the file, made a couple of modifications to the music fields in my spreadsheet and then uploaded thru EP4. The file uploaded successfully and the changes I made were updated.
Quote:
Originally Posted by mc12345678
When you populated your new record for your new "music" product, did you have an artist entered in the v_artists_name field?Quote:
Originally Posted by mrmcastle
Following your logic, I decided to try changing the v_products type to 1 on that item (the music product item you had me create) and then uploaded it back up via EP4. I thought for sure the item would no longer show the recording artist, record company and genre but those fields are still there. It seems like it's one of two things.... either the version ZC I have doesn't want to work with the EP4 version I have or there is no switching over once you've created an item as a general or music product. EP4 is pretty good but it has its quirks... I installed the Ceon URI mapping program and it would not switch my existing inventory over until I went in to each product and saved it. Yeah, I know there was a fix out there but I didn't want to shell out the $60 for it....
Oh sorry just saw your recent post will check it and get back to you
Yes, I had artist, record company and genre fields filled in. Using a new music inventory item I just created, I could change those 3 fields after exporting out and then importing back in.
If I take an existing record, change the v_type to 2 and then add artist, record company and genre fields it shows (see pic) that those fields were imported but when you go edit the item, those 3 fields are not included.
Quote:
Originally Posted by mrmcastle
Piece of information asked about was left off, but that is also why I asked the questions in the way I did.Quote:
Originally Posted by mrmcastle
Here's the situation.
EP4 is generally written to handle day-to-day normal operations with the ability to modify multiple things in a single import. It is not specifically written to just let anything be done to the database just because it exists or might be possible. So, to prevent the "common" user form themselves there are ways to update particular fields if it is desired to override the safeguards that are both built into Zen Cart and similarly into EP4.
It is not "normal" to update a product from being a general product to some other product type. When inserting a new product, it is expected so that a product type can be assigned to the product. So, if it is desired to update a field that is otherwise "protected" and (as currently implemented) in the products table, then would need to use the custom fields to force the products_type to be processed as a field to update.
As far as Ceon URI Mapping, there is an indicator that the software is installed; however, EP4 as released does not include the processing to manage populating the URIs. That is something else. There is an indicator for Stock By Attributes as well, though it may not be shown if certain files and database records are missing.
Yes, what you are saying makes perfect sense. I really can't complain... if I had setup the music fields when I first began it would have never become an issue. Thanks again for your help on this.
Welcome and hopefully have been able to convert the product to a music product type and populate the desired fields. As to notification that was successful, well there are still likely some notifications that could be incorporated to catch such a situation of either an update with a change of product type or attempt to apply music field records to a non-music product.Quote:
Originally Posted by mrmcastle
As to maintaining software up-to-date as discussed several posts back, while a store may not be AS concerned about PCI compliance, maintaining software up-to-date is not just about PCI compliance to manage the expected operations.
Unfortunately as time marches on, those that wish to cause trouble find new and innovative ways to do it. Consider this: how often do you go through your store as a customer to see how it operates and responds? What if in one of these attacks, changes were made to your site where data began to be collected that you don't need to operate your store? What if that attack could have been prevented by the site being maintained up-to-date?
Do I expect such an issue with EP4? Not necessarily directly; however, there are ever more creative ways that it may get used such as automating data import which really means that depending on someone else to have ensured the safety/security of their data.
Just some food for thought...
Hi,
before I install easypopulate I have few questions about language support. My database has UTF-8 document collation. Also my language is not English and it contains umlauts like åöä. Is this a problem with easypopulate exports/imports?
This program has been adopted in the German version of the Zen Cart software by webchills. It also uses/expects UTF8; however, has some support for latin1. The only issues I've specifically seen regarding at least German is that the version of their Zen Cart software does not use the version check software to identify when a new version is available. There has been report that some languages such as Chinese and Russian are not well supported, but haven't been able to work with such users to resolve the issue(s).Quote:
Originally Posted by OopsIbrickedIT
I am still getting this error:
It appears you don't have
permission to access this page.
403 Error. Forbidden.
When I tried to download it from the server from the website. I don't want to download it from a FTP software. How can I fix this?
Quote:
Originally Posted by wmorris
Hmm... When I follow this section of install.txt, I don't have problems downloading files generated by EP4:
c) Create a directory where EP4 related datafiles will be uploaded/exported. If this
directory will be in your admin area, then be sure to either merge the contents/changes
of the folder htaccess4AdminTempFolder with your new folder, or place the file(s) there.
This directory is *not* auto-created.
I followed what the instructions says I am still can't get it to work. Still getting that error message when I tried to download it from the admin area.Quote:
Originally Posted by mc12345678
What are the contents of the .htaccess file found in the directory where your EP4 exports are sent?Quote:
Originally Posted by wmorris
myadmin/temp/Quote:
Originally Posted by mc12345678
Code:#
# @copyright Copyright 2003-2013 Zen Cart Development Team
# @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
# @version GIT: $Id: Author: DrByte Sat Dec 21 17:00:00 2013 -0500 Modified in v1.5.3 and for EP4$
#
# This is used with Apache WebServers
#
# The following blocks direct HTTP requests to all filetypes in this directory recursively, except certain approved exceptions
# It also prevents the ability of any scripts to run. No type of script, be it PHP, PERL or whatever, can normally be executed if ExecCGI is disabled.
# Will also prevent people from seeing what is in the dir. and any sub-directories
#
# For this to work, you must include either 'All' or at least: 'Limit' and 'Indexes' parameters to the AllowOverride configuration in your apache/conf/httpd.conf file.
# Additionally, if you want the added protection offered by the OPTIONS directive below, you'll need to add 'Options' to the AllowOverride list, if 'All' is not specified.
# Example:
#<Directory "/usr/local/apache/htdocs">
# AllowOverride Limit Options Indexes
#</Directory>
###############################
DirectoryIndex index.php
# deny *everything*
<FilesMatch ".*\..*">
Order Allow,Deny
Deny from all
</FilesMatch>
# but now allow just *certain* necessary files:
<FilesMatch "(?i).*\.(csv|CSV|txt|TXT)$">
Order Allow,Deny
Allow from all
</FilesMatch>
IndexIgnore */*
<limit POST PUT>
order deny,allow
deny from All
</limit>
## NOTE: If you want even greater security to prevent hackers from running scripts in this folder, uncomment the following line (if your hosting company will allow you to use OPTIONS):
# OPTIONS -Indexes -ExecCGI
##################
## Optional caching improvements
## Requires mod_header and mod_deflate to be enabled within Apache
##################
<IfModule mod_headers.c>
Header unset Pragma
FileETag None
Header unset ETag
#Header set Cache-Control "no-transform"
<FilesMatch "(?i).*\.(ico|jpe?g|gif|otf|webp|png|swf|flv|svg|svgz)$">
Header set Cache-control "max-age=864000, public, must-revalidate"
Header unset Last-Modified
</FilesMatch>
<FilesMatch "(?i).*\.(html|htm|xml|txt|xsl)$">
Header set Cache-control "max-age=7200, must-revalidate"
</FilesMatch>
</IfModule>
<IfModule mod_deflate.c>
<FilesMatch "(?i)\.(js|css)$">
SetOutputFilter DEFLATE
</FilesMatch>
</IfModule>
##################
## Optional improvements
## Requires mod_expires to be enabled within Apache
##################
<ifmodule mod_expires.c>
ExpiresActive On
ExpiresDefault A300
ExpiresByType application/x-javascript A3600
ExpiresByType text/css A3600
ExpiresByType image/gif A604800
ExpiresByType video/x-flv A604800
ExpiresByType application/pdf A604800
ExpiresByType text/html A300
ExpiresByType image/x-icon A86400
ExpiresByType image/jpeg A2592000
ExpiresByType image/png A2592000
ExpiresByType text/cache-manifest "access plus 0 seconds"
</ifmodule>
#turn off X-PHP-Originating-Script header when sending emails from admin
#uncomment to activate:
# php_flag mail.add_x_header Off
That file appears to be from ZC 1.5.3 with minor modifications to support download of csv files. Now I don't see in this post stream nor in a look at recent posts what version of ZC is being used, but I'm going to use the example from the current ZC 1.5.6 admin folder:Quote:
Originally Posted by wmorris
Code:#
# @copyright Copyright 2003-2016 Zen Cart Development Team
# @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
# @version $Id: .htaccess 19328 Modified in v1.6.0 and for EP4 $
#
# This is used with Apache WebServers
#
# The following blocks direct HTTP requests to all filetypes in this directory recursively, except certain approved exceptions
# It also prevents the ability of any scripts to run. No type of script, be it PHP, PERL or whatever, can normally be executed if ExecCGI is disabled.
# Will also prevent people from seeing what is in the dir. and any sub-directories
#
# For this to work, you must include either 'All' or at least: 'Limit' and 'Indexes' parameters to the AllowOverride configuration in your apache/conf/httpd.conf file.
# Additionally, if you want the added protection offered by the OPTIONS directive below, you'll need to add 'Options' to the AllowOverride list, if 'All' is not specified.
# Example:
#<Directory "/usr/local/apache/htdocs">
# AllowOverride Limit Options Indexes
#</Directory>
###############################
DirectoryIndex index.php
# deny *everything*
<FilesMatch ".*\..*">
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order Allow,Deny
Deny from all
</IfModule>
</FilesMatch>
# allow access to the root
<FilesMatch "^$">
<IfModule mod_authz_core.c>
Require all granted
</IfModule>
<IfModule !mod_authz_core.c>
Order Allow,Deny
Allow from all
</IfModule>
</FilesMatch>
# but now allow just *certain* necessary files:
<FilesMatch "(?i).*\.(php|js|css|html?|ico|otf|jpe?g|gif|webp|png|swf|flv|xml|xsl|csv|txt)$">
<IfModule mod_authz_core.c>
Require all granted
</IfModule>
<IfModule !mod_authz_core.c>
Order Allow,Deny
Allow from all
</IfModule>
</FilesMatch>
IndexIgnore */*
<limit POST PUT>
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order Allow,Deny
Deny from all
</IfModule>
</limit>
## NOTE: If you want even greater security to prevent hackers from running scripts in this folder, uncomment the following line (if your hosting company will allow you to use OPTIONS):
# OPTIONS -Indexes -ExecCGI
##################
## Optional caching improvements
## Requires mod_header and mod_deflate to be enabled within Apache
##################
<IfModule mod_headers.c>
Header unset Pragma
FileETag None
Header unset ETag
#Header set Cache-Control "no-transform"
<FilesMatch "(?i).*\.(ico|jpe?g|gif|otf|webp|png|swf|flv|svg|svgz)$">
Header set Cache-control "max-age=864000, public, must-revalidate"
Header unset Last-Modified
</FilesMatch>
<FilesMatch "(?i).*\.(html|htm|xml|txt|xsl)$">
Header set Cache-control "max-age=7200, must-revalidate"
</FilesMatch>
</IfModule>
<IfModule mod_deflate.c>
<FilesMatch "(?i)\.(js|css)$">
SetOutputFilter DEFLATE
</FilesMatch>
</IfModule>
##################
## Optional improvements
## Requires mod_expires to be enabled within Apache
##################
<ifmodule mod_expires.c>
ExpiresActive On
ExpiresDefault A300
ExpiresByType application/x-javascript A3600
ExpiresByType text/css A3600
ExpiresByType image/gif A604800
ExpiresByType video/x-flv A604800
ExpiresByType application/pdf A604800
ExpiresByType text/html A300
ExpiresByType image/x-icon A86400
ExpiresByType image/jpeg A2592000
ExpiresByType image/png A2592000
ExpiresByType text/cache-manifest "access plus 0 seconds"
</ifmodule>
#turn off X-PHP-Originating-Script header when sending emails from admin
#uncomment to activate:
# php_flag mail.add_x_header Off
I have copy what you put,,, and it still not working.Quote:
Originally Posted by mc12345678
OK, so what do you have in your admin folder for an .htaccess file?
I may ask about another file depending on the content/answer.
The central issue is that there is some security setting of the file structure that is preventing accessing the file as a download. Whether it is permissions, ownership or the like. It shouldn't be a filename issue unless the basic naming structure has been revised in the software to something "unusual".
You could move your "temp" folder to the catalog side where there is no :htaccess file that limits the file download structure at least as relates to a default Zen Cart install.
Ok, this is my .htaccess file in the main admin folder:Quote:
Originally Posted by mc12345678
Code:#
# @copyright Copyright 2003-2016 Zen Cart Development Team
# @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
# @version $Id: .htaccess 19328 Modified in v1.6.0 $
#
# This is used with Apache WebServers
#
# The following blocks direct HTTP requests to all filetypes in this directory recursively, except certain approved exceptions
# It also prevents the ability of any scripts to run. No type of script, be it PHP, PERL or whatever, can normally be executed if ExecCGI is disabled.
# Will also prevent people from seeing what is in the dir. and any sub-directories
#
# For this to work, you must include either 'All' or at least: 'Limit' and 'Indexes' parameters to the AllowOverride configuration in your apache/conf/httpd.conf file.
# Additionally, if you want the added protection offered by the OPTIONS directive below, you'll need to add 'Options' to the AllowOverride list, if 'All' is not specified.
# Example:
#<Directory "/usr/local/apache/htdocs">
# AllowOverride Limit Options Indexes
#</Directory>
###############################
DirectoryIndex index.php
# deny *everything*
<FilesMatch ".*\..*">
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order Allow,Deny
Deny from all
</IfModule>
</FilesMatch>
# allow access to the root
<FilesMatch "^$">
<IfModule mod_authz_core.c>
Require all granted
</IfModule>
<IfModule !mod_authz_core.c>
Order Allow,Deny
Allow from all
</IfModule>
</FilesMatch>
# but now allow just *certain* necessary files:
<FilesMatch "(?i).*\.(php|js|css|html?|ico|otf|jpe?g|gif|webp|png|swf|flv|xml|xsl)$">
<IfModule mod_authz_core.c>
Require all granted
</IfModule>
<IfModule !mod_authz_core.c>
Order Allow,Deny
Allow from all
</IfModule>
</FilesMatch>
IndexIgnore */*
<limit POST PUT>
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order Allow,Deny
Deny from all
</IfModule>
</limit>
## NOTE: If you want even greater security to prevent hackers from running scripts in this folder, uncomment the following line (if your hosting company will allow you to use OPTIONS):
# OPTIONS -Indexes -ExecCGI
##################
## Optional caching improvements
## Requires mod_header and mod_deflate to be enabled within Apache
##################
<IfModule mod_headers.c>
Header unset Pragma
FileETag None
Header unset ETag
#Header set Cache-Control "no-transform"
<FilesMatch "(?i).*\.(ico|jpe?g|gif|otf|webp|png|swf|flv|svg|svgz)$">
Header set Cache-control "max-age=864000, public, must-revalidate"
Header unset Last-Modified
</FilesMatch>
<FilesMatch "(?i).*\.(html|htm|xml|txt|xsl)$">
Header set Cache-control "max-age=7200, must-revalidate"
</FilesMatch>
</IfModule>
<IfModule mod_deflate.c>
<FilesMatch "(?i)\.(js|css)$">
SetOutputFilter DEFLATE
</FilesMatch>
</IfModule>
##################
## Optional improvements
## Requires mod_expires to be enabled within Apache
##################
<ifmodule mod_expires.c>
ExpiresActive On
ExpiresDefault A300
ExpiresByType application/x-javascript A3600
ExpiresByType text/css A3600
ExpiresByType image/gif A604800
ExpiresByType video/x-flv A604800
ExpiresByType application/pdf A604800
ExpiresByType text/html A300
ExpiresByType image/x-icon A86400
ExpiresByType image/jpeg A2592000
ExpiresByType image/png A2592000
ExpiresByType text/cache-manifest "access plus 0 seconds"
</ifmodule>
#turn off X-PHP-Originating-Script header when sending emails from admin
#uncomment to activate:
# php_flag mail.add_x_header Off
Then, would recommend the following to be placed in your folder for downloading/uploading EP4 files:Quote:
Originally Posted by wmorris
Code:#
# @copyright Copyright 2003-2016 Zen Cart Development Team
# @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
# @version $Id: .htaccess 19328 Modified in v1.6.0 and for EP4 $
#
# This is used with Apache WebServers
#
# The following blocks direct HTTP requests to all filetypes in this directory recursively, except certain approved exceptions
# It also prevents the ability of any scripts to run. No type of script, be it PHP, PERL or whatever, can normally be executed if ExecCGI is disabled.
# Will also prevent people from seeing what is in the dir. and any sub-directories
#
# For this to work, you must include either 'All' or at least: 'Limit' and 'Indexes' parameters to the AllowOverride configuration in your apache/conf/httpd.conf file.
# Additionally, if you want the added protection offered by the OPTIONS directive below, you'll need to add 'Options' to the AllowOverride list, if 'All' is not specified.
# Example:
#<Directory "/usr/local/apache/htdocs">
# AllowOverride Limit Options Indexes
#</Directory>
###############################
DirectoryIndex index.php
# deny *everything*
<FilesMatch ".*\..*">
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order Allow,Deny
Deny from all
</IfModule>
</FilesMatch>
# but now allow just *certain* necessary files:
<FilesMatch "(?i).*\.(csv|txt)$">
<IfModule mod_authz_core.c>
Require all granted
</IfModule>
<IfModule !mod_authz_core.c>
Order Allow,Deny
Allow from all
</IfModule>
</FilesMatch>
IndexIgnore */*
<limit POST PUT>
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order Allow,Deny
Deny from all
</IfModule>
</limit>
## NOTE: If you want even greater security to prevent hackers from running scripts in this folder, uncomment the following line (if your hosting company will allow you to use OPTIONS):
# OPTIONS -Indexes -ExecCGI
##################
## Optional caching improvements
## Requires mod_header and mod_deflate to be enabled within Apache
##################
<IfModule mod_headers.c>
Header unset Pragma
FileETag None
Header unset ETag
#Header set Cache-Control "no-transform"
<FilesMatch "(?i).*\.(ico|jpe?g|gif|otf|webp|png|swf|flv|svg|svgz)$">
Header set Cache-control "max-age=864000, public, must-revalidate"
Header unset Last-Modified
</FilesMatch>
<FilesMatch "(?i).*\.(html|htm|xml|txt|xsl)$">
Header set Cache-control "max-age=7200, must-revalidate"
</FilesMatch>
</IfModule>
<IfModule mod_deflate.c>
<FilesMatch "(?i)\.(js|css)$">
SetOutputFilter DEFLATE
</FilesMatch>
</IfModule>
##################
## Optional improvements
## Requires mod_expires to be enabled within Apache
##################
<ifmodule mod_expires.c>
ExpiresActive On
ExpiresDefault A300
ExpiresByType application/x-javascript A3600
ExpiresByType text/css A3600
ExpiresByType image/gif A604800
ExpiresByType video/x-flv A604800
ExpiresByType application/pdf A604800
ExpiresByType text/html A300
ExpiresByType image/x-icon A86400
ExpiresByType image/jpeg A2592000
ExpiresByType image/png A2592000
ExpiresByType text/cache-manifest "access plus 0 seconds"
</ifmodule>
#turn off X-PHP-Originating-Script header when sending emails from admin
#uncomment to activate:
# php_flag mail.add_x_header Off
That Worked,,, Thank You!Quote:
Originally Posted by mc12345678
Million $ question: would this work with recently released 1.5.6b??? .. Thank you!
OK. I took a chance and successfully installed that on a test folder running on Zen-cart 1.5.6b. Working just fine HOWEVER I only needed this to get Google Base exports (just like in EP Advanced 3.0.3). Any hope that Google Base Export soon to be added to 4.0, too? Thanks.
Help me please.
I am an user of zen1.3.0.2. Now I want to make new install zen1.55
After install zen1.55, installed Easy Populate 4.0.37.6 - 02-08-2017 from github.
I put Japanese Language Pack into zen1.55 and entered two Categories, one is Top level Category and another is a sub-category of it. And I entered a product at the sub-category.
I exported file by "Complete Products (with Metatags)" for testing EP4.
It worked without any error.
After that, I uploaded downloaded EP File without any chenge then occured an error.
EP4 doesn't stop!
I interrupted zen1.55 by ESC key and checked ep_debug_log.
ep_debug_log as follow:
---------------------------------------------------------------------------------
MySQLi error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ':products_model:' at line 30
When executing:
SELECT
p.products_id as v_products_id,
p.products_type as v_products_type,
p.products_model as v_products_model,
p.products_image as v_products_image,
p.products_price as v_products_price,p.products_weight as v_products_weight,
p.products_discount_type as v_products_discount_type,
p.products_discount_type_from as v_products_discount_type_from,
p.product_is_call as v_product_is_call,
p.products_sort_order as v_products_sort_order,
p.products_quantity_order_min as v_products_quantity_order_min,
p.products_quantity_order_units as v_products_quantity_order_units,
p.products_priced_by_attribute as v_products_priced_by_attribute,
p.product_is_always_free_shipping as v_product_is_always_free_shipping,
p.products_date_added as v_date_added,
p.products_date_available as v_date_avail,
p.products_tax_class_id as v_tax_class_id,
p.products_quantity as v_products_quantity,
p.products_status as v_products_status,
p.manufacturers_id as v_manufacturers_id,
p.metatags_products_name_status as v_metatags_products_name_status,
p.metatags_title_status as v_metatags_title_status,
p.metatags_model_status as v_metatags_model_status,
p.metatags_price_status as v_metatags_price_status,
p.metatags_title_tagline_status as v_metatags_title_tagline_status,
subc.categories_id as v_categories_id
FROM products as p, products_to_categories as ptoc,categories as subc WHERE
p.products_id = ptoc.products_id AND
ptoc.categories_id = subc.categories_id AND
p.products_model = :products_model:
MySQLi error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ':products_model:' at line 30
When executing:
SELECT
p.products_id as v_products_id,
p.products_type as v_products_type,
p.products_model as v_products_model,
p.products_image as v_products_image,
--------------repeat MySQLi error 1064 as above------------------
-------------------------------------------
-------------------------------------------
---------------------------------------------------------------------------------
It seems to be stuck in a infinite loop.
Before I put Japanese Language Pack , I tested EP4 as below. EP4 worked without any error.
-------------------------------------------
I entered two Categories, one is Top level Category and another is a sub-category of it. And I entered a product.
I exported file by "Complete Products (with Metatags)" for testing EP4.
It worked without any error.
I modified exported file by OpenOffice to add new product and import the file. It also worked without error and found new product at Store front.
-------------------------------------------
v_categories_name_1 is wrote in english and v_categories_name_2 is wrote in Japanese.
I still not have done any other customization.
Have I made anything wrong ?
Win10 64bit, Xampp7.0.3, zencart:zen-cart-v1.5.5f-12312017b
EasyPopulate-4.0-master.zip from https://github.com/chaddro/EasyPopulate-4.0
How I can fix this?
Thank you,
Keisei.
Regarding the Japanese language pack:
Is that for the catalog side, the admin, or both?
After installing the Japanese language pack was the default language changed/modified? Or perhaps better asked is what language settings were modified?
Is the default English language still present? Is it considered language_id of 1? (should be able to see this information on the main screen of tools->Easy Populate v4).
There is a slightly more up-to-date version at https://github.com/mc12345678/EasyPopulate-4.0) where there were some changes to some of the language processing; however, please answer the above questions to ensure successful support. There may still be something needing modification.
The error message is indicating that at some point in trying to match the record with a database entry that a variable substitution is not being made for the "phrase" ':products_model:'.
Sorry that I missed this post.Quote:
Originally Posted by enginarat
What is needed from the database to support that functionality? I thought that much of it was already present or avaulable once the desired data was exported. A sample of the field headings and an associated row would help identify this.
Please enclose in code brackets. (before pasting, press the # button in the message box toolbar to create the code tags and then paste between them.)
Thank you for your quick reply.
1.The Japanese language pack is for the both side.
I didn't change the data base by SQL.
I changed default language from the main screen.
I intend to remove the Japanese language pack and test again.
2.After installing the Japanese language pack, I changed the default language to Japanese.
English language is still present and it's language_id is 1. I didn't touch about English.
----------the information on the main screen of tools->Easy Populate v4---------------
Easy Populate 4.0.37.6 - 02-08-2017
Installed Languages
2-ja: Japanese
1-en: English
Default Language: 2-Japanese
Internal Character Encoding: UTF-8
DB Collation: utf8
--------------------------------------------------------------------------------------
3. I will try https://github.com/mc12345678/EasyPopulate-4.0 .
4. I think this message is regarding ':products_model:', but I don't know how to solve it because of my limited ability.
I will try what I can.
Thank you.
Sorry, ':products_model:' had become a face mark.Quote:
Originally Posted by hanachi
It had done the same thing to me as well. :)Quote:
Originally Posted by hanachi
Ok, so I haven't reproduced the issue yet. I need to figure out how the installed version is/was 4.0.37.6, but from chaddro's distribution...
I do see that at least from the GitHub location I posted, as long as the exported file has v_products_model as a field, then it should do the substitution that seems to be missing.
Another question: in configuration->EasyPopulate V4, What is the setting for EP4_DB_FILTER_KEY? This is the setting that identifies whether to use products_model, products_id or new_blank as a setting.
Does the issue still occur if the default language is returned to English, but the language pack is installed?
1.About the version of EP4:
I downloaded EP4 from https://github.com/mc12345678/EasyPopulate-4.0 and verified with former installed EP4 that occured the error.
I found they are same 4.0.37.6 of EP4.
I remember I got an error by using EP4 v4.0.35.ZC.2 and I found EP4 at https://github.com/mc12345678/EasyPopulate-4.0, so I
tried EP4 4.0.37.6, because it is later than EP4 v4.0.35.ZC.2.
2.About Another question:
in configuration->EasyPopulate V4->Import/Export Primary Key .... value is products_model
And I confirmed EP4_DB_FILTER_KEY is set products_model at the database "configuration".
3.Does the issue still occur if the default language is returned to English, but the language pack is installed?
Yes. I tried to set the default language to English without remove Japanese language Pack.
There is same error occured.
4.I delete Japanese from Localization -> Languages and tested , but the language pack is removed.
There is no error occured!!
About the Japanese language Pack, there are no SQL query included.
The Japanese language Pack only include language folder, email folder, and template(only buttons images).
5.I delete Japanese from Localization -> Languages and tested , but the language pack is installed.(I put the Japanese language Pack again)
There is no error occured!!
I think there is some conflict when add new language at Localization -> Languages
Thank you.
Sounds like some good investigation.
To ensure that the issue appears "corrected", the new languages_id for Japanese though now is 3 correct?
In the additional testing, was a new export file created after reinstalling the language pack? And do the fields of the japanese language have the current/new languages_id?
Before, English was 1 and japanese was 2. Because japanese was removed and then readded, I would expect japanese to now be 3.
If the problem continues with a new export/import, I will take a look at duplicating the issue even though I can't read Japanese. I took some lessons many years ago, but that was conversational not "business".
1.About the new languages_id for Japanese
Yes, Absolutely 3.
2.Latest testing
After readded new language "Japanese" from Localization -> Languages, I made a new export and import.
No error occured!!
I still not have perform another testing, but seems to be able to avoid the error.
I can't understand there is what kind of difference between languages_id 2 and 3.
Any way I will continue test and report to you here.
You already have advanced programming skills and sense of responsibility, just add a bit "love of Japanese", I think it's not difficult to use Japanese in business.
Thank you
The error still occur when CSV file include Japanese.
When I export CSV file include Japanese at Tools->EasyPopulate 4,
Bottom of the table, there displayed File Name, Size,Date & Time,Type etc.
Type of exported file displayed "CSV Unknown Delimiter".
If the exported CSV file doesn't include Japanese then displayed "CSV ,".
When I import CSV file include Japanese then error occur,
and if it doesn't include Japanese then no error occur.
Does it relate to parse a csv file include Japanese ?
Does it relate encoding Japanese ?
My php.ini has the following two lines.
"mbstring.language = Japanese".
"mbstring.internal_encoding = UTF-8".
May recommend that in the configuration settings that you try a different export delimiter? Then export again with Japanese.
It appears that the default comma is selected which is what a CSV file (Comma Separated Values file) should have. There has been some extra code added to attempt to identify the separator in the file to support easier import; however, if the delimiter (separator) is not consistent or appears to be different between rows, then the import will also not work.
Put another way, prior to trying to import a file, a small test is performed against the file to see if overall it is likely to be able to be processed. Exporting a file with a delimiter other than a comma may provide different results.
I'm not yet sure if the php.ini settings are an issue or not. Provided those settings are acceptable for php, then I don't think they are a problem.
Though not specifically stated, it does seem that the same process as before has been used: export data, attempt to import the unmodified data. If I am wrong there, please say so.
Is the 1.56B version supported?
Nothing about the Zen Cart software has changed through the 1.5.6 sub-versions that affect the operation of the version available from github. There were some changes that were incorporated for the increased strictness of php versions and database strictness.Quote:
Originally Posted by jiji2018
The issue being discussed relates to one of the languages that has been identified over the years as being problematic. The languages seen to be an issue have been Japanese and Russian. Those that have been able to support them do not appear to have provided back the solution that worked for them. Hanachi may be able to resolve that at least for Japanese to where the solution can be documented in the instructions.
zen version v1.5.6b
I have easy populate version 4.0.30 on one of my sites that is zen version 1.5.4. I have a new site using v1.5.6b and I installed easy populate 4.0.36.ZC. I downloaded my products from the earlier version and uploaded on the new site and new version of easy populate. Here is the error I am getting.
In admin on zen 1.5.6b I am not seeing any products up loaded. I am seeing products on catalog side, but no catagories, products are only viewable if you choose all products.
What am I missing. Is the old version of easy populate compatible with the new version? Is something amiss with zen 1.5.6b.
I did notice that the new version of easy populate calls for installing a EASYPOPULATE_4_CONFIG_TEMP_DIR and says to install in /public_html/ but when installing in 1.5.6b it says confirguration file calls for this to be in admin.
Looking for help, love this plug in and has been very helpful in the past. I have over 2,000 products and do not want to add them one by one.
Ok, couple of things here... One, really if you have a new site that is being built off of an older site, the database from the old site should be updated instead of just moving product around at least in a maintaining information consistently perspective.Quote:
Originally Posted by Speak394
Then, there is that newer operating systems and the newer environment is becoming more stringent about processing. There has been an "issue" with EP4 integration with ZC for a long time where adding a new category doesn't assign a category description and that ZC doesn't assign a default category description value. Therefore, the database throws an error basically and the product is not inserted into a new category but instead into the "zero" category which is the root of the store.
Long story short, for now apply this patch (identified in post #2961)posted a few pages back) to your ZC 4.0.36.ZC version and likely the above issue will be resolved.
As to where to put the export files. The program allows setting the folder anywhere desired; however, recommends the admin first to provide at least one level of protection of the data (admin folder and associated .htaccess). Remember this program is importing data in a file directly to the database. Attempts should be made to maintain that data as known information and only edited by trusted sources. There are configuration options for EP4 to choose to use the admin (true/false) and then a place to fill in the foldername. If though, the foldername leads to the admin or a sub-folder of the admin, then the admin's foldername portion will be removed from the storage location and the storage location identified as being in the admin. The idea of this change was to not store the admin's folder name either directly or indirectly in the database, there is nothing about a default install of Zen Cart that puts it in the database, so why should this plugin?
I'm working on an update, I have a working version, but I don't like *why* it works the way it does. The solution doesn't follow previous patterns and I'm trying to only change it in a way that can be easily duplicated and at least for now is consistent. I'm looking at doing a bit of a rewrite soon, but that is to modify the code orientation and reusability not its operation.
Hi all,
I cannot seem to find how to mark the products as Virtual using Easy Populate 4. Can anybody point me in the right direction?
This is through the use of the User Defined Products Fields area of the configuration menu. Would need to at least add the field products_virtual to the export/import list. Then the import file will need v_products_virtual in it to match. As usual would recommend after adding the field products_virtual to the user defined list to then do a test export and review the results before performing an import with that field.Quote:
Originally Posted by Pingfah
Perfect, I didn't even realise it had this function, but that worked flawlessly.
Thank you.
Hello Hanachi,
At the suggestion of mc12345678, I'm also testing the EP4 module now, to see if we can get to the bottom of the error you are experiencing.
At the moment, with mostly demo data on my site, I could not recreate the error, despite most categories and many product names and descriptions having Japanese translations. I can both export (complete products (with metatags)) to CSV and import the exported CSV file without trouble.
- My platform: GNU Debian linux x86_64 "sid/unstable"
- PHP verson: 7.3.6-1
- MySQL/MariaDB version: 10.3.16-MariaDB-1 Debian 10
- Web server: nginx 1.14.2
- Zen Cart: 1.5.6c
- Easy Populate version (downloaded and installed today):
Quote:
Easy Populate 4.0.37.9 - 02-08-2017
I must admit I do not know how closely my Japanese language pack (adapted from 1.5.1jp) matches yours. I too have language_id for Japanese set to 3 (English is 1), since I too uninstalled the language and reinstalled it at some point. Default language is English. So here some locale information:
- OS Locale:
Quote:
# locale -v
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
- locale settings in ADMIN/includes/japanese.php
Quote:
$locales = array('ja_JP.UTF-8', 'ja_JP', 'ja', 'Japanese_Japan.932');
@setlocale(LC_TIME, $locales);
mb_language('Japanese');
mb_internal_encoding("UTF-8");
mb_http_output("UTF-8");
If that gives you anything to go on, that would be great. Also, would be nice to get a bit more of an idea of the data you are having trouble with. Maybe you can send a tiny sample file with description. Then I can try to duplicate your category/product registration in my Zen Cart and see if the export is the same. And also check if I can import such a file (assuming duplication does not show any differences that could explain the error).
Cheers!
An addition here, just to indicate the importance of setlocale() before the use of fgetcsv():
1. http://static.zend.com/topics/multibyte-fgetcsv.pdf
2. http://php.segmenta.ru/manual/en/fun...tcsv.php#62759
3. https://qiita.com/uedatakeshi/items/...c6b3e26a57c237
Perhaps it would be worthwhile to expose the desired setting of setlocale() to users so that they can choose/experiment both at export and import with the choice if their locale settings (either on the PC or in Zen Cart) are not ideal for CSV export/import.
Good information, thank you gernot. I haven't taken the opportunity yet to review the details. Do you have suggestions on information placement? Are you also thinking that it should be something "customizable" from within the EP4 configuration?Quote:
Originally Posted by gernot
Sorry could come up with a number of questions, just trying to get an idea of ways thought that this could be applied best to/for users (from you or others with interest) and best to minimize issues out-of-the-box.
Hi mc12345678,
The PDF file link is quite enlightening.
I was thinking maybe, if I understand EP4 correctly, a fairly user-friendly way would be to have an editable field in the "Upload EP file" section, and another in the "Filterable Exports" section.
Not sure how feasible it is to display the current used Locale information there, that could well give users a hint in case something goes wrong.
Aside: does EP4 handle BOM or only BOM-free CSV files?
There is no additional processing performed to address a BOM, so would say BOM free. If can identify some resources that identify how to detect a BOM, then it could be relatively easily incorporated as a check. Otherwise, I've generally tried to stay away from asking the user to "know" the condition of the file and "remember" whether it needs to be specially treated or not at least on a case by case basis. Otherwise, the thought has been that some sort of "routine" is established for processing.Quote:
Originally Posted by gernot
As to the "location(s)" upload puts the file on the server, import is where the file is processed and where the setting most likely applies, though by that point the upload may have occurred moments ago or at some point in the distant past... For those cases the file may need to be again downloaded and reviewed before again importing...
As far as exporting (filterable exports) seems I still need to review those links to see how it plays in the export process.
As for displaying in the information area on the right, if it can be detected, it can be displayed. :) so a definite consideration to show over there. Then it's just a matter of offering a control other than end users hard coding information to adjust/modify the setting for use in EP4.
Ah, of course, fgetcsv is only on import... silly me.
As for BOM, yes, apparently an issue when creating CSV files with, say, Microsoft Excel.
Example of detecting BOM (UTF-8) and removing it (first three bytes if they exist) to get to BOM-free UTF-8N:
https://qiita.com/PET_HAL/items/fd1364513f81562671b6
Also in the fgetcsv PHP manual page:
https://www.php.net/manual/en/function.fgetcsv.php
For BOMs for UTF-16 also:
https://github.com/fezfez/parsecsv-for-php/issues/23
Even PHP6 people are trying to get rid of BOM issues, heh:
https://bugs.php.net/bug.php?id=22108
As a fellow community forum member, I wanted to provide some information to those using this in particular regarding the product type of music. Those that use the music product type or have repurposed it should know that the current plan for this product type as of about 4 hours ago is to fully remove it from Zen Cart 1.5.7 and beyond. I have not seen where a reason for its removal has been explained.
The pull request on github where this is initially slated to be removed is at: https://github.com/zencart/zencart/pull/2691
Perhaps the best place to discuss the importance of the product type is where its removal has been accepted by one of the core developers: https://github.com/zencart/zencart/issues/2596
Couple of things. As a forum member, likely you are a user of the Zen Cart software not just someone that does installations. If you didn't realize it, you have a voice in the current and future operation of Zen Cart. Now, that said, please use your professional voice. Changes, especially large spread ones tend to get made to address the needs expressed by the users. Take the opportunity to express your need for the product type and features that will be affected.
I personally don't think it offers value to indicate indifference or direct acceptance to its removal as I'm sure there are multiple features of Zen Cart that do not directly impact one or more individuals. This is an opportunity for those that use or need the capability or those that can clearly explain the problem of its presence to express their need and importantly *WHY*.
I don't yet know how that would impact this software considering it supports the music product type. I also do not know if some alternate plugin will be developed. I am providing a service message and asking that you as users step up and voice your need for the product type no matter how much you think you may be the only one...
Requests for improvement:
- can we get rid of the mysql_ functions? People should be using mysqli_ at this point. Users needing old functions can just download prior versions.
- similarly, can we get rid of the Zen Cart 1.3 stuff?
- the use of the constant EASYPOPULATE_4_CONFIG_MAX_QTY_DISCOUNTS seems unwise, since users may not know this value. The true number can be deduced by a query:
select count(*) as c from products_discount_quantity group by products_id order by c desc limit 1;
- can we add the discount_price_w field when it exists to the price break discount?
easypopulate_4_export.php line 781 - using round with 2 for the price isn't right - you should look at the currency settings for the cart. Some people use 3 decimal places.
Please forgive me if this has already been addressed and feel free to send me to a specific post.
1.5.5f, php 5.6.4, version of easypopulate seems to be most recent.
I have a website that has several addon domains - all have zen cart and all are using this mod. In the addon domains which are in subfolders of the main domain, I can set the download directory to the site's root and it all works. I have had to set the primary domain to the admin folder instead like it's supposed to. No biggie but now that these sites have been upgraded to 1.5.5f, the primary domain does still export the files correctly but when you try to access the files, it says not found and they are there in the correct folder in admin.
I did find an htaccess file I must have put in long ago and removed it (without looking at it) but there is no change. Still can't "find" the file. The htaccess file for admin is not changed - using default 1.5.5f. The htaccess file for the primary domain does include the Ultimate SEO mod and a redirect for ssl.
What am I missing?
There's not really a "supposed" to directory, the placement or folder used is as necessary to support the desired functionality. The big change was that the specific location or path of the storage location would not be stored in the database so that the database could not be accessed to determine the folder location of the admin.Quote:
Originally Posted by delia
So there are two "settings" in the configuration area associated with the storage of the files. One is an indicator of whether the folder location is to be relative to the admin or the catalog, the other is the path from that choice. There is some detection performed upon data entry/selection to try not to store the folder name of the admin folder in the database.
Then, after that, the issues that are likely to occur are related to download depending on where the folder has been set and the path of "permission" (htaccess overlay). This means the htaccess in the folder(s) of and above the location of the storage location affect the ability to download the file. In a typical ZC store, there is no htaccess in the root, so if a folder were created off of the root/catalog of the store, then the file(s) likely could be downloaded without issue. If the folder is off of the admin folder then the admin's htaccess first provides direction with changes needed to be incorporated to support download of csv files.
So, basically, if you are able to create new files by export of data and able to import new files that are uploaded, then if there is a problem with download, the issue is properly providing access to get to the csv file from the Web browser and that is more of a server/permissions setup issue than with this plugin. To provide direct assistance would recommend identifying the server version information, the htaccess for the admin and possibly the htaccess for the images directory. With that information and assuming that uploads/downloads within those two areas work fine, then should be able to suggest a revised version that would work in the EP4 folder being used.
Thanks for reminding me of the second setting. When I changed it to a folder outside admin, it worked fine.
Does Easy Populate have the function to toggle an attribute on/off based on the selection value of another option?
May have to read this response a few times.Quote:
Originally Posted by GoldBuckle
EP4 or any variation of such does not itself offer catalog side control of options. It interacts with the database to provide information (on import) to populate the database information. If there is a plugin that uses such data to control customer selection, then in that case the data imported will affect the customer's ability to select the product's attributes.
Such a plugin may be Stock By Attributes, available from https://github.com/mc12345678/Stock_...butes_Combined
Using that plugin (or a similar commercial option) it is possible to indicate what attribute(s) become available based on selection of a previous attribute. In that regards, this plugin does support stocking attribute variants that are already defined. This population is currently supported for SBA. It is unknown if other such modules are supported as they have not been tested by me nor reported by others as supported.
Bear in mind that the selection of options occurs in the catalog when the customer is buying an item - this is completely separate from easy populate, which is an admin function that populates/updates the database.Quote:
Originally Posted by GoldBuckle
Okay I will check out Stock by Attributes, thanks!Quote:
Originally Posted by swguy
Bulk import properties have not been successful, I made the csv table as follows
Attachment 18647
I manually added the property, after exporting, I changed the model number and want to import it to another product, suggesting that the import was successful, but the product has no display attributes.
“v_products_attributes_id” and “v_products_id” No values are filled in.
I just want to add attributes to the product based on the model.
how should I do?
I tested it on the default zencart system a lot and didn't find a way to use this plugin feature.
What is shown is the detailed attribute file. A basic attribute file must be used first to add the attributes to the product and the detailed attribute file then to set the additional properties.Quote:
Originally Posted by jiji2018
The filename(s) for each are different and must follow the standard as described in the instructions.
I do have a question if this is possible.....
My warehouse DB uses the Excel or CSV format.
I tie my Excel DB with my Warehouse Excel DB.
I am using the =vlookup command when I use the product number and quantity from the warehouse excel DB and when I use my Excel DB some of my quantities says "N/A" when means either my warehouse doesn't carry that product anymore. When I upload the updated excel to to the it shows those products shows (0) quantities. Is it possible that the N/A can be automatically deleted from the database without me delete it from the database manually?
Could you please clarify? When I first read the message I thought the request was to possibly delete the product from the database, but now it seems like may be asking to delete the text 'N/A' from the product's quantity.Quote:
Originally Posted by wmorris
If it is the deletion of 'N/A' I would say that the "better" option is to further use the formulas to detect if the value is N/A and use 0 when it is. The function ISNA supports that.
i have a custom field in products table called barcode(also known as UPC), when i export this field the values look like this 7.34995E+11, and it imports like this
In what application does it change to that? I would not expect the CSV file downloaded from the server and opened with a plain text editor to look like that. If the spreadsheet program is used, then it appears that this column should be identified to be treated as text upon import rather than numbers if it allows.Quote:
Originally Posted by jimmie
i open it with microsoft excel
Definitely Excel is taking that long set of numbers and changing the display of them scientific. That column though should be treated as text on import.Quote:
Originally Posted by jimmie
I did an Internet search for: excel import csv column as text
And came up with a lot of good results.
Im trying to set up a simple cron job to import a CSV.
However, upon trying to run the command php ep4_cron.php import=myproducts.csv, the system throws a bunch of these types of errors.
Notice: Undefined index: securityToken in [myadmin]/includes/classes/class.admin.zcObserverLogEventListener.php on line 158
Notice: Use of undefined constant EASYPOPULATE_4_DISPLAY_IMPORT_RESULTS_TITLE - assumed 'EASYPOPULATE_4_DISPLAY_IMPORT_RESULTS_TITLE' in easypopulate_4_import.php on line 2493
Any thoughts on how to properly get this to work? There doesnt not seem to be much of any documentations at all.
It's relatively new and incorporated to help someone that had asked for the possibility and didn't know how to put together the bits that would be necessary for its execution, so yes, little to no documentation other than what is in the file itself.Quote:
Originally Posted by chibipaw
As for the warnings received, that's because the language file is not pulled into the cron and not into the import portion. Furthermore it's because the import file does more than just import, it also prepares text to be exported, but does not actually export text.
So, to get those messages to go away, I am thinking the following would work.
In line 332 of admin/ep4_cron.php add the following:
With the require for the import file being at line 339 as it may seem.Code:if (isset($_SESSION['language']) && file_exists(DIR_FS_ADMIN . DIR_WS_LANGUAGES . $_SESSION['language'] . '/easypopulate_4.php')) {
require DIR_FS_ADMIN . DIR_WS_LANGUAGES . $_SESSION['language'] . '/easypopulate_4.php';
} else {
require DIR_FS_ADMIN . DIR_WS_LANGUAGES . 'english'. '/easypopulate_4.php';
}
My ISP is having some serious issues so I am limited on what I can test, confirm, and manipulate basically by what my cell phone can do or what can be done with limited cell phone data tethering.
Looks likes that bit of code actually worked.
Still spews a lot of similar errors, but the csvs were processed. I'll just redirect the garbage into /dev/null and hope it will get clean up at some point.
The good thing is, it's working.
Now that we're on the topic of automation. Any thoughts about crontabbing status of categories ?
I'm thinking of doing something like this right after the cron ep4_cron job to toggle the status of the category.
mysql --user=[username] --password=[password] < [script pathway]
—————SCRIPT——————
update products set catagories_status=1 where catagories_id = [product to be toggled];
Quote:
Originally Posted by mc12345678
Don't know why, but I kind of get the feeling that the concept of open source *community* is not fully understood...Quote:
Originally Posted by chibipaw
The error messages/problems won't fix themselves and probably will go undiscussed/undiscovered for quite a while if 1) everyone follows suit with dumping the "garbage" and 2) not providing the log files to potentially allow correction of the issue(s). Sure the issue could still be on either side (the code or the server), but one will never know if the information is not shared. I had thought that my previous description of the origin of this code section would encourage discussion rather than just ignoring what is going on.
All that aside, the query suggested won't do what is desired or thought unless that "simple" line is to get intrepretted correctly based on what is provided.
The status of a category is in the categories table. The status of a product is in the products table. A category's status condition is or can be independent of the product. Adjusting the product's condition based on the category being modified potentially has some nuances as a product can have a category as its master category or it can be linked to the category with some other category being the master. In either case, changing the status of the product changes it in all locations. If the desire is to "hide" a product from a specific category but not everywhere, then the products_to_categories table may need adjustment to remove the link from the product to that category or to change the master category as part of that.
Just understand that the overall desire is always to resolve issues and not ignore them. The easiest thing to do on your side is to provide back logs (with the admin directory obscured) so that at least if there is something amiss with the code it can be corrected whether you adopt the changes or not.
Quote:
Originally Posted by mc12345678
Trust me I know the nature of open source projects But I dont think lecturing people will improve upon it the nature of it.
At least I posted a excerpt of the logs, could have been simply nothing like most people.
But Ooof, lets move on.
Anyways, I've gotten the category toggling working with the bit of mysql script listed earlier. Lets consider that incident closed.
Focusing back to ep4_cron.php. Since Im not a coder, I'll leave this for those who are more capable than I am.
ZC: 1.5.5f
AWS Linux 4.14.146-93.123.amzn1.x86_64 #1 SMP
DB: MariaDB 10.3.8
Php 7.1.32
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Constant BOX_CONFIGURATION_REWARD_POINTS already defined in /home/shopping/fakeadmin/includes/languages/english/extra_definitions/reward_points_definitions.php on line 5
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Constant TEXT_PREVIOUS_EXPORTS already defined in /home/shopping/fakeadmin/includes/languages/english/extra_definitions/shipping_export.php on line 33
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Constant EP4_ADMIN_TEMP_DIRECTORY already defined in /home/shopping/fakeadmin/ep4_cron.php on line 84
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Use of undefined constant EASYPOPULATE_4_SPECIALS_HEADING - assumed 'EASYPOPULATE_4_SPECIALS_HEADING' in /home/shopping/fakeadmin/ep4_cron.php on line 124
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Use of undefined constant EASYPOPULATE_4_DISPLAY_STATUS_PRODUCT_SHORT_DESC - assumed
'EASYPOPULATE_4_DISPLAY_STATUS_PRODUCT_SHORT_DESC' in /home/shopping/fakeadmin/ep4_cron.php on line 175
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Use of undefined constant EASYPOPULATE_4_DISPLAY_STATUS_PRODUCT_UNIT_MEAS - assumed
'EASYPOPULATE_4_DISPLAY_STATUS_PRODUCT_UNIT_MEAS' in /home/shopping/fakeadmin/ep4_cron.php on line 179
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Use of undefined constant EASYPOPULATE_4_DISPLAY_STATUS_PRODUCT_UPC - assumed 'EASYPOPULATE_4_DISPLAY_STATUS_PRODUCT_UPC' in /home/shopping/fakeadmin/ep4_cron.php on line 183
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Use of undefined constant EASYPOPULATE_4_DISPLAY_STATUS_PRODUCT_GOOGLE_CAT - assumed
'EASYPOPULATE_4_DISPLAY_STATUS_PRODUCT_GOOGLE_CAT' in /home/shopping/fakeadmin/ep4_cron.php on line 187
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Use of undefined constant EASYPOPULATE_4_DISPLAY_STATUS_PRODUCT_MSRP - assumed 'EASYPOPULATE_4_DISPLAY_STATUS_PRODUCT_MSRP' in /home/shopping/fakeadmin/ep4_cron.php on line 191
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Use of undefined constant EASYPOPULATE_4_DISPLAY_STATUS_PRODUCT_MAP - assumed 'EASYPOPULATE_4_DISPLAY_STATUS_PRODUCT_MAP' in /home/shopping/fakeadmin/ep4_cron.php on line 195
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Use of undefined constant EASYPOPULATE_4_DISPLAY_STATUS_PRODUCT_GP - assumed 'EASYPOPULATE_4_DISPLAY_STATUS_PRODUCT_GP' in /home/shopping/fakeadmin/ep4_cron.php on line 199
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Use of undefined constant EASYPOPULATE_4_DISPLAY_STATUS_PRODUCT_EXCLUSIVE - assumed
'EASYPOPULATE_4_DISPLAY_STATUS_PRODUCT_EXCLUSIVE' in /home/shopping/fakeadmin/ep4_cron.php on line 203
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Use of undefined constant EASYPOPULATE_4_DISPLAY_STATUS_PRODUCT_DPM - assumed 'EASYPOPULATE_4_DISPLAY_STATUS_PRODUCT_DPM' in /home/shopping/fakeadmin/ep4_cron.php on line 207
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Use of undefined constant EASYPOPULATE_4_DISPLAY_STATUS_PRODUCT_SBA - assumed 'EASYPOPULATE_4_DISPLAY_STATUS_PRODUCT_SBA' in /home/shopping/fakeadmin/ep4_cron.php on line 211
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Use of undefined constant EASYPOPULATE_4_DISPLAY_STATUS_PRODUCT_CEON - assumed 'EASYPOPULATE_4_DISPLAY_STATUS_PRODUCT_CEON' in /home/shopping/fakeadmin/ep4_cron.php on line 215
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Use of undefined constant EASYPOPULATE_4_DISPLAY_HEADING - assumed 'EASYPOPULATE_4_DISPLAY_HEADING' in /home/shopping/fakeadmin/easypopulate_4_import.php on line 23
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Use of undefined constant EASYPOPULATE_4_DISPLAY_LOCAL_FILE_SPEC - assumed 'EASYPOPULATE_4_DISPLAY_LOCAL_FILE_SPEC' in /home/shopping/fakeadmin/easypopulate_4_import.php on line 26
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Undefined index: v_status in /home/shopping/fakeadmin/easypopulate_4_import.php on line 301
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Undefined index: in /home/shopping/fakeadmin/easypopulate_4_import.php on line 301
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Undefined index: v_status in /home/shopping/fakeadmin/easypopulate_4_import.php on line 414
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Undefined index: in /home/shopping/fakeadmin/easypopulate_4_import.php on line 414
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Undefined variable: v_status in /home/shopping/fakeadmin/easypopulate_4_import.php on line 686
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Undefined variable: v_status in /home/shopping/fakeadmin/easypopulate_4_import.php on line 689
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Undefined index: securityToken in /home/shopping/fakeadmin/includes/classes/class.admin.zcObserverLogEventListener.php on line 158
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Undefined index: securityToken in /home/shopping/fakeadmin/includes/classes/class.admin.zcObserverLogEventListener.php on line 158
[26-Oct-2019 23:37:07 America/Los_Angeles] PHP Notice: Undefined index: securityToken in /home/shopping/fakeadmin/includes/classes/class.admin.zcObserverLogEventListener.php on line 158
[26-Oct-2019 23:37:08 America/Los_Angeles] PHP Notice: Undefined index: securityToken in /home/shopping/fakeadmin/includes/classes/class.admin.zcObserverLogEventListener.php on line 158
[26-Oct-2019 23:37:08 America/Los_Angeles] PHP Notice: Undefined index: securityToken in /home/shopping/fakeadmin/includes/classes/class.admin.zcObserverLogEventListener.php on line 158
[26-Oct-2019 23:37:08 America/Los_Angeles] PHP Notice: Undefined index: securityToken in /home/shopping/fakeadmin/includes/classes/class.admin.zcObserverLogEventListener.php on line 158
[26-Oct-2019 23:37:08 America/Los_Angeles] PHP Notice: Use of undefined constant EASYPOPULATE_4_DISPLAY_RESULT_UPDATE_PRODUCT - assumed 'EASYPOPULATE_4_DISPLAY_RESULT_UPDATE_PRODUCT' in /home/shopping/fakeadmin/easypopulate_4_import.php on line 1752
[26-Oct-2019 23:37:08 America/Los_Angeles] PHP Notice: Undefined index: securityToken in /home/shopping/fakeadmin/includes/classes/class.admin.zcObserverLogEventListener.php on line 158
[26-Oct-2019 23:37:08 America/Los_Angeles] PHP Notice: Undefined index: securityToken in /home/shopping/fakeadmin/includes/classes/class.admin.zcObserverLogEventListener.php on line 158
[26-Oct-2019 23:37:08 America/Los_Angeles] PHP Notice: Undefined index: securityToken in /home/shopping/fakeadmin/includes/classes/class.admin.zcObserverLogEventListener.php on line 158
[26-Oct-2019 23:37:08 America/Los_Angeles] PHP Notice: Undefined index: v_status in /home/shopping/fakeadmin/easypopulate_4_import.php on line 2281
[26-Oct-2019 23:37:08 America/Los_Angeles] PHP Notice: Undefined index: in /home/shopping/fakeadmin/easypopulate_4_import.php on line 2281
[26-Oct-2019 23:37:08 America/Los_Angeles] PHP Notice: Undefined index: securityToken in /home/shopping/fakeadmin/includes/classes/class.admin.zcObserverLogEventListener.php on line 158
[26-Oct-2019 23:37:08 America/Los_Angeles] PHP Notice: Undefined index: securityToken in /home/shopping/fakeadmin/includes/classes/class.admin.zcObserverLogEventListener.php on line 158
[26-Oct-2019 23:37:08 America/Los_Angeles] PHP Notice: Undefined index: securityToken in /home/shopping/fakeadmin/includes/classes/class.admin.zcObserverLogEventListener.php on line 158
[26-Oct-2019 23:37:08 America/Los_Angeles] PHP Notice: Use of undefined constant EASYPOPULATE_4_DISPLAY_IMPORT_RESULTS_TITLE - assumed 'EASYPOPULATE_4_DISPLAY_IMPORT_RESULTS_TITLE' in /home/shopping/fakeadmin/easypopulate_4_import.php on line 2493
[26-Oct-2019 23:37:08 America/Los_Angeles] PHP Notice: Use of undefined constant EASYPOPULATE_4_DISPLAY_IMPORT_RESULTS_NUM_RECORDS_UPDATE - assumed 'EASYPOPULATE_4_DISPLAY_IMPORT_RESULTS_NUM_RECORDS_UPDATE' in /home/shopping/fakeadmin/easypopulate_4_import.php on line 2520
[26-Oct-2019 23:37:08 America/Los_Angeles] PHP Notice: Use of undefined constant EASYPOPULATE_4_DISPLAY_IMPORT_RESULTS_NUM_RECORDS_IMPORT - assumed 'EASYPOPULATE_4_DISPLAY_IMPORT_RESULTS_NUM_RECORDS_IMPORT' in /home/shopping/fakeadmin/easypopulate_4_import.php on line 2522
[26-Oct-2019 23:37:08 America/Los_Angeles] PHP Notice: Use of undefined constant EASYPOPULATE_4_DISPLAY_IMPORT_RESULTS_NUM_ERRORS - assumed 'EASYPOPULATE_4_DISPLAY_IMPORT_RESULTS_NUM_ERRORS' in /home/shopping/fakeadmin/easypopulate_4_import.php on line 2524
[26-Oct-2019 23:37:08 America/Los_Angeles] PHP Notice: Use of undefined constant EASYPOPULATE_4_DISPLAY_IMPORT_RESULTS_NUM_WARNINGS - assumed 'EASYPOPULATE_4_DISPLAY_IMPORT_RESULTS_NUM_WARNINGS' in /home/shopping/fakeadmin/easypopulate_4_import.php on line 2526
[26-Oct-2019 23:37:08 America/Los_Angeles] PHP Notice: Use of undefined constant EASYPOPULATE_4_DISPLAY_IMPORT_RESULTS_MEM_USE - assumed 'EASYPOPULATE_4_DISPLAY_IMPORT_RESULTS_MEM_USE' in /home/shopping/fakeadmin/easypopulate_4_import.php on line 2529
[26-Oct-2019 23:37:08 America/Los_Angeles] PHP Notice: Use of undefined constant EASYPOPULATE_4_DISPLAY_IMPORT_RESULTS_MEM_PEAK - assumed 'EASYPOPULATE_4_DISPLAY_IMPORT_RESULTS_MEM_PEAK' in /home/shopping/fakeadmin/easypopulate_4_import.php on line 2531
[26-Oct-2019 23:37:08 America/Los_Angeles] PHP Notice: Use of undefined constant EASYPOPULATE_4_DISPLAY_IMPORT_RESULTS_EXEC_TIME - assumed 'EASYPOPULATE_4_DISPLAY_IMPORT_RESULTS_EXEC_TIME' in /home/shopping/fakeadmin/easypopulate_4_import.php on line 2537
[26-Oct-2019 23:37:08 America/Los_Angeles] PHP Fatal error: Uncaught Error: Call to a member function add() on null in /home/shopping/fakeadmin/easypopulate_4_import.php:2547
Stack trace:
#0 /home/shopping/fakeadmin/ep4_cron.php(332): require()
#1 {main}
thrown in /home/shopping/fakeadmin/easypopulate_4_import.php on line 2547
Is the 1.56c version now supported?
Is the 1.56c version now supported?
Not 100% sure how to answer this question. As written (which may be related to a language issue) the answer is yes because issues that are identified are corrected. As perhaps understood to be meant, I have been able to successfully use EP4 as provided from GitHub on ZC 1.5.6c. Currently, one of the added features is not 100% complete.Quote:
Originally Posted by jodean
The new feature of using the extension of _en or similar to denote a specific language works for the full import; however, does not for one or two of the other imports.
Note, that this new feature has been incorporated to allow continued use of the import file(s) as they were (a language dependent field ending with the language_id associated with how that database is setup) but it also offers some override type features where if both the language_code (e.g. en, de) and language_id were used then one overrides the other.
Further note, that although I chose to be somewhat forceful in discussion with a recent user at the cost of being seen as a jerk, the information obtained led to a solution that resolved the issues that otherwise were going to be ignored.
As far as the software with Zen Cart 1.5.6c there is nothing done to that version of software affecting this, the issues if any are or expected to be related to php versions.
ZC 1.5.6a Classic Clone.
CheckBoxTextBoxIconV1.0.3
EasyPopulate-4.master-ZC
one_page_checkout-2.0.5
ColumnGridLayout_for_155f
Using two "Product Types"
(Type 1) Product General and (Type 4) Document Product.
When I export with ep4 the v_products_type column is correct.
( I get 1 & 4 )
When I import all type 4 get changed to type 1.
Searched all morning but could not find a solution.
Is there a setting that over rides product types when importing with EP4?
In Admin "editing " category mode (Type) doesn't have any effect on the Product Type setting of products already entered.
When entering new products in Admin the Type setting works correctly
Thank You in Advance for your time.
While there are few "restrictions" really placed on the software, one that is present is by default allowing the product type to be changed on update. That said, because it is a product field, there is the ability to incorporate it as a user defined field in the configuration area. In this way, updates will attempt to modify the products_type field so long as products_type is identified there.Quote:
Originally Posted by linuxguy2
Quote:
Originally Posted by linuxguy2
I've tried to look further into what might cause a change in the status and see that it seems if the v_products_type field is not present in the import file, then the value might be changed. Could you please identify the presence of that field in an import file where this type conversion has occurred? Have a few ideas about how to address what appears to be a todo item, though I thought it had been otherwise addressed.Quote:
Originally Posted by mc12345678
The v_products_type field is in the import file and contains the desired values ( 1 & 4)Quote:
Originally Posted by mc12345678
As I indicated the export file contains the correct value 1&4 in the v_products_type field which was entered/selected via the Admin interface.
Uploading the same file flips all v_products_type back to 1.
Thanks,
And the settings for the User defined fields in configuration->Easy Populate V4?Quote:
Originally Posted by linuxguy2
I believe I just use the default settings.Quote:
Originally Posted by mc12345678
Please see attached images
Attachment 18747Attachment 18748
Ahh yes, that version 4.0.36.ZC did have a little issue with products_type on import which at least is partially addressed in the current master branch. I thought that change had been incorporated sooner, but see that is not the case.Quote:
Originally Posted by linuxguy2
Anyways, I wanted to acknowledge the issue and am trying to put together even just some code here to address it, but at the moment I'm a little short on resources.
I do "think" that if the field were added as a user identified field that the file's value would override the code's attempt to set/maintain a value.
Cool! No rush. Just wanted to be sure I wasn't overlooking some setting.Quote:
Originally Posted by mc12345678
I'll see if I can find the fix in the code, a work around or upgrade to the newest version.
Haven't used this feature before and because I'd like to display "Quantities on Hand" on specific items it will come in handy.
This Plugin has been such a time saver I can't imagine using ZC without it.
Thanks, For Your time!!!!
Hi all. Upgrading from Easy Populate 1.2.5.4
Please confirm that I'm understanding this correctly:
Old version: v_categories_name_1, v_categories_name_2, v_categories_name_3 (etc.) was Category, Sub-Category, Sub-sub-Category (etc.) (ie. Vegetable, Tomato, Roma, for example)
New version: v_categories_name_1, v_categories_name_2, v_categories_name_3 (etc.) are now languages (ie. English, French, German, etc. would be Vegetable, Légume, Gemüse, etc.)
To get sub-categories, I need to put all words in the v_categories_name_1 (for English) separated by carats Vegetable^Tomato^Roma
Correct?
Thanks.