Page 233 of 348 FirstFirst ... 133183223231232233234235243283333 ... LastLast
Results 2,321 to 2,330 of 3479
  1. #2321
    Join Date
    Apr 2006
    Location
    Dark Side of the Moon
    Posts
    987
    Plugin Contributions
    1

    Default Re: EasyPopulate 4.0 Support Thread

    PHP Code:
    $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.

  2. #2322
    Join Date
    Aug 2014
    Location
    Lisbon
    Posts
    594
    Plugin Contributions
    0

    Default Re: EasyPopulate 4.0 Support Thread

    Didn't realize that you're Chadd from EP4

    Hats off !
    “Though the problems of the world are increasingly complex, the solutions remain embarrassingly simple.” ― Bill Mollison

  3. #2323
    Join Date
    Aug 2014
    Location
    Lisbon
    Posts
    594
    Plugin Contributions
    0

    Default Re: EasyPopulate 4.0 Support Thread

    Quote Originally Posted by chadderuski View Post
    $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 .
    “Though the problems of the world are increasingly complex, the solutions remain embarrassingly simple.” ― Bill Mollison

  4. #2324
    Join Date
    Jul 2012
    Posts
    16,488
    Plugin Contributions
    17

    Default Re: EasyPopulate 4.0 Support Thread

    Quote Originally Posted by mesnitu View Post
    But is there a reason to make this change ?

    PHP Code:
    $categories_delimiter $category_delimiter// add this to configuration variables 
    Should'n it be a "global" delimeter ?
    Quote Originally Posted by chadderuski View Post
    $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.
    Quote Originally Posted by mesnitu View Post
    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:
    Code:
    $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...
    ZC Installation/Maintenance Support <- Site
    Contribution for contributions welcome...

  5. #2325
    Join Date
    Aug 2014
    Location
    Lisbon
    Posts
    594
    Plugin Contributions
    0

    Default Re: EasyPopulate 4.0 Support Thread

    No issue or confusion, I was just pointing that out.
    “Though the problems of the world are increasingly complex, the solutions remain embarrassingly simple.” ― Bill Mollison

  6. #2326
    Join Date
    Jul 2012
    Posts
    16,488
    Plugin Contributions
    17

    Default Re: EasyPopulate 4.0 Support Thread

    Quote Originally Posted by mesnitu View Post
    No issue or confusion, I was just pointing that out.
    But what was being pointed out?
    ZC Installation/Maintenance Support <- Site
    Contribution for contributions welcome...

  7. #2327
    Join Date
    Aug 2014
    Location
    Lisbon
    Posts
    594
    Plugin Contributions
    0

    Default Re: EasyPopulate 4.0 Support Thread

    That in EP4
    PHP Code:
    $category_delimiter "\x5e"//Need to move this to the admin panel 
    on import (before the your last commit ):

    PHP Code:
    $categories_delimiter $category_delimiter;
    $categories_names_array[$lang['id']] = mb_split($categories_delimiter$items[$filelayout['v_categories_name_' $lang['id']]]); 
    Why not :
    PHP Code:
    $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.
    “Though the problems of the world are increasingly complex, the solutions remain embarrassingly simple.” ― Bill Mollison

  8. #2328
    Join Date
    Jul 2012
    Posts
    16,488
    Plugin Contributions
    17

    Default Re: EasyPopulate 4.0 Support Thread

    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.
    ZC Installation/Maintenance Support <- Site
    Contribution for contributions welcome...

  9. #2329
    Join Date
    Oct 2008
    Posts
    44
    Plugin Contributions
    0

    Default Re: EasyPopulate 4.0 Support Thread

    Quote Originally Posted by Nightfly66 View Post
    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 ?

  10. #2330
    Join Date
    Jul 2012
    Posts
    16,488
    Plugin Contributions
    17

    Default Re: EasyPopulate 4.0 Support Thread

    Quote Originally Posted by Nightfly66 View Post
    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. :)
    ZC Installation/Maintenance Support <- Site
    Contribution for contributions welcome...

 

 

Similar Threads

  1. Hebrew Support - latest release [Support Thread]
    By eranariel in forum Addon Language Packs
    Replies: 19
    Last Post: 23 Jan 2023, 08:04 AM
  2. BackUp ZC [Support Thread]
    By skipwater in forum All Other Contributions/Addons
    Replies: 285
    Last Post: 23 Dec 2020, 10:40 AM
  3. Wordpress On ZC [Support Thread]
    By hira in forum All Other Contributions/Addons
    Replies: 1858
    Last Post: 17 Jan 2014, 01:24 AM
  4. ZJ Black 2 support thread
    By Liamv in forum Addon Templates
    Replies: 1
    Last Post: 15 Feb 2010, 02:53 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
disjunctive-egg
Zen-Cart, Internet Selling Services, Klamath Falls, OR