EasyPopulate 4.0 Support Thread

[chadderuski]

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

This also worked for me. Looks like a great solution

@mesnitu: It was always intended to make the category delimiter customizable in the config area, but issues like these got in the way.
Also note that EP4 is the only easypopulate version that actually supported multilingual categories. I was quite proud of that.

[mesnitu]

Didn't realize that you're Chadd from EP4

Hats off !

[mesnitu]

$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 .

[mc12345678]

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 ?

$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 .

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...

[mesnitu]

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

[mc12345678]

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

But what was being pointed out?

[mesnitu]

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.

[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.

[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 ?

[mc12345678]

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. :)