Printable View
PHP 8.3.27 / ZC 2.0.1 / Easy Populate 4.0.39.ZC
After struggling through some errors and a lot of hunt and pecking while trying to patch those, I managed to get this mod to finally work with ZenCart 2.0.1.
Just a few questions:
1. is the EasyPopulate SBA modification supposed to create new combinations for inventorying? Is there a way to do so?
2. Is this the most recent version of Easy Populate to use? I couldn't keep track on the Git Hub repository.
Could really be helpful to identify what errored and/or needed patching in association with EP4. Forgive me, but the above makes it seem (right or wrong) that all of the issues experienced in association with ZC 2.0.1 were only issues with EP4 v4.0.39.ZC. Would like to address any that exist.Quote:
Originally Posted by retched
In answer to the questions:
1. Effort has not been put forth to address the necessary complication of generating new SBA combinations through file upload based on what would be needed to import a new combination containing characteristics that do not yet exist and how easy an existing combination could get destroyed/improperly updated with that same set of considerations/concerns. If this is in relation to the previous query created to "import"/generate combinations for newly added product each with an attribute that do not yet have a combination, mind you, whatever problem was experienced (which I didn't see a proper explanation of why the particular issues existed) the query was still sound and could be executed outside of each of these applications.
2. Yes, 4.0.39.ZC is the most recent version to push for all to use. There were a LOT of changes made and while I attempt to test series of combinations and possibilities, I do not believe I can test every possibility, which brings me back to the above, if the issue(s) are EP4 related, let's fix them. If they are/were from something else, then please clear the air.
Well, a couple of things.Quote:
Originally Posted by Pingfah
First, apologies that 4.0.36 did not include some of the "error" checking that would likely have helped identify that using the products_id as a primary key may have been necessary (as compared to desired?).
There have been newer versions generated to address/correct the lack of the primary key value/data being present along with some other notifications so that do not have a false positive of success.
One thing that I didn't ask for was, what field headers were present in the file having an issue as compared to one that didn't. Then another was if the new file had unescaped special characters that possibly could have affected the import evaluation.
That it seems that no changes what-so-ever were made in the underlying code or the import file (meaning same ZC version, same EP4 version, same previous import file) seems to mean that either MySQL version and/or PHP version changed to a value affecting the code operation. Suggestion might be to compare two CSV files, the working and not working one(s) to see what other differences might exist causing the issue of basically the product table data getting imported to the correct area(s), but the products description table seems to only take the description (and therefore things like products_name) only were imported basically against the last product. To me, that aligns more with the issue of missing data associated with the chosen primary key or that all those affected have the same primary_key value.
Glad though that it seems a fix was found. As far as a log, generally, if EP4 logging is turned on, then a log that might get generated assuming a loggable event occurred would be in the debug log in the EP4 import/export file directory or added to it if it already existed.
With regards to the first, that is absolutely fine with regards to SBA. I thought I was doing something wrong and it wasn't generating the desired changes.Quote:
Originally Posted by mc12345678
A lot of it was bandaid patching up (a big one was bad MYSQL code in easypopulate_4_filelayout.php and PHP 8's change to strformat (ie. if you provide arguments in the string, but only provide one, there is a fatal error thrown. One such error exists in the language file and it breaks from there.). I can certainly provide the changes I did, and will send a Git Fork/MR as soon as I can settle down on it. Most of the errors were caused by the export functions.
I noticed you mentioned 4.0.39 is available. I am using 2.0.1V of ZC. I checked GitHub and the latest I found is 4.037.13. Would you mind sharing where I can find the 4.039? Also, any idea if SBA import/export will be available in the future for the newer release particularly to work w/ v2.0.1 of ZC? Thanks.Quote:
Originally Posted by mc12345678
Link is provided in post 3564.Quote:
Originally Posted by chuckrey
However, it is also provided here: https://github.com/mc12345678/EasyPo...ree/v4.0.39.ZC
As for SBA, the intention is for it to still work. It does appear some mistakes were made in changing query formatting and then at least one of my concerns in query formatting/sequencing came to a head at least in the export code. I've created a solution, but trying to figure out the best or right versioning to apply.
Thanks very much. Looking forward to its use.
A few hours ago, uploaded modifications to address issues recently identified:Quote:
Originally Posted by chuckrey
- SBA export of detailed and basic attributes caused SQL errors in the recent 4.0.39.ZC. One of them had a problem because in reformatting to ANSI style queries, an *AND* did not get moved correctly. In the other query, table relationships may have worked historically, but yes with updated server versions, needed to be reworked plus at least one table alias was incorrectly carried through.
- Also corrected the admin page headers so that if one of the menus from this plugin is the first to trigger the issue, well it won't anymore. BTW, what I'm saying is, understand the code that generates that log does so only once per session no matter how many different admin pages "deserve" the report. To me, it would seem better for the session variable to be unique for each such admin page. Maybe someone else agrees, if so, feel free to take it up with the code maintainers.
- Believe I've corrected/addressed the issues that prevented loading/executing the code to/from the zc_plugins folder, although still have a catalog type folder to load so that can use existing ajax calls rather than creating some new ajax tool.
- I haven't installed an alternate language to be able to maybe correct reported issues with categories not aligning or some similar messaging posted recently. The issue typically occurs or was expected to be reported if a single product in two different languages on a single record was pushed to two different category branch depths. In a way, this was done because it seems that ZC doesn't seem to openly support/encourage product/category trees being completely different in a multiple language store. I wanted to offer some amount of store protection in loading/working multiple languages; however, have only been working theoretically/logically.
All of my testing has been against PHP 8.3.2 and MySql 8.0.28-0ubunto0.20.04.3. to include ZC 2.0.whatever is out right now as none of that really has shown to have an impact on the code.
I would like to put it together for publication to the ZC site, but still seeking any additional feedback on issues so that can try to fix them before committing for the majorities.
I do have some changes in mind (for next sub-version):
I'm working on for import to force/ensure data type "conversion" and checks in association with default values. I haven't fully incorporated it because I'm still identifying some of the expected field default values/data types. I've also started considering how to implement default starting values across product types, though I presume "most" still use just the standard product type or if still in use the book type that was branched off of the code.
Another change to incorporate is the use of notifiers that begin with either NOTIFY_ or NOTIFIER_ so that auto loading could be used. My plan is to "duplicate" each notifier to include the additional NOTIFY_ prefix with each new one to follow the existing one. (E.g. where $zco_notifier->notify('EP4_START'); is used, it will be followed on the next line with $zco_notifier->notify('NOTIFY_EP4_START');)
Hi,
Does anyone know how to export attributes (e.g sizes) based on a category/brand rather than the entire site?
Thanks
While there remain a couple updates to incorporate to the github.com version, the v4.0.39.ZC branch offers such filtering. One known issue to incorporate a fix for is import of a file not having the v_status field sets the status to off regardless the existing status. I have a fix for that, but need to incorporate into the fileset.Quote:
Originally Posted by waterbender