ARGH! the jooma router strikes back!

[Cyril Thibout]

Hi

We love Joomla... but much less its router :( 

Actually the main problem we have with Joomla is its router and its sef management. Joomla only builds its sef routes upon the menu items.

It would be ok IF it would consider any kinds of menu items BUT it only knows the native Joomla menu items!

Any sef routes is buit according to menu items Joomla knows:

- direct link to the article

- list / blog of articles of the same category

but the router ignores any menu path outside these elements. 

Drupal doesn't have this problem. Why does Joomla keep this legacy that makes not ugly routes but also set the viewer in the wrong page (wrong breadcrumb)

 if it can't find the kind of menuitems it was lookinf for ?

 

I'm very surprised that no 3.x version comes with a totally reworked router but maybe there is ?

thanks

cyril

[George Wilson]

We've started. But there aren't enough people willing to work on such a complex feature - especially when the backlash happens when with such a complex feature some minor b/c thing gets left in somewhere. Look at the new JComponentRouterInterface shipping in Joomla 3.3 also co-ordinate with Hannes who has been working tirelessly on this if you're interested.

Kind Regards,

George

[Hannes Papenberg]

Hello Cyril,
I'm very happy that we were able to implement at least some small
improvements in 3.3.0 and prepare Joomla in that area for the future. As
I wrote several times before, I have more code and more ideas for the
routing, which make the whole system more flexible and easier to develop
for by extension developers.

Lots of code has already been written and lots of time has already been
invested into this. Unfortunately my time available for something like
this currently is very limited and I tend to use that little that I have
to rather work through the bug tracker than to code on such new
features. I would happily invest more time into this, but I have to pay
my bills, too, and so I have to prioritize my paid work higher.

All that said, I would be very happy if a few companies could join their
forces on this and finance the further development of this feature. I
know of two companies/persons that are willing to support me financially
for about 5 hours of work already. I guess that the basic
rewrite/improvement would take about 30-40 hours. Everything that goes
beyond that would go into more features, like menu-less routing, etc.

So if you are interested in supporting this, feel free to contact me.

Thank you and regards,
Hannes

> --
> 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-cm...@googlegroups.com>.
> To post to this group, send 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/d/optout.

[Cyril Thibout]

Hi

I sent you an email about this but I MAKE HERE AN OFFICIAL CALL for any company / people who wants to get the joomla router gets redone with much less menu-dependency to join our forces and support the developpers (Hannes and any other willing developper).

This is maybe one of the the weakest point in the Joomla architecture that prevents from bigger developpements. I know many companies are about to switch to other solutions (if they haven't already done it) because of this legacy menu dependency architecture.

Thanks

cyril

[Beat]

Hi Cyril,

I'm happy to co-support this important effort, but only if there is a clear process and road-map for success in place: That means that there is:

1. a will from decision makers to go that route,
2. a specification of the feature and a design of software architecture
   
3. that those are submitted to community feedback and approved by the decision makers (PLT and whoever else has a say)
4. with a commitment from decision-makers to merge the result IF it corresponds to a) specifications and implementation architecture, b) Joomla code-style and c) Joomla code-quality standards.

That process was attempted with partial success last year for some of the new features for Joomla 3.2.0, and from the lessons learned personally (I almost got a burnout as a dedicated free volunteer!) I would be insisting on those points before co-supporting the effort, to save the mental health of participating developers as well as to have a chance that the money we poor into that doesn't get lost at delivery. Another idea: To show project co-commitment and to improve that chance, how about OSM pairing with us and topping same amount of the very reasonable development costs of this important feature ?

Best Regards,
Beat
http://www.joomlapolis.com/

[brian teeman]

Personally (and with the new release strategy) I would make b/c a prerequisite. Otherwise you will be writing code that might not see the light for a very long time

[Hannes Papenberg]

Hi Brian,
hi Beat,
of course B/C is a given. Wouldn't want to do it any other way. ;-)

Regarding the points by Beat: I doubt that we will get an official
ruling with letter and seal from anything in the project. I've been on
this topic for several years now and couldn't get such a commitment. The
rest is already required by the normal Joomla contribution requirements.
The specs and features and even the code is already out there for
several years. It is not something brand new that surprises everybody.

Long story short: I doubt that the project will give us an official
ruling and the only thing that anybody can reliably promise is, that the
code gets written and the contribution process is adhered to. Everything
else is not something that I could guarantee the contributors to this.

But considering that we have made a step forward in 3.3.0, I don't think
the PLT is going to stop reasonable and good progress.

Hannes

Am 16.04.2014 12:43, schrieb brian teeman:
> Personally (and with the new release strategy) I would make b/c a
> prerequisite. Otherwise you will be writing code that might not see
> the light for a very long time
>
> On Wednesday, 16 April 2014 10:19:09 UTC+1, Beat wrote:
>
> Hi Cyril,
>
> I'm happy to co-support this important effort, but only if there
> is a clear process and road-map for success in place: That means
> that there is:
>

> 1. a will from decision makers to go that route,
> 2. a specification of the feature and a design of software
> architecture
> 3. that those are submitted to community feedback and approved by

> the decision makers (PLT and whoever else has a say)

> 4. with a commitment from decision-makers to merge the result IF

[George Wilson]

