Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Routing: Discover Itemid in Router for com_content #5285

Closed
wants to merge 7 commits into from

Conversation

Hackwar
Copy link
Member

@Hackwar Hackwar commented Dec 2, 2014

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

@dgrammatiko
Copy link
Contributor

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.

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)?

@Hackwar
Copy link
Member Author

Hackwar commented Dec 2, 2014

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.

@Hackwar
Copy link
Member Author

Hackwar commented Dec 2, 2014

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...

@Hackwar
Copy link
Member Author

Hackwar commented Dec 2, 2014

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.

@Hackwar
Copy link
Member Author

Hackwar commented Dec 30, 2014

Since this is now superseded by #5444, #5446 and #5501, I'm closing this one.

@Hackwar Hackwar closed this Dec 30, 2014
@Hackwar Hackwar deleted the ItemidInRouter branch December 30, 2014 10:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants