Ceon URI Mapping V5.0

[mc12345678]

Thanks mc ... I appreciate your detailed response and the explanation of the database emphasis and the potential of a corrupt carry over makes sense. I will endeavor to upgrade to v5.0.0 and hopefully that will resolve the issue.

Again many thanks,
Mike

One thing though, while the newer version may integrate better, if there is a problem with the installation of Zen Cart (as it was likely an upgrade) or the database, even using the newer version of this module may not resolve the problem with adding new product. There may still be an issue with either the database or fileset that causes this problem. Just offering my own input on the matter. Your feedback on the result will be an indicator.

[shags38]

One thing though, while the newer version may integrate better, if there is a problem with the installation of Zen Cart (as it was likely an upgrade) or the database, even using the newer version of this module may not resolve the problem with adding new product. There may still be an issue with either the database or fileset that causes this problem. Just offering my own input on the matter. Your feedback on the result will be an indicator.

Hi MC .... UPDATE ... I found the problem but am not sure of the solution per se.

I changed the main products 'category' name after I did this site duplication (cloned site to new domain) - so 'all clip on earrings' (old) became 'dazzlers clip on earrings full range' (new) ..... whilst experimenting I changed the category name back to what it was (old) and all is good.

So that solved the 404 issue but I have no idea why CEON would not redirect the new category name - it rewrote the url according to the new category name but that resulted in a 404 - the mapping uri in the category remained as [all-clip-on-earrings-c1] but CEON used the category name and not the designated uri name saved in category configuration?? I can understand the DB entries uri's carried over from the former site being the 'old' original category name, that is why they still functioned correctly, just not understanding why CEON didn't adapt?

So if I changed the uri mapping name to the new category name then I get 404's for all the products in the database at time of cloning - so I guess once you have category names then you have to stick to them, right?

Thanks for all your help.

cheers,
Mike

[mc12345678]

Hi MC .... UPDATE ... I found the problem but am not sure of the solution per se.

I changed the main products 'category' name after I did this site duplication (cloned site to new domain) - so 'all clip on earrings' (old) became 'dazzlers clip on earrings full range' (new) ..... whilst experimenting I changed the category name back to what it was (old) and all is good.

So that solved the 404 issue but I have no idea why CEON would not redirect the new category name - it rewrote the url according to the new category name but that resulted in a 404 - the mapping uri in the category remained as [all-clip-on-earrings-c1] but CEON used the category name and not the designated uri name saved in category configuration?? I can understand the DB entries uri's carried over from the former site being the 'old' original category name, that is why they still functioned correctly, just not understanding why CEON didn't adapt?

So if I changed the uri mapping name to the new category name then I get 404's for all the products in the database at time of cloning - so I guess once you have category names then you have to stick to them, right?

Thanks for all your help.

cheers,
Mike

On the surface, this makes no sense and does not really answer/address the issue. The original report was that new product did not get a functional rewrite. Now the discussion is that the rewrite works, but only if the category designation remains the same as it originally was. This doesn't make sense either, because the rewrite generation for a product is independent of the rewritten category.

By that I mean (and I just tested this so am comfortable saying it) if a category exists that has a name of say 'test1' and assuming it is found at the root of the store, the initial uri would be /test1. If one goes in and edits that empty category to change the rewrite to /newtest1, then specifically the category is reachable by /test1 and /newtest1. The browser though when using either of those will show /newtest1 as that is the single active uri for that category.

If now a product is added to the category, the initial rewritten uri will be based off of the category's name, not its rewritten uri. So if the product were called prod1, then the auto-generated rewritten uri would be /test1/prod1, even though the category in whole would be reached by /newtest1. If a second product were added (to account for potential settings regarding going directly to a product if there is only 1 product in a category) that is named prod2, then it's autogenerated uri would be /test1/prod2.

Navigation now to /test1 would show in the browser as /newtest1, and the links to the products would show as /test1/prod1 and /test1/prod2 respectfully for product 1 and product 2.

Attempting to go to /newtest1/prod1 will result in a product not found, because the product doesn't have that rewritten uri associated with it (whether as an original uri or as a new/revised uri).

To change the uri for each of the product to have /newtest1 in the path, both product would need to be edited to have that as part of their rewritten uri and stored.

Sum and total, every rewritten uri is maintained independent of any higher up rewrite where a new rewrite for an item is built directly off of the name of whatever is above it. In the above situation of adding product after revising the category rewrite, the category's name would need to be changed to "match" the rewritten uri before attempting to add product to the category using the auto-generation feature. Of course, the product could be edited after that rename, the checkbox ticked to auto-generate, and the new uri will then be generated where the previous is still accessible along with the new uri.

None of this though really explains why you received a 404, but also, there is no explanation about exactly how the issue was discovered as in from where the link was attempted that was generated for said new product.

To then also try to answer the questions firectly about changing a category, you can modify the category uri all you want, it will not change the link(s) to the product in the category. If you change the category name, but do not check the auto-generate box when doing so, then the category rewrite will remain the same and new product will follow the rewrite rule to auto-generate the uri with the new category name. This would result in old product still having the old category name and new product having the new category name. I believe though that the commercial version makes this "easier" to handle/address as it is designed to make changes en mass rather than one product/category/ez-page/manufacturer at a time.

[DannyVarley]

Hi Guys, I am having an issue with updating the category fields. I belive it has something to do with where it is placing the fields on the page

DISCLAIMER, I mostly do not know what I am on about so please excuse anything that is wrong or otherwise just stupid im just guessing at most stuff here after testing

On the category pages I believe that it places the URI mapping fields just before the last form, as you can see on my screenshot the row highlighted in blue is the mapping fields and this is in the main for so works fine.


However if you restrict the category to only certain product types then it places the URI mapping fields inside the wrong form as the last form on the page is the currently restricted product types, So when the category is restricted to product types it does not let the URI mapping work


I hope this makes sense and you can help me figure out a way to solve! Basically when the category is restricted to certain product types the URI mapping will not update as it is not in the main form.

[mc12345678]

Hi Guys, I am having an issue with updating the category fields. I belive it has something to do with where it is placing the fields on the page

DISCLAIMER, I mostly do not know what I am on about so please excuse anything that is wrong or otherwise just stupid im just guessing at most stuff here after testing

On the category pages I believe that it places the URI mapping fields just before the last form, as you can see on my screenshot the row highlighted in blue is the mapping fields and this is in the main for so works fine.


However if you restrict the category to only certain product types then it places the URI mapping fields inside the wrong form as the last form on the page is the currently restricted product types, So when the category is restricted to product types it does not let the URI mapping work


I hope this makes sense and you can help me figure out a way to solve! Basically when the category is restricted to certain product types the URI mapping will not update as it is not in the main form.

Looks like somewhere around line 369 of admin/includes/ceon_uri_mapping_javascript.php change:

var place = classList[classList.length - 1];

To:

var place = classList[0];

[DannyVarley]

Works perfectly!

Thanks!

[lat9]

I've got a site, recently upgraded to zc156c and Ceon 5.0.0. I'm seeing that, for the product_info page, if a requested product has an entry in the ceon_uri_mappings::uri field and the associated product exists in the products table ... but the product is disabled that the $_GET['products_id'] value isn't set.