Joomla Routing

[Hannes Papenberg]

Hello everybody,
I recently opened 3 bug tracker items here:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31107
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31104
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31103

These are/were urgent bugs for one of my clients, which is why I filed
them and where I hoped that someone would fix them. However I was
contacted both by David Hurley and Jean-Marie Simonet if I could provide
patches for those issues.

In the last few weeks I planned on offering a new routing system to
Joomla and to finance that work through a kickstarter campaign. This
first failed on me not being a US or UK citizen, but I was planning
around that with the help of a friend. Now however I'm faced with these
bugs, one of which is a devcon1 for me, and I guess I don't really wanna
take chances with this being fixed or not. But I also don't want to fix
a system that I think has inherent design issues, so that a desperately
needed overhaul for the routing system is postponed because "it
currently works, don't touch it".

So I would like to ask the project if my proposal from almost 2 years
ago
(https://groups.google.com/forum/?fromgroups=#!searchin/joomla-dev-cms/joomla$20routing/joomla-dev-cms/BEeudTYi1Gk/Q9sh6-bjzWoJ)
could now be looked upon again. I'm offering to implement this new
routing system into the Joomla CMS and do the necessary work, but I'm
asking the project leads to look at it now and give it a thumbs up or
thumbs down before I start work on this again. The concept is there and
it wont change. However I simply can't afford to invest several weeks of
work into this when it is then rejected because the concept is not
approved.

I'm open for discussion on this concept and I'm happy to explain it to
everybody interested. Besides this mailinglist, you can get me in the
#joomla channel on freenode and on Skype.

I hope that we can finally tackle this problem and get Joomla forward on
this long standing issue.

Thanks,
Hannes Papenberg

[Michael Babker]

For what it's worth, I still support this and would love to see the code Hannes is proposing brought in.  Last I was talking to him about the code in December and tested it, something I noticed immediately was how much faster the system was as a whole with the improved code (more info about it here - https://gist.github.com/mbabker/5544011).

I know a show stopper in the past for this has been talks about B/C breakage.  I don't remember now if that's handled in the code or not, but if it is handled, we should seriously look at this for 3.2, in my opinion.

Everyone pretty much agrees that the routing system is in need of a massive overhaul.  This is a step in the right direction.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.

[Mark Dexter]

If it is something that could offered as an option there might be less
concern about b/c. Obviously changing the routing rules could be a big
issue in middle of a release train. Mark

[Hannes Papenberg]

The system right now is backwards compatible for all extensions except for those that mess with the standard Joomla routing, like sh404sef. So all component routers still work and it would even be possible to have a 2.5 router and a 3.2+ router in the same extension at the same time.

The URLs generated by this would be identical by default to the ones generated so far.

Overall the only thing not working like before would be extensions like sh404sef. And even that is only a pessimistic guess.

[Mark Dexter]

Sounds great. We just need to test the heck out of it to make sure. Mark

On Sun, Jun 9, 2013 at 2:24 PM, Hannes Papenberg

[Hannes Papenberg]

Of course. I'll start with a branch in my repo.

[Dimitris]

I count 4 extensions for joomla 3.0 routing in http://extensions.joomla.org/extensions/site-management/sef 

Simple Custom Router, JoomSEF, sh404SEF,  MijoSEF 

So really there are not so many stoppers

 

Just saying

[Matt Thomas]

Does this only mean that these 3pd extensions would need to update their code to work with the new routers? In other words, this wouldn't kill them, and they could also benefit from this, but would need to do some work?

Best,

Matt Thomas
Founder betweenbrain™
Lead Developer Construct Template Development Framework
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

Sent from mobile. Please excuse any typos and brevity.

--

[Hannes Papenberg]

The interface to the Joomla routing changes only slightly. It might
already be enough for them to switch out a few method names. But, yes,
they would only have to update their components to play with the new
routers again.

Hannes

Am 10.06.2013 02:08, schrieb Matt Thomas:
>
> Does this only mean that these 3pd extensions would need to update
> their code to work with the new routers? In other words, this wouldn't
> kill them, and they could also benefit from this, but would need to do
> some work?
>
> Best,
>
> Matt Thomas

> Founder betweenbrain�

> Lead Developer Construct Template Development Framework
> Phone: 203.632.9322
> Twitter: @betweenbrain
> Github: https://github.com/betweenbrain
>
> Sent from mobile. Please excuse any typos and brevity.
>
> On Jun 9, 2013 6:22 PM, "Dimitris" <d.gram...@gmail.com

> <mailto:d.gram...@gmail.com>> wrote:
>
> I count 4 extensions for joomla 3.0 routing
> in http://extensions.joomla.org/extensions/site-management/sef
>
>
> Simple Custom Router

> <http://extensions.joomla.org/extensions/site-management/sef/21251>, JoomSEF
> <http://extensions.joomla.org/extensions/site-management/sef/1063>, sh404SEF
> <http://extensions.joomla.org/extensions/site-management/sef/10134>, MijoSEF
> <http://extensions.joomla.org/extensions/site-management/sef/22026>

>
> So really there are not so many stoppers
>
> Just saying
> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

> To post to this group, send an email to
> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

[Hannes Papenberg]

I was asked if I could explain the idea behind this router a bit more,
so here it goes:

Right now there are several issues in the Joomla routing:
1. It's slow. There is some code in there, that is a performance drain.
2. It's not object oriented. Everybody needs to copy-paste the code
again and again for his or her component router.
3. Quite a lot of behavior is hardcoded into the routing.
4. Most important however: Right now its broken by design. All links
have to go through their respective components *HelperRoute::get*Route
function to get the right Itemid. Now if you have a URL in an article,
you either have the Itemid attached to the URL or not. In the first case
"everything is fine" - as long as you don't change your menu structure
and remove that menu item (in favour of another menu item). Then that
link will not generate the right URL, although its perfectly possible
from a computational standpoint. In the later case, the URL simply wont
be correct and you have two URLs to one content item.

What does this router do?
The main concept is, that all behavior of the router is a rule and rules
can be added, changed or removed depending on your need. So if you need
a different behavior for the menu system or for the HTTPS behavior (for
example you are working with a load balancer and HTTPS) you can enable
or disable the default behavior of Joomla in that regard and write a
rather simple plugin and add your own behavior. Right now you would have
to basically copy the whole routing system again and run it in a system
plugin before the actual routing of Joomla happens.
The next thing is, that this idea is not only confined to the main
routing of Joomla, but also applies to the component routing. By
defining an interface and using objects instead of functions, you can
either write your router in the classical sense or you extend your
router class from a base-class that allows to add rule-driven-behavior.
Now if we also standardize on "only views can have a SEF URLs", which so
far has been true for all good components that I've seen so far, you
only have to register those views with a few basic parameters in the
router and the rest is done by Joomla itself.

What does this mean in the end?
The router of com_content would look like this:

defined('_JEXEC') or die;
/**
* Content Router
*/
class ContentRouter extends JComponentRouter
{
function __construct()
{
$this->register('categories', 'categories');
$this->register('category', 'category', 'id', 'categories', '',
true, array('default', 'blog'));
$this->register('article', 'article', 'id', 'category', 'catid');
$this->register('archive', 'archive');
$this->register('featured', 'featured');
parent::__construct();
}
}

And even for other components, writing a router would only mean to add
one line per view to the router to register it.

Now, by using this scheme, we can now switch out the rules for component
routers, too, and for example have URLs with the date in them for
articles or simply domain.tld/article-alias or we could simply remove
the IDs from the URLs. And the good part: All extensions adhearing to
this system benefit from each rule directly, without any changes in
code. This also introduces a coding idea that I think Joomla should
enforce in the future: convention over configuration. Yes, it gives you
the ability to write your own router if you really need to. But you
benefit a lot more by simply sticking to the convention, since then your
code will play nicely together with other SEF code.

A further benefit would be, that we get rid of all the *HelperRoute
classes, since their behavior would be integrated into the router. So
regardless of your link going through ContentHelperRoute, it will always
have the right Itemid and create the right URL.

Last, but not least, this change would most likely make it obsolete for
most users to use an SEF component.

There is one downside to this. While most code in this new router is a
lot simpler than now, the rules for the component router that I'm
proposing above is very complex. It is very generalized and thus hard to
maintain. But I hope to be able to ease the pain regarding this with
extensively commented code, so that the intentions behind every line are
made clear.

Does that make the plan a bit clearer? For everything else I would
prefer to go through this with some code to show you.

Hannes

Am 10.06.2013 02:08, schrieb Matt Thomas:
>

> Does this only mean that these 3pd extensions would need to update
> their code to work with the new routers? In other words, this wouldn't
> kill them, and they could also benefit from this, but would need to do
> some work?
>
> Best,
>
> Matt Thomas

> Founder betweenbrain�

> Lead Developer Construct Template Development Framework
> Phone: 203.632.9322
> Twitter: @betweenbrain
> Github: https://github.com/betweenbrain
>
> Sent from mobile. Please excuse any typos and brevity.
>
> On Jun 9, 2013 6:22 PM, "Dimitris" <d.gram...@gmail.com

> <mailto:d.gram...@gmail.com>> wrote:
>
> I count 4 extensions for joomla 3.0 routing
> in http://extensions.joomla.org/extensions/site-management/sef
>
>

> Simple Custom Router
> <http://extensions.joomla.org/extensions/site-management/sef/21251>, JoomSEF
> <http://extensions.joomla.org/extensions/site-management/sef/1063>, sh404SEF
> <http://extensions.joomla.org/extensions/site-management/sef/10134>, MijoSEF
> <http://extensions.joomla.org/extensions/site-management/sef/22026>
>

> So really there are not so many stoppers
>
> Just saying
> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

> To post to this group, send an email to
> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

[Joe Palmer]

This is fantastic Hannes, I think this is essential for Joomla!

> Founder betweenbrain™

[shumisha]

Hell Hannes,

After reading your last message, I'm a bit confused.

1 - Does this new router has some "legacy" mode that allows it to work straight from the existing router.php files, or else who's going to provide the new JComponentRouter children classes which register the rules?
2 - How are backward compatible urls produced for even simple things like articles, if rules such as

$this->register('article', 'article', 'id', 'category', 'catid');

are used for content articles?
What I mean is that on existing sites, many articles are linked from menus, and thus have urls such as example.org/my-article.html, based on the menu item title. How are those reproduced?

Rgds

Yannick

[Thomas PAPIN]

Another suggestion :)

