[MGNLETK-27] Multi site support and virtualURIMappings don't play nice together: can not resolve site definition Created: 12/May/10 Updated: 03/Jul/14 Resolved: 26/May/10 |
|
| Status: | Closed |
| Project: | Extended Templating Kit (closed) |
| Component/s: | None |
| Affects Version/s: | 1.3 |
| Fix Version/s: | 1.3.1 |
| Type: | Bug | Priority: | Major |
| Reporter: | Ernst Bunders | Assignee: | Jan Haderka |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | multisite, vpro | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||
| Template: |
|
||||||||||||||||||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||||||||||||||
| Description |
|
This only happens when you are browning your site on the admin server, and have the site name in the url (no host mapping) for instance: I have this page: http://localhost:8080/festival/event.html?name=Kasabian the site root node name is 'festival' and the site def node name is 'festivalsites' I create links to this page 'manually' , and i ran into the problem that I would have to know if the site name should be part of the url or not. My first surprise was that if you open the site from the admin central, the site name is used, like localhost:8080/festival, but the LinkUtil (used by all stk teasers) appends the site definition name in stead. But both seem to work, so OK. But we also want to use virtalURIMappings, to create nice urls to this page (and page caching), like: so i created the virtualURIMapping, and it works well on url's without the sitename. It also works well on url's with the site name, like: But, alas, the url i got from LinkUtil, doesn't have the site node name, but the site definition node name, so the url becomes: which throws an error: here is an xml dump from my virtualURIMapping configuration: <?xml version="1.0" encoding="UTF-8"?> For some reason the site definition and the related style can not be resolved. (don't know why) by the way, http://localhost:8080/festivalsites/event.html?name=Kasabian works equally wel as http://localhost:8080/festival/event.html?name=Kasabian |
| Comments |
| Comment by Ernst Bunders [ 12/May/10 ] |
|
I just found another bug that is closely related to this one.
It seems to me that site definition name should not be used. just stick to the site name, and all seams to be well. |
| Comment by Philipp Bärfuss [ 12/May/10 ] |
|
To investigate upon that few things would be helpful:
The site name is used to ensure that the site can be detected in the authoring environment. Two links are supported:
This kind of site-aware links were introduced to solve problems when you combine the mutlisite and i18n feature (the uri does not necessarily represent the content's path) I don't know why this is failing in combination with virtual uri mappings but we will try to debug it. In case you are not using the i18n feature you could disable the site aware links by doing the following: --> change the value of /server/rendering/linkManagement/class from info.magnolia.module.extendedtemplatingkit.ETKLinkTransformerManager to info.magnolia.link.LinkTransformerManager Jan wrote recently a blog post explaining that in more details for those who are interested: http://weblogs.java.net/blog/rah003/archive/2010/05/03/once-more-multi-site-support |
| Comment by Jan Haderka [ 13/May/10 ] |
|
I'm not able to reproduce the exact issue, however I can confirm that VirtualUriFilter looses site information on forward: This issue should be fixed in latest snapshot of ETK [1]. In order to deploy the fix, please replace the existing ETK jar with the snapshot and change the config://server/filters/virtualURI/class to info.magnolia.module.extendedtemplatingkit.filters.ETKVirtualUriFilter In order to further investigate the original issue, please provide the info metioned by Philipp in the comment above. |
| Comment by Jan Haderka [ 13/May/10 ] |
|
Deployed latest snapshot at [1] |
| Comment by Ernst Bunders [ 14/May/10 ] |
|
hello Jan I tried you new jar, but i can not see a difference. Both bugs are still there. I consider the fact that the site definition name is used in by magnolia to create links as the core of the problem, that is: both errors won't occur if the link is used with the site node name in stead of the site definition node name. but I'm not sure. I attach a couple of files.
So, I hope this information is helpfull. Keep me posted. for us resolving this problem is top prioritoy, so if you need anything from me, let me know as soon as you can. |
| Comment by Ernst Bunders [ 14/May/10 ] |
|
The promised files. |
| Comment by Jan Haderka [ 14/May/10 ] |
|
Hi Ernst, thanks for the additional info. I'm looking into it right now. Jan |
| Comment by Jan Haderka [ 14/May/10 ] |
|
One additional question - did you try switching off ETKLinkTransformerManager as suggested by Philipp? |
| Comment by Ernst Bunders [ 14/May/10 ] |
|
hello Jan I hadn't tried it yet indeed. I just did, and the following happens:
Is this enough information for you? |
| Comment by Jan Haderka [ 14/May/10 ] |
|
Yes it is enough. I believe I found the real problem here. |
| Comment by Ernst Bunders [ 14/May/10 ] |
|
hello Jan Do you want me to test this? if so:
regards, Ernst |
| Comment by Jan Haderka [ 14/May/10 ] |
|
You can test it if you want. It is definitively the cause of failure of my local tests, but since our setup might not be exactly the same, it would be good if you can confirm it too. |
| Comment by Jan Haderka [ 14/May/10 ] |
|
Nevermind, this will not fix your problem, there is a deeper issue which I need to tackle first. |
| Comment by Jan Haderka [ 14/May/10 ] |
|
So to summarize:
|
| Comment by Ernst Bunders [ 14/May/10 ] |
|
Hello Jan I'm a bit confused by your remarks. Assuming you are strictly talking about the virtualURIMapping problem: it already works provided that the site node name is in the url and not the site definition node name, as is the case with links generated by magnolia. So The second issue has similar characteristics. The wrong urls are created. Call the pages with the site node name in the url and problems are gone. What am i missing? |
| Comment by Jan Haderka [ 14/May/10 ] |
With the latest snapshot both URLs should work. The one with site root node as well as the one with site definition name. What you are missing is probably flow of what is happening behind the scene when using multisite and virtual uri mappings and how the URI is transformed to the handle in general. Without trying to get into too many details:
The whole issue is around the fact that while forwarding the request, VirtualURIFilter was also causing loss of the site information (due to cleanup actions triggered by forward ). The second issue, while seemingly very similar, has completely different cause. It's caused by the fact that models were assembling links for pagination and navigation manually instead of using LinkUtil which knows is aware of the site related mappings. |
| Comment by Jan Haderka [ 14/May/10 ] |
|
To deal with the second part of the issue (links on pagination) I've deployed the STK snapshot with the fix. |
| Comment by Ernst Bunders [ 17/May/10 ] |
|
I'v been testing all morning and it is looking good! We are going to go ahead with these fixes. |
| Comment by Jan Haderka [ 17/May/10 ] |
Thanks for the feedback.
Absolutely. I still don't consider issue fixed. What I did was just apply workaround for MultiSiteFilter to track Site itself so you can go ahead. This still need to be fixed at the AggregationState level before we can close this issue. If you find any more issues with the multisite support let me know so we can include tests for it as well on top of all other tests already mentioned by Philipp. |
| Comment by Ernst Bunders [ 17/May/10 ] |
|
One small request: would it be possible to create source jars for the snapshot jars as well? We use those quite extensively, especially the stk one. It is quite inconvenient to have to do without them. |
| Comment by Jan Haderka [ 17/May/10 ] |
| Comment by Ernst Bunders [ 17/May/10 ] |
|
For completeness: I add the contents of the mail i just sent here as well, as it appears to be caused by the etk snapshot jar We are now experiencing a new problem: we can not activate content anymore. I send you a piece of the stacktrace, which is very long, because I did some tests, and learned the following:
-------------------------------------------------------------------------------------- |
| Comment by Ernst Bunders [ 18/May/10 ] |
|
Yes, it works again. Thanks again. |