EasyPopulate 4.0 Support Thread

chadderuski:

$category_delimiter (not categories) is defined at the top of easypopulate_4.php.

This code is a bit "mixed up" here from attempts to fix the various issues dealing with multi-byte languages.

My use of EP4 is with full export and now with bookx files. And in those situations I don't see a reason to re-assign that variable upon categories.
But possibly is related with attributes and stuff that I never used.
Or someother stuff that I'm not seeing .

mesnitu:

But is there a reason to make this change ?

$categories_delimiter = $category_delimiter; // add this to configuration variables

> 
> Should'n it be a "global" delimeter ?

> **chadderuski:**
>
> $category_delimiter (not categories) is defined at the top of easypopulate_4.php.
> 
> This code is a bit "mixed up" here from attempts to fix the various issues dealing with multi-byte languages.

> **mesnitu:**
>
> My use of EP4 is with full export and now with bookx files. And in those situations I don't see a reason to re-assign that variable upon categories.  
> But possibly is related with attributes and stuff that I never used.
> Or someother stuff that I'm not seeing .

Not sure what the confusion/issue is, but let me discuss a little about change control...

Looking back on the history of admin/easypopulate_import.php, one can see that $categories_delimiter was set as:

$categories_delimiter = "^";

Somewhere around line 1097 (at one point, ie: ```
https://github.com/mc12345678/EasyPopulate-4.0/blob/37d4428346615d82127117df00b9ceb1e8b69db4/admin/easypopulate_4_import.php
```)

So, looking through the code, the only place that the variable $categories_delimiter was used, was in the commented out explode function that followed it for those that might still be using latin1.

Okay, so the variable basically wasn't used anywhere in the import code.

Now, the overall goal is that whatever is used to join the categories on export, would be the same as that for separating them on import.  Well, on export the variable used was simply a carat "^", no special UTF-8, no mb_implode (assuming function exists), nothing special... Just take the category's root, append the carat, add the next sub-category, add a carat, and in the end have the category path for the product concatenated with the carat between each category.

So... Then on import, the goal was to then take all of those carat's and split them up to go to the appropriate category tree... Well, in an effort to maintain the ability to do that with "foreign" characters, the multi-byte function mb_split was used which is supposed to analyze the string and correctly identify where the cut-offs are at.  Well, at the time of writing, it was not discovered on how to split that string into it's pieces using the multi-byte function and the desired character; however, it was known what that character in UTF-8 had to be: ```
\x5e
```.  So to allow things to move forward, the specific UTF-8 equivalent character encoding was supplied to the mb_split function and the variable $categories_delimiter was in a way "left behind"... But.....

Now there are those that have (maybe?) reviewed the code because of some issue and seen the comment in the file... Hey if you're using latin1, then uncomment the one line and comment out the mb_split line... Okay, so they do that and continue on their merry way knowing that $categories_delimiter is set as "^" and is used in the function.  So, sure the individuals could have gone and changed other things, but now a modification has been introduced.  Namely, if we define the delimiter to be used for any category at the "top" of execution, ie in one place, then it needs to be used in all places..... Well, to accomplish this and not modify too many places of code for too many different users, make the least amount of changes at this time to maintain operation for those that have chosen to use the code as is.  Therefore, for those still using latin1 (for the most part suggest moving to UTF-8 as ZC now pushes for all things to be UTF-8), then the $categories_delimiter variable should match whatever is being used on export ($categories_delimiter = $category_delimiter).... Okay, so that would take care of those using latin1; however, those using UTF-8 (otherwise unaltered code), they need to have something consistent... Well, in the import side there is this variable that now is assigned to a relatively appropriate value and is defined locally rather than some far off distant pre-code, so... $categories_delimiter was chosen to be used... This also would support those that may have previously used that variable similar to how it is being used now (preg_quote($categories_delimiter)) therefore, this would have a minimal impact on those users that chose not to share their solution.  Will it stay this way? Maybe, maybe not, but it provided some of the minimal changes that could be made to remain possible to follow and logical when reviewing the code.  Could the mb_split function have used $category_delimiter, sure, but would you know where to search at that point to identify what it's value was?  The other way this could have gone is that everywhere on the export code that $category_delimiter was used it could have been renamed $categories_delimiter, and then the $categories_delimiter in the import code could have been commented out... Considered that.. Didn't make sense...  

