Printable View
A review of recent posts may have revealed the direction provided here: https://www.zen-cart.com/showthread....52#post1381452Quote:
Originally Posted by Reviresco
Again, the problem is/was (most likely) the default settings were set incorrectly. I have two improvements to make and then I will be uploading an updated copy that won't start off that way.
I just installed Easy Populate 4.0.37.13. I was able to download the products file and open it in OpenOffice. But, I am getting all kinds of warnings in the log files. Many of these warnings are related to the image below where undefined constants show up and "no supported file types." I created a new folder in Admin /temp. I copied the .htaccess file into that newly created (empty?) folder. Just wondering if I did anything wrong.
Also, I noticed a few folks having issues in previous posts about things not uploading. Is this still an ongoing issue? I need to upload about 150 products before the end of the day! :O
Attachment 19656
I get the same red text error messages. I've ignored them and all works fine. I did discover that your upload file name cannot have spaces in the name. For example new products.csv will not work. Use instead newproducts.csv
Perhaps that text could be changed (the text in red) to be in some other way descriptive. What is done on that part of the screen is to provide the file naming prefix that is needed to process that type of file and indicate below that section what file (if any) is processable by that filter. For the user that has determined that the extra info is of no use, there is a configuration option to hide the sections not used or if so desired to return to the original distribution that would only show filenames with no extra assistance. That switch option is titled: Show all EP4 Filetypes with Files.Quote:
Originally Posted by g2ktcf
As for import issues? If this is/was a default install, none of those configuration settings have been modified before attempting upload, and the headings of the import file reflect those of the default export file, then *yes* there will be an import "problem". I would have thought that through review of those two discussions one would be able to determine the action necessary to prevent the "issue" and even once I release 4.0.38, there will still be the *possibility* of such a problem because the software is being made to support being more flexible/capable.
Let me once again put it simply. In a default install of 4.0.37.13, change the configuration setting for 'Import Language Override" so that it includes the language dependent field identifiers in the import file. I.e.: language_code_only (desired fields to import will only be reviewed if they end with a language code, e.g. products_name_en), language_id_only (desired fields to import will only be those that end with a language id, e.g. products_name_1) or in the case where both types could exist, which of them is preferred realizing that if the preferred method is not present but the alternate is that the alternate will be used.
Again even simpler than trying to understand how to use the software, in a default install, if the exported file is used to create a new import then change the EP4 configuration setting for "import Language Override" to any other setting. I suggest doing so with understanding, but free to do what is desired.
As far as errors in the log files, I have on php 8.0 with a fresh install only found one case of logs being generated which was the use of a constant that wasn't defined prior to clicking the update or install link while reloading the EP4 tools page which was described above recently and is corrected in 4.0.38.
As far as the htaccess file consideration, as of Zen Cart 1.5.7, no such htaccess file is needed in the admin of a default installed store and if the folder is to be placed on the catalog side, no such file would be needed unless changes from a default install have precluded csv files from download/access.
As for release of 4.0.38, I'm trying to work through some perceived issues with the new zc_plugins directory and software structure that works for default users but may cause problems for those that have gotten creative with say folder names within the store's structure. I want the software to be as easily modifiable as possible to ensure operation in both conditions and to update/modify as necessary to ease support as it becomes used more. Right at this moment I've considered adding internal folder references and then evaluate during installation if/how differences exist between the expected folder paths and current paths.
Ok, you made it past that paragraph, what I would like is if some alternate text could be provided to clarify the above red text about "No Supported Data Files". Either changing that text or providing a little info associated with this "table" to amplify what data is being shown. Please do so asap so that I can incorporate into 4.0.38.
.Quote:
Originally Posted by mc12345678
After playing around with different import files and names, I finally understand how this new workflow handles files. That is what I was missing. Just to prove it, I added category-ep to a file and uploaded it, and, then is shows up instead of "No Supported Data Files." The text you have is fully understandable now. Might I suggest "No Supported Data Files Uploaded"?
Hate to interupt brainstorming. Can you or others think of some additional ideas? It doesn't have to be just adding a single word. Whatever would minimize confusion of the absence of filenames where the "guide" for filename prefix is present.Quote:
Originally Posted by g2ktcf
While I might also consider changing the color, I've come to learn through the guidance of others on this site that color changes/differences should be used with care as there is an effort to sustain visibility for those with difficulting seeing colors or color differences.
Just FYI, I was having similar issues to the previous poster in regards to the language import settings. After going back over the previous threads and changing the Import Language Override: language_id, everything started working fine.
Thanks!
well, the intent is to show that there are no "applicable" files for that filter...First off, yes, red is typically a "you messed up color" so I would think something in blue would work. "No Filter Specific Files Found in Uploads Folder"...you could show that folder path if it helps. BTW, I have a partial Red/Green color deficiency but I have no problems with PURE reds and greens.Quote:
Originally Posted by mc12345678
I've come to the mind that I am going to be establishing in new installs that language_id_only will be the default. The upgrade to 4.0.38 will *not* change the setting from those using 4.0.37.13, but the text about what *is* the default will change.Quote:
Originally Posted by g2ktcf
So the reason? Well, while adding capability and functionality is an improvement, there are too many that have already established their process. It may/may not include a column of text that uses or has a field that follows the language_code format (_en), but I'd rather this capability be considered a "secret" feature than a store's problem.
Another that has adapted/added to EP4 in support of the book product type had previously suggested that this feature just should not exist. At the same time I have seen and experienced the confusion that can exist by use of the database driven language_id instead of the international use of the language_code. But, in the improvement of the software, it is/was a feature seen as needed. Unfortunately I completely botched the default settings... I THOUGHT they were set right, but I was abhorrently wrong. I did also consider making a single switch that controlled both import and export together, but that to me seemed too restrictive and prone to its own issues.
And, while not addressed recently. One should consider that if an issue wasn't readily identified in the past that perhaps the issue is only from a recent change and often, I would say that a problem experienced "now" with the latest software is either directly because of the latest change or perhaps was not made known as an issue in the past... meaning, search of the posts beyond the latest release is not (or should not?) likely reveal assistance on those issues sought. That is if the issue is with the expected "normal" operation.
Hopefully now that the import/export discrepancy has been described at least three different ways, that until 4.0.38 or newer is installed over 4.0.37.13 that the situation can be more clearly understood/corrected.
This info *is* all about one's "perspective". I've not wanted to use the word Upload, because selecting one of the export filters creates a file for the associated filter area and while it could then be uploaded, it also could be downloaded. For some, that folder is used just for that perspective such as for data updates to external sources.Quote:
Originally Posted by g2ktcf
Again, don't want to give up on something new/more appropriate, just because "now" it makes sense, the goal is for it to make sense without discussion.
Note, the folder "path" is shown in the upper right hand corner of theadmin screen. Doesn't or isn't expected to show the true admin folder name, but...
I spent 6 hours today trying to get this plugin to work. Spreadsheet shows all lines with same values as the 2 line template downloaded, yet it will not create the items when uploads. All I get is an error message that there is no category for this product for 68 items in the spreadsheet. If one has to use openoffice to make this work, then that is a problem. Either make it work with MS or change the file format to text so that the excel import wizard will fire up and ask for delimiters. CSV files will not start the import wizard. Im exhausted.
Please follow the links at this post. This issue has been discussed multiple times within this thread already.Quote:
Originally Posted by pixelpadre
Shortcut? Within the Admin of your Zen Cart Version, please select the configuration menu option, scroll down to Easy Populate V4 and open it.
at the fourth option down, select to edit the menu option Import Language Override?
Assuming that you are using a "normal" or "historical" type csv file/field-naming convention, change the value to anything other than the EP4.0.37.13 installation default of language_code_only. That is, the value selected should in some way represent the language type identifier that you are using in your file. The default import was incorrectly set to language_code_only. That setting requires fields to include the language_code (en, de, es, etc...). Good ole' EP4 uses the language_id and the default export was set to use language_id.
The new default will be language_id_only in the next distribution.
For those that have already installed, read through this forum about the recent release (huge) ISSUE, the next upgrade will not adjust whatever value is currently set, but the description will be updated to identify the new default. Default for export and import will match at using the historical language_id.
Seems like that worked. You should delete the previous 3,000 posts and start from here.
I am trying to create an csv order upload for Shippo. When I use the orders download from EP4 all I am getting is headers only...no orders even when I select status that have orders. Any idea where to start looking for the issue? I do not see a date range on that so I assume it is all based on order statuses.
I've changed the menu option Import Language Override to language_id, and I'm still getting the same result: when I click the Import button, I get redirected to the admin main page and nothing has been imported; also no errors anywhere. This also happens if I click the Delete button.Quote:
Originally Posted by mc12345678
Sadly, through a lack of investigation/support, the orders aspect of EP4 has not been flushed out. The overall functionality is not present because no level of consensus of the output file format was even closely identified. The "functionality" (selection?) though remained because I suspect others may have completed the effort and not shared their work, but I also didn't want to make it difficult for them to retain what they had done... Without a good output format, it is difficult to develop an import format. BTW, this "feature" was added back in rev 4.0.31a to try to begin/further the ability. V4.0.31 was announced released in August of 2015 and at this post: https://www.zen-cart.com/showthread....33#post1291133. V4.0.31a is in github at: https://github.com/mc12345678/EasyPo...4.0.31a_posted. I would have to research further to provide more historical perspective.Quote:
Originally Posted by g2ktcf
There are other plugins that provide that feature in its entirety and I likely could flush out the operation from one/more of those, but...
What's the name of the file? I am assuming that it has a space in it...Quote:
Originally Posted by Reviresco
which plugin?Quote:
Originally Posted by mc12345678
Hmmm.. I guess I again have been foiled by this search... I came across this thread (from many years ago) about the import difficulty associated with orders... Export is one thing (and there are export utilities), but import involves a huge amount of manipulation though not to say it isn't possible, it isn't made freely... There are some tools that would help with mapping fields to database areas and such have been discussed herein, but please take a look at this old post about the effort involved with the import process: https://www.zen-cart.com/showthread....942#post855942Quote:
Originally Posted by g2ktcf
That's just on the interrelationship of data...
The real question here is, what is the need for this import? Is this presumably related to a store upgrade or what is the associated need?
I just want to EXPORT so I can import the shipping info from my store into Shippo since that their API is so old.
Ohhh... Darnit, I deleted the link that I had found for Orders Exporter. Sorry... I went too far into the "dilemma". :)Quote:
Originally Posted by g2ktcf
She-Loves-Color-Secret-Shop-2021.csvQuote:
Originally Posted by mc12345678
Quote:
Originally Posted by Reviresco
Still trying to get this to work.
Quote:
Originally Posted by Reviresco
Quote:
Originally Posted by mc12345678
Quote:
Originally Posted by Reviresco
While I have it (version 4.0.36.13/ZC) working with ZC 1.5.7x I am not seeing the above issue(s) occurring... I could see a possible problem if files in a site's directory were in some way "locked" down, for example, clicking the delete button for a file that is prevented from being deleted, possibly. I don't see anything special about the filename that would prevent deletion (as stated typical/historical issues with filenames as far as preventing something from happening) has been spaces in the filename or some other character that is not accepted by the filesystem where the file has been stored.Quote:
Originally Posted by Reviresco
The only other time that I have seen ZC 1.5.7 respond the way that is described is when a form (user input area) is set to provide information in the browser address bar instead of passing the information along in the background. In EP4 the links that are like this "problem" area are the clickable links below the filters (they export data) and the download link adjacent to each stored filename. Even those in that situation feed back to the same file. Feeding back to the same file actually is a good thing as it actually eliminates a problem.
Perhaps attempt to upload the files again? I know Chadderuski used to suggest verifying file load to include possibly building a temporary site, loading the files to it and then attempt to upload and import the file(s).
Basically either I need to be able to see the issue in action or I need to be able to reproduce it in order to find a solution.
Here's what the form looks like:Quote:
Originally Posted by mc12345678
HTML Code:<form name="import_form" action="https://www.mysite.com/my-shop/my-admin/index.php?cmd=easypopulate_4.php" method="post"><input type="hidden" name="securityToken" value="securitytokenhere"><input type="hidden" name="import" value="She-Loves-Color-Secret-Shop-2021.csv"><input type="submit" name="import_button" value="Import"></form>
When I change (in the browser console):Quote:
Originally Posted by Reviresco
index.php?cmd=easypopulate_4.php
to just:
easypopulate_4.php
it works.
What's the best way to change this? Is it a global setting I need to change in Zen Cart? Htaccess? Something else? All the links in the admin "Tools" dropdown menu use the "index.php?cmd=xxxx" format.
That is the content expected...Quote:
Originally Posted by Reviresco
Hmmm.. What specific version/sub-version of ZC 1.5.7 is installed?Quote:
Originally Posted by Reviresco
"You are presently using: v1.5.7"Quote:
Originally Posted by mc12345678
Okay here's how I got it to work:
In easypopulate_4.php, change:
to:Code:zen_draw_form('import_form', basename($_SERVER['SCRIPT_NAME']), /*$parameters = */'', 'post', /*$params =*/ '', $request_type == 'SSL')
and also do the same with the forms "delete_form" and "split_form"Code:zen_draw_form('import_form', FILENAME_EASYPOPULATE_4, /*$parameters = */'', 'post', /*$params =*/ '', $request_type == 'SSL')
ChangingtoCode:basename($_SERVER['SCRIPT_NAME'])
also works.Code:basename($_SERVER['SCRIPT_NAME'], '.php')
Also, is the file: admin/includes/extra_datafiles/easypopulate_4_filenames.phpQuote:
Originally Posted by mc12345678
having the content:
Loaded to the server?Code:<?php
// $Id: easypopulate_filenames.php, v4.0.35.ZC.2 10-03-2016 mc12345678 $
define('FILENAME_EASYPOPULATE_4', 'easypopulate_4');
(I'm not where I can test system response without that file, so this is a little bit of a possible reason or as otherwise known: a guess. :))
The best solution is to upgrade as soon as possible to 1.5.7c. There are a number of corrections that are implemented and considered necessary.Quote:
Originally Posted by Reviresco
As to "this issue", the correction I believe is located in admin/includes/application_bootstrap.php (with possibility of other areas of the system affected/touched):
changing:
To:Code:$serverScript = basename($_SERVER['SCRIPT_NAME']);
$PHP_SELF = isset($_SERVER['SCRIPT_NAME']) ? $serverScript : 'home.php';
$PHP_SELF = isset($_GET['cmd']) ? basename($_GET['cmd'] . '.php') : $PHP_SELF;
$PHP_SELF = htmlspecialchars($PHP_SELF);
$_SERVER['SCRIPT_NAME'] = str_replace($serverScript, '', $_SERVER['SCRIPT_NAME']) . $PHP_SELF;
There may be other places where a change may be necessary to support the above; however, EP4 has not required the change described above to work in up-to-date systems.Code:$serverScript = basename($_SERVER['SCRIPT_NAME']);
$PHP_SELF = isset($_SERVER['SCRIPT_NAME']) ? $serverScript : 'home.php';
if (basename($PHP_SELF, '.php') === 'index') {
$PHP_SELF = isset($_GET['cmd']) ? basename($_GET['cmd'] . '.php') : $PHP_SELF;
}
$PHP_SELF = htmlspecialchars($PHP_SELF);
$_SERVER['SCRIPT_NAME'] = str_replace($serverScript, '', $_SERVER['SCRIPT_NAME']) . $PHP_SELF;
i notice this is for .csv, i have a supplier that offers an .xml of products, is there a module for these or can this module be altered easily to work with .xml?
I'm afraid I need a bit of advice here. I'm using Easy Populate 4.0.37.13, with the SBA mod. Does anyone know what import/export options in EP I should use to take a category with 300 products, all with 4 or 5 attributes (sizes), all with different stock levels, from one website, and copy it into another website? I foresee problems in that the options and attributes have different id numbers on each site, and I can imagine it all crashing horribly. The export site is on ZC 1.5.7b, the import site on 1.5.7c, both with the correct SBA version, (SBA for 1.5.7b, and SBA for 1.5.7c) and both with EP 4.0.37.13. Are there any steps I should take before attempting it ? Thanks.
"Easily" would be a matter of perspective; however, I can envision where the current "file read" code may be positioned to a function with some "trigger" being added to identify what the source is for the filetype and support properly moving through the file. While this operation is perhaps easier in newer PHP versions, it remains important to note that the process would work best by stepping into/through the file rather than loading it entirely into memory. The file reading occurs in a few of the modules as well as the main import file. There is also a field delimiter test that is performed against files that may need to be altered to exclude such xml files or provide an equivalent test if necessary.Quote:
Originally Posted by flappingfish
So, the first question is why is the database being "manually" transferred from one site to another by a process other than transferring the entire database?Quote:
Originally Posted by cefyn
As far as the concern of matching product and designations, yes that is/would be a concern and for reasons that are described above.
Note also, that the SBA "filter" does not create/remove relationships of product attributes to/from product. It supports modifying the data associated with an existing relationship.
There is guidance in the README about the following: A way to reproduce attributes in one store from another using EP4:
That would at least get the attributes established, but then would need to go generate the SBA relationships. Then would suggest exporting the new SBA relationship file and compare/align data for a proper update.
I'm relatively certain that the question has been asked before in here with details provided. I've spent a little time trying to search on "SBA" or "stock by attributes". There are posts associated to each of those 2 search "terms", but I haven't dug into all/most of them and also haven't cross referenced when the SBA import/export was incorporated to narrow down the window of applicable dates. Maybe if it is found it can be linked back from this area.
Thanks for your reply, mc. The database it's being copied from has 5000 products. There's an easy way to do it. Copied and uploaded the products with EP, used the native function admin/attributes controller/copy options to a whole category, and then just updated stock quantities with EP.
Glad that worked. Note that I had asked the question of why because 1) in following the standard ZC process for updating, the database is retained from one location to the other and 2) understand that if the same content is carried across multiple sites that as far as the internet is concerned, you're competing against yourself and the two sites having the same content will likely (eventually) cause a change in rankings. They may each have the same or different products_id; however, with ranking being content centric these two sites would initially grossly have the same content.Quote:
Originally Posted by cefyn
Again, understand that EP4 does not (yet) recreate the SBA variants which can be independently stocked from the total stock of the product. If the variants exist in the database, then yes natively copying should support duplication of the variants that can then be updated with EP4.
The products will be removed from one site after the transfer. You're right, there's no point in having any identical content, it'll get ignored at best. As for the rest of it easier said than done. I can read the downloaded EP files and edit them manually. I was able to get all the products uploaded somehow, but the files that EP is generating are showing "CSV unknown delimiter" and the SBA EP files aren't updating stock. I notice you've discussed something like this before in regards to a Japanese language pack. Manual edit in SBA I'm afraid.
What I've found is this: the product import will likely have invalid csv delimiter reports if the software has not been updated (top right corner should show an update clickable link). The sba import may have a similar report in a given condition, but this is an issue when data is exported and then not "corrected" within the applicable spreadsheet. If exported, downloaded, corrected and then uploaded, the import works. It is resolved in the next update, but I've been preoccupied with something else recently which has delayed my updating of the instruction for distrubution. I can post the fix for the sba issue separately if that is the only csv delimiter issue... Otherwise need to review the first four lines of the csv file tovalidate formatting, delimeter being used, etc. Those are what the software reviews to provide that notification.Quote:
Originally Posted by cefyn
If the sba file is showing that it is acceptable to import, but the stock is not being updated, then please identify the process to get the sba file and populating its stock. Even with the csv delimiter issue, I have seen that stock updates. Include discussion of the filename for the import file.
Thanks mc, that worked. I updated the EP database, exported Stock of items with attributes including SBA, corrected quantities, uploaded, imported, and all stock with attributes updated correctly. All files were identified as csv by EP. Thanks for all your work on zen cart, it is very much appreciated.
No problem, glad that it worked... Wondering what needs to be done to "better" identify the need to do that update... The link is normally not present and only shows under specific conditions... I suspect it could be more "flashy" but also is something that should be executed after uploading updated files... :/Quote:
Originally Posted by cefyn
I am having an issue with ZC 1.5.7c and EP 4.0.37.13.
I have tried to import categories from 1.3.9h in several languages and got the result "File uploaded Successfully: CategoryMeta-EP2021-08-24-121946.csv Issues with the CSV file delimiter(s)"
Lower in the EP page in the table it says "CSV Unknown Delimiter" and "Import Error".
So I tried to remove all the languages from the categories CSV and left only the main language which is EN and again tried to upload and I get the same result.
Have checked the file in OO and also in Notepad++ to make sure of the delimiter etc'.
Both ZC and EP are latest versions and on SG hosting.
Any ideas?
Is there a link in the upper right hand corner of the EP4 screen indicating to update/upgrade or just the remove/uninstall link? If update/upgrade is available select that first then review the condition of reporting about the CSV delimiter.Quote:
Originally Posted by eavinu
To help narrow down the issue(s), may I suggest the following test(s):
Create a file using one of the "export" options: Does the CSV Unknown Delimiter issue occur? If so, then it is a problem with the EP4 software.
The CSV file that has been generated, mentioned that using Open Office or similiar, is the file being stored (saved as and following additional action to ensure that the encoding is UTF-8) as a UTF-8 format file (not having a BOM)?
When viewing the CSV file, what are the first 4 lines of text? (These are used to evaluate the likelihood that the CSV delimiter has been properly applied/used.
I tried several versions of export and the same error occurs.Quote:
Originally Posted by mc12345678
There is no update/upgrade, only uninstall.
First 4 rows look fine, the exported files are UTF-8 without BOM...
To confirm, when say tried several versions of export and to be sure that we are each talking about the same thing (no assumptions) please identify what was done to perform the export(s). I know it sounds silly, but sometimes the difference/solution is in the communication.Quote:
Originally Posted by eavinu
So, what delimiter is identified in your configuration settings and what delimiter is being used? I have seen some systems where the export file includes a delimiter that was unexpected/unrequested. Also hate to say this, but the question was what do the first four rows include, as in please provide the first four rows for an independent review. While it may appear correct by one individual's review, extra eyes help find the issue.
Furthermore I'm not able to repeat the issue with 1.5.7 nor 1.5.8, though both are on the same server/host, one with php 7.4 the other 8.0.
I failed to say that the DB is actually an import from 1.3.9h that is on Godaddy hosting (10 years old) and the installation is fresh 1.5.7c files and I did DB upgrade with zc_install of course.Quote:
Originally Posted by mc12345678
I then saw an issue with the encoding for Hebrew, it was showing gibberish both in the DB and in the storefront while in the old website it showed gibberish in the DB but showed Hebrew in the storefront.
Then I started trying to resolve by only exporting and importing the categories_description table to see it it helps and still had gibberish instead of Hebrew.
I asked for assistance from Eran Ariel (eranariel) The Zenner that published the Hebrew UTF-8 ZC language pack and he suggested to try going with latest version of EP and then I installed EP4 on both installations.
After exporting from the old one and importing to the new one I realized this error.
I went over all the parameters and also inspected the exported categories file and everything looked okay.
Then I decided to check what happens if I export a file from the new website and try to import it back to the new website, I get the same error.
The error in the table shows after exporting and not only when importing.
To answer your questions, under "Category Export/Import Options" I chose Model/Category at first, later I also tried Categry with Meta Tags.
I also tried full export under Filterable Exports.
First 4 rows of category file:
v_products_model,v_categories_name_2,v_categories_name_3,v_categories_name_4,v_c ategories_name_5,v_categories_name_6,v_categories_name_7,v_categories_name_9,v_c ategories_name_10,v_categories_name_11,v_categories_name_12,v_categories_name_13 ,v_categories_name_1
"MG02","Round Herb Grinders^Metal grinders","Round Herb Grinders^Metal grinders","Round Herb Grinders^Grinders de metálico","Round Herb Grinders^Metal grinders","Round Herb Grinders^Metal grinders","Round Herb Grinders^Metal grinders","Round Herb Grinders^Metal grinders","Round Herb Grinders^Metal grinders","Round Herb Grinders^Metal grinders","Round Herb Grinders^Metal grinders","Round Herb Grinders^Metallmühlen","Round Herb Grinders^Metal grinders"
"MG08","Round Herb Grinders^Metal grinders","Round Herb Grinders^Metal grinders","Round Herb Grinders^Grinders de metálico","Round Herb Grinders^Metal grinders","Round Herb Grinders^Metal grinders","Round Herb Grinders^Metal grinders","Round Herb Grinders^Metal grinders","Round Herb Grinders^Metal grinders","Round Herb Grinders^Metal grinders","Round Herb Grinders^Metal grinders","Round Herb Grinders^Metallmühlen","Round Herb Grinders^Metal grinders"
"MG05","Round Herb Grinders^Metal grinders","Round Herb Grinders^Metal grinders","Round Herb Grinders^Grinders de metálico","Round Herb Grinders^Metal grinders","Round Herb Grinders^Metal grinders","Round Herb Grinders^Metal grinders","Round Herb Grinders^Metal grinders","Round Herb Grinders^Metal grinders","Round Herb Grinders^Metal grinders","Round Herb Grinders^Metal grinders","Round Herb Grinders^Metallmühlen","Round Herb Grinders^Metal grinders"
I just clicked now to export the file and I also have a new line added to the table below in the EP4 page that has this export file name and says CSV Unknown Delimiter and Import Error, I didn't try to upload and import this file...
That's the useful information that helps...
So a couple of things. One it would appear that probably need to convert the database to utf8/utf8mb4, though that may may/not correct the issue in total. Other things of "interest" would be the collation on the admin/catalog side as identified for the language being used at least on the admin side. E.g., is English being used for the admin or one of the other "foreign" languages? Another thing, is that as I recall (need to search a little more) I thought that with Hebrew, there was possibly some alternate effort needed. Not quite the same as Japanese or Russian, but similar... There is some guidance about what needed to be done differently within EP4 and/or one's server possibly 20 pages back? It was "recently" discussed and by recent in this case I mean within the last year...
It was discussed by an individual that has been busy updating/modifying code to support Japan so even looking up the Japanese language pack may find the individual and from there look at their posting history to see when/where posted to EP4 (or perhaps they are happily in receipt of this message and can pop in to provide some assistance though there is a "process" by which they may/may not see the message(s) right now.)
To me, what is curious though is that basically all languages use the "same" category names... I would have thought that there would have been more of a translation.
So, short summary, good to know that the database was "upgraded" using zc_install (hopefully did not run into issues that stopped updating of the configuration table which can be tested by attempting to update a configuration option of any setting, if there is a sql error then there is likely some additional "work" to be done/redone).
Next has to do with character encoding of the database and system. Then there is possibly some additional action to address languages; however, there is the discussion that creating a new CSV file has also exhibited a CSV delimiter issue... Again as an assumption, I believe the above provided data is from the CSV that was generated by EP4. The next thing to consider is if there is a "system" issue by generating a new CSV file directly (one line of data would be suggested in a single language) and attempting upload and import... Would suggest again posting the contents of that file here; however, this time please use the [CODE][/CODE] tags generated by pressing the # button in the message box while generating the post.
So I am happy to say that finally the Unknown CSV Delimiter issue was solved.
I don't know why I didn't try this before...
At first, since this was an upgraded website and had previous versions of EP (1.2....), there was a temp folder in the root and I left it there, changed in the EP4 configuration to false under Uploads directory Admin/Catalog.
Now I decided to move it to the Admin folder and changed the configuration to True and the Unknown CSV Delimiter indication turned to a "CSV ," indication.
So now I only need to deal with the other issue that I discovered today, going through checkout timesout... doesn't matter which shipping method or payment method is being chosen.
Hope to find the correct thread to get help with that LOL
Thanks a lot mc12345678 for your efforts.
Regards,
Eran
So actually they have a lot of products and categories and many of them are not fully translated to all languages, this is actually why they decided to drop a few languages now so making my job a bit easier :)Quote:
Originally Posted by mc12345678
So I can now report that I found the error for that one as well (checked Debug logs), the issue was sending emails so I cancelled the email sending options for now since there is no point in trying to configure that while still in SG staging area and not under the correct domain...Quote:
Originally Posted by eavinu
Turns out on further checking i can actually make my own custom mapped feed at the suppliers website and in .csv format :). I've tried a few times. finally found how to add gtin as an option too and tried to upload again to get the following error messages "Missing primary key from file" and "File Import Completed with issues."Quote:
Originally Posted by mc12345678
I've spent hours trying to solve this and even hired developers to install the module and get the feed working as i didn't fancy doing it myself. developers worked over the quoted time and between say 4 of us its getting frustrating lol. it's something simple being missed now i'm sure of it?
Anything that's commonly done that would cause such issues ie not including the "v_" beginning to product fields? i'm sure it was in this support thread i read your not supposed to include that part?
The message provided indicates that whatever is being used for your "unique record" is not present in the first line of the file... By default that field header is: v_products_modelQuote:
Originally Posted by flappingfish
By making changes in the configuration menu, it is possible to instead change to using: v_products_id
By way of code, there is an observer that can be used to select/use a completely different primary key.
Note that again, this "primary key" is what ties the data being imported to the record(s) in the database. Depending on what is used for the primary key, multiple database records may be affected. For example, if there was a word within the products description that was used as a "primary key", then every record that has that word would be impacted by importing a row of data with that word. This is why when using v_products_model if more than one product has that exact model designation that import of a record with that model designation will affect all such product.
As far as the reference to using/not using the prefix "v_", that is associated to identifying other product table fields that are to be used in the import/export. The place where the "v_" is omitted is within the configuration settings for the User Defined Products fields... When entering/adding such fields within the configuration menu, they should be added using whatever the field is actually called in the products table.
Perhaps the above helps? It may be of assistance to provide the configuration settings and other pertinent information to get to your solution.
adding the v_ prefix has got it working for me :DQuote:
Originally Posted by mc12345678
Few slight issues though sadly if you can assist with any of these i'd be eternally grateful :) ..
1. The gtin field isn't being populated on my end even though its showing in the feed from supplier as "v_gtin". ive also tried it as "gtin" to no avail. after thought as typing should i try "v_products_gtin" it displays on my product listing with field name "gtin" and ive added it to the easy populate configuration (as shown in image below)
2.The supplier gives url's for the images but they also have not populated using "v_products_image"
3. I added the extra field support for the field "Condition" -as shown below, (ie new, used) however, i see it is showing on the page where you upload the feed file as the following...
User Defined Products Fields:
gtin: TRUE
Condition: FALSE
This would cause issues on google unless i set my merchant centre to assume items as new if not specified so number 3 i can live without solving for now
Attachment 19715
on checking again it appears it has accepted the link and attempted to display the picture on my website. clicking on the image title that is showing instead comes up as the following, think this is more specific to my site rather than issues porting the field or easy populate. ill ask my developer about this one or post a seperate thread if cant resolve so just points 1 and 3 that are technical help with the module whereas 2 is more site specific and might need its own thread if i'm struggling still
Attachment 19716
think i'm down to site specific issues or at least the feed from the suppliers, i don't want to clog up the support thread for the module so i have created a separate thread if anyone can spare a few moments to assist me or in the future if you have similar issues perhaps you will find your solution at the new thread i made https://www.zen-cart.com/showthread....he-please-help :)
Hi guys, im having some issues with my site.
So basically my website has just been setup on easy populate and i ran a feed, it put categories where i didnt want them ect and despite my best efforts i had to ask a developer who has since resolved this by editing easy pop to direct the items uploaded with the filename cointaining the word computing to be appended with Computing^ however a week or so later i'm seeing items selling from my dropshipper at cost price!
I can't see these items under admin and they also have "cPath=0" and "product_type=1" in the url (using ultimate seo urls)
The cost price issue was me picking product cost instead of product price at the dropshippers whilst setting up the feed, i've changed that now and when i re-ran the feed it only updated about half the items in the feed file.
I added this v product type of 1 field and i can't remember what i read that made me add this field but i think its responsible. do I remove the field from the .csv file? and once ive done that how do i delete these "ghost items" as i have affectionately called them?
Any help would be greatly appreciated as I think this is an issue i've investigated myself whilst my developers aren't at work over the weekend and it would be great to resolve it before anymore cost price items are sold by bargain hunters finding them via google shopping results :S
seems my mobile template is also not loading proper but i have no idea whats going on and been left in the predicament of pay more money for the fix, try myself or ask for help in at least working out how i go about removing these ghost items in the hope that fixes everything else sadly. developer doesnt want to seem to admit there are issues that need sorting under warranty and wont work unless i pay more :/
Ok, breakdown of things...Quote:
Originally Posted by flappingfish
product_type = 1, that means that the product is a standard product, it is not a document product, it is not a music product, it is not a display only document type... Etc... Most people use the standard product and never use any of the other options, but they are there .
A default install would set that value to 1 if the field was not uploaded. EP4 has only attempted a different products_type when it believes that the information is describing a music product which then would assign a products_type=2.
So, the cPath=0 issue... That is because a product was incorporated into the database where the category was not properly captured or the product was given a master_categories_id of 0 or possibly some other mix up.
Thing is, and I believe I commented on this in another location, it seems that your database has been modified away from default settings or perhaps it has not been properly updated from some older version. It has been stated earlier that an import file had to include the fields products_quantity_order_units and products_quantity_order_max. A current installation defaults those to '1' and '0' respectively and therefore new product would not need to define that value when using EP4 because EP4 wouldn't interfere with applying the default value if the field was excluded. But again, that to me indicates that there has been something modified about the database in places that should not be modified which also then indicates the possibility that the issue described has come from some other abnormal operation.
At any rate, if you are able to determine the products_id of the product that have cPath=0, and either their products_model (likely visible when looking at the product) then further research can be done to identify what "simple" database changes may be necessary.
Price updating or otherwise requires matching the product in the file to the product in the database. As again previously discussed in this forum, a product is updated by matching the primary key information in the file to the database.... If only about "half" were updated, then those were the half that had a match for the products_model information and the other half did not have a match...
As far as deletion, again setting v_status to the value of 9 for the product in question will delete whatever product have the matching primary key data (products_model based on previous discussion).
I've looked through the export code for EP4 and it does not include a direct export of the product that are having this issue if the product has just enough information to display on the catalog side, but not on the admin. Such product still can be modified in the admin once they are "found". It just requires editing the admin browser path information to display the particular product.
Hmm.. Not entirely sure how helpful any of that is in fixing your issue though other than pointing out that the guesses made about the source of the issue are not involved with the problem(s). The lack of update as said is because the data in the file is not matching data in the database. That isn't an EP4 caused issue. Deletion of the "product" should be carefully considered: there are product and there are linked product and the issue may be with the linked version of the product or it may be with the product itself...
thanks mc, I seem to be getting a bit closer, spent the last few hours doing as you suggested to find the products before you typed this, Iv'e spent 5 days trying to figure it out though. eventually i managed to figure out if i went directly into my php admin i could filter the products table to mater category id of 0. deleted all of those then about 4 hours later i searched for category 0 or less then i found a further 25 items, deleted those and re ran the feed.
This time it stopped at 25 items like it had the last few times... finally decides to look at the .csv and i find item 26 has no category name!
I then remember asking if it was possible to have these "skipped due to no category" items diverted to a miscellaneous folder (which the developer did a code change for) A quick scan through and i deleted any other lines with no category and ran the file to find 1668 items succesfully added... i lost my cool with category links and decided to delete the whole category and re add it hence the whole lot going back in, only to find the feed file links products with it having items twice in different categories lol.
Maybe your right about the database or something else being old, i've removed the quantity max and minimum fields now but i see this on some items...
Attachment 19766 and the following when i add one of these items to basket and go to basket....
Attachment 19767
also getting some issues with the google product feeder crashing on processing. When i refreshed the page i see 2 files one ending lock.xml, i sent the usual one and its down about 200 items. log folder shows an error of running out of memory and showing the resulting file as having .xml issues in merchant centre but it's accepted the data for processing no problems? i dont think people can actually checkout with these items with the weird minimum 0 issue though?
One bit of good news is that the hidden items seemed to have been causing the issue's with the way the mobile template was displaying also so now they've gone at least my site looks appealing on mobile devices again :)
I just wanted to take a moment and thank everyone who has worked on EP4. I have used this in so many ways just in the last few days. We wanted to add some different categories to several hundred products. I was able to create all of those links in a matter of minutes. I wanted our sort order modified to mimic the SKU numbers (helps us with orders and inventory). Again, a few formulas in a spreadsheet along with copy & paste the values back to the CSV file and I was golden!
:cheers:
Chris
Even though i still have problems with my EP, i could not agree with you more. The feedback and help here are amazing.
Quote:
Originally Posted by g2ktcf
@kernheimer, as you and I know, we have talked outside this forum. I would like to ask a few questions to find an answer.Quote:
Originally Posted by kernheimer
In admin->Configuration->Easy Populate 4:
What are the settings for:
1. Import/Export Primary Key
2. Import Language Override
The problem described indicates a conflict.
To correct the issue I understand:
If 1. is products_id or blank_new, then 2. should *NOT* be products_model_only.
If 1. is products_model (historically the default), then 2. should *NOT* be products_id_only.
The above is for the problem described. The problem described has been, when importing a product file created by export, the system response is "No category provided for this new product".
I have more questions, but in this situation I want to slow down and address one issue at a time. Please continue to have patience.
I have just got the latest version from git hub and wanted to check if it is now a requirement that the folder in which you keep the uploaded files is under [YOURADMIN] directory.
The reason I ask is that I was having trouble with all the files showing CSV Unknow Delimiter. I tracked the code down to module easypopulate_4.php lines 438-444
The issue is thatPHP Code:$basepath = "";
$realBase = realpath($basepath);
$userpath = $basepath . $file;
$realUserPath = realpath($userpath);
if ($realUserPath === false || strpos($realUserPath, $realBase) !== 0) {
return NULL; // return back to the function with a non-result?
}
$file /MYSERVER/HOME/EASYPOPULATELOADDIR/EasyPopulateUploadDIR/Myfile.csv
$realBase /MYSERVER/HOME/EASYPOPULATELOADDIR/MYADMIN
$userpath /MYSERVER/HOME/EASYPOPULATELOADDIR/EasyPopulateUploadDIR/Myfile.csv
$realUserPath /MYSERVER/HOME/EASYPOPULATELOADDIR/EasyPopulateUploadDIR/Myfile.csv
does not pass the test unless EasyPopulateUploadDIR is under MYADMIN
thus $file /MYSERVER/HOME/EASYPOPULATELOADDIR/MYADMIN/EasyPopulateUploadDIR/Myfile.csv
I can leave the folder under MYADMIN just checking that this is now a requirement, OR if i have set something up wrongly.
Was not intended to become a "requirement". I have a fix for the above issue that retains the expected security.Quote:
Originally Posted by brittainmark
It can be found at this commit: Restore import from catalog side/remove CSV delimiter warning · mc12345678/EasyPopulate-4.0@84331eb (github.com)
Quote:
Originally Posted by brittainmark
I can't seem to "properly" edit the previous post and it is not a "timeout" issue, the original content just doesn't appear in the editor.Quote:
Originally Posted by mc12345678
Anyways, the above is to be incorporated into the next version which I'm near completing for forum posting but had some things to work out/on.
Thats great. Thanks. If i find anything else shall i post here or raise issue on git-hub.
For me to respond, either would work; however, generally in the spirit of the community, I would suggest posting here. If that is then determined better to capture/address in github such can be then be done.Quote:
Originally Posted by brittainmark
I want to also say that the above posted "solution" considers the admin directory to be only one directory deep away from the "public" folder being used. E.g. if a store were found in https: // DOMAIN / sub-folder / 2nd sub-folder and the file were located at https: // DOMAIN / filename.csv Then I suspect/expect that the CSV unknown delimiter issue would occur... That also said, I was just about to indicate how I might change the message to reflect the condition causing this issue; however, I'm not so sure that I want to offer up that additional piece of info that the file is being retrieved from a location considered to be unauthorized...
The general principle behind the check is to consider the actual file path (location on the server) and in a way to ignore or not use database and/or constant related information when considering likeness.
Think I understand now. The "Uploads Directory Admin/Catalog" setting determins where the upload file should be located. I think my issue was that this flag had been reset in the update from false to true. I will reinstall and old version and reupdate to see if it happens again.Quote:
Originally Posted by mc12345678
Just for completeness "Show all EP4 Filetypes with Files" has true and false with a capital letter, all the others are lower case.
Sused it. If you include the admin directory in the path of the "Uploads Directory" you set the "Uploads Directory Admin/Catalog" flag to true and remove the admin directory from the path. V clever!Quote:
Originally Posted by brittainmark
I'll carry on testing.
The false to true condition is further discussed below. It is possible "upon upgrade" that the software will look in the admin instead of the store side if the previous version did not contain this configuration setting as the default install/upgrade is to add the configuration setting with it set to true by default. Therefore, if one were using the catalog side in the old version (where the setting did not exist), then when the configuration switch is added it is by default set to true and therefore now the software looks in the admin for the folder that was intended to be on the catalog side.Quote:
Originally Posted by brittainmark
"Show all EP4 Filetypes with Files", I don't see where a capital letter is used for true or false in my search of the extra functions file and the main file. A capital is used for "Hidden", but that appears to be consistently used. If there is a discrepancy in other use of capital/small letter, could you please point me in the direction where that problem exists? "True" != "true" per se... At least it is not intended to be equal.
So, in an earlier effort to ensure that the admin directory remains as "obscured" as possible and recognizing that a default install of Zen Cart does not populate the database with the admin directory, I sought to remove storage of the admin directory in as "simple" of a way as possible. That is not to say that someone couldn't work around the issue and force the admin directory to be in the database, but I take that to be something that someone with the appropriate access and at that time authority wanted to include the admin directory and that it is on them, not necessarily the software.Quote:
Originally Posted by brittainmark
Glad it was figured out though.. Thanks for feedback.
Quote:
Originally Posted by mc12345678
Dear mc12345678
What are the settings for:
1. Import/Export Primary Key. - Products_model
2. Import Language Override. _ Language_code _only
Ok, I *tried* to ask for information about the settings that are involved with this, I missed one setting.... Although I did not ask for one setting, I received information that is/was helpful.Quote:
Originally Posted by kernheimer
The settings I was *really* interested in were:
1. Import/Export Primary Key
2. Import Language Override
3. Export Language Identifier
The default settings for these in 4.0.37.13 were:
1. products_model
2. language_code_only
3. id
The problem with some of those defaults (as discussed several times before) is that when importing data that is language dependent, trying to import only fields with the language_code means that the field likely does not exist. Because the specific field does not exist then the data does not exist for the program. Why would the field not exist? Because when exporting the data, the language dependent field(s) only ended with the language_id.
So, to more accurately state the necessary conditions:
If 3. (Export Language Identifier) is id when exporting the file, then 2. (Import Language Override) should *NOT* be language_code_only.
If 3. (Export Language Identifier) is code when exporting the file, then 2. (Import Language Override) should *NOT* be language_id_only.
The above is for the problem described. The problem described has been, when importing a product file created by export, the system response is "No category provided for this new product". Why? because, if the code is looking for categories_name_en, but it only contains categories_name_1, then it is true that the category is considered to be missing.
So, in summary, may I suggest changing the setting for Import Language Override to ANYTHING other than language_code_only. Generally speaking, I would suggest changing it to language_id_only to keep things "simple". :)
Hi,
I tried updating the image and description of existing categories using the CategoriesMeta-EP file. The file import was complete and the image and description were inserted. However, there is an 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"
The debug error log shows:
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 '
categories_id = 10387,
language_id ...' at line 1
When executing:
INSERT INTO zen_meta_tags_categories_description SET ,
categories_id = 10387,
language_id = 1
How can this error be fixed please?
Thanks
Either of three ways:Quote:
Originally Posted by waterbender
1. Since appears that only updating v_categories_name_ related fields, then name the file with the prefix format of "category-ep", it appears though that to update categories_description that for now it should use the "categorymeta-ep" file format and one of the below would apply. I am not 100% sure why the "category-ep" file format never included the categories_description field into the "category-ep" file format. Trying to review to see what if any issues might be expected by including the description in the general category file or a similar file.
2. Add any (or all) of the following three fields to the import file that has the filename format of categorymeta-ep:
a. v_metatags_title_
b. v_metatags_keywords_
c. v_metatags_description_
3. Modify the file admin/includes/modules/easypopulate_4_import_categorymeta_ep.php to incorporate the following code change:
changing lines 165-166 https://github.com/mc12345678/EasyPo....php#L165-L166 from:
toCode:$sql .= ",
";
Though this last "fix" should also include a notification that effectively nothing is being done as there is no meta data that has been provided, just category name information...Code:if ($update_count) {
$sql .= ",
";
}
If there remain issues, then it may also be helpful to identify the admin->configuration->Easy Populate 4 settings for:
1. Import Language Override
2. Export Language Identifier
It looks like the problem is resolved when I changed these column titles:
v_categories_name_1
v_category_path_1
v_categories_description_1
v_metatags_title_1
v_metatags_keywords_1
v_metatags_description_1
to
v_categories_name_en
v_category_path_en
v_categories_description_en
v_metatags_title_en
v_metatags_keywords_en
v_metatags_description_en
Another question on importing attributes. Currently, I first use the Attrib-Basic-EP file to import attributes, then use the Attrib-Detailed-EP file to revise attributes that cost extra. However this seems tedious as I have to manually find and match the corresponding products_attributes_id one by one. Is this the only way to it?
First of all, glad that were able to perform the import.Quote:
Originally Posted by waterbender
Second, simply changing the title of the fields became a "one time" correction because it is obvious that 1) the export file was generated using the language_id for export but import was ignoring the language_id and instead was using the language_code... So, please, please, please, review almost any number of pages back about changing the import/export settings so that they match... Please....
Third this appears to have revealed a condition that was to be prevented. Basically when it would not be possible to import content it was to provide a message. The current check for doing that simply validated that at least *some* field exists even if the current settings wouldn't have imported the content. So thank you for identifying that issue.
So population of attributes to a product requires at least two "levels" of data population: existence to a product, and detail about that existence.Quote:
Originally Posted by waterbender
Perhaps some of that could be done all in one file, but it certainly wouldn't be pretty.
The current process, also described in the instructions, basically has the basic file get populated with product, option name type, option name, and option values associated to that option name.
Export a detailed report.
Update the details of the detailed report
Import the detailed report to refresh the values.
So, I'm not entirely sure what "manual matching" issue is... I say that to get some further information, just because I don't understand doesn't mean it isn't an issue.
On the export of the detailed file, the products_model is included along with *some* other "human readable" content that should make it easier to locate the row to update. Certainly other data could be added for inclusion such as products_name, though that also shouldn't be necessary if "default settings" are used for operation as products_model should refer to a unique product... (Yes a little tongue in cheek there too, because there are additional settings that allow more freedom in using the software.)
Hi,
What I meant was to find out the corresponding attribute id of the imported product which has an additional cost.
There are many products on the site. When attributes are exported, can we be selective? If not, the file will be very big as the attributes of every single product will get exported.
Much more understandable. :)Quote:
Originally Posted by waterbender
Correct, at the moment it is a full or no basic/detailed attribute export. Incorporating the use of the dropdowns across the top is possible; however, would require some additional code in:
admin/easypopulate_4.php
admin/includes/languages/english/easypopulate_4.php
admin/includes/modules/easypopulate_4_filelayout.php
and
admin/includes/easypopulate_4_export.php
The thought is that in the filelayout, would incorporate an additional "string" to substitute before the "ORDER BY" statement.
In the language file(s), would incorporate the word(s) for the option(s) that would be in the dropdown (considering adding just the two "features" of basic/detailed attributes).
In the base file, adding the new language defines to support dropdown expansion.
In the export file adding the "control" to substitute the string added before the "ORDER BY" statement either with the desired filtering or to just make it blank as would be expected for the "default" export.
So, yes, doable and I'll look to initiate the change/addition of the feature/option. Thank you for clarifying.
Now, last part to that, the above does not add/offer the ability to specifically target just a single product nor the ability to enter in a list of specific/designated product, but would allow selection through existing selection options (category, manufacturer, enabled/disabled, etc...). So a "closer" range to select product, but perhaps not as unique as desired(?).
I'm getting an import error upon exporting the entire catalog and cannot import any changes to the csv file.
Version Easy Populate 4.0.37.13 - 05-03-2021 On 1.5.7
php7.4
Please read over the last 10-15 posts. Feel free to answer the questions asked about settings of some of the specific configuration options.Quote:
Originally Posted by wtfbbq
Almost have it. Forgot that the attribute exports don't use the products to categories table so having to generate the product list based on products in categories. I plan to create two export options for each basic and detailed to support of linked product and the second to exclude linked product.Quote:
Originally Posted by mc12345678
The solution to the import error in place of the import button was the configuration option to store the eptemp folder outside of admin is the cause of the problem.
This leads to another question. Why is setting the eptemp folder outside the admin folder causing this import error?
Understanding that English is not the stronger language, I will try to answer what I may understand.Quote:
Originally Posted by wtfbbq
A problem was created in a code change where placing the EP4 upload/download folder outside of the admin directory would cause the files identified in that folder to not be processed for import by EP4. The file would be identified as having a CSV delimiter error. Although a solution was only recently publicly posted, the solution had been determined a while ago awaiting someone else to confirm that there was an issue and request resolution (see ). That solution appears to have worked.
I am not sure if the question above is now answered by the above text, or if a more technical explanation is requested about why the code works the way it does, so I am going to step out and attempt an explanation.
To attempt to limit the ability of database settings from pointing to folder locations that are not expected to represent "safe" spaces in the Zen Cart software, a method is incorporated in the software to report/determine the file's location that is executing the code. That location is then compared to the path of the file to be accessed. If the two sets of information align then the path is used, if the requested path is not in the file's path or downstream from it (in a sub-folder or some sub-sub-folder), then the path is not trusted. But, a folder that is placed outside of the admin folder would need to be at least one folder to the left of the current folder. Therefore to allow that path, additional effort/code is required to permit the parent folder to be allowed.
So why not just have the folder always point to the parent folder? Not everyone sets up their admin folder to only be a sub-folder off of the catalog, there has been discussion of removing the admin folder, *and* I consider the "safer" option for all CSV data to be imported and exported from within a secure area such as the admin folder. Therefore, I wrote the code to default running from the admin directory instead of from one directory above the current folder and allow any folder off of the catalog root to be permitted.
Otherwise, because I made a mistake. :)
The basic idea of the process is: if the database is modified by a bad actor, the worst that they can do/access is a file within the ZC catalog but not above it. In so accessing they would have to modify the file that is performing execution in order to affect something else with the idea that the user has placed their files in some sub-folder. Further, the admin directory itself is not stored in the database so that it can not be discovered by database review/inspection. While there is not a requirement right now for csv files to be in a sub-folder, I likely will incorporate such a requirement in a future release based on this evaluation.Quote:
Originally Posted by mc12345678
Great thanks. Looking forward to the newer version with this feature that can selectively export a range of attributes (either by categories, manufacturers or date if possible).Quote:
Originally Posted by mc12345678
Current plan is to support combination of categories and manufacturers through the existing dropdowns at the top of the EP4 admin screen. Not planning on addressing dates (newly added request) because of what I perceive as too many options to consider and dates to also address. Not to say that it couldn't be done. At the moment I see it as too much effort, likely too confusing for the user, with little in way of overall returns.Quote:
Originally Posted by waterbender
As to the category "issue" came across another wrinkle that am trying to ensure is addressed sufficiently. ZC 1.5.7 and older generated results in one format for a function, but upcoming ZC 1.5.8 will use a different response when working via the admin side. I want to "set it and forget it" by allowing a single body of code to function in both environments. So working through implementing the logic to address and for it to not add significant complexity.
Further status update. After further consideration of the "configuration" of the associated function across at least those two versions of Zen Cart, I decided to draw the function into EP4 instead of using the Zen Cart provided "versions". The reasoning is this:Quote:
Originally Posted by mc12345678
in earlier versions, an array is generated where the key to the array represents the "numbered" item in the list (5 product, the last key would be 5) and the value of the array represented the products_id. In the upcoming version, the key to the array represents the products_id and the value of the array represents the category path. So I thought I had a good system developed to be able to evaluate the array results and make a determination off of that as to which result was being provided. In general this would work when evaluating the differences of the below to arrays:
$myArrayOld[1] = 7
$myArrayOld[2] = 5
versus
$myArrayNew[7] = 6
$myArrayNew[5] = 3
Using the above, I could sort the array by key, then evaluate the number of array items and if the key of the last array item did not equal the number of items, then I was using the "new" system and could "withdraw" the products_id for processing. If the last key was equal to the number of array items, then I would use the values for products_id.
But... In the boundary condition where the products_id of the first few products (1 and 2 for example) were being returned, then:
$myArrayOld[1] = 1
$myArrayOld[2] = 2
versus
$myArrayNew[1] = 8
$myArrayNew[2] = 9
Would mistakenly in a new system attempt to process the array with consideration of the right side (value) being the products_id, although that value side (the result) is actually the category path of category 8 followed by category 9 instead of products_id 1 followed by 2.
A separate consideration was to attempt to identify where the associated function was "stored" with the old version being in the admin directory and the new version in the catalog. But, then modifications that one *may* have made to their site could increase the needed assistance (much like the issue generated by the current defaults for import/export of language related fields). So, I don't of course like that concept. Then there was the consideration of attempting to identify the number of parameters of the associated function, same issue of support *and* though I had a process developed to internally adjust for an earlier catalog side code discrepancy that is corrected for ZC 1.5.8, if one doesn't incorporate a specific change (missed it or didn't want to apply it for some reason), again additional support assistance would become necessary.
So... As a result, I have incorporated the ZC 1.5.8 version of the applicable function directly into the easypopulate_4_export.php file giving it a specific ep4 related name so that the code is otherwise written more simply. I considered adding it to the extra_functions file, but really I am looking to move away from that file and instead implement that code into an ep4 class instead so that the code would only load while using ep4 or at an on call basis.
I know, more than you wanted to know @waterbender, but I wanted to at least publish somewhere "public" why the changes I'm making were made the way they were. I would expect that as time wears on and the code requires significant change to support operation, that any consideration of using it on a version less than 1.5.8 will mean that could revert back to the Zen Cart core code, but as long as this code is supported on a ZC version before 1.5.8, it seems the best course of action for the code is to use the ep4 version of the function.
Hi, I apologize if this has been answered but I cannot locate the question in this thread. EP4 for 1.5.7 is working just great for me with ONE exception. When downloading the Basic Attributes, I am seeing only 1 line when I have many, many more lines of data. I attempted to split thinking the size of the file may have been an issue, but it's nowhere near that big. Is there a setting or known solution to basic attributes not displaying all lines of data? Thanks so much and once again, I apologize if this was addressed elsewhere. Thank you!
So, I've only seen a "single" line of data when either there are no attributes assigned or there is a possibility that the method of defining the attributes to the product doesn't ensure a record in each of the tables: products_attributes (table a), products (table p), products_options (table o), and products_options_values (table v) and further that those tables are related by: a.products_id = p.products_id AND a.options_id = o.products_options_id AND a.options_values_id = v.products_options_values_id AND o.language_id in = v.language_id.Quote:
Originally Posted by chuckrey
Those tables could possibly instead be referenced by left joins, but there may also be undesirable data found when doing that on the export...
Basically, there may be an issue with the data in the database, but I have done a comparison of the v4.0.37.13 software to what I am currently working on as an upgrade where my upgrade works (and a similar issue hadn't previously been identified) and haven't found anything that specifically limits the number of responses/records. The query that generates the list to be exported is:
If that is only resulting in a single row and there are multiple product with attributes, then I would think there is something "wrong" (different than expected) with the data. The data may be handled differently and therefore this sql may need to be adjusted to accommodate ideally with the same fields being returned.Code:SELECT
a.products_attributes_id as v_products_attributes_id,
a.products_id as v_products_id,
a.options_id as v_options_id,
a.options_values_id as v_options_values_id,
p.products_model as v_products_model,
o.products_options_id as v_products_options_id,
o.products_options_name as v_products_options_name,
o.products_options_type as v_products_options_type,
v.products_options_values_id as v_products_options_values_id,
v.products_options_values_name as v_products_options_values_name,
v.language_id as v_language_id
FROM products_attributes as a, products as p, products_options as o, products_options_values as v
WHERE
a.products_id = p.products_id AND
a.options_id = o.products_options_id AND
a.options_values_id = v.products_options_values_id AND
o.language_id = v.language_id ORDER BY a.products_id, a.options_id, v.language_id, v.products_options_values_id
Thanks for the response, I am going to have a closer look at the data in the DB as well as compare to another DB that is including all data. I will update with my finding.
Thanks again!
If I may ask, are there multiple languages involved? What language(s)?Quote:
Originally Posted by chuckrey
I do have dutch, english, french, german, russian and spanish folders located in the Includes/languages folder.
Dutch was installed w/ Printable Pricelist module
French German and Spanish came w/ the Template of "YourStore". However I have another site using it and Basic Attr works just fine.
I am not using any other language than English on the website.
So I'll note that the existence of language files for EP4 is not an issue, when/if Russian is used there may be an issue with the language content being populated properly such as importing the products_description related field, but it shouldn't cause the reported issue.Quote:
Originally Posted by chuckrey
On another note, for the site having the issue, do the other exports also have an issue? E.g. the product export or price listing?
Another question, when looking at the EP4 admin screen, what index does the English language have? It's in the info on the upper right area.
The other exports do not have an issue, just the basic attributes.
Detail and full work great and export all without an issue.
Regarding the index question. Is this what you are looking for?
Installed Languages
1-en: English
Default Language: 1-English
Internal Character Encoding: UTF-8
DB Collation: utf8mb4
Yes. While haven't seen it in the wild, I've once caused the language_id for English to become like 3 or 4 and was the only language installed. Just wanted to confirm no unexpected issues likely from database language data. Thanks for that. Still suggesting until otherwise determined that is database related.Quote:
Originally Posted by chuckrey
Quote:
Originally Posted by chuckrey
Wait... detailed attribute export works as expected, but basic does not? Much of the query for both of those is the same. I mean they are each asking for different fields, but the from and where portions are nearly identical. A difference that stands out is that the detailed export adds a limitation of using the language assigned to the value of 1.Quote:
Originally Posted by mc12345678
Fyi, in the past a recommendation has also been to remove and reinstall the software.
I am going to try that this evening and see if it resolves. Thanks again!!Quote:
Originally Posted by mc12345678
Issue with images ... I've tried everything to figure this out. When using a CSV file with Easy Populate everything works fine but the images remain small when clicking on the "larger image" link. The pop-up will only display a small image. The only way to fix this is through the admin by clicking the edit button for the product, click preview, and then save. That fixes the issue for every item. But why does "Easy Populate" cause this problem with every CSV import? I've tried making the image names and extension lowercase (and lowercase as well in the CSV file) so they all match but it doesn't help. Any ideas?
So I just finished removing EP 4.0 and reinstalled the latest from Github. I did not have any luck, same result of not displaying the data from Basic Attributes.....Quote:
Originally Posted by mc12345678
However.. I tested an older version I have on my hard drive. Specifically Easy Populate 4.0.30 - Beta 06-27-2015 and it worked where all data is now downloading without an issue. The version that was not allowing me to export Basic Attributes is Easy Populate 4.0.37.13 - 05-03-2021