[#5285] - Routing: Discover Itemid in Router for com_content
- Closed
- 30 Dec 2014
- Medium
- Build: staging
- # 5285
- Diff
- Hackwar:ItemidInRouter
- Success The Travis CI build passed Details
User tests: Successful: Unsuccessful:
This change moves the code that discovers the right Itemid for this content item from the ContentHelperRoute class into the component router. This means that also URLs in the content get the right Itemid and we don't need to pre-calculate them during the time the article was written. It also means that all URLs are treated correctly and not just those going through ContentHelperRoute. At the same time, this also fixes the Itemid discovery for form views in com_content. If you have a menu item that points to a create article view, this menu item is taken for editing articles in the frontend instead of the homepage.
This makes ContentHelperRoute obsolete, but I did not change that class yet, since that would interfer with PR #5140. So #5140 should be merged first in order to test this one properly. That means that also #5264 and #5276 should be merged before this one.
This only touches com_content for the moment. Further components can be done at a later stage. I also wanted to keep it testable, since no one could be expected to test all components at once.
It should be made clear that this ultimately changes the behavior of ContentHelperRoute in the way that it removes the Itemid from its output. For a sane developer that would not be a problem, since he would not mess with the output any further, but I have the gut feeling that there are developers out there, that take an article, let ContentHelperRoute calculate the right Itemid and then parse that Itemid back from the URL that is returned by ContentHelperRoute. The question is, how far we are going to go to prevent people from shooting themselfs in the foot... (Read: Doing the above described thing would be Homer-Simpson-stabs-himself-with-a-knife-in-the-hand-stupid)
To give you a little insight into the future: In one of the next steps, this code will be moved into a component router rule, which is generalized and where one code works for all components. At that point, this code is removed again from the component routers.
This was made possible through the generous donation of the people mentioned in the following link via an Indiegogo campaign: http://joomlager.de/crowdfunding/5-contributors
jissues-bot
- | Labels |
Added:
?
|
||
brianteeman
- | Category | ⇒ | SEF |
The new code would not need to be deprecated, since the preprocess method will still be present in the later version and still do the same work, just in a base class. I'm simply providing this, since I will need more time to get the router rule done correctly. It is not so much about the code to be written, but to write it in a way that will be sane and not cause us grieve in the future. I've got the code ready, but I'm simply not 100% sure that the way I'm going there is the right one. I hope that this could be merged into 3.4 already.
I've decided to implement the ContentHelperRoute changes, too, in order to make the testing realistic. In worst case, I have to update the other PR and solve the conflicts there...
Oh, and I also declared the findItem() method as private. That means that we can drop the method as soon as the component router rule is ready.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2014-12-30 10:02:20 |
Hannes instead of moving this code block around (deprecating it twice, i guess) why don’t you directly put them in the rules (deprecating only the ContentHelperRoute)?