I agree with Brian but I also think that any current urls would have to continue existing with any new architecture. People into the future will expect their links to keep working as they did before (even if it's not as good as the new system)

I have no real problems with beats prerequisites but I think as well we should try and give more emphasis to the technical report procedure. Let's be honest the issue with the installer from web last year was that half the relevant people didn't read the report properly or at all (I know it was on this list - but there's a lot on this list :p) so we should probably agree a format for these major feature submissions.

I'm not particular in favour of OSM covering developing costs for features. If that were to happen I'd rather just see a new permanent employee in place. I think Chris' kick starter efforts last year anyhow showed it's not particularly a popular endeavour to have funding for these big projects. Either way this is a discussion for another issue. I think we assume as is with no funding (except for maybe a code sprint).

Kind Regards,

George

--
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/pCAPIs980kk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.

[Cyril Thibout]

Hi 

I'm very happy to see this initiative may get some support. Frankly the router is in very bad shape and a real obstacle for many bigger projects. 

How is it possible that years after the finder got developped it still can't make its sef urls correct unless the article/content doesn't have a 'list of articles from a category' menu link ??

We should look at what Drupal guys did with their router. We spent hours/days in almost any joomla project fighting with this restrictive menu driven architecture.

My company (with others) could support the effort of some developpers in this task but it should be a real project, not necesarily driven by OSM, but with clear objectives. I don't believe the PLT would not accept such an improvement of our CMS since it will bring a real benefit to the community.

According to me these objectives could be :

• make joomla less menu sensitive. 
• allow some third party plugins be added to the finder so that the results sef urls are correct even with no native joomla menu items
• allow third party component to build sef routes to contents again even if there is no native joomla menu on them (for example in JCE make a link to another article that has no native joomla menu on it). 
• if the content is accessible from different menu items there should be only one sef urls for Joomla (not only for google). We should not care where we came from (as Drupal does)

Thanks

cyril

[Hannes Papenberg]

Hi folks,
with quite a bit of positive feedback, I thought I might create some
means to get this project rolling and started an Indiegogo campaign:
https://www.indiegogo.com/projects/advance-the-joomla-url-router/piad

You can contribute to this development endeavour and even get something
in return. ;-) I would be very happy if you could spread the word about
this one.

If you have any questions, feel free to ask here or in the project. I
will try to answer asap.

Regards,
Hannes

Am 16.04.2014 15:22, schrieb Cyril Thibout:
> Hi
>
> I'm very happy to see this initiative may get some support. Frankly
> the router is in very bad shape and a real obstacle for many bigger
> projects.
>
> How is it possible that years after the finder got developped it still
> can't make its sef urls correct unless the article/content doesn't
> have a 'list of articles from a category' menu link ??
>
> We should look at what Drupal guys did with their router. We spent
> hours/days in almost any joomla project fighting with this restrictive
> menu driven architecture.
>
> My company (with others) could support the effort of some developpers
> in this task but it should be a real project, not necesarily driven by
> OSM, but with clear objectives. I don't believe the PLT would not
> accept such an improvement of our CMS since it will bring a real
> benefit to the community.
>
> According to me these objectives could be :
>

> * make joomla less menu sensitive.
> * allow some third party plugins be added to the finder so that the

> results sef urls are correct even with no native joomla menu items

> * allow third party component to build sef routes to contents again

> even if there is no native joomla menu on them (for example in JCE
> make a link to another article that has no native joomla menu on it).

> * if the content is accessible from different menu items there

> should be only one sef urls for Joomla (not only for google). We
> should not care where we came from (as Drupal does)
>
>
> Thanks
>
> cyril
>
>
>
>
>
>
>
>
>

> --
> 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-cm...@googlegroups.com>.

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

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

[Dimitris]

I like and support the idea.

[Johan Janssens]

Cyril,

The router in Joomla can definitely be improved. Unsure though bold statements like : 'the router is in very had shape and a real obstacle' are the best start of productive improvements.

A little bit of context :

- Joomla's menu system uses a composite architecture. A menu item links to an entity or a collection of entities using a 'has a' relationship. Pattern wise Joomla uses composition driven menu architecture.

- Drupal's menu system uses an 'is a' relationship, where each menu item is an entity and is represented by a node id. Pattern wise Drupal uses an inheritance driven menu architecture.

- In the very early days of Mambo a menu system didn't even exist. There was a hardcoded menu had one level and was just a list of links. In Mambo 4.5.1 or 2 (unsure) the menu manager was added to the core allowing the add different menu's and manage menu items for each. At the same time the Itemid was also introduced. (Note : I wrote one of the very early menu managers for Mambo before the core had this concept). 

- The composite approach that Joomla follows for menu management has both it's advantages and disadvantages. One of the advantages is that is very easy to fit anything in the menu system; at the same time this also one of the major disadvantages.

- Changing the composite based menu system and thus the way routing works is possible but requires a complete re-architecture of Joomla. The menu system defines how components are integrated into Joomla. Changing this, means changing the core of Joomla.

About your suggestions. 

- Making Joomla less menu aka Itemid centered - while possible - would mean changing the complete architecture. One of the requirements of the composite approach is that a Itemid and thus menu item needs to be present for routing to be possible. 

- Allow to build routes to content even if there is no menu item, while possible creates all sorts of unwanted side effects we worked hard to solve in the past few years. The menu item and Itemid defines : access level, template, component options, page title, etc. If you take the Itemid away you will break the security model, the template system, ... etc. 

I'm very happy with the OO changes that Hannes has introduced in Joomla 3.3. Hannes has been working on routing for almost a decade, we had many discussions and arguments in the past on routing and I'm most happy to see the 100% BC change he has introduced. 

I understand that for bigger and more custom projects routing and the composite menu structure might not be ideal. For those projects there are more advanced PHP frameworks like Zend, Symfony etc that provide more flexible routing architectures.  Maybe your problem is not so much Joomla being in bad shape but your project being out of scope for Joomla ?

Hope that helps,

Johan

[G.D. Speer]

Is this about the rewritten router in the current Beta?  Are you having issues testing it or are you just moaning about the old router?

----- Original Message -----

From: Johan Janssens

To: joomla-...@googlegroups.com

Sent: Tuesday, April 22, 2014 4:18 PM

Subject: [jcms] Re: ARGH! the jooma router strikes back!

Cyril,

The router in Joomla can definitely be improved. Not sure though bold statements like : 'the router is in very had shape and a real obstacle' are the best start of a productive solution.

Lets try to put things in context a little bit :

- Joomla's menu system uses a composite architecture. A menu item links to an entity or a collection of entities using a 'has a' relationship. This is called composition.

- Drupal's menu system uses an 'is a' relationship, where each menu item is an entity and is represented by a node id. This is called inheritance. 

- In the very early days of Mambo a menu system didn't even exist. There was a hardcoded menu had one level and was just a list of links. In Mambo 4.5.1 or 2 (unsure) the menu manager was added to the core allowing the add different menu's and manage menu items for each. At the same time the Itemid was also introduced. 

Note : I wrote one of the very early menu managers for Mambo before the core had this concept. 

- The composite approach that Joomla follows for menu management is has both it's advantages and disadvantages. One of the advantages is that is very easy to fit anything in the menu system; at the same time this is a disadvantages in certain contexts.

About your suggestions :

1. Make Jooml

On Wednesday, April 16, 2014 3:22:42 PM UTC+2, Cyril Thibout wrote:

--
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 email to joomla-...@googlegroups.com.

[Beat]

Hi Hannes,

Congratulations for your initiative and for the great success during the first hours of your campaign. :-)

I haven't yet done my usual due diligence on your campaign that I would like to support subject to due diligence results, but I have 2 preliminary questions:

1. Do you have an URL for diffing your branch to the relative master version at https://github.com/Hackwar/joomla-cms/tree/jrouter ?

2. And a preliminary questions to current PLT members and J! merge decision makers (that obviously follow this user group):
Do you support Hannes' effort, and have comments on his proposed code ?

Obviously my suggested requirements a few posts back are still overboard for the way Joomla works :-) but some personal comments from indivual members would sure help in the due diligence process and Hannes' campaign.

Best Regards,
Beat
http://www.joomlapolis.com/

> <mailto:joomla-dev-cms+unsub...@googlegroups.com>.

[Hannes Papenberg]

Hello Beat,
regarding your first question: No, I don't have a way to diff it against
the current master branch. What can be found in that branch is rather
like a proof of concept and while I will use the concepts in that
branch, the code needs to be refactored.

Regarding #2: As you know, there is no official ruling from the PLT
regarding this and we wont get one, but considering that at least 2 PLT
members are among those that contributed to the campaign so far, I think
it is pretty safe to say that they look at this favourably. :-)

Hannes

Am 23.04.2014 11:54, schrieb Beat:
>
> Hi Hannes,
>
> Congratulations for your initiative and for the great success during
> the first hours of your campaign. :-)
>
> I haven't yet done my usual due diligence on your campaign that I
> would like to support subject to due diligence results, but I have 2
> preliminary questions:
>
> 1. Do you have an URL for diffing your branch to the relative master
> version at https://github.com/Hackwar/joomla-cms/tree/jrouter ?
>
> 2. And a preliminary questions to current PLT members and J! merge
> decision makers (that obviously follow this user group):
> Do you support Hannes' effort, and have comments on his proposed code ?
>
> Obviously my suggested requirements a few posts back are still
> overboard for the way Joomla works :-) but some personal comments from
> indivual members would sure help in the due diligence process and
> Hannes' campaign.
>
> Best Regards,
> Beat
> http://www.joomlapolis.com/
>
>
>
> On Tuesday, April 22, 2014 9:08:23 AM UTC+2, Hannes Papenberg wrote:
>
> Hi folks,
> with quite a bit of positive feedback, I thought I might create some
> means to get this project rolling and started an Indiegogo campaign:
> https://www.indiegogo.com/projects/advance-the-joomla-url-router/piad

> <https://www.google.com/url?q=https%3A%2F%2Fwww.indiegogo.com%2Fprojects%2Fadvance-the-joomla-url-router%2Fpiad&sa=D&sntz=1&usg=AFQjCNGDKGPyToubKfTRWVfXgSFsT_p8SA>

> > an email to joomla-dev-cm...@googlegroups.com <javascript:>
> > <mailto:joomla-dev-cm...@googlegroups.com <javascript:>>.

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

> <javascript:>
> > <mailto: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/d/optout

> <https://groups.google.com/d/optout>.
>

[Beat]

Hi Hannes,

Great news for #2. I'm now not asking for PLT decision as that would take much longer than your campaign LOL, but for individual personal opinions :) and fact that 2 already contributing individually to the campaign is a great sign :-) hope there will be more! (e.g. a majority of PLT members, LOL) ;-)

I think github allows to compare any commit to any other one. It's just a matter to find from which exact commit you forked ;-)

Best Regards,
Beat
http://www.joomlapolis.com/