If a new router is integrated into Joomla, it will be great to be able to generate FRONT URL from the backoffice.

Currently, If I am not wrong it's not possible without some "tricks code" to generate a SEF for a front url in the backoffice and this is really bad when you are sending for example a mail with a link to a page in the front.

Thomas

2013/6/10 Hannes Papenberg <hack...@googlemail.com>

> Founder betweenbrain™

[Olivier Nolbert]

+1 for the suggestion Thomas,

I use to deal with this problem in plugins that send emails with events raised from backend...

Olivier

[elin]

I'll just say that three extension will cause many many problems.  Even 1% of all Joomla sites is a lot of sites and breaking people's links is really devastating for their businesses. It's also not just routing extensions. It's fairly safe to say messing with core patterns is very common.  Any change for 3.2 would I think have to be opt in or we can count on very low  adoption of 3.2.  Personally I'm strongly opposed to anything that increases the centrality of categories, such dependencies have been the cause of numerous compatibility issues requiring custom code (plenty of extensions don't use categories) and of course many and perhaps most people don't want to use strict hierarchies for organizing their content presentation. (And even if they want to have filing system they most certainly don't want to show their private organization to the world in the form of urls.) Beginning users with 5 pages shouldn't have to use categories at all (hence  the workaround of a fake uncategorised status) and large users  prefer flexible structures with multiple classifications not restricted by the component concept.  Gopher (http://en.wikipedia.org/wiki/Gopher_(protocol))  type organizing structures are really a very narrow and specific use case. Like Yannick said most likely the most common use case is people wanting mydomain.com/myarticle which is why people constantly request the ability to add an article directly to a menu. At least now you can get that easily for a brochure site, sadly though not for anything else.  Any new system we adopt should also be forward looking to the data structures we are moving to and aiming for for the long term, not backward looking to what we have in 2.5. 

I'm not positive but I suspect if we can switch to JApplicationWeb (testers for Michael's branch needed to help find b/c issues) we could move to a more configurable system in which case an opt in model might be viable.   Even though the code for some other applications may not be pretty, it is quite a nice and attractive feature for users to be able to pick the structure of urls that they prefer.  That's what I would aim for rather than a monolithic solution.

All three of those reports look like valid bug or code quality fixes to me based on a cursory look although we should be cautious about changing existing urls  as in 31107 though I definitely think that is a bug where we should just be checking if a link is to a category at level 1--which is not a root since categories has a single root-- and I'm sure there was some reason that was done. Moving toward  JHelperRoute is also designed to help with eliminating a lot of the duplication but any step in that direction is a good thing.

Elin

[Dimitris]

Hannes you have the code somewhere?
Thanx

Dimitris

[Hannes Papenberg]

There is code here: https://github.com/Hackwar/joomla-cms/tree/jrouter
But that code is outdated. I hope to be able to update that stuff soon.

Hannes

[Theo Basios]

Hannes let me ask you if finally anyones from the PLT has contact you to proceed with the implement your code to your core of Joomla?

Finally Joomla needs real SEF system.

You have spent a lot time on this one and it will be just annoying if the PLT just ignore it!

Thanks

[Bakual]

As far as I know that is not exactly how it works.

 

Instead someone has to create a feature request on the tracker, submit a Pull Request on Github and then enough testers need to test it. Only if that is done, someone (maybe the PLT?) will review it and it will get merged.

Without an actual PR, nothing is going to happen at all. I don't know what the current state is, but I understood it that there is an outdated code at the moment, so this would have to be updated first.

[Matt Thomas]

While that is true, Hannes has made past PRs for this. With that being the case, and the amount of work it will take to get it current, it would be great if PLT gave him a general thumbs up or down on proceeding, while not guaranteeing acceptance.

Best,

Matt Thomas
Founder betweenbrain™
Lead Developer Construct Template Development Framework
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

Composed and delivered courtesy of Nexus 7.

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.

[Dimitris]

I gave it a try and I can confirm that the loading time is less than half of that with the standard Joomla router. 

If it's ok for Hannes I can try to get the code to 3.1.

So then Hannes can make another PR and hope that PLT will accept it this time.

I really like to see this MAJOR improvement either in 3.2 or 3.5

Dimitris

[brian teeman]

if i remember correctly the biggest problem with this was backwards compatibility

[Hannes Papenberg]

It is backwards compatible. It can even be installed as a plugin into
current Joomla 2.5 and still everything would be working as before.

Hannes

[Hannes Papenberg]

Hi Dimitris,
I would be very happy about some help. My time is currently pretty
limited. I was planning on doing this in two parts. First implementing
the general routing and then in a second step refactore the component
routing together with the abstract rules.

Hannes

[brian teeman]

You said it was not b/c with 3pd extensions for routing and Yannick of sh404sef asked a question to which I dont see a response

[Hannes Papenberg]

Hi folks,
I finally got some time and started on bringing the code up to speed. I
got JRouter, JRoute, JRouterInstallation, JRouterSite and
JRouterAdministrator done. I don't know if they are in the right places,
since I'm not really up-to-date with the latest naming schemes. I've
also done some work on JComponentRouter, the component routers and I
added the routing plugin in the repository, but all this is still some
way to go. I also changed the global configuration to support this new
system.

There are no database changes necessary for this, except that you have
to discover the routing plugin in your system and you can see that the
old component routers are still working like they did before, side by
side with the new ones.

I'm happy about any help and I would also appreciate any reviews of the
above mentioned classes that are done and the scheme itself.

You can find the code here:
https://github.com/Hackwar/joomla-cms/tree/hackwar_routing
I'll update it in that repository.

Hannes

Am 16.06.2013 16:11, schrieb brian teeman:

[Theo Basios]

Very good news that you are working on it Hannes.

I hope devs will help you on this !!

This a major step at the routines of Joomla!

Very well done!!

[Theo Basios]

Hello

I m wondering why no one sees so serious this is.

Why is so hard in Joomla to implement something in the core which will speed up the load and also finally provide really SEF urls.
Really I dont understand why Joomla is having closed doors on this one.
Hannes is spending so much time on it and no one cares?!

And I see also other beautiful features like this : http://www.ostraining.com/blog/joomla/25-3-upgrade-check/
 which are staying away from the core ?! Why ?

Maybe Joomla Team Leaders has to change something in the way they are working???

I dont find it right!

[brian teeman]

Until Hannes provides the code no one can test it.

[Hannes Papenberg]

I've provided the first code 22 days ago:
https://github.com/Hackwar/joomla-cms/tree/hackwar_routing

and asked for feedback 19 days ago:
https://groups.google.com/d/msg/joomla-dev-cms/Lnyo5JLtwlU/NJw5Bg1rGSoJ

[Dimitris]

The routing is not there yet? 

For the articles, categories that have a menu all good

no rewrite no sef

/index.php?option=com_content&view=category&layout=blog&id=2&Itemid=467 normal old url

rewrite sef

/category-demo New url

for some modules, components still no correct URL especially if they dont have a menu

(/component/content/category/2 seems to be one instead of /category-demo)

I can't find the way to change the options on the sef part
I try to work out the code but is quite tricky...

Hannes if you can share some thoughts on what to look...

[Hannes Papenberg]

Hello Dimitris,
did you discover the new plugin that was added in the repo? Yes, the
URLs are currently not correct, the question was more aimed at the whole
concept/workflow of the routing. Instead of forcing us through a
*HelpeRoute class first, JRoute::_() now takes a URL string or an
associative array of URL parameters and processes those. It has no
default behavior of any kind and instead uses routing rules that you can
enable and disable through global configuration freely. One of those
rules is the component routing itself like we know it, which again now
invokes classes instead of functions and lets those process the
component part of the URL. It is in those classes that we find the
correct Itemid instead of in an external *HelperRoute class. Since we
are using classes for routing, we can now extend parent classes that
take over all the hard part of creating the URLs for us. So instead of
writing the whole router yourself, you simply extend the component
router base class, which is similarly build like the big Joomla router
in that it uses configurable rules, too.

My request for code review was aimed at the changes in JRoute, JRouter,
JRouterSite, JRouterAdministrator, JComponentRouter, etc. to see if I
put the classes in the right position and if they look good from a code
perspective. The individual rules that make the current routing system
still need to be properly implemented. But since that would take me
quite some time to do, I first want a positive review from the people in
charge that this code will be accepted and is worth pursuing. I wont
invest several weeks again only to have this code not even looked at. In
the end, there are dozens of big and small improvements in there, that
either reduce the processing time for routing by 50% or make it less
code and a lot more flexible than the current routing. So even if not
everything was accepted, I would be happy if I could get some feedback
to know which parts to concentrate on. Thank you.

Hannes

[Hannes Papenberg]

Hello folks,
I found another nice routing bug:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31557

For those believing in "duplicate content on the same domain":
congratulations, Joomla has an infinite number of URLs per article.

For those believing in the concept of Tim Berners-Lee "one unique URL
per content item": I'm sorry, Joomla fails at this again.

Hannes

P.S.: Sorry, but this took me an hour to debug at a client, 2 hours to
explain and convince him, cost him quite some grief and frustrates me
beyond belief, since all this was working in 1.6....

Am 15.07.2013 19:33, schrieb Dimitris:

[Richard McDaniel]

Hannes, I appreciate your concern and sympathize with you. Our group has run into this issue as well. We also have issues with Google crawling pages, finding category lists and creating duplicate URL's that way. For example, we'd have uah.edu/hr and uah.edu/police and then somehow Google would start indexing uah.edu/hr/police/etc links. If you would like to contact me by email we can setup a way to chat, perhaps IRC and share information on this issue. I would really like to help you fix all of these bugs. Thanks for your attention.

[Dimitris]

similar problem with https://groups.google.com/forum/#!searchin/joomlabugsquad/duplicate/joomlabugsquad/GC-YNB3xPuY/rJiEZlR9btoJ 

It is really sad that the PLT doesn't want to address these problems. 

[Amy Stephen]

On Wednesday, July 24, 2013 7:00:39 PM UTC-5, Dimitris wrote:

similar problem with https://groups.google.com/forum/#!searchin/joomlabugsquad/duplicate/joomlabugsquad/GC-YNB3xPuY/rJiEZlR9btoJ 

It is really sad that the PLT doesn't want to address these problems. 

Did you get a chance to response to Hannes?

I'm not sure what the PLT would respond too. It is not ready yet. Those who are hoping to get it into core should be responding to Hannes's requests for help.

Hannes - it might be worth getting a Google group going like some of the other teams are doing. That way, you can identify developer support needed.

I've heard nothing that seems to suggest this wouldn't be considered but as with all things - the community has to put in the effort to finish the work, get the testing in place, and then it can be considered.

Don't sit and wait and complain the PLT aren't doing something or it will not happen, I think that's a guarantee.  Make it happen.

On Thursday, July 18, 2013 2:26:37 AM UTC-5, Hannes Papenberg wrote:

Hello Dimitris,
did you discover the new plugin that was added in the repo? Yes, the
URLs are currently not correct, the question was more aimed at the whole
concept/workflow of the routing. Instead of forcing us through a
*HelpeRoute class first, JRoute::_() now takes a URL string or an
associative array of URL parameters and processes those. It has no
default behavior of any kind and instead uses routing rules that you can
enable and disable through global configuration freely. One of those
rules is the component routing itself like we know it, which again now
invokes classes instead of functions and lets those process the
component part of the URL. It is in those classes that we find the
correct Itemid instead of in an external *HelperRoute class. Since we
are using classes for routing, we can now extend parent classes that
take over all the hard part of creating the URLs for us. So instead of
writing the whole router yourself, you simply extend the component
router base class, which is similarly build like the big Joomla router
in that it uses configurable rules, too.

[Amy Stephen]

BTW - no one gets an exclusive claim on being the discovery group or only set of people who recognize "Joomla's URLs are less than ideal."

What is missing are groups of these two kinds:

1. Joomla URL Fan Club Enthusiasts

2. A working solution for something else that is complete, testable, and offers some kind of reasonable backward compatibility.

We have always had plenty of people, myself included, who can articulate what is wrong with the current situation. We've also had many attempts at fixing it or partially fixing it or sorta fixing it, most of the time just making it worse.

If this changes, it will be changed by those who invest in it and refuse to fail and aren't waiting for permission or approval or looking for someone to blame.

[Dimitris]

Amy few days ago Hannes responded with: My request for code review was aimed at the changes in JRoute, JRouter,

JRouterSite, JRouterAdministrator, JComponentRouter, etc. to see if I

put the classes in the right position and if they look good from a code.
I guess this is about the essential code of the cms and I guess all Hannes is asking from Plt is if the code will fit the roadmap. If it doesn't there is no need for him or any of us to even talk about it. I saw what happens with the rad-fof. Maybe what you say makes sense (make it then ask for getting it to core) but if I recall the rad team had to change quite a lot of code. And this is not a library that someone might use, it's in the hart of the cms, so it's not quite the same.

[Michael Babker]

I can't speak for everyone else's priorities, but I know I said somewhere that I intended on looking at his code after we got through our backlog from the PBF event and this next release out the door.  Unfortunately, that's taken much longer than anyone expected, but such is life.

[Amy Stephen]

Dimitris - this code has not changed -- at least significantly -- since 1.6. There have been some who do not support this approach because it's too much like the existing approach - I'm in that group - and others like Michael and Mark who in this very thread gave as much support as you can give without actually having code in hand working. So, great, the code from 1.6 era is now in github but there is a ton of work to do to get it into Joomla and functioning for each component - let alone trying to even understand the possible ramifications.

Sitting around and beeping at the PLT every week or so about code that is not even changing just seems like a great way to get everyone unhappy. Hope you can appreciate that.

As far as the RAD team, I disagree completely with your recollection. The first time up, sure it was shot down. But the next time it was proposed they were supported by many/most/if not all and the only reason it will even go in is because they made it happen. I don't recall anyone forcing them to change a lot of things, but then again, maybe I missed it and regardless, that's how things go.

But to sit and wait - well, how can anyone else be to blame?

If it were up to me, I'd say no - leave the URLs alone. For. Goodness. Sake. until the architecture is rewritten. But, it's not and I sure as hell am not going to stand in anyone's way if they can take their idea to fruition. More power to them. But please - we've all had enough drama. Do it. Don't do it. But take responsibility for that choice and if it fails, at least you tried. I don't see anyone trying to stop anyone.

[Hannes Papenberg]

I'm idling on freenode in #joomla as Hackwar

Hannes

[Hannes Papenberg]

The situation is comparable to implementing the plugin system. Amy, you
expect me to not only write the plugin system, but also all plugins
before you will take a look at it? The main code, the processing
pipeline (=plugin and event system), is ready. It is the foundation of
the whole system. It has also been updated for 3.1 and it actually is
not like the current system. It is also the minimum implementation of a
routing system I could find. (I compared against AngularJS and CakePHP
here.)

We will have discussions and most likely also disagreements over the
specific rules (=plugins), how to implement them, what those rules
should do and what rules we should ship with the Joomla core. But before
I start into the fine details of implementing these rules, I'd like to
have at least one other person to review the code/concept for the basic
processing pipeline. If you dislike this system, because it is to much
like the old one, please give me feedback. Maybe my concept is the wrong
approach. Maybe this should be done completely differently. However, so
far I've not seen anyone else come forward with a concept or code proposal.

For gods sake, I'm writing to this mailinglist in the hopes of having a
discussion about this topic/problem/concept and maybe falsifying me, so
that we get a great routing system out of this, instead of just having
an anonymous PR somewhere and then either be shot down or shove this
change down peoples throats. Instead we are discussing for over a month
now if a concept is worth discussing. Meta-discussions ftw!

Hannes

Am 25.07.2013 02:18, schrieb Amy Stephen:
> On Wednesday, July 24, 2013 7:00:39 PM UTC-5, Dimitris wrote:
>
> similar problem
> with https://groups.google.com/forum/#!searchin/joomlabugsquad/duplicate/joomlabugsquad/GC-YNB3xPuY/rJiEZlR9btoJ

> <https://groups.google.com/forum/#%21searchin/joomlabugsquad/duplicate/joomlabugsquad/GC-YNB3xPuY/rJiEZlR9btoJ>

[Amy Stephen]

Hannes -

There are five members of the PLT: Michael, Mark, and Nick who seem to be quite busy, Chris is working on webservices and heading the documentation team, then there is Ron who I have no idea what he does, but I don't think he can review your work. That's the reality of the PLT - no one is stonewalling you, they are quite busy.

I have seen Michael and Mark *in this thread* encourage your work as much as anyone can. Your code has not changed since those comments were made. Those are most likely the ones on the PLT who will provide that guidance and they have given you as much of a green light as you can possibly hope for.

So, my message to you is -- do it, don't do it.  Given everything, Hannes, I wouldn't blame you for deciding you don't want to invest the time, especially since it is entirely possible the work will not be accepted. (And understand up front, the work is not likely to be accepted absent tests - that's almost a guarantee - so factor that into your decision process).

Right now, it's as close to a community-driven process as I think it will ever be. Everyone is taking a chance when they develop a feature. If you are able to pull off pretty URLs and do so in a way that is testable and maintainable and keep that performance increase Michael has already shown - it's almost a guarantee it's going to be accepted.

It's really up to you. On a personal level, Hannes, nothing would make me happier than to see that happen.

[Gary Brooks]

If I had a vote and I was on PLT, I would like to see a new way of how URL are handled. Its a long standing issue in our community and if we can battle out a solution, I would love to see it put into position asap.  As long as we do not hurt the old URL's with new commits.  

Hannes, is it time to start user testing your new code? Does it do anything to the backend UI of Joomla?  

Gary Brooks 
garyb...@cloudaccess.net
Phone:  +1-231-421-7160 Ext: 7161

Direct Office: +1-231-421-7161
Skype id: garyjaybrooks2000
Fax:    313-899-7032
Web:    http://www.cloudaccess.net
Address:  10850 Traverse Hwy, Suite 4480 | Traverse City, Michigan 49684

--
You received this message because you are subscribed to a topic in the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-cms/Lnyo5JLtwlU/unsubscribe.
To unsubscribe from this group and all of its topics, send an email to joomla-dev-cm...@googlegroups.com.

[Alan Sparkes]

Late to this thread ....but did an early post from Hannes suggest this could be a plugin and avoid the b/c issues?

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.

[Hannes Papenberg]

What would need to happen to get this first PR, that fixes some of the
bugs in the current routing, to be accepted?
https://github.com/joomla/joomla-cms/pull/1560
If this change is accepted, I have at least 3 more PRs that I would like
to send in to fix the worst bugs in 3.1 and 2.5.

@Alan
There is no gain in doing this as a plugin. I thought about providing a
plugin for 2.5 to implement this, but that doesn't change the (minor) bc
issues.

Hannes

Am 25.07.2013 22:39, schrieb Alan Sparkes:
>
> Late to this thread ....but did an early post from Hannes suggest this
> could be a plugin and avoid the b/c issues?
>
> On 25 Jul 2013 17:43, "Gary Brooks" <garyb...@cloudaccess.net

> <mailto:garyb...@cloudaccess.net>> wrote:
>
> If I had a vote and I was on PLT, I would like to see a new way of
> how URL are handled. Its a long standing issue in our community
> and if we can battle out a solution, I would love to see it put
> into position asap. As long as we do not hurt the old URL's with
> new commits.
>
> Hannes, is it time to start user testing your new code? Does it do
> anything to the backend UI of Joomla?
>

> *Gary Brooks
> *garyb...@cloudaccess.net <mailto:garyb...@cloudaccess.net>
> *Phone: * +1-231-421-7160 Ext: 7161
> <tel:%2B1-231-421-7160%20Ext%3A%207161>
> Direct Office: +1-231-421-7161 <tel:%2B1-231-421-7161>
> *Skype id: *garyjaybrooks2000
> *Fax: * 313-899-7032 <tel:313-899-7032>
> *Web: * http://www.cloudaccess.net <http://www.cloudaccess.net/>
> *Address:* 10850 Traverse Hwy, Suite 4480 | Traverse City,

> Am 25.07.2013 02 <tel:25.07.2013%2002>:18, schrieb Amy

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

> To post to this group, send an email to
> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

> Visit this group at http://groups.google.com/group/joomla-dev-cms.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

> To post to this group, send an email to
> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

[brian teeman]

On Tuesday, 30 July 2013 11:45:21 UTC+1, Hannes Papenberg wrote:

What would need to happen to get this first PR, that fixes some of the
bugs in the current routing, to be accepted?

Exactly the same as any Pull Request it needs to be successfully tested 

As you haven't completed "How to reproduce the problem and/or test the patch::" on the issue tracker http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8103&tracker_item_id=31107 it is hard for testers to know what they are testing.

[Hannes Papenberg]

I added a description now as a comment.

Hannes

Am 30.07.2013 13:01, schrieb brian teeman:
>
>
> On Tuesday, 30 July 2013 11:45:21 UTC+1, Hannes Papenberg wrote:
>
> What would need to happen to get this first PR, that fixes some of
> the
> bugs in the current routing, to be accepted?
>
>
> Exactly the same as any Pull Request it needs to be successfully tested
>

> As you haven't completed "*How to reproduce the problem and/or test
> the patch:*:" on the issue

[brian teeman]

I believe I followed your test instructions completely but could not replicate the error. https://www.youtube.com/watch?v=emc9z4JMmMg

[Richard McDaniel]

Hello, first let me thank you for your time and attention on this matter. I really appreciate it. I am trying to improve Joomla! from a SEO standpoint and most approaches to SEO consider duplicate content to be a negative. The following issue also causes Google search bots to index a lot of extra pages that might not be desirable. I apologize if using the Joomla! demo sites in this manner is inappropriate. In the interests of time, I don't see any harm but if it causes any issues, I will gladly put forth the extra work to setup a demo of my own.

Now, allow me to demonstrate the problem.

This is the original URL:

http://joomla25.cloudaccess.net/using-joomla/extensions/components/content-component.html

From that I can display a category list anywhere:

http://joomla25.cloudaccess.net/using-joomla/extensions/components/26-park-site

http://joomla25.cloudaccess.net/using-joomla/extensions/26-park-site

http://joomla25.cloudaccess.net/using-joomla/26-park-site

http://joomla25.cloudaccess.net/26-park-site

Unfortunately the problem can also be compounded:

http://joomla25.cloudaccess.net/using-joomla/extensions/components/26-park-site/19-joomla/29-fruit-shop-site

This seems to affect 3.1.x too:

http://joomla31.cloudaccess.net/

http://joomla31.cloudaccess.net/2-uncategorised

I'm unsure how to proceed because this doesn't seem to be a implementation bug per se but rather just a possible oversight in the design. If anyone would like to suggest a course of action, I am more than willing to dedicate time to fix this issue.

Thanks again for your attention and any insights you may have.

On Sunday, June 9, 2013 12:09:32 PM UTC-5, Hannes Papenberg wrote:

Hello everybody,
I recently opened 3 bug tracker items here:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31107
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31104
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31103

These are/were urgent bugs for one of my clients, which is why I filed
them and where I hoped that someone would fix them. However I was
contacted both by David Hurley and Jean-Marie Simonet if I could provide
patches for those issues.

In the last few weeks I planned on offering a new routing system to
Joomla and to finance that work through a kickstarter campaign. This
first failed on me not being a US or UK citizen, but I was planning
around that with the help of a friend. Now however I'm faced with these
bugs, one of which is a devcon1 for me, and I guess I don't really wanna
take chances with this being fixed or not. But I also don't want to fix
a system that I think has inherent design issues, so that a desperately
needed overhaul for the routing system is postponed because "it
currently works, don't touch it".

So I would like to ask the project if my proposal from almost 2 years
ago
(https://groups.google.com/forum/?fromgroups=#!searchin/joomla-dev-cms/joomla$20routing/joomla-dev-cms/BEeudTYi1Gk/Q9sh6-bjzWoJ)
could now be looked upon again. I'm offering to implement this new
routing system into the Joomla CMS and do the necessary work, but I'm
asking the project leads to look at it now and give it a thumbs up or
thumbs down before I start work on this again. The concept is there and
it wont change. However I simply can't afford to invest several weeks of
work into this when it is then rejected because the concept is not
approved.

I'm open for discussion on this concept and I'm happy to explain it to
everybody interested. Besides this mailinglist, you can get me in the
#joomla channel on freenode and on Skype.

I hope that we can finally tackle this problem and get Joomla forward on
this long standing issue.

Thanks,
Hannes Papenberg

[Hannes Papenberg]

Hi Richard,
In short, this is a bug that was introduced somewhere around 1.7. In 1.6 this was working correct. The problem is, that the core routers don't care for the hierarchy of the views. A menu item of an article view can't create a link pointing to a category view, since an article is always the leaf in the tree that is created with the categories, category, article structure. So when somebody tried to improve the routers, he messed them up completely.so without rewriting them completely, you won't get this fixed. But if we are rewriting the component routers, we might as well improve the whole routing of homes for 3.2 altogether, which my proposal is about.

Hannes

--

[Richard McDaniel]

I have a patch that fixes this particular issue: http://joomlacode.org/gf/download/trackeritem/31680/83692/31680.patch

Here is the tracker item: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8103&tracker_item_id=31680

[brian teeman]

I am here to help but as stated already I cannot replicate the error with Hannes test instructions

[Adam Rifat]

Isn't the bug the one richard highlights on August 5th?

That is, on the cloud hosted instance of Joomla you can easily recreate duplicate urls by using variations of almost random urls?

In which case these two tracker items are essentially duplicates...

http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8103&tracker_item_id=31107
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8103&tracker_item_id=31680

Or is this bug richard hightlights a separate issue?

[Hannes Papenberg]

Hi Adam,
the two bugs that you are posting are not the same. Mine targets the
ContentHelperRoute class (/component/com_content/helpers/route.php),
which is broken and is one part of Joomla that generates wrong URLs. The
bugreport from Richard targets the router.php in
/components/com_content/, which is also broken and, as I said, doesn't
care for the hierarchy of the entities in Joomla. However, I opened a
bug report for that already here:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31557
Since this is a routing bug, I also want to ask not to apply Richards
patch there, since it does not solve the bug and in fact rather makes
matters worse by spreading the issue over more files.

Hannes

> <http://joomla25.cloudaccess.net/using-joomla/extensions/components/26-park-site>
> http://joomla25.cloudaccess.net/using-joomla/extensions/26-park-site
> <http://joomla25.cloudaccess.net/using-joomla/extensions/26-park-site>
> http://joomla25.cloudaccess.net/using-joomla/26-park-site
> <http://joomla25.cloudaccess.net/using-joomla/26-park-site>
> http://joomla25.cloudaccess.net/26-park-site

> <http://joomla25.cloudaccess.net/26-park-site>
>
> Unfortunately the problem can also be compounded:
>
> http://joomla25.cloudaccess.net/using-joomla/extensions/components/26-park-site/19-joomla/29-fruit-shop-site
> <http://joomla25.cloudaccess.net/using-joomla/extensions/components/26-park-site/19-joomla/29-fruit-shop-site>
>
> This seems to affect 3.1.x too:
>
> http://joomla31.cloudaccess.net/
> <http://joomla31.cloudaccess.net/>

> http://joomla31.cloudaccess.net/2-uncategorised

> <http://joomla31.cloudaccess.net/2-uncategorised>
>
> I'm unsure how to proceed because this doesn't seem to

> be a implementation bug /per se/ but rather just a

> possible oversight in the design. If anyone would like
> to suggest a course of action, I am more than willing
> to dedicate time to fix this issue.
>
> Thanks again for your attention and any insights you
> may have.
>
> On Sunday, June 9, 2013 12:09:32 PM UTC-5, Hannes
> Papenberg wrote:
>
> Hello everybody,
> I recently opened 3 bug tracker items here:
> http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31107

> <http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31107>
>
> http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31104
> <http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31104>
>
> http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31103

> <https://groups.google.com/forum/?fromgroups=#%21searchin/joomla-dev-cms/joomla$20routing/joomla-dev-cms/BEeudTYi1Gk/Q9sh6-bjzWoJ>)

> <http://groups.google.com/group/joomla-dev-cms>.

> For more options, visit
> https://groups.google.com/groups/opt_out

> <https://groups.google.com/groups/opt_out>.
>
>
>

[Hannes Papenberg]

I provided new testing instructions.

Hannes

> <http://joomla25.cloudaccess.net/using-joomla/extensions/components/26-park-site>
> http://joomla25.cloudaccess.net/using-joomla/extensions/26-park-site
> <http://joomla25.cloudaccess.net/using-joomla/extensions/26-park-site>
> http://joomla25.cloudaccess.net/using-joomla/26-park-site
> <http://joomla25.cloudaccess.net/using-joomla/26-park-site>
> http://joomla25.cloudaccess.net/26-park-site

> <http://joomla25.cloudaccess.net/26-park-site>
>
> Unfortunately the problem can also be compounded:
>
> http://joomla25.cloudaccess.net/using-joomla/extensions/components/26-park-site/19-joomla/29-fruit-shop-site
> <http://joomla25.cloudaccess.net/using-joomla/extensions/components/26-park-site/19-joomla/29-fruit-shop-site>
>
> This seems to affect 3.1.x too:
>
> http://joomla31.cloudaccess.net/
> <http://joomla31.cloudaccess.net/>

> http://joomla31.cloudaccess.net/2-uncategorised

> <http://joomla31.cloudaccess.net/2-uncategorised>
>
> I'm unsure how to proceed because this doesn't seem to be

> a implementation bug /per se/ but rather just a possible

> oversight in the design. If anyone would like to suggest a
> course of action, I am more than willing to dedicate time
> to fix this issue.
>
> Thanks again for your attention and any insights you may have.
>
> On Sunday, June 9, 2013 12:09:32 PM UTC-5, Hannes
> Papenberg wrote:
>
> Hello everybody,
> I recently opened 3 bug tracker items here:
> http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31107

> <http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31107>
>
> http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31104
> <http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31104>
>
> http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31103

> <https://groups.google.com/forum/?fromgroups=#%21searchin/joomla-dev-cms/joomla$20routing/joomla-dev-cms/BEeudTYi1Gk/Q9sh6-bjzWoJ>)

> <http://groups.google.com/group/joomla-dev-cms>.

> For more options, visit
> https://groups.google.com/groups/opt_out

> <https://groups.google.com/groups/opt_out>.
>
>
>

[Richard McDaniel]

Hannes, thanks for your criticism. It is definitely good to be cautious. If you wouldn't mind, please go to the issue tracker item and post the results of any tests you've done. I'm not sure what you mean when you say that it makes matters worse but maybe it's fixable. The only difference my patch makes is that it returns 404 messages instead of serving pages that aren't supposed to exist. I don't see how that's a bad thing but maybe you can explain better what you mean. Thanks for your help.

[Hannes Papenberg]

Hi Richard,
the biggest issue is, that you are trying to fix a problem in the wrong
place. This is a routing issue and thus it should be fixed in the
routing code. You are fixing it in the wrong area. The next problem is,
that you remove the possibility of nested categories. You are retrieving
the URI and compare it to the menu route. But when you have a menu item
that links to a category view and want to navigate to a subcategory from
there, it would fail, since you would have a url like
domain.tld/menu-item-1/menu-item-2/42-subcategory, which does not relate
to a menu route.

In the end, the router needs to parse the URL and throw the 404, but
only when it properly checked the menu item and the hierarchy of the
entities of the component. A simple string comparison will not be enough
here.

Hannes

> <http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8103&tracker_item_id=31107>
>
> >
> http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8103&tracker_item_id=31680

> <https://groups.google.com/forum/?fromgroups=#%21searchin/joomla-dev-cms/joomla$20routing/joomla-dev-cms/BEeudTYi1Gk/Q9sh6-bjzWoJ

> Visit this group at http://groups.google.com/group/joomla-dev-cms.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Adam Rifat]

It is easy to recreate this issue using a fresh install and following Hannes instructions.

The patch supplied also appears to fix the problem. Updted the tracker in case anyone is interested.

I haven't been able to test with any languages installed though.

[Richard McDaniel]

Thanks for testing things out for us Adam. I have a second patch up @ http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8103&tracker_item_id=31680 if you have some spare time I would appreciate you testing it as well. Thanks!

[Hannes Papenberg]

Hello altogether,
Richard and I had a little discussion on IRC and it came up that there
might be some confusion and that we also need some guidance from all of
you to proceed on this whole matter. So first a small recap on where we are:

I currently have 3 code changes in the pipeline for the routing system.
2 bugfixes and 1 redesign.

#1: ContentHelperRoute creates wrong URLs because it doesn't look up the
right Itemid
(http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8103&tracker_item_id=31107
with PR here: https://github.com/joomla/joomla-cms/pull/1560)
This bug messes around with URLs when you have categories that are
nested several levels deep. For more insight, please read the tracker
item. There is a working patch for this, which brings big performance
gains (although it doesn't reach the absolute optimum, but anyway) and
which fixes the first routing bug. This bug was introduced in a
refactoring somewhere in the end of 2010. This bugs needs to be fixed in
2.5.x and 3.1.x.

#2: Component routers parse about anything, returning nonsense pages
instead of a 404
(http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31557)
This bug lets Joomla parse any URL that starts with a number and that is
not a menu item as a category page. This depends on the homepage or last
menu item properly read. So domain.tld/21-half-answer will return in
most cases a content category page with the Itemid of the frontpage and
category-ID 21. domain.tld/contact/42-full-answer will return a contact
category with the Itemid of the contact menu item and the category-ID 42
(if /contact is a com_contact menu item). And this works for all core
components interchangeably. The alias doesn't matter one bit in this
case. The big problem here is, that the router does not care for the
hierarchy of the different entities. It means that for example an
article menu item can't create a link to a category with the article
menu item as the menu item. In the end, our components always create a
tree hierarchy with content items (articles, weblinks, newsfeeds,
contacts) as the leafs and categories as the inner nodes. A category
menu item can only create links to child categories of itself or to
articles in itself or its child categories. Or in other terms: a URL to
one category can never be shorter than a URL to its parent category from
the same menu item.
There is no patch for this yet, but I plan on creating one this weekend.
This bug was introduced in the same refactoring as mentioned above. This
bugs needs to be fixed in 2.5.x and 3.1.x.

#3: Redesign the routing of Joomla
(https://github.com/Hackwar/joomla-cms/tree/hackwar_routing)
This attempt aims at rewriting the current routing to be OOP, fast,
light, more flexible and easier to implement for developers. It also
tries to remove IDs from URLs and a lot more. The code in the link above
gives an outline of the concept behind all of this and I was hoping
someone could review that concept before I start re-implementing the
specific rules. I got some feedback, although not the one that I hoped,
so I'm going to try to implement this stuff over the weekend, too.
However I don't know if I will have the time. In any case, I will keep
you posted. This could be introduced in 3.2.

Now after this recap for all those that just joined the party:

*To work on #2 I need some advice from you!

*As I wrote above, the components create hierarchies in our URLs and we
do the same in the menus, etc. It is actually common behavior that I can
take a URL, seperate it into its '/'-delimited segments and when I
delete the last segment, I get to a higher level page. For example
domain.tld/contacts/director-1 would lead to the contact of director-1,
while domain.tld/contacts leads to the overview page of all contacts on
the website. Another example: domain.tld/faq gets me to the faq, where
domain.tld/faq/how-do-urls-work gets me to the page about "How do URLs
work".

Joomla however fails in that regard.
domain.tld/menu-item/42-half-answer/full-answer brings you to the
category "Full answer", but domain.tld/menu-item/42-half-answer doesn't
get you to the category "Half answer", but also to the category "Full
answer". To actually do this properly, we would have to have URLs like
domain.tld/menu-item/21-half-answer/42-full-answer. When the code was
refactored in 2010, this common behavior was broken. I would like to
bring it back, but that would create new URLs for a lot of sites. I
understand that that is quite a problem for a lot of people, even though
the URLs that we currently have are not good.

Because of that, I would like to propose to introduce new parameters
into the core component configurations that allow us to define the
behavior of this. I would opt for 3 settings: 1. New URLs without IDs,
2. New URLs with IDs and 3. Old style URLs. In case you are wondering:
If we implement these fixed/improved routers, we might as well remove
the need for the IDs altogether. 1. would create a slight performance
disadvantage, compared to 2., but for sites that need every bit of
performance, they can switch back to 2. All existing sites could use 3.
and decide themselfs if they want to switch or not. The default behavior
for new sites would be 1., for existing sites it would be 3. That
setting could be set in the update process, both in 2.5 and 3.1.

I would like to know if that would be acceptable behavior or if it is
impossible to implement proper URLs in 2.5/3.1? Please give me some
advice regarding this. If I should create a patch to solve this routing
bug, I need a go for either "Don't implement this in 2.5/3.1" or "With a
config option this is acceptable."

Thank you,
Hannes

Am 05.08.2013 23:16, schrieb Richard McDaniel:
> I have a patch that fixes this particular
> issue: http://joomlacode.org/gf/download/trackeritem/31680/83692/31680.patch
>
>
> Here is the tracker
> item: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8103&tracker_item_id=31680
>
> On Monday, August 5, 2013 4:10:25 PM UTC-5, Hannes Papenberg wrote:
>
> Hi Richard,
> In short, this is a bug that was introduced somewhere around 1.7.
> In 1.6 this was working correct. The problem is, that the core
> routers don't care for the hierarchy of the views. A menu item of
> an article view can't create a link pointing to a category view,
> since an article is always the leaf in the tree that is created
> with the categories, category, article structure. So when somebody
> tried to improve the routers, he messed them up completely.so
> without rewriting them completely, you won't get this fixed. But
> if we are rewriting the component routers, we might as well
> improve the whole routing of homes for 3.2 altogether, which my
> proposal is about.
>
> Hannes
>
> Am 05.08.2013 19:53 schrieb "Richard McDaniel" <rm0...@uah.edu

> <javascript:>>:

>
> Hello, first let me thank you for your time and attention on
> this matter. I really appreciate it. I am trying to improve
> Joomla! from a SEO standpoint and most approaches to SEO
> consider duplicate content to be a negative. The following
> issue also causes Google search bots to index a lot of extra
> pages that might not be desirable. I apologize if using the
> Joomla! demo sites in this manner is inappropriate. In the
> interests of time, I don't see any harm but if it causes any
> issues, I will gladly put forth the extra work to setup a demo
> of my own.
>
> Now, allow me to demonstrate the problem.
>
> This is the original URL:
>
> http://joomla25.cloudaccess.net/using-joomla/extensions/components/content-component.html
> <http://joomla25.cloudaccess.net/using-joomla/extensions/components/content-component.html>
>
>
> From that I can display a category list anywhere:
>
> http://joomla25.cloudaccess.net/using-joomla/extensions/components/26-park-site

> <http://joomla25.cloudaccess.net/using-joomla/extensions/components/26-park-site>
> http://joomla25.cloudaccess.net/using-joomla/extensions/26-park-site
> <http://joomla25.cloudaccess.net/using-joomla/extensions/26-park-site>
> http://joomla25.cloudaccess.net/using-joomla/26-park-site
> <http://joomla25.cloudaccess.net/using-joomla/26-park-site>
> http://joomla25.cloudaccess.net/26-park-site

> <http://joomla25.cloudaccess.net/26-park-site>
>
> Unfortunately the problem can also be compounded:
>
> http://joomla25.cloudaccess.net/using-joomla/extensions/components/26-park-site/19-joomla/29-fruit-shop-site
> <http://joomla25.cloudaccess.net/using-joomla/extensions/components/26-park-site/19-joomla/29-fruit-shop-site>
>
> This seems to affect 3.1.x too:
>
> http://joomla31.cloudaccess.net/
> <http://joomla31.cloudaccess.net/>

> http://joomla31.cloudaccess.net/2-uncategorised

> <http://joomla31.cloudaccess.net/2-uncategorised>
>
> I'm unsure how to proceed because this doesn't seem to be a

> implementation bug /per se/ but rather just a possible

> oversight in the design. If anyone would like to suggest a
> course of action, I am more than willing to dedicate time to
> fix this issue.
>
> Thanks again for your attention and any insights you may have.
>
> On Sunday, June 9, 2013 12:09:32 PM UTC-5, Hannes Papenberg
> wrote:
>
> Hello everybody,
> I recently opened 3 bug tracker items here:
> http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31107

> <http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31107>
>
> http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31104
> <http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31104>
>
> http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31103

> <https://groups.google.com/forum/?fromgroups=#%21searchin/joomla-dev-cms/joomla$20routing/joomla-dev-cms/BEeudTYi1Gk/Q9sh6-bjzWoJ>)

> <javascript:>.

> To post to this group, send an email to

> joomla-...@googlegroups.com <javascript:>.

> Visit this group at
> http://groups.google.com/group/joomla-dev-cms

> <http://groups.google.com/group/joomla-dev-cms>.

> For more options, visit
> https://groups.google.com/groups/opt_out

> <https://groups.google.com/groups/opt_out>.

[Bakual]

I'd say the best thing would be if the created URLs would be following the new way, but the old URLs were still supported. Kind of how SEF works: SEF URLs are created, but non-SEF URLs always work as well.

This way it wouldn't matter much when URLs are changing, since the old URLs still yield a valid page. And it would allow a "migration" between the systems since the old URLs eventually phase out and are replaced in the search engines (and extern links) with the new ones.

 

If that's not possible, then your three options will probably a good approach as well. But there will be no way for existing sites to migrate to the new system without potentially breaking existing links.

[Hannes Papenberg]

Yes, I agree with you. The issue is, that we actually only want those
URLs to work that Joomla has generated itself. Right now, the router
generates a small number of URLs, but parses an infinite number of URLs
that the router did not generate. The question is, if we want Joomla to
only parse those URLs that it has generated (or potentially can
generate) itself or if we want it to parse all those broken URLs that
might float around out there, since someone didn't copy the whole URL or
forgot to add whitespace after the URL, creating a longer one and such.

In the end, whatever we do, we will break some URLs. There is no way
around that, except to keep it broken like that. However, those URLs
that we will break, are the ones that were not generated by Joomla, but
by someone copying half a URL or which were extended by a stupid
program. (Real world example: A friend has a Joomla site, postes URLs of
that site on Facebook and G+. A socialservice site reads the G+ entry,
removes all HTML without adding whitespace for line breaks and thus we
get a URL like "http://domain.tld/interesting-topicHere you can find
stuff about X". Google sees "http://domain.tld/interesting-topicHere",
tries to parse it and Joomla returns a valid page under an invalid URL.
These URLs would break after this fix, no matter what we do.) So, we
need to decide how much we want to break. We could do the option 3 with
a parsing behavior that would not care for the alias, but at least cares
for the hierarchy that we have and the other options would also check
the alias. But I wouldn't allow stuff like the example that I gave above
to return a valid page.

Hannes

> <https://github.com/joomla/joomla-cms/pull/1560>)

> This bug messes around with URLs when you have categories that are
> nested several levels deep. For more insight, please read the tracker
> item. There is a working patch for this, which brings big performance
> gains (although it doesn't reach the absolute optimum, but anyway)
> and
> which fixes the first routing bug. This bug was introduced in a
> refactoring somewhere in the end of 2010. This bugs needs to be
> fixed in
> 2.5.x and 3.1.x.
>
> #2: Component routers parse about anything, returning nonsense pages
> instead of a 404
> (http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31557

> <http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31557>)

> <https://github.com/Hackwar/joomla-cms/tree/hackwar_routing>)

> <https://groups.google.com/forum/?fromgroups=#%21searchin/joomla-dev-cms/joomla$20routing/joomla-dev-cms/BEeudTYi1Gk/Q9sh6-bjzWoJ

[piotr_cz]

I wouldn't mind few links pointing to the same resource as long as the number of alternative links is kept reasonable (ie. article: trough menu item and category / article path).

But IMHO what's really important is the creation of canonical links.

Joomla since 3.0 adds canonical link to a page and if there's a mistake in algorithm (see past bugs), you'll get bans from search engines.

[Adam Rifat]

Hi Hannes,

Thanks for all your time on this. Here is another real world example.

We are in the process of migrating a legacy ColdFusion application into Joomla. We have 1000s of URLs many of which are changing and need 301 redirecting. I am/was planning on using a system plugin similar to the core redirect plugin which picks up any 404 pages and checks against a predefined list to see if there is a mapping in the new site for this old url.

However, some of my old urls are actually giving 200 responses. For example 

old url - mydomain.co.uk/activity/286-boating
new url - mydomain.co.uk/things-to-do/boating

Although the first url is not defined in my Joomla site at all it still resolves to a page due to the id in the url. As we have 6000 urls of this type its a bit of a headache. I know this is perhaps a convoluted example but if I could rely on a 404 error actually being generated for an invalid url it would make my life much easier.

Regarding your proposals.

#1 - You appear to have a working patch for tracker item 31107, which is cool.
#2 - A patch for this would also be cool and would (I hope) solve my above problem. I will happily test this for you as soon as it is ready. Is this the change that will require new component parameters?

As the above are normal pull requests with the appropriate testing is there any reason they wouldn't be added to the next release?

#3 - Sounds cool, although it's anyones guess as to whether it would make it in or not.

Also, I have to agree with piotr_cz that the problem of canonical meta tags also needs to be solved as well. For some reason a canonical tag is placed on every page of my 3.1.5 site even though the pages are unique. I guess I will have to write a separate plugin to remove canonical tags until we can figure that one out.

Thanks,

Adam

[Amy Stephen]

I mentioned earlier that I was not in favor of Hannes proposal is because it doesn't address the real problem with Joomla URLs. While I appreciate the pretty URLs, and I definitely agree that stupid primary key does not belong there, a lack of human readable URLs is far from the biggest problem.

The architecture was designed before the argument was settled and folks like Matt Cutts started making it clear that duplicate content is an issue. The architecture also preceded RESTful solutions.

What was cool about Joomla was being able to place an article on multiple "pages" (each with a different URL), modules were used to customize the page for those visitors. In it's day, the cat's meow.

Today, URLs like this (which have been like this for years) are unacceptable, period.

• http://community.joomla.org/blogs/leadership/1763-you-can-make-this-part-up.html
• http://community.joomla.org/blogs/leadership/and-you-can/add/levels/cool/huh/1763-you-can-make-this-part-up.html

Even if you *think* you can solve that problem, the system will always permit multiple URLs per content item. Anyone who thinks that is okay today really is clinging to old ideas, it is not good for websites and it takes a lot of knowledge and planning (and a small site) to ensure it doesn't happen with Joomla.

Provided multiple URLs per item continues to be considered "flexible", it'll be a constant shuffling of one problem for the other. Then, when someone like Hannes isn't "on staff" fixing them, it just gets worse. I don't think URLs have ever been in a more sorry state than they are today.

Out of technical debt, into technical inflation.
http://martinfowler.com/bliki/TechnicalDebt.html

[Amy Stephen]

One more point related to one of the proposed patches.

Remember that robots "catalog" a site with content. That's, in part, how it's able to tell there is duplicate content. It has a list of URLs. It has some value for the content, it compares the two. Duplicate content does impact GPR. Not good, not even a debate today.

Later, if the same URL turns up as a 404, then, that's another strike against the site. Content should stay put - or - the 301 redirect to the new URL.

So, any fix really should 301 redirect the invalid URLs. Given Joomla URLs are problematic to begin with, expecting that is likely to much. So, at least consider stop gap measures that prevent the robot from tracking more bad URLs. Stop the bleeding - even if it's not a correct fix, it could have a positive impact on a site by not allowing things to get worse when waiting for a better solution.

And, if possible, 301 redirect after a fix.

[Andrew Eddie]

I don't know about anyone else but I'm getting a bit lost following the emails and what's a priority to fix. Hannes, could you put an executive summary (the problem to fix and the stages to fix it) on a wiki page/Google doc/whatever which [always] reflects the latest status of this thread? I think that will help everyone that who has an interest in the routing being able to tell where the discussion is at. I'm always a little nervous about routing changes because we've had numerous tug-of-war "patches" in the past that have sometimes done more harm than good.

Also, do we have a wiki pages that outlines how the router is supposed to perform as of today? (whether it's the "right way" is up for debate, but we always have to make sure we don't break the current state even if we don't agree with it).

Thanks in advance.

Regards,

Andrew Eddie

[Hannes Papenberg]

Hello Andrew,
there are some pages in our wiki about routing:
http://docs.joomla.org/Routing_implementation_details
http://docs.joomla.org/Search_Engine_Friendly_URLs#tab=Implementation_Details
http://docs.joomla.org/J2.5:Creating_a_System_Plugin_to_augment_JRouter
http://docs.joomla.org/Supporting_SEF_URLs_in_your_component

Unfortunately, they basically stop before it would get interesting for
this discussion. I will try to write up something about this whole thing
in the coming days.

Hannes

[Hannes Papenberg]

Hello Amy,
I agree with you in several parts here, the most important one: URLs to
a content item should be unique.

But I also disagree with you on other parts. For example, I don't think
that duplicate content on one and the same domain is an issue. However,
that is only a technicality, since that is something that Google is
pushing us to do, but which is no standard. The rule "One content item =
one and only one unique URL" however is a standard and thus overrules
what Google wants. So in the end, wether you are an SEO or not, we are
on the same page here.

In Joomla you can create menu items to categories and articles and you
can create as many to the same category or article as you want. That
DOES create different URLs for the same content item and is actually a
bad thing. But it is a conscious decision by the admin. Those URLs are
created by the menu system. In case of URLs created outside the menu
system, specifically those that don't have a fixed Itemid attached to
them, Joomla already actually only creates one "URL" per content item.
So you might have two links to an article in your menu, but when you go
to that article and the title is linked, you will (or should) only see
one of the two "URLs", regardless via which menu item you came. This is
already reality.

I think we can all agree on the bad idea of having more than one menu
item per content item, but I'm actually VERY hesitant to change the
possibilities in Joomla in that regard. This comes from 3 reasons: #1 It
is pretty difficult to manage the filter on the content items that have
been linked and those that haven't, #2 You would have to add that to the
specific component and could not do it in the menu manager (think about
all those components out there that have rather cryptic ways to define
what to show on the menu item) and #3 we don't know how people are using
this. Maybe there IS a good reason for them to do it like this. In any
case, the necessary work to implement a barrier like this seems pretty
high. To high for me.

So much for some of the side effects. Now on to the real issues at hand:

Yes, we will break some URLs. But those URLs have not been created by
the admin in a conscious decision and that is a big argument for me
against keeping them. The URLs that we are talking about eliminating,
exist because of accidents, typos or broken software outside of the
hands of both the Joomla project and the admins of the Joomla sites. So
I guess it is good that those URLs go away.

You say that the sites get a penalty for the duplicate content. We are
aiming at removing that penalty by removing the duplicate content. You
say that the sites would get a penalty for the 404s that would be
generated by the removal of the duplicate content. I would say the
opposite is going to happen. Google can drop the penalty for duplicate
content (and the wrong canonical tags that people have in their sites)
and it will only index the "real, canonical" URL of the content item
from that update onwards. I see the scenario like this: Google might
give you a temporary penalty for the 404s, but when that one goes away,
the site will rank better than before, because it does not have a
duplicate content penalty anymore. Would you rather have one month with
slightly worse rankings than now and better rankings afterwards or stay
on the current level indefinetly?

You talk about 301 redirects. The funny thing is, that we actually could
do that. If we had the new system in place already. :-) Right now we
can't do that, since it would require the framework routing classes to
know about the component specific routing classes like
ContentHelperRoute to generate the right URL. In a new system, the
component router should only be a black box with a defined interface,
not as it is right now with side effects by stuff like ContentHelperRoute.

Thinking about this: If we plan on adding the proposed code from #3 of
my earlier mail into 3.2, we could skip the bugfix for 3.1, introduce
the fixes in 3.2 and have the 301s. At the same time, we could release a
fixed router for 2.5, eventhough it wouldn't have the 301s.

Hannes

[Robert Vining]

Hello Hannes (and everyone else),

I think that removing URL's that are not a direct child of the assigned category, or contain the actual article alias or menu item alias, is a good thing. This is a huge drawback in today's canonical URL environment. SEO has become a very different process over the past 3 or 4 years, and now relies on unique content/URL more than ever.

Just to let you know Hannes, from what I read, Feature Freeze was July 15th for 3.2 and got extended to July 31st from what I remember. That means you might get a bugfix into a 3.1.16 release, but otherwise, September (next month) is the 3.2 release. So if you plan to put something together before then, you better have code in hand in very short order.

I'm willing to assist manpower to get this done, if we can get some type of response from someone with some authority around here.

MARK DEXTER

NICK SAVOV

MICHAEL BABKER

DAVID HURLEY

Can one of you please tap into the castle skype chat and see if there are others among you that can come to some type of consensus on this?

It seems to me that's what Hannes has been asking for 2 months now (June 9 - Aug 10).

[Hannes Papenberg]

Just a quick FYI: Here is the PR for issue #1 from my earlier mail for
2.5: https://github.com/joomla/joomla-cms/pull/1708

I would be very happy if we could test and merge both PRs regarding this
soon.

Hannes

[Mark Dexter]

I have stated in the past that I don't see any problem with improving the routing performance as long as backward compatibility is maintained. To me, this would require substantial testing, including especially with third-party extensions. Personally, this is not a subject I want to spend a lot of my limited time on, but I am totally open to improvements in the routing (as in any other aspect of the code). Obviously this is something with major potential for b/c issues, so the testing bar imo should be high for any changes.

That's my .02. Mark

[Robert Vining]

Thanks Mark, I just read through the tracker for the bug and PR and it does seem a lot of folks are already testing and working on this.

I apologize for naming people above that are already helping with these issues. Guess I shouldn't comment at 3 in the morning when I should be sleeping.

I hate that we have 3 locations to discuss the same exact code/patch. Google List, JoomlaCode and GitHub comments. You really have to go on long walk to keep up with the status of just a single issue.

[Amy Stephen]

I responded to Hannes directly.  Maybe when you get the bigger patch updated, split this discussion into two? One for URL futures and the other for the three issues? It is confusing.

For clarity, Hannes created three issue reports in June and a link to a pull request he made over 2 years ago that was rejected. He did not submit any patches in June. Thus far, he submitted one patch for one of these issues a couple of days ago on August 6th.

His bigger URL rewrite is here https://github.com/Hackwar/joomla-cms/tree/jrouter - but above you'll see Hannes has acknowledged the code is not up to date so there isn't a whole lot for anyone to do right now until those updates are available. Also, testing will be needed - so that could take time.

Point being -- no one is waiting on the PLT.  The best way to get things moving is to test the patch available or create a fix to the other two issues Hannes raised.

Issue #1

Fixing HelperRoute Classes - generate wrong URLs due to selection of an incorrect Itemid. This error came from changes to ContentHelperRoute::getCategoryRoute() where the category path lookup was removed.

http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8103&tracker_item_id=31107

Initially, testers had problems reproducing - Hannes provided updated testing scenarios and the issue was confirmed

8-6-2013 Hannes provided a patch for 3.1

Adam Rifat test on 8-6
Richard McDaniel test on 8-7

8-10 PR from Hannes for 2.5 https://github.com/joomla/joomla-cms/pull/1708 Needs Testers

No testers yet

++++

Issue #2 

HelperRoute classes contain unnecessary code and potentially create unnecessary load

http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31104

There is no patch for 3.1 or 2.5

++++

Issue #3

#31103] Multi-lingual sites under heavy load via *HelperRoute classes

Right now, the *HelperRoute classes (like ContentHelperRoute) will run an
unnecessary DB query for each and every link displayed on the website

7-12-2011 Patch from Mihail Irintchev for 3.1 https://github.com/joomla/joomla-cms/pull/1513 creates static array of languages

One tester from Daniel Kanchev

No patch for 2.5

[Dimitris]

Amy one small correction: 

the url for the refactor of routing is pointing to the j2.5 repo which is outdated (joomla 2.5 will not have a new routing system -future freeze). 

The one that is current (j3.x) is: https://github.com/Hackwar/joomla-cms/tree/hackwar_routing

which does't have the sef rules (half baked)

[Amy Stephen]

Cool, easier still =)

If I understand correctly, then, use the links below to test Issue 1.

There are a couple of tests on 3.1 - patch up on 8-6

The most recent patch was for 2.5 - patch up on 8-10

All three issues are addressed in the one patch.

Not a PLT thing, just a regular patch which requires community testers.

Thanks Hannes.

Hello Amy,
thx for the summary. Regarding the other issues, I put the fixes for the last two tracker items into the PRs for the first tracker item, since they depend on one another. We can actually close the last two as being solved by the first. I will comment accordingly in the items.

Hannes

[Ofer Cohen]

@Hannes, do you have fix or plugin to remove ids from urls?

Thanks,

Ofer Cohen

BillRun.net

[Hannes Papenberg]

Hi Ofer,
I have lots of code, but its all a bit dated and needs to be updated for
Joomla 3.x. Unfortunately I don't have a lot of time and unless I find a
day to spare in the coming week, I wont be able to invest any more time
into this before the second half of september. Most of my code is out
there on github, so if you are interested, you can pick it up and fix it
to work properly in 3.x.

Hannes

Am 24.08.2013 16:01, schrieb Ofer Cohen:
> @Hannes, do you have fix or plugin to remove ids from urls?
>
> Thanks,
>

> /
> /
> /Ofer Cohen/
> /BillRun.net <http://BillRun.net>/

>
> On Sun, Aug 11, 2013 at 2:14 AM, Amy Stephen <amyst...@gmail.com
> <mailto:amyst...@gmail.com>> wrote:
>
> Cool, easier still =)
>
> If I understand correctly, then, use the links below to test Issue 1.
>
> There are a couple of tests on 3.1 - patch up on 8-6
>
> The most recent patch was for 2.5 - patch up on 8-10
>
> All three issues are addressed in the one patch.
>
> Not a PLT thing, just a regular patch which requires community
> testers.
>
> Thanks Hannes.
>
> Hello Amy,
> thx for the summary. Regarding the other issues, I put the
> fixes for the last two tracker items into the PRs for the
> first tracker item, since they depend on one another. We can
> actually close the last two as being solved by the first. I
> will comment accordingly in the items.
>
> Hannes
>
>
>

> On Sat, Aug 10, 2013 <tel:2013> at 2:40 PM, Amy Stephen
> <amyst...@gmail.com <mailto:amyst...@gmail.com>> wrote:
>
>
> *Issue #1 *

>
> Fixing HelperRoute Classes - generate wrong URLs due to
> selection of an incorrect Itemid. This error came from changes
> to ContentHelperRoute::getCategoryRoute() where the category
> path lookup was removed.
>
> http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8103&tracker_item_id=31107
>
> Initially, testers had problems reproducing - Hannes provided
> updated testing scenarios and the issue was confirmed
>

> 8-6-2013 Hannes provided a patch *for 3.1*

>
> Adam Rifat test on 8-6
> Richard McDaniel test on 8-7
>

> 8-10 PR from Hannes *for 2.5*

> https://github.com/joomla/joomla-cms/pull/1708 Needs Testers
>
> No testers yet
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

> To post to this group, send an email to
> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

[Ofer Cohen]

Hey Hannes,

Thanks for your response.

Could you please share the github branch?

Thanks,

Ofer Cohen

BillRun.net

[Hannes Papenberg]

https://github.com/Hackwar/joomla-cms/tree/hackwar_routing

Am 26.08.2013 09:47, schrieb Ofer Cohen:
> Hey Hannes,
> Thanks for your response.
> Could you please share the github branch?
>
> Thanks,
>

> /
> /
> /Ofer Cohen/
> /BillRun.net <http://Billrun.net>/

>
>
> On Sun, Aug 25, 2013 at 10:13 PM, Hannes Papenberg
> <hack...@googlemail.com <mailto:hack...@googlemail.com>> wrote:
>
> Hi Ofer,
> I have lots of code, but its all a bit dated and needs to be
> updated for
> Joomla 3.x. Unfortunately I don't have a lot of time and unless I
> find a
> day to spare in the coming week, I wont be able to invest any more
> time
> into this before the second half of september. Most of my code is out
> there on github, so if you are interested, you can pick it up and
> fix it
> to work properly in 3.x.
>
> Hannes
>
> Am 24.08.2013 16:01, schrieb Ofer Cohen:
> > @Hannes, do you have fix or plugin to remove ids from urls?
> >
> > Thanks,
> >
> > /
> > /
> > /Ofer Cohen/
> > /BillRun.net <http://BillRun.net>/
> >

> > On Sun, Aug 11, 2013 <tel:2013> at 2:14 AM, Amy Stephen
> <amyst...@gmail.com <mailto:amyst...@gmail.com>

> > <mailto:amyst...@gmail.com <mailto:amyst...@gmail.com>>> wrote:
> >
> > Cool, easier still =)
> >
> > If I understand correctly, then, use the links below to test
> Issue 1.
> >
> > There are a couple of tests on 3.1 - patch up on 8-6
> >
> > The most recent patch was for 2.5 - patch up on 8-10
> >
> > All three issues are addressed in the one patch.
> >
> > Not a PLT thing, just a regular patch which requires community
> > testers.
> >
> > Thanks Hannes.
> >
> > Hello Amy,
> > thx for the summary. Regarding the other issues, I put the
> > fixes for the last two tracker items into the PRs for the
> > first tracker item, since they depend on one another. We can
> > actually close the last two as being solved by the first. I
> > will comment accordingly in the items.
> >
> > Hannes
> >
> >
> >

> > On Sat, Aug 10, 2013 <tel:2013> <tel:2013 <tel:2013>> at

> 2:40 PM, Amy Stephen
> > <amyst...@gmail.com <mailto:amyst...@gmail.com>

> > <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com
> <mailto:joomla-dev-cms%252Buns...@googlegroups.com>>.

> > To post to this group, send an email to
> > joomla-...@googlegroups.com
> <mailto:joomla-...@googlegroups.com>

> > <mailto:joomla-...@googlegroups.com

[Ofer Cohen]

Hannes, thanks for sharing. I'll look on this and give you feedback.

Ofer Cohen

BillRun.net

[Theo Basios]

Hello there.

Do we have any news about this important chapter of Joomla ?
I see there was a commit : https://github.com/joomla/joomla-cms/pull/1560#issuecomment-25150811

Any other progress or the project abandoned ?!

Thanks

[Hannes Papenberg]

Indeed, the first bug was fixed. I'm currently hesitant to fix the other bug,since it means a rewrite of the core routers and I'd rather invest my time into the new routing system. I've been working a bit on that stuff in my personal repo in the last few days and will provide new code in the coming days.

Hannes

--

[Theo Basios]

Hey Hannes

Thanks for the quick reply !
Its good news that finally someone is trying to improve that very important chapter of Joomla.
Just hoping that would be ready for the 3.2 release which announced will be out at November but I guess it needs a lot more time as a core changes thing .

Jooomla NEEDS real SEF system not extra components !!

Keep Walking my friend !!  ;)

Thanks

[Ofer Cohen]

Hey Hannes,

I must say that your work is great and I really happy that your fix the routing bugs, because those issues critical to our product.

Thanks,

Ofer Cohen

http://embad.com 
Facebook | Twitter | LinkedIn

[Hannes Papenberg]

Quick update!
In order to get some improvements in this area, I decided to split my
proposal apart and to make it into more chewable size. So here is the
first small improvement that is 100% b/c:
https://github.com/joomla/joomla-cms/pull/2487

Please test and approve. ;-)

