482 replies to this topic

[mvanderhoff]

Great piece of software!

One thing I noticed when I installed it was my Header SEO Tags would NOT show the product information anymore after installing SEO URLS 5. Any thoughts on this?

[jmoll]

Good evening. I'm using osC 2.3.1 on a Windows IIS server (I know, I know...). Anyway, I have USU 5 Pro installed, and is working well from what I can tell. I installed another add-on that adds a next and previous button to each product page, so that you can navigate easily and quickly between products within a given category. Some of my products are in more than one categoary, e.g. a wicker chair is in category path "Outdoor Wicker -> Wicker Chairs", but also in "Outdoor Wicker -> Wicker Collections -> XYZ Collection". The next/prev. buttons from the add-on always default to the category path for Wicker Chairs. I.e., when viewing prod page for a chair in cat path 2_18, fine, but when in cat path 35_42, as soon as I click either the Prev or Next button (from the add-on), it goes back to thinking it's in cat path 2_18. Debugging through all the code, I've determined it's due to a variable $current_category not containing the current path value, e.g. "35_42", so it queries and gets first cat path returned from the db, which is always "2_18". So, tracing through all the code, I'm realizing that the cPath info is being lost somehow by USU 5 Pro somewhere in the bowels of all the object oriented code - i.e. the links on the product listing page for the current category have just the p-xxx data in them, i.e. just the product id values, but no cPath data. Now I can "fix" this by going to the admin for USU 5 Pro and enabling the setting to add in the cPath, and this will fix the problem in that my Next and Prev buttons navigate correctly through the current category, but the admin option does this by tacking it on as a URL query param, i.e. "?cPath=35_42", which I'm thinking then defeats the whole point of having an SEO friendly URL formatting add-on.... Does anyone have any ideas how I can fix this without having to resort to the non-SEO friendly cPath query param tack-on to the end of links? Remember that I'm on IIS and don't have an htaccess file to add re-write rules to, so I'm looking for ideas to implement via program code. Thanks in advance for any help/ideas/suggestions!

[jmoll]

jmoll, on 16 May 2012, 01:21, said:

Good evening. I'm using osC 2.3.1 on a Windows IIS server (I know, I know...)....

Solved this by simply setting a session variable to store the correct cPath value then retrieving this if set in application top.