>     > <mailto:joomla-dev-cms+unsub...@googlegroups.com <javascript:>>.

[Michael Babker]

Answering your first question:

https://github.com/Hackwar/joomla-cms/compare/jrouter will give you a visual diff (when you've selected a branch on GitHub, you can change the "tree" part of the URL to "compare" if you're still at the repo root; they don't show the compare button at all times and the only way I know to simulate it is to go through the steps to open a PR).

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 email to joomla-...@googlegroups.com.

[Bakual]

I can only speak for myself. I think the same rules apply for this as to any other PR out there.

1. Don't break anything
2. Do a proper implementation
3. Follow codestyle
4. Get enough testers

In the case of routing, I think especially the first part is crucial. It doesn't matter much if the created URLs are the same as before, but it matters a lot when existing URLs (Google, other sites, ...) suddenly generate a 404 error. Any proposal has to make sure it will not break existing URLs. As crappy as they may be, they still have to work. 404 errors will hurt SEO more than any amount of duplicate URL we may generate :)

Best would be if they are automatically redirected to the correct URL with the proper status codes, so Google knows what happens and can adjust their links.

The problem with the existing PRs related to routing was usually that they didn't get tested well. Everybody seems to like better URLs, but nobody invests time to test these changes.

If nothing breaks, code is well written and follows good architecture and the PRs are getting tested, then I don't see why we shouldn't merge it.

[Cyril Thibout]

Hi

I'm very happy to see my suggestion may help everyone. I'm not a real Joomla developper but a company manager who invested on Joomla for years and see its router as a weak element in the whole picture.

• The finder, for example, can only build right sef urls on its results with native menu items (either a direct link to the article or a 'lsit of articles of a category' link). If our contents don't have such menu items the finder builds wrong sef urls.

• With JCE, another example, if you try to add a link from an article to another article that doesn't have a native Joomla menu item, the SEF urls is wrong again

These two simple examples show that outside the native joomla menu item type, the router is lost. We hope we can have a new router that will fix these issues.

We now build all our project with joomla + seblod which gives us a very stable platform but the router issues always get in the way. Most of our seblod contents (which are real native joomla articles + new fields) don't have native joomla menu items but seblod menu links that are fully ignored by the router.

If the new router could allow us to make it seblod menu items aware, that would be perfect.

cyril

[Peter Lose]

Hi Hannes

Great initiative! I have some questions regarding your proposed solution. Will it solve the current issues with the large number of duplicated URL's? I can't really deduce that from your proposal.

Will it cater for some of the other URL SEO related issues? For instance trailing slashes and uppercase vs. lowercase

Kind regards

Peter

> <mailto:joomla-dev-cms+unsub...@googlegroups.com>.

[Hannes Papenberg]

Hi Peter,
yes and no. One of the big goals is preventing false 200 responses, so
actually throwing a 404 when the URL is wrong (think of
domain.tld/menu-item/42-the-truth-is-o instead of
domain.tld/menu-item/42-the-truth-is-out-there) and it will solve some
of the issues with duplicate URLs. I can't guarantee 100% success, but
maybe 90%. ;-)

It will also solve some of the other SEO issues, yes. The main focus
right next to the above mentioned 200/404 problem however is to clean up
the current structure and make it maintainable and extendable for the
future.

Hannes

> > an email to joomla-dev-cm...@googlegroups.com <javascript:>
> > <mailto:joomla-dev-cm...@googlegroups.com <javascript:>>.

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

> <javascript:>
> > <mailto: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/d/optout

> <https://groups.google.com/d/optout>.
>

[Bakual]

Just commenting on this:

One of the big goals is preventing false 200 responses, so
actually throwing a 404 when the URL is wrong (think of
domain.tld/menu-item/42-the-truth-is-o instead of
domain.tld/menu-item/42-the-truth-is-out-there)

I disagree that it should throw a 404. It should generate a 30x (probably 301) redirect. Otherwise you risk breaking a lot of existing URLs.
And honestly, if we can redirect to the correct URL, why should we not do it?

[George Wilson]

I agree to an extent with Bakual. When people enter the wrong alias but still are redirected to the correct URL because they have the id of the item correct that SHOULD be a 404. Think now instead of making the text shorter i now make it

domain.tld/menu-item/42-f-ck-you

and I'm still sent to the item with id 42 :P and code wise there isn't any difference between the example Hannes showed and the example I'm giving there.

However if we make core changes to the structure/composition of the SEF URLs then yes we should have a 301 redirect to the new item for b/c for all sites

Kind Regards,

George

--
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/pCAPIs980kk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to joomla-dev-cm...@googlegroups.com.

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

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

[Hannes Papenberg]

The routing system is meant to be flexible in the future. So I'm going
to add rules that either act exactly like the current routing, throw
proper 404s or return 302s. That means that people can enable the
behavior that they want and in 4.0 we can remove the current routing and
the 302 rule. ;-)

Hannes

Am 24.04.2014 17:13, schrieb George Wilson:
> I agree to an extent with Bakual. When people enter the wrong alias
> but still are redirected to the correct URL because they have the id
> of the item correct that SHOULD be a 404. Think now instead of making
> the text shorter i now make it
>
> domain.tld/menu-item/42-f-ck-you
>
> and I'm still sent to the item with id 42 :P and code wise there isn't
> any difference between the example Hannes showed and the example I'm
> giving there.
>
> However if we make core changes to the structure/composition of the
> SEF URLs then yes we should have a 301 redirect to the new item for
> b/c for all sites
>
> Kind Regards,
> George
>
>
>
> On 24 April 2014 15:31, Bakual <werbe...@bakual.ch

> <mailto:werbe...@bakual.ch>> wrote:
>
> Just commenting on this:
>
> One of the big goals is preventing false 200 responses, so
> actually throwing a 404 when the URL is wrong (think of
> domain.tld/menu-item/42-the-truth-is-o instead of
> domain.tld/menu-item/42-the-truth-is-out-there)
>
>
> I disagree that it should throw a 404. It should generate a 30x
> (probably 301) redirect. Otherwise you risk breaking a lot of
> existing URLs.
> And honestly, if we can redirect to the correct URL, why should we
> not do it?
> --
> 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/pCAPIs980kk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email
> to joomla-dev-cm...@googlegroups.com

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

> To post to this group, send 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/d/optout.
>
>

> --
> 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-cm...@googlegroups.com>.

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

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

[Richard McDaniel]

I think that the 301/302 error codes should only be used when something has actually moved, because that's what the error codes mean.

[Bakual]

Technically, it has moved. Currently, "domain.tld/menu-item/42-f-ck-you" will work. There may be existing links to that page which are even indexed by Google. After the change the only valid URL may be "domain.tld/menu-item/42-proper-alias". One way would be to tell the visitor that this page doesn't exist and generate a 404. Or we can say the page is no longer found at "domain.tld/menu-item/42-f-ck-you", but we redirect you to the correct URL "domain.tld/menu-item/42-proper-alias", please update your link. Which is exactly what the status code 301 ("Moved Permanently") does. It's what Google recommends here: https://support.google.com/webmasters/answer/93633

[Richard McDaniel]

The point of a 30x redirect is to tell the client "yes that was once a valid link but now it's not, it's been moved to XYZ". These links with offensive titles were never valid. Note that I don't consider a valid link to be just anything that generates a 200 response. I mean a valid link according to what the webmaster actually intended.

[Bakual]

The offensive title was just an example to show that currently, the alias part just doesn't matter at all. It's just ignored. The same could also happen if the webmaster changes an existing alias.

But then, what is the point in showing a 404 to begin with? Breaking existing links should never be a goal as the user will be punished in the end. A 404 is last resort only.

[Marko Đedović]

Purity aside (not to debate whether 301 or 404 is technically proper), websites exist for users, and when user clicks on a link, they expect either to reach an existing page or if the page they wanted to open is somewhere else, to be redirected to it. I'm sure user would not care about any of our technicalities if we give them 404 when we know what is the page they want. 404 should be given to them only if the page they want to view is completely dead and nothing else makes sense, as that visitor will most likely be lost.

[Dimitris]

My point of view:

New router creates ONLY proper routes, urls. So new sites don't have to suffer from the old habits.

The way to handle the old bad urls, i think is better put on a plugin and give admin the option to select between the actual proper link with a 301, or render a 404 error.

Dimitris

[Matt Thomas]

On Fri, Apr 25, 2014 at 12:44 PM, Dimitris <d.gram...@gmail.com> wrote:

The way to handle the old bad urls, i think is better put on a plugin and give admin the option to select between the actual proper link with a 301, or render a 404 error.

+1

Best,

Matt Thomas

203.632.9322
http://betweenbrain.com/

[Hannes Papenberg]

Hi folks,
I just wanted to spread the exciting news, that we just reached the
initial goal for the Indiegogo campaign! So this is definitely going to
become reality!
https://www.indiegogo.com/projects/advance-the-joomla-url-router/x/7199684#activity

I'm very excited and thankfull. Thanks to everyone who contributed so
far and also to those that spread the word and made this possible. You
guys are awesome!

Regards,
Hannes

> --
> 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-cm...@googlegroups.com>.

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

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

[Dmitry Rekun aka b2z]

Great news! Now all eyes on you :)

Dmitry

[Grigor Mihov]

302 means that the page has been moved from that URL temporary. So Google will come back each day to check if has returned to that URL.
The proper code is 301.

>     <mailto:joomla-dev-cms+unsub...@googlegroups.com>.

>     To post to this group, send 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/d/optout.
>
>
> --
> 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+unsub...@googlegroups.com>.

[Peter Lose]

Hi Hannes

Any news on your progess? :)

> <mailto:joomla-dev-cms+unsub...@googlegroups.com>.

[Hannes Papenberg]

Hello Peter,
I've been working on the JRouter* classes and got those mostly done, but
I'm struggling with making this really backwards compatible. There are a
few things that make this problematic... Unfortunately I have some
further delays and thus I expect to be able to get the next PR up in
about 2 weeks. After that, the people with guinea pig level should get
their first look a week after that and if everything works out, 2 weeks
after that we have a plugin release. ;-)

Regarding adding this to Joomla itself: This also depends a bit on
people testing the PRs. The first PR did not really get any feedback up
till now and it would be pretty good if we could get that one accepted
first, before I add further PRs to this.

Regards,
Hannes

Am 08.07.2014 13:33, schrieb Peter Lose:
> Hi Hannes
>
> Any news on your progess? :)
>
>
> Den fredag den 25. april 2014 20.02.59 UTC+2 skrev Hannes Papenberg:
>
> Hi folks,
> I just wanted to spread the exciting news, that we just reached the
> initial goal for the Indiegogo campaign! So this is definitely
> going to
> become reality!
> https://www.indiegogo.com/projects/advance-the-joomla-url-router/x/7199684#activity
> <https://www.indiegogo.com/projects/advance-the-joomla-url-router/x/7199684#activity>
>
>
> I'm very excited and thankfull. Thanks to everyone who contributed so
> far and also to those that spread the word and made this possible.
> You
> guys are awesome!
>
> Regards,
> Hannes
>
> Am 25.04.2014 19:50, schrieb Matt Thomas:
> >
> > On Fri, Apr 25, 2014 at 12:44 PM, Dimitris <d.gram...@gmail.com

> <javascript:>

> > <mailto:d.gram...@gmail.com <javascript:>>> wrote:
> >
> >
> > The way to handle the old bad urls, i think is better put on a
> > plugin and give admin the option to select between the actual
> > proper link with a 301, or render a 404 error.
> >
> >
> > +1
> >
> > Best,
> >
> > Matt Thomas
> > 203.632.9322
> > http://betweenbrain.com/
> > --
> > 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 <javascript:>
> > <mailto:joomla-dev-cm...@googlegroups.com <javascript:>>.

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

> <javascript:>
> > <mailto: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/d/optout

> <https://groups.google.com/d/optout>.
>

[rolandd]

Hannes,

This Friday we have a PBF event here in Rotterdam. Let me know which PR and I will see if we can get people to test this.

Thanks.

[Peter Lose]

Hi Hannes

Sounds great! I'm looking forward to seeing your upcoming PR :)

>     > <mailto:joomla-dev-cms+unsub...@googlegroups.com <javascript:>>.

[Peter Lose]

Hi Rolandd

I think it's this one: https://github.com/joomla/joomla-cms/pull/3759 

[Bakual]

PRs dealing with Unit tests can't really be tested beside running the tests.
Unfortunately Travis reported errors with the tests, which usually isn't good.
Can you try rebasing the PR with current staging? We had some issues with Travis which are fixed with latest staging. If the PRs passes Travis and nobody has objections to it, I could merge it.

[George Wilson]

The only thing about Hannes PR is the changes to createURI. I looked through the code and tested and I'm pretty sure it's fine. But it probably could do with a second quick test so we can say we followed the rules to the letter.

Kind Regards,

George

--

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/pCAPIs980kk/unsubscribe.
To unsubscribe from this group and all its topics, 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.
For more options, visit https://groups.google.com/d/optout.

[Hannes Papenberg]

I've updated the PR to latest staging. Lets wait what Travis says. :-)

Hannes

[Peter Lose]

Travis seems happy :)

[Lapoux Sébastien]

Hi Hannes,

Hope you're well.

Please send us some feedback about https://www.indiegogo.com/projects/advance-the-joomla-url-router/x/7199684#activity.

It's normal that people who give this money are waiting some feedback and nothing during last 4 months is not very positive for a such first campaign in Joomla world.

Please give us a honest state of this project and the difficulty that you maybe meet to propose maybe some way to solve (or cancel this project)

Thanks a lot.

Sebastien.

[Leo Lammerink]

Sounds like a fair request with Euro 4,830 pocketed by Hannes with crowdfunding?

--
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 email to joomla-...@googlegroups.com.

[Allrude]

Its a fair request to here what the status is and what is holding it back, 

but its not fair to talk about te money, 

let say Hannes worked on it for 1 hour a day during the last 4 months, that gives him an hourly rate of 40 bucks

yeaaah he's really making the big bucks there.

its more importend that this crowd funding succeeds so that future projects will profit from this example.

so lets help Hannes were we can and help Joomla and ourselves, getting a better router and a better joomla.

So Hannes write what the status is and what you need to succeed 

 

Op woensdag 8 oktober 2014 23:53:47 UTC+2 schreef Leo Lammerink:

[Sergio Manzi]

This!

[Hannes Papenberg]

Hi folks,
I'm sorry for not getting back to you all earlier, both in regard to
updating more often with the project status and in regard to your
requests from the last 2 days. (I'm fighting with a flu right now...) I
will post new code and an update on the situation on monday. I hope it
is acceptable for you to wait until then.

Regards,
Hannes

Am 09.10.2014 um 13:31 schrieb Sergio Manzi:
> This!
>
> On 2014-10-09 13:07, Allrude wrote:
>> Its a fair request to here what the status is and what is holding it
>> back,
>>
>> but its not fair to talk about te money,
>>
>> let say Hannes worked on it for 1 hour a day during the last 4
>> months, that gives him an hourly rate of 40 bucks
>>
>> yeaaah he's really making the big bucks there.
>>
>> its more importend that this crowd funding succeeds so that future
>> projects will profit from this example.
>>
>> so lets help Hannes were we can and help Joomla and ourselves,
>> getting a better router and a better joomla.
>>
>> So Hannes write what the status is and what you need to succeed
>>
>>
>>
>> Op woensdag 8 oktober 2014 23:53:47 UTC+2 schreef Leo Lammerink:
>>
>> Sounds like a fair request with Euro 4,830 pocketed by Hannes
>> with crowdfunding?
>>
>> On Wed, Oct 8, 2014 at 12:09 PM, Lapoux Sébastien
>> <sebastie...@seblod.com <javascript:>> wrote:
>>
>> Hi Hannes,
>>
>> Hope you're well.
>> Please send us some feedback
>> about https://www.indiegogo.com/projects/advance-the-joomla-url-router/x/7199684#activity

>> <https://www.google.com/url?q=https%3A%2F%2Fwww.indiegogo.com%2Fprojects%2Fadvance-the-joomla-url-router%2Fx%2F7199684%23activity&sa=D&sntz=1&usg=AFQjCNHHINwC70PGFYwipg3VyzHr_S4GlA>.

>>
>> It's normal that people who give this money are waiting some
>> feedback and nothing during last 4 months is not very
>> positive for a such first campaign in Joomla world.
>>
>> Please give us a honest state of this project and the
>> difficulty that you maybe meet to propose maybe some way to
>> solve (or cancel this project)
>>
>> Thanks a lot.
>> Sebastien.
>> --
>> 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

>> <javascript:>.

>> To post to this group, send 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/d/optout

>> <https://groups.google.com/d/optout>.

>>
>>
>> --
>> 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-cm...@googlegroups.com>.

>> To post to this group, send 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/d/optout.
>
> --
> 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-cm...@googlegroups.com>.

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

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

[Sergio Manzi]

Any news for us, Hannes?

[Hannes Papenberg]

Hello Sergio,
here is the update:
http://joomlager.de/crowdfunding/8-backwards-compatibility-foils-the-plan

Regards,
Hannes

[Lapoux Sébastien]

Thanks for the honest update Hannes!

So it seems not easy/possible to see something really new on the router on Joomla 3.

Sebastien.

[dgt41]

Hannes I am a little bit confused here.

What is the current target?

id’s too hard to die?

custom rules?

If you have some time please elaborate and enlighten us all.

Thanks

Dimitris

[Johan Janssens]

Hi Hannes, 

Thanks for the update, especially looking forward to improvements in component routing. I still believe it is possible to solve the problem with the core routers while maintaining backwards compatibility.

I would like to invite you to our Nooku Jam on 29/30 of October to work on this. More info : http://www.nooku.org/nj14/ All the Timble guys will be there, that's a lot of Joomla brain power. I'm confident that we can work out a solution. 

And I still owe you a beer!

Johan

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/pCAPIs980kk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.

[Hannes Papenberg]

Hello Sebastien,
hello Dimitris,
I might have not been really clear: Basically the application router is
responsible for the menu part of the URL. You can get around that one
with some effort, so its not THAT bad that I can't fix this before
Joomla 4.0. It's just that there are some bugs in there that can't be
fixed in a backwards compatible way and the structure is horrible and
against good coding rules.

The component router is responsible for the IDs in the URL and some of
the strange behavior that you see in Joomla. (Being able to reach every
category and every article by specially crafted URLs from the homepage
for example.) That part will still be possible to improve in Joomla 3.x
and will provide a lot of simplifications, removing the IDs being one of
the options here.

Regards,
Hannes

[Hannes Papenberg]

Hi Johan,
thanks for the invite, but unfortunately I already have commitments at
that time. I will get you my current work regarding the application
router in a branch of my repo so that you can take a look at it. And we
will find some way to get a beer together. ;-)

Regards,
Hannes

> >>>> <sebastie...@seblod.com <mailto:sebastie...@seblod.com>

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

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

> <mailto: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/d/optout
> >>>> <https://groups.google.com/d/optout>.
> >>>>
> >>>>
> >>>> --
> >>>> 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>
> >>>> <mailto:joomla-dev-cm...@googlegroups.com
> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>>.

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

> >>>> <mailto: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/d/optout.
> >>> --
> >>> 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>
> >>> <mailto:joomla-dev-cm...@googlegroups.com
> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>>.

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

> >>> <mailto: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/d/optout.
>
> --
> 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/pCAPIs980kk/unsubscribe.
> To unsubscribe from this group and all its topics, 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

[Johan Janssens]

Great Hannes, happy to review the code and take a stab at the application level routing. Let me know if you have a repo up.

To unsubscribe from this group and all its topics, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.

[Lapoux Sébastien]

Thanks for details Hannes! 

In all cases it's very welcome to see any small improvement on this topic for our Joomla 3.

But hoping you will find a way with Johan to add all what you plan on Joomla 3 without waiting Joomla 4.

@Johan, thanks a lot for your participation!

Sebastien.

[Johan Janssens]

Thanks Sebastien, lets try :)

--

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/pCAPIs980kk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to joomla-dev-cm...@googlegroups.com.

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

[Sergio Manzi]

Thanks for the very honest update, Hannes.

I'll have to think it over...

My first two considerations (speaking freely and without having thought that much over it) are:

1. For me, from a practical point of view, getting rid of the articles/categories ID from the slug and having the slug to be just the alias would be a major improvement. Would this be considered a breach of BC? In a sense It probably is, as the URLs will be different and those already indexed by search engines will not be valid anymore. But there can be solutions for this: a) accept also the old-styled URLs either directly or through a 301 redirects, or, b) have the "new behavior" be a an option, turned off by default.
2. From a philosophical point of view,  in general and not only in this context, I'm asking myself if this BC commitment is not limiting Joomla evolution too much. I think we should find a compromise between BC and evolution...

Thanks again,

Sergio

[Chad Windnagle]

Hi Hannes

I'm curious about this as well. I wonder if there's a way for us to be forward compatible. What I mean is, is there a way those of us who are interested in the new routing can basically, intentionally and knowingly adopt a new application router now in the form of some sort of plugin, and thus be prepared for new component routing in Joomla 4.

My thinking is that we can basically prepare for the future with Joomla 3 now, those of us who are capable of doing so and we can give component developers a chance to adopt and build on the new application architecture. I kind of see this as a "reverse legacy mode" similar to Joomla 1.5. Thoughts?

Regards,
Chad Windnagle

--

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 email to joomla-...@googlegroups.com.

[Sergio Manzi]

Forward compatibility: a very good, intelligent and interesting point of view!

+1000

[Matt Thomas]

Would love to see this as well.

Best,

Matt Thomas

203.632.9322
http://betweenbrain.com/

[Johan Janssens]

Guys, 

Why is it that if a difficult problem or decision comes up on this mailing list the same two solutions are always suggested :

1. Add a setting

2. Drop backwards compatibility 

Both solutions are anti-patterns and lead to kludges (or kluges as defines by Eric Raymond) It feels to me that over the years Joomla developers have become masters of kludgemanship. 

1. Settings

Adding settings leads to configuration hell. Looking at Joomla 3.x it feels very much like looking at what would have been Mambo 4.5.3. There are settings for everything and anything. Users have no clue about most of them and they don't even use most of them. Even many seasoned Joomla developers don't know what all the settings in Joomla are for.

To quote Albert Einstein : "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."

2. Compatibility

Dropping compatibility just because you cannot solve a particular problem is merely showing you don't understand the problem well enough. 

To quote Albert Einstein :  “If I had an hour to solve a problem I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”

What is see happening on this list too frequently is people proposing solutions without even having a clue about the complexities involved, or even having looked or studied the problem. 

About the problem : routing

A couple of points on routers to put things in perspective :

1. The problem to solve with routing is not 'remove ID's from the URL'. Removing of ID's from the URL is component specific and not an architecture concern.

Also, removing ID's from the URL (in content) has no benefit what so ever besides solving a wrong perception that it would improve something. I still need to meet the first person who can tell me what that something is and can demonstrate that objectively. It's time the Joomla community debunks the 'ID's are bad' myth. We have dragged this on for long enough now.

2. Removing the ID to use alias based lookups is more complex. To be able to use aliases you need to ensure aliases are unique. This isn't always wanted or ideal, also, if the alias changes the URL will change and thus an additional 301 redirect mechanism needs to be added adding additional complexity. 

The basic framework implementation of a router should offer simplicity not complexity. The complexity is left to individual components. Core routers should also be build for simplicity as they acted as examples for developers on how to do things. In this respect using alias lookups adds complexity which if it cannot be made simple enough should be avoided for core routers.

3. ID's are very useful to make routing simply and easy. An ID is a permanent piece of data that can unique identify a resource. Because it doesn't change, it's the perfect way to do a direct lookups (in the database). ID's allow for simple routing and very fast lookups. 

4. ID's especially GUID are the cornerstone of the modern internet. GUID are used by any web services to uniquely identify a resource. GUID where used already in RSS 1.0. To move forward Joomla needs more (GU)ID's and API's that are (GU)ID aware. Not less.

5. Routing is not a user problem, its not about SEF, SEO or 'remove ID's from the URL'. Routing simply is a mechanism to translate the request information into a common interface that developers can work with. Routing doesn't involve only the URL it involves the whole request. 

6. The problem to solve is a developer problem : make routing and router implementations easier for developers. The core component routers today are overly complex, with implementations going in 100's of lines of code. Routers offered in the Joomla core acted as examples for other developer, they should be simple and easy to understand. 

In short what I would like to see improved in Joomla 3.x

- Implement an OO API for component routers (already done in 3.3)

- Offer a default router implementation that uses best practices. 

- Clean up the core component routers and make implementation simpler.

- Implement component routing in the administrator

- Refactor application routing mechanism without compromising backwards compatibility

- Turn on SEF by default and remove the setting to turn it off.

Note : The last change is an important one. Joomla 1.5 introduced a SEF and no SEF mode to allow for full backwards compatibility. Today all components have routers, those who don't will still work even with SEF on. To make further improvements to routing the core first needs to adapt an everything is being routed approach. 

This way a lot of the logic can be removed from the application routers, the code becomes more lean and can be improved again from there. For extensions developers things also become simpler as they no longer need to test and build their routers and extensions to take a SEF and no  SEF modes into account. 

What I don't want to see changed in Joomla 3.x

- Removal of ID's in URL's. If you wanna do that use a SEF component. This is not the core's responsibility, nor does it solve any real problem. Its purely visual, with URL's not visible in mobile browsers and very likely being removed in desktop browsers in the near future this is a waste of development time.

- Removal of Itemid's. The mere suggestion you want these removed means you don't understand well enough how Joomla works. (See also my reply a bit earlier in this thread)

In short, routing is an application CoC (Cross cutting concern), it is nested deep inside the Joomla architecture on different levels. Problems like no Id's in a URL are merely variations of a routing approach chosen by a developer. Developers implement behaviour they don't define form. The form is defined by the core API's. Those API's and thus their form defines what the behaviour might look like.

Our task and problem to solve : define the form (API's) in a simple and extensible way to allow developers to implement any routing behaviour they require. 

Hannes has been working on routers long before most of you ever used Joomla. He knows the problem better then anyone. Hannes and myself have had technical arguments on them in the past (and we probably still do) but if anyone can improve routing in Joomla he can. I'm confident he will deliver. Lets give him the time and creative freedom to that.

Thanks!

Johan

--
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/pCAPIs980kk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to joomla-dev-cm...@googlegroups.com.

[Sergio Manzi]

Johan,

While I agree with some of your points (n.6 in particular), the charter of the crowdfunding campaign launched by Hannes at https://www.indiegogo.com/projects/advance-the-joomla-url-router/ (oops an URL... :-/ ) is the following one:

What are the problems?

The routing in Joomla has a few issues, namely for the end-user:

• Unnecessary IDs in the URLs
• Different URLs for the same content a.k.a. Duplicate Content
• Because of false URLs to some content, the wrong modules are loaded
• No choice in URL style

For the developers:

• Not object oriented, still pretty strictly procedural code
• A component router is extremely complicated to write
• The current code is pretty slow

To solve these problems, I also gave my (small) contribution and, therefore, these are the goals that I'd like to see implemented.

[Johan Janssens]

Correct. First 4 are about behaviour not form. Even if you wish to solve those you first need to solve the architectural issues  especially the flexibility and complexity problems as Hannes has pointed out.

With that said, I'm still happy to argue (and this is where Hannes and myself differ in opinion) that those are unnecessary changes that are not solving any real world problems. As I explained above : Id's are not bad, lets not try to fix what ain't broken.

1. Unnecessary ID's in URLs. 

You can probably take some of the ID's out. The cost will be additional complexity and the change is not solving any real world problems as explained above.

2. Different URL's for the same content aka duplicate content

This is not a routing issue. The problem lies in the way module links are generated and in the way links to articles are inserted in the editor.  Essentially, a module link and an article link need to be bound to a Itemid before the link is inserted, not after. Joomla now tries to guess the right Itemid and this fails in many cases.  

The fix for this lies in the module implementation and the article editor plugin implementation. Not the routing API or implementation.

3. Because of false URL's to some content, the wrong modules are loaded

Same problem and fix as above.

4. No choice in URL style

Choosing URL styles is no longer a requirement on the modern web. On mobile devices users don't see URL's and - as I pointed out - in future the same will happen on desktop. A url is a url. No need to be able to change it's style. 

Also, additional styles means additional settings, and additional testing. More documentation, more confusion, more complexity. 

If Hannes can solve the architectural problems nothing would prevent developers (and or Hannes) from solving the end user problems through an extension. Let just keep the complexity out of the core please.

Johan

[Dmitry Rekun aka b2z]

+1

Dmitry

[Mathew Lenning]

Only partially related but... I had a random thought regarding the modules issue while reading this earlier. Why not remove the module <-> menu item dependency? We could implement a module layout system that allowed one to assign modules to a layout. Then associate records using a param. We are already doing something similar with templates.

Would be so much simpler than trying to guess what menu item to use.

[Hannes Papenberg]

Hi Mathew,
so which layout would you use if there are only layouts for categories
and you are in an article or even worse, if there is no layout defined
for that page at all? Hint: You would have to guess the right layout.
What you are describing is exactly the system that we have right now.
Except if you are proposing to define its own layout for each and every
possible page in Joomla by hand, which I don't want to have.

The menu as a central part of navigation and configuration of Joomla is
a good solution and there is little wrong with that, except that our
routing currently is pretty broken and assigns wrong Itemids and wrong
content to Itemids. We could also improve our UI a bit to make it easier
for people. But regarding the Itemid, I wouldn't change that. And no,
node-based systems don't really help there either. They have their own
set of problems.

Regards,
Hannes

[Mathew Lenning]

Hannes, you wouldn't have to guess anything because the layout would be associated to the item not the menu.

If you are in a category then you use the layout associated with the category record. If your in a article you use the one associated with the article.

No guessing. If a layout isn't assigned then you don't show modules.

Of course like all params you could I use cascading, but that would be up to the developer.

Also since Joomla already loads the params there is nothing that has to change in the models. Just how we render the composite page and a new field type.

Currently when are modules rendered? Before/after component?

Sincerely,
Mathew Lenning

Babel-university.com

P.S. This message was sent via iPhone, so please forgive any errors

> --
> 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/pCAPIs980kk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to joomla-dev-cm...@googlegroups.com.

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

[brian teeman]

how about staying on topic

[Mathew Lenning]

Sounds good. When I get some time I'll experiment with this thought a little more. 

+1 for keeping this thread focused on router  .

Sincerely,

Mathew Lenning

Babel-university.com

P.S. This message was sent via iPhone, so please forgive any errors

On Oct 15, 2014, at 7:19 PM, brian teeman <joom...@googlemail.com> wrote:

how about staying on topic

[Sergio Manzi]

Sorry Dmitry, but exactly +1 to what?

His first statement (the "Correct" to my post) which implies it his right to expect what Hannes promised to deliver

or

the rest of his post which tries to explain why delivering that would be wrong?

[Sergio Manzi]

"his right" -> "is right"

[MonkeyT]

For the record, URLs may not matter for browsers or users anymore, but they still mean a helluva lot to search engines.  If we can't control the structure and content of the url, it becomes a huge handicap to winning the SEO war against competing websites.  When we've got a huge database of product labels which people actually use (UPC numbers, MLS Numbers, book titles, etc.) we WANT them in the URL and we need to be able to read them to construct DB searches - we can't take the time to create millions of menu items or aliases to get that data into the URL.  

Also, while browsers may not show you the URL, smartly designed sites still use them intelligently.  Look at php.net: it's a lot friendlier to be able to enter "php.net/substr" than to memorize the canonical URL for that command, and you can bet they haven't manually created an alias for every single command in the language.

Tim Stiles

[dgt41]

Thanks Hannes and Johan

nice explanations. I would like to state that Hannes already had written the option to remove IDs in 1.6. And is already in joomla 3.x.

Can I propose, to just bring this up to date and make this the default option for new installations (the old ones can keep the other urls so they won’t loose the ratings and their visitors)

There were a few contributions in this direction starting from here

What needs to get this done (at least for the core components):

• Correct all the components routers
  
• Make sure that once this new option is used the user CANNOT change the alias, as that will render the old url to a 404 page (maybe a plugin that injects disabled to the alias field, once is published?)

Can that be achieved or is way out of the picture?

[brian teeman]

Hannes took the money so he should deliver what he promised or give the money back. Sorry to be blunt but you know we are all thinking it you just dont want to be the one to say it

All community development and discussion about SEF, Routing and URLS stopped for the last 5 months because people were waiting for Hannes to provide the code that he promised and encouraged people to pay him for. 

So Hannes are you going to deliver something that does what you promised or not? If not then please say so that the Joomla community can get back to doing what it has done for the last 9 years and work together, freely sharing ideas, time and skills to produce a solution to a problem.

[Hannes Papenberg]

Hello Brian,
yes, of course I am going to deliver what I promised. Those people that
pledged money to the fundraiser will get a complete plugin with
everything that was promised in the campaign. What I can't deliver is,
as I said, the rewritten application router for Joomla 3.x, since that
would break backwards compatibility. I will of course provide that code
for Joomla 4.0.

Regards,
Hannes

Am 15.10.2014 um 19:09 schrieb brian teeman:
> Hannes took the money so he should deliver what he promised or give
> the money back. Sorry to be blunt but you know we are all thinking it
> you just dont want to be the one to say it
>
> All community development and discussion about SEF, Routing and URLS
> stopped for the last 5 months because people were waiting for Hannes
> to provide the code that he promised and encouraged people to pay him
> for.
>

> */_So Hannes are you going to deliver something that does what you
> promised or not?_/* If not then please say so that the Joomla

> community can get back to doing what it has done for the last 9 years
> and work together, freely sharing ideas, time and skills to produce a
> solution to a problem.

> --
> 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-cm...@googlegroups.com>.

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

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

[Leo Lammerink]

Hannes with all respect but you wrote very clearly that you have promised too much in your fund raiser request in http://joomlager.de/crowdfunding/8-backwards-compatibility-foils-the-plan and you wrote and I quote

" I promised full backwards compatibility, but this will not be possible for the application router and I'm sorry for promising too much"

That says it all I believe?

Leo Lammerink
MD GWS - Enterprise Ltd
Skype: gwsgroup
www.gws-desk.com | www.gws-host.com | www.gws-deals.today

[Hannes Papenberg]

Hello Leo,
there is a difference between the practical compatibility and the
theoretical compatibility. Practically, its backwards compatible. There
are VERY extreme corner cases where there might be issues, but that
would require the developer of the site where this breaks, to do stupid
things. "Unfortunately" Joomla wants to stay backwards compatible even
for those people and that means that I can't introduce this with good
faith. I could of course go ahead and simply weasel in my changes like a
change to pagination, password hashing or remember me plugin. Instead I
took a different route and wrote unittests to explicitely prevent such
regressions and between writing those unittests and the actual code, it
became clear that I can't write this in such a backwards compatible way
that it would pass the official rules of Joomla.

As I said in my response to Brian, I will provide this code for all
those that contributed to the campaign and they can decide if they want
to switch the new application router on or not. I will also provide the
code to Joomla so that it can be implemented when the next break in
backwards compatibility is allowed (=4.0)

Regards,
Hannes

Am 15.10.2014 um 19:38 schrieb Leo Lammerink:
> Hannes with all respect but you wrote very clearly that you have
> promised too much in your fund raiser request in
> http://joomlager.de/crowdfunding/8-backwards-compatibility-foils-the-plan
> and you wrote and I quote
>
> " I promised full backwards compatibility, but this will not be
> possible for the application router and I'm sorry for promising too much"
>
> That says it all I believe?
>
> Leo Lammerink
> MD GWS - Enterprise Ltd
> Skype: gwsgroup

> www.gws-desk.com <http://www.gws-desk.com> | www.gws-host.com
> <http://www.gws-host.com> | www.gws-deals.today <http://gws-deals.today>

[Johan Janssens]

@matthew : Please keep discussions on topic and please read what I wrote earlier. If you don't understand the problem study it first, ask questions, ... a lot of us here are most happy to explain 'why' things are as they are but please do that in a separate thread.

@sergio : The 'correct' was simply related to the fact that this is indeed what is Hannes wrote on Indiegogo. What Hannes intends to do with his Indiegogo campaign is up to him. I'm approaching the router question from a project and architecture perspective. 

Hannes his 'user' proposal involves fixes to individual core component routers. The problem I'm trying to solve is how we can improve routing for any component, both core and third party. 

@tim : You can control the structure and content of a URL. That is what routers are for. This works today, and has worked since Joomla 1.0. I'm merely pointing out the core shouldn't provide a way to set different URL styles through the UI by exposing settings to do this. This is out of scope, it's not an 80% problem, it's a 20% problem.

In your specific scenario : A huge database of product labels which people use (UPC numbers, MLS numbers, book titles etc ...) How many people have this problem ? Definitely not 8 out of 10. This problem needs to be solved through extendability, and that extendability is already present today. Actually has been there since Joomla 1.0.

About PHP.net. This has nothing to do with routing. How URL's and thus different resources relate is not the responsibility of the router or routing API. This is problem to be solved elsewhere. Specifically In Joomla this is for 'a large part' the responsibility of the menu manager. 

@dimitris : That's indeed correct. A sef_advanced_link parameter was added to some of the core routers. This setting isn't exposed in the component parameters and, when I tested it by changing it through the code it didn't work indeed. 

This is another great example of how it shouldn't be done. Why ?

-  This is yet another setting that has been introduced. Which increase complexity, documentation and makes testing harder. 

- This is a local solution not an architectural solution. In essence you are adding this specifically to each router, and not to the framework itself.

-  This increase the complexity of specific component routers, while it should be the opposite. 

Overal the code is a good example of code duplication which is an anti-pattern. The same setting is exposed for each router. Big no no!

To answer your question : can this be achieved ? Anything can be done. Should we do it ? Definitly not. Why ? Because it doesn't solve any real problem, or make things simpler to use. The only thing it does is make things more complex. 

@all : I'll repeat what I said above. 

Our task 

Improve the routing API's and Joomla architecture to be more simple and extensible to allow developers to implement any routing behaviour they require.

Any solutions that increase code complexity, add additional settings or focus on a 20% problem should not be considered.

Johan

[Sergio Manzi]

Hi Johan!

Regarding this:

On 2014-10-15 20:09, Johan Janssens wrote:

...

@sergio : The 'correct' was simply related to the fact that this is indeed what is Hannes wrote on Indiegogo. What Hannes intends to do with his Indiegogo campaign is up to him. I'm approaching the router question from a project and architecture perspective. 

...

I would like to remind you that this is exactly the topic of this thread. See OP:

On 2014-07-08 13:33, Peter Lose wrote:

Hi Hannes

Any news on your progess? :)

Den fredag den 25. april 2014 20.02.59 UTC+2 skrev Hannes Papenberg:

Hi folks,
I just wanted to spread the exciting news, that we just reached the
initial goal for the Indiegogo campaign! So this is definitely going to
become reality!
https://www.indiegogo.com/projects/advance-the-joomla-url-router/x/7199684#activity

I'm very excited and thankfull. Thanks to everyone who contributed so
far and also to those that spread the word and made this possible. You
guys are awesome!

Regards,
Hannes

So, any other theoretical discussion about the router, while *extremely* interesting and worth a whole new thread is, in my opinion, absolutely OT.

Regards,

Sergio

[Mathew Lenning]

@Johan, Thanks for the advice. I'm actually familiar with the "problem", but it has little to do with the topic of this thread or any other in this forum and more to do with "why" as a form of rationalization for illogical implementations. I get it. Everything has a reason, I just don't believe that all reasons are created equal. I don't want to take this thread off topic any further, so I'm starting a new one. I'm going to call it "Why do menu's link determine page structure?" and the conversation can go from there. 

For what it is worth, I agree 100% that our mission should be simple and extensible. But the topic of this thread is really about making promises, compensation, and unfulfilled expectations. So perhaps your take on the router situation should go in a different thread also. 

I won't respond in this tread again, so if you have any follow ups please post in the "Why do menu's link determine page structure?" thread. =^D Happy Joomla!ng

[Johan Janssens]

Hi Sergio,

The topic of this thread : "ARGH! the jooma router strikes back!" I don't see how any of my replies are off topic. 

I sympathise with the facted that you feel you are entitled to the changes promised by Hannes because you payed (funded) them. Calling someone else his reply off topic because he doesn't agree with what is proposed is not very respectful. 

There is also a dangerous undertone here. You are basically saying that the contributions of someone who is payed are worth more then those of someone who is not. 

I'm very proud to be able to say that in the 3 years that I worked on Joomla 1.5  I have never been payed by anyone for any of the thousands of hours I contributed. 

Respectfully,

Johan

[Sergio Manzi]

Hi Johan,

first of all I would like you to know that not for a second I had the will to offend you in any way.

Now...

ss far as regards the topic of this thread, I may have possibly been partially wrong, but there are good reasons and I would like you to explain:

• I registered to this Google Group this year, on April 30.
• The first post I've seen on this thread has been the one by Peter Lose (July, 8) asking news to Hannes about his ongoing crowdfunded project.
• Since then the thread had dealt mainly with this aspect, that is "How things are going Hannes?"
• I thus formed an opinion that *that* was the topic of the thread and thus I've seen your interventions as off topic and I've tried to keep the thread focused on what I *thought* was the *main issue*
• Apparently others too had the same feeling (but this is not that much important)
• In any case, as I told you (and mind-you: I'm always straight tongued), I *really* found your interventions interesting and therefore asked you to continue with them in a new thread.
• Now... I've gone to see on the Google Group web site, and... crap, there was a lot more on this thread before April 30 (my subscription date)!
• Therefore I've been mistaken: your post were ON topic, and, please, accept my apologies (ehmmm... I must also say that you could had pointed me to the relevant posts I missed too prove me wrong!)

So, no, I didn't called you off topic because your proposals didn't match with those by Hannes (for crying out loud, I never ever in my life had done something so idiotic!)

And I really don't understand from which of my statements you formed the opinion that I was "basically saying contributions of someone who is payed are worth more then those of someone who is not". Same story? Because you think I've called you OT because of a mismatch of opinions? HUGE double-sided misunderstanding, I would say! I hope you now understand that this wasn't the case...

In any case I also want to add (and yes, this is OT!) that there are several ways in which one can be payed-out for contributions to a project like Joomla,  e.g. because your code is functional to a project you are bringing on, be it an extension with witch you want to "go commercial" or a web site you are developing and for witch you need a new functionality. I thinks it is OK. Hannes has found a new way: crowdfunding. I don't see anything wrong with that too. I also think (but I may be wrong) that in a way or another many Joomla developers have their personal economical interest in it, and this "interested" code is surely not worth more than any hypothetically "not-for-profit" code, but it is neither less worth!

I hope all is clear now...

Sincerely and respectfully,

Sergio

--

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.

[Johan Janssens]

@Sergio : Apology accepted. Tip : In future don't tell someone he is OT without reading the whole thread on the Google Group.

-- First try to understand ,and then seek to be understood.

--
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/pCAPIs980kk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to joomla-dev-cm...@googlegroups.com.

[Sergio Manzi]

Thanks, appreciated, really.

Yes, you're right, I *should* had checked the whole thread *if* I didn't missed the fact the Peter Lose's post was not the the first of the thread. I did a mistake, but not a mortal sin, I guess.

Now, may I reflect your advice on you and ask you to not automatically imply, in the future, that someone is such a douchebag to call you OT because of different opinions and be offended by that? Maybe a personal message could had solved this issue long before...

-- First try to understand, and then seek to be understood.

[Cyril Thibout]

Hello Hannes

Can you please make a new update on this project ? This is something many people are waiting for ...

Thanks a lot

cyril

[Hannes Papenberg]

Hi Cyril,
I'm still waiting for people to test and maintainers to review my PRs
that are related to this. There are currently 2 PRs that need to be
accepted before I can go any further:
https://github.com/joomla/joomla-cms/pull/4848
https://github.com/joomla/joomla-cms/pull/4849
These changes are an integral part of the new router. I choose these
small PRs since they can be implemented independently and don't leave
the repository in an undefined/incomplete state. My later code is based
on these PRs and I could create further changes right now, but earlier
experience told me to keep the amount of change per PR to a reasonable
amount, because otherwise it is not testable and more specifically,
people will not test it. What I'm trying to say is, that I can't provide
the complete new router in one go, because nobody will be able to follow
those changes and that in the end was the reason why my 4 earlier
attempts at rewriting this before this crowdfunding campaign failed.

While I'm waiting for the tests and code reviews, I've also started
rewriting some other routing code in Joomla. You can see the latest
proposals here:
https://github.com/joomla/joomla-cms/pull/5104
https://github.com/joomla/joomla-cms/pull/5105
https://github.com/joomla/joomla-cms/pull/5107
https://github.com/joomla/joomla-cms/pull/5108
https://github.com/joomla/joomla-cms/pull/5124
https://github.com/joomla/joomla-cms/pull/5135
https://github.com/joomla/joomla-cms/pull/5140

All these PRs are a result of going through the current routing code and
preparing for the new router. Feel free to test any of these.

Regards,
Hannes

> --
> 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-cm...@googlegroups.com>.

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

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

[Hannes Papenberg]

Hello again,
just wanted to inform you, that the CMS maintainers had a busy day and
made me pretty happy by merging 5 of my PRs in the last 2 days, among
them the 2 main routing PRs that were blocking me right now. I will be
able to provide the next batch of changes in the coming week. :-) Thanks
to the maintainers for their hard work.

Regards,
Hannes

[Sergio Manzi]

Hannes, congrats for this major contribution to Joomla!

Sergio

[dgt41]

Personally I wanted to thank you not for the upcoming batch but for the patch: Optimizing JComponentHelper::getComponent. Great Performance Boost!

Keep up the good work

Dimitris

[Viktor Vogel]

Great, Hannes! Thank you for your contribution to the Joomla! project.

Regards
Viktor

>> <mailto:joomla-dev-cms+unsub...@googlegroups.com>.

[Cyril Thibout]

Hi Hannes

We are extremmely thankful for all the efforts you made. Does it mean Joomla 3.4 will include the new component routers please ?

And what about the "interim solution" for the Application router and Joomla 3.x ?

thanks again

cyril

[Hannes Papenberg]

Hi folks,
just a quick notice that I wrote an update regarding the router and the
crowdfunding here: http://joomlager.de/crowdfunding/9-it-lives-and-grows

Regards,
Hannes

> --
> 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-cm...@googlegroups.com>.

[Omar]

Excellent work on your progress Hannes. If you need me to help with testing, please let me know.

As a recap, speaking for myself and perhaps some others, being on dozens of forums and going through hundreds of emails, it's easy to get lost....

So, if you can kindly provide a quick "this is what I want you all do to...LINK HERE" I'll be happy to test.

Regards,
omar

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.

[Hannes Papenberg]

That is basically described in that link at the end of the post. ;-)

Hannes

[Sergio Manzi]

I want to publicly state that I think Hannes is doing a GREAT job with the new router and I don't regret even a cent of the (few) Euro I contributed.

I sincerely hope his work will be merged at the earliest opportunity.

Thanks, Hannes!

Sergio

[Hannes Papenberg]

Hi folks,
yet another quick update on the progress so far:
http://joomlager.de/crowdfunding/10-more-progress
Please support this by testing and reviewing the work. It can only
become great when as many brains as possible look over this.

Regards,
Hannes

[Johan Janssens]

Thanks Hannes, left my comments in the PR's. Things are shaping up nicely.

Johan

>> <mailto:joomla-dev-cms+unsub...@googlegroups.com>.