Plus for those that did any type of comparison in upgrading and saw this change and saw that it didn't work could revert back to what was previously there with great ease... The two of you identified there was a problem, provided alternate solutions; however, neither appeared to accomplish the main goal, divide a string of text that is in UTF-8 format into its UTF-8 components based on a UTF-8 "divider" regardless of the language or information in the string and to ensure that the dividing delimiter was the same for both export AND import through a single assignment... Ie.. Make it easier for those that use this to maintain consistency and to alter the divider as desired... 

So, like I said, I don't know what the issue is with the variable $categories_delimiter at least "temporarily" (until a later change) being used and assigned to $category_delimiter is...

No issue or confusion, I was just pointing that out.

mesnitu:

No issue or confusion, I was just pointing that out.

But what was being pointed out?

That in EP4

$category_delimiter = "\x5e"; //Need to move this to the admin panel

on import (before the your last commit ):

$categories_delimiter = $category_delimiter;
$categories_names_array[$lang['id']] = mb_split($categories_delimiter, $items[$filelayout['v_categories_name_' . $lang['id']]]);

Why not :

$categories_names_array[$lang['id']] = mb_split($category_delimiter , $items[$filelayout['v_categories_name_' . $lang['id']]]);
```\[/PHP]

But has you explain, this was a ongoing process, and I quite understood.

Submitted version 4.0.34.a to include the preg_quote() command for import and address maintaining the category separation for both export and import... That is the only real change, which for those that already have installed 4.0.34 or manually made some of the earlier changes will see the notification on their admin page.

When reviewed and accepted will be available from this download link.

Nightfly66:

Now, with a little more calm, I tried the v4.0.34 and it works OK!
Thank you ! You were very good!
I always duplicate products, but I have no import errors.
Thanks again !

Can i to use new Version ?

Nightfly66:

Can i to use new Version ?

I'm sorry, I don't believe I understand the question. I can take a few guesses, but I'd rather not. :)

mc12345678:

Submitted version 4.0.34.a to include the preg_quote() command for import and address maintaining the category separation for both export and import... That is the only real change, which for those that already have installed 4.0.34 or manually made some of the earlier changes will see the notification on their admin page.

When reviewed and accepted will be available from this download link.

Version 4.0.34.a has been made available for download. Version corrects the issue discussed over the past couple pages about the delimiter for categories.

hi
I've been looking into rewards points. Not sure if already exists in EP4, but if it doesn't , it looks not too complicated to do it, but :
Now that EP4 as all those notifiers, what it's the best approach in terms of logic and performance, to incorporate in the core, or use another class, auto load , etc... ?
In this case, it would only deal with ration for categories that could be attach to categories file, and products... possibly in the full export.

Best Regards

mesnitu:

hi
I've been looking into rewards points. Not sure if already exists in EP4, but if it doesn't , it looks not too complicated to do it, but :
Now that EP4 as all those notifiers, what it's the best approach in terms of logic and performance, to incorporate in the core, or use another class, auto load , etc... ?
In this case, it would only deal with ration for categories that could be attach to categories file, and products... possibly in the full export.

Best Regards

What data is applicable to the rewards point system as it relates to products? Ie, what changes are made to the ZC database to support this added functionality. If the only thing really modified is the products table, then no code changes are required. Would simply add the products table field data to the user defined fields in the admin configuration.

I don't have the updated module, not sure if it is the same, but for what I see, related to products it's only one table, the rewards master, that uses a columns "scope" to define if it is a product or categories, and "scope_id" to relate those cats / products IDs, and the rest to place the rewards ratio.
But I just have a quick look, so I'm talking in the air.
But, for what I understand , if it's outside the "products" tables, the user defined fields, doesn't "work"

edit: There's a global reward ratio, and the categories can all use that one or have there own ratio, but if one doesn't have hundreds of categories they are quite accessible ... but for me, the products it's more significant. That's the reason the I thought on doing it

You are correct the user defined field is good for only products table data. To incorporate something like this where data is being populated in a single table, I would suggest creating an additional link on the main EP4 page using the notifier that is in line with options like full export, categories, attributes, etc. Before that would pull in any definitions needed at EP4_START. Would add a file type/name, export filelayout and sql would be addressed by the default:section of the filelayout module listening for the desired "filetype" then well, I've currently run out of steam on describing the remaining export, but there should be an existing appropriate location to address a "new" filetype export. Import would more than likely be similar to what has been done for bookx, but more than likely be using the primary key of the rewards module table rather than a specifc products_id or category_id.

That last part said, two file types could be created, one for products and one for categories, or maybe three to then have a combined style. The user then could choose which method is easiest for their work method and controls...

I was checking , and the Features File , on import using the 9 status doesn't delete the featured product.
Is there another way ? Or this is not implemented ?

tahnks

Actually the status 1 is not doing anything. And if a date is left blank I'll get the year 2036.

mesnitu:

I was checking , and the Features File , on import using the 9 status doesn't delete the featured product.
Is there another way ? Or this is not implemented ?

tahnks

mesnitu:

Actually the status 1 is not doing anything. And if a date is left blank I'll get the year 2036.

This back to discussions you and I have had about the specificity of EP4. It has to date worked with ZC as one would work with ZC except in large quantities. Are you able to change the status of a product from the featured section of the ZC admin? As for the date, changes had been implemented in the main product area, will take a look at the featured section to see what has or has not been done to account for the absence of entered data/more recent PHP versions, etc... The expectation of a non-date when populating the database is 0001-01-01. The result of 2036 is entering 0000-00-00 which I thought I had seen even that this could be a database setup issue of having a default of 0000-00-00... (Issue brought to light in upgrading to ZC 1.5.5 and sql needed to correct for some date fields in some tables.)

Had the ability to start edting the above, but figured I would run out of time. I expect there to be comments that everything ought to be possible in a single upload, but there are some aspects that when working with multiple tables and many, many, many rows of data at once take an inordinate amount of time to process. Even EP4 has a file split operation to allow upload of multiple products as a result of the breadth and processing power (time) needed to import so many rows into so many tables. Yes some have been able to increase the number of rows by decreasing the number of fields (for other reasons as well) but there are still limits.

Never had used the featured file.
But I thought that would import, cause there's a import button, and all the status fields... so, this file should not be imported ? Or is just to change dates ?

I meant deleting a featured product, not the product itself.... I think the featured as it's own relation.

Nop, sorry for the dumb question, I've check the import section for the featured file, and it's all there.
If I have them active, I can set them to 0 . But from 0 status to 1 .... no.
But, again, has I'm using the books fields, probably something is not right.
I'll check that later.

It's basically date based. Factors involved are starting date, ending date and current date. Other fields are present to aid the "reader". Do YOU know what products_id 189 is? Maybe as one that manages the ZC data all the time you might, but someone that works in "the store" doing inventory or selling an item, more than likely they know it by it's name or description.

At any rate, the code works like this: if the available date for the featured item is less than the current date and the current date is less than the end/expire date, then the product is turned "on" during import with ZC taking over the remaining on/off controls, if the current date is before the start date or after the end date then as written EP4 will turn off the featured item. That said, the test probably should be if it is after the end date but the end date isn't "empty" (0001-01-01) then turn it off, after all if someone wants a product to always be featured after some point, then that would seem like the date to use, but probably also need to look at how ZC accomplishes this before making that change.

Anyways, that's a brief description of the operation. This is not "product type" specific meaning that using bookx or not, the core EP4 code works as described above, though it does look like it could use some minor improvements in this area. (More for Version 4.0.35 :) )