Hannes

Am 04.10.2013 09:50, schrieb Theo Basios:
> *Hey Hannes*
>
> *Thanks* for the quick reply !

> Its good news that finally someone is trying to improve that very
> important chapter of Joomla.
> Just hoping that would be ready for the 3.2 release which announced
> will be out at November but I guess it needs a lot more time as a core
> changes thing .
>

> _Jooomla NEEDS real SEF system not extra components !!_
>
> *Keep Walking* my friend !! ;)
>
> Thanks

[Hannes Papenberg]

Hi folks,
another little update: Here is the change to have class based routers:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=32736&start=0
https://github.com/joomla/joomla-cms/pull/2538

Hannes

Am 04.10.2013 09:50, schrieb Theo Basios:
> *Hey Hannes*
>

> *Thanks* for the quick reply !

> Its good news that finally someone is trying to improve that very
> important chapter of Joomla.
> Just hoping that would be ready for the 3.2 release which announced
> will be out at November but I guess it needs a lot more time as a core
> changes thing .
>

> _Jooomla NEEDS real SEF system not extra components !!_
>
> *Keep Walking* my friend !! ;)
>
> Thanks

[Theo Basios]

Hello Hannes

I m so glad that you still working in this very serious chapter of Joomla.
Sending you my positive energy !!

I hope developers and devs of Joomla involves in your try !!

Thanks

[Theo Basios]

Joomla Routing is a very serious chapter and we have to make it work.
I hope Hannes you will try to finish this big work.

WordPress has a better SEF as I m reading in several compare tests.

So as a good CMS we have to work on the things we are behind. And Joomla routing is a very serious one.

Lets make Joomla powerful !

Thanks
Theo