[VANITY-11] Support for dynamic pages Created: 22/Jul/15 Updated: 22/Jul/15 |
|
| Status: | Open |
| Project: | Vanity URL app |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Neutral |
| Reporter: | Edgar Vonk | Assignee: | Frank Sommer |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Template: |
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
| Date of First Response: |
| Description |
|
Hi guys, We really like this Vanity URL App. However one thing we really miss in the app and that is the ability to create virtual URI mappings to dynamic pages in Magnolia (of which we have a lot). For example a single dynamic news page which serves a large number of individual news items (/news/123.html etc). Or the destination pages on the Magnolia demo site (https://demo.magnolia-cms.com/travel/destination~northAmerica~.html). We traditionally use the default Magnolia virtual URI mappings for these mappings (e.g. /123 -> /news/123.html) but it seems these dynamic pages are not supported in your Vanity URL App. I cannot also cannot enter them in the destination field manually it seems. Is it possible to build this functionality into your app? Without this we and I think many other Magnolia users will still need to resort to the default Magnolia virtual URI mapping mechanism. |
| Comments |
| Comment by Frank Sommer [ 22/Jul/15 ] |
|
Dynamic pages are supported. You can provide request parameters by setting the link suffix. The usage of path enhancement by selectors or additional path segments is not standard use case for dynamic pages. The destination field works with node identifiers, but it accepts external urls, too. So as workaround you can provide external links in the destination field. |
| Comment by Edgar Vonk [ 22/Jul/15 ] |
|
Hi Frank, Thanks for the quick reply! I see what you mean about request parameters and external URLs. The thing is that we use virtual URI mappings to get rid of the request parameters (and be able to use the Magnolia page caching etc). Our client (who manages virtual URI mappings) does not even know about these request parameters. Ideally we would like to be able to add additional (virtual) path segments to our dynamic page URLs in the app but I understand that this might not be a default use case for you. E.g. in our case we would like to use in the destination field: /eaie/prague/programme/programme-activities/activity/92.html however this is rejected because the 'activity' page is a dynamic page with a virtual URI mapping. As you say we could tell our client to either use request parameters or full ('external') URLs like: http://www.eaie.org/prague/programme/programme-activities/activity/92.html
I guess the latter is acceptable to us and easiest for the client but has the obvious drawback that the vanity URLs are then environment specific since they now have the host name in them.. Maybe you have some additional thoughts? |