Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
RE: Liferay 7.2: DefaultFriendlyURLMapper and public-render-parameter
Hi,
I'm still working on our 6.1.1 to 7.2.0 update.
Now I've run in to a slight issue with DefaultFriendlyURLMapper and public-render-parameters. While trying to fix it I noticed that there's the exact same issue on this site.
Take a look at this URL: https://liferay.dev/blogs/-/categories/39286915?p_r_p_resetCur=true&p_r_p_categoryId=39286915
Note that 39286915 is repeated becuase it's a public render parameter. That didn't happen in Liferay 6.1.1.
As far as I can tell p_r_p_-version isn't actually needed, the public render paramter seems to work without it.
Is this a bug in 7.2.0, or needed for some technical reason?
I guess I have to implement my own FriendlyURLMapper to get rid of it?
I'm still working on our 6.1.1 to 7.2.0 update.
Now I've run in to a slight issue with DefaultFriendlyURLMapper and public-render-parameters. While trying to fix it I noticed that there's the exact same issue on this site.
Take a look at this URL: https://liferay.dev/blogs/-/categories/39286915?p_r_p_resetCur=true&p_r_p_categoryId=39286915
Note that 39286915 is repeated becuase it's a public render parameter. That didn't happen in Liferay 6.1.1.
As far as I can tell p_r_p_-version isn't actually needed, the public render paramter seems to work without it.
Is this a bug in 7.2.0, or needed for some technical reason?
I guess I have to implement my own FriendlyURLMapper to get rid of it?
Hi Lars,
I'm not sure if you can get rid of the p_r_p. I have used public render parameters in multiple solutions since the 7+ architecture has started. When I have them as regular (non public) render parameters, then the mappings work as expected. In all of my cases though, as soon as I promote them to be public, they start showing up in the url. I never dug into the source to validate why, but I also assumed that it was because they needed to live in the higher requests objects (the original request) so that they could be visible to all plugins on the layout.
I can't remember in 6.2 (or 6.1 for that matter) ... are you saying that in your 6.1 installation the p_r_p doesn't show in the url?
I'm not sure if you can get rid of the p_r_p. I have used public render parameters in multiple solutions since the 7+ architecture has started. When I have them as regular (non public) render parameters, then the mappings work as expected. In all of my cases though, as soon as I promote them to be public, they start showing up in the url. I never dug into the source to validate why, but I also assumed that it was because they needed to live in the higher requests objects (the original request) so that they could be visible to all plugins on the layout.
I can't remember in 6.2 (or 6.1 for that matter) ... are you saying that in your 6.1 installation the p_r_p doesn't show in the url?
Yeah, in Liferay 6.1.1 the p_r_p-version of the parameter isn't shown when using DefaultFriendlyURLMapper.
For instance: https://www.cypax.dk/produkter/-/category/vis/BCDHEXSwitch
Here "vis" and "BCDHEXSwitch" are public render paramters.
For instance: https://www.cypax.dk/produkter/-/category/vis/BCDHEXSwitch
Here "vis" and "BCDHEXSwitch" are public render paramters.
I see -- hmm. Well, the next thing I would try then is comparing the DefaultFriendlyURLMapper from 6.1 portal source to the version from 7.1 or 7.2. Might be an oversight on Liferay's part tha tyou can report to them, but temporarily fix with a custom mapper. If you do have a look and see something, can you let me know? (I've added checking myself to the list, but there are a lot of things ahead of it -- especially for a Friday!
)

Copyright © 2025 Liferay, Inc
• Privacy Policy
Powered by Liferay™