#70 On-the-fly indexer doesn't correctly handle product renames or name collisions

v1.0_(example)
accepted
nobody
None
1
2014-08-13
2013-09-01
No

Product renames doesn't update url key

Maybe I import things incorrectly? I use the datapump API. Is there a way to make Magmi safely update the url key?

Behavior when a product is renamed - steps to reproduce:
1. 'Product A' is imported with Magmi. It gets url-key 'product-a'.
2. 'Product A' is renamed to "Product A2" and imported. The product name is updated in Magento, but the url-key is not changed to 'product-a2'.

Expected behavior:
1. The url-key is changed to 'product-a2'
2. An url-rewrite is created from product-a.html to product-a2.html.

Doesn't handle name collisions correctly
Steps to reproduce:
1. 'Product A' (sku prod-a) is imported with Magmi. It gets url-key product-a.
2. 'Product A' (sku prod-a2) is imported with Magmi. It get no url key at all.

Both products resides in the same category.

Expected behavior
1. Product A (sku prod-a2) should get an url-key.

Related

Bugs: #70

Discussion

  • Sebastien Bracquemont

    Hi, Magmi won't assume "automatic behaviours" like this. Name & url_key fields are not "automatically bound". In fact your product A can have any url key if you want, even in Mangento.
    If you want to force binding of name to url key, then use value replacer plugin with the Slugger (there is a sample of such a behaviour in the wiki)
    Magmi does only what you tell it to do, especially for creating/updating new values. So if you want the url_key to be changed, you have to explicitely tell it to magmi.

     
  • Andreas Nilsson

    Andreas Nilsson - 2013-09-01

    Hi Sebastien, thanks for your reply.

    How shoud I go about setting the url-key when using the datapump API? Something like $item["url-key"] = "my new urlkey?

    If a new URL Key is set like this, "manually", will Magmis indexer create url-rewrites from the old url to the new url?

     
  • Sebastien Bracquemont

    yes , or you can just configure the Value replacer plugin to bind your url_key field to the name (i think the attribute code has an underscore).
    like this :

    value to replace : url_key
    new value for url_key : {{ Slugger::slug({item.name}) }}

    Since url_key would have changed, the on the fly indexer will take it into account & change url accordingly

     
  • Andreas Nilsson

    Andreas Nilsson - 2013-09-01

    I've tested now and it doesn't work.

    I ran ingest() with an item as before, but I also set the url_key like this:
    $item['url_key'] = Slugger::slug($product->name);

    Result, after import (the on-the-fly-indexer has been run):
    1. The url_key was set for Product A (the second one, the one which didn't get an URL key in the original description).
    2. No url rewrite was created for the product. The product is still only accessible through catalog/product/view/id/3256/s/product-a/category/6/

    What should I do to get the on-the-fly indexer to create an url-rewrite?

    Note: There is (as mentioned) two products called 'Product A' in the system, so there are now two products with the same url-key. When Magentos own URL Catalog Indexer runs this isn't a problem, it detects the collision and creates two different rewrites that doesn't collide (for example product-a.html and product-a-1.html.

     
  • Sebastien Bracquemont

    Ah ok, this one is for conflicting url keys. indeed, the on the fly indexer does not provide collision detection yet.i may add it on the git quickly.

     
  • Sebastien Bracquemont

    • status: open --> accepted
     
  • Sebastien Bracquemont

    Should be now ok on latest git version. i added a specific url key attribute handler (i manage conflicts at url key setting, not in indexer).
    currently you'll need to remove the conflicting url key & reimport , it should work. i don't fix existing conflicts in DB yet but new inserted/updated values should not conflict anymore.

     
  • Andreas Nilsson

    Andreas Nilsson - 2013-09-01

    Hi Sebastien. That would be very much appreciated! Thank you very much.

    Den söndagen den 1:e september 2013 skrev Sebastien Bracquemont:

    Ah ok, this one is for conflicting url keys. indeed, the on the fly
    indexer does not provide collision detection yet.i may add it on the git
    quickly.


    Status: open
    Created: Sun Sep 01, 2013 11:46 AM UTC by Andreas Nilsson
    Last Updated: Sun Sep 01, 2013 01:13 PM UTC
    Owner: nobody

    Product renames doesn't update url key

    Maybe I import things incorrectly? I use the datapump API. Is there a way
    to make Magmi safely update the url key?

    Behavior when a product is renamed - steps to reproduce:
    1. 'Product A' is imported with Magmi. It gets url-key 'product-a'.
    2. 'Product A' is renamed to "Product A2" and imported. The product name
    is updated in Magento, but the url-key is not changed to 'product-a2'.

    Expected behavior:
    1. The url-key is changed to 'product-a2'
    2. An url-rewrite is created from product-a.html to product-a2.html.

    • Doesn't handle name collisions correctly *
      Steps to reproduce:
    • 'Product A' (sku prod-a) is imported with Magmi. It gets url-key
      product-a.
    • 'Product A' (sku prod-a2) is imported with Magmi. It get no url key at
      all.

    Both products resides in the same category.

    Expected behavior
    1. Product A (sku prod-a2) should get an url-key.


    Sent from sourceforge.net because you indicated interest in
    https://sourceforge.net/p/magmi/bugs/70/

    To unsubscribe from further messages, please visit
    https://sourceforge.net/auth/subscriptions/

    --
    Mvh / Kindest regards,
    Andreas Nilsson
    CTO, E-Commerce Engineer

     

    Related

    Bugs: #70


    Last edit: Andreas Nilsson 2013-09-01
  • Sebastien Bracquemont

    Still working on it in fact, should be ok in a few minutes

     
  • Andreas Nilsson

    Andreas Nilsson - 2013-09-01

    Thank you Sebastien. I will check it out!

     
  • Sebastien Bracquemont

    Latest git is now ok. there was a use case that was not well handled, but now it is

     

Log in to post a comment.