Joomla! Discussion Forums

Hi all,

Thanks for the feedback. I have made the following changes to SVN :

^ Deprecated sefRelToAbs, use JRoute::_() instead
^ Removed Itemid in JRoute implementations, JRouter handles this automatically
^ Removed JURI::resolve, moved functionality into JRoute::_()

Instead of directly pushing the parse route information into the request as explained earlier, I know added a JRouter->setVar function to push it into the JRouter and let him handle the rest. This is a needed change in order to get the pagination working fully again. Be carefull with the code as it is unfinished and still a work in progress.

I also removed JURI::resolved and added a JRoute static class. The functionality that was in JURI::resolve has been moved into the JRoute::_($url, $ssl) function. The JRoute::_() function is also replacing the sefRelToAbs function. People who are writing components that have the legacy layer turned off make sure you use JRoute::_() instead of seRelToAbs.

And finaly I screened the whole codebase and removed $Itemid out of the component  JRoute calls. This completely decouples the components from the $Itemid. I haven't been able to handle all issue, some of them require specific attention.

To answer some of the other questions raised :

@Kenmcd : Thanks, I'll keep that in mind and implement a rewritter in JRouter to easily change the format of the slugs. I have put this on my to do list.

@Doko : Best would be to test this with the none-legacy menu style. The legacy styles have not been tested yet. Your issue is probably caused by a small bug in these styles.

@Pollen : Could do that don't really see the advantage ? Could you try explaining why you would want this change ? The index.php part can be removed by enabling mod_rewrite.

@Alejo : It would work without a hitch. This is exactly what the system does, allow you to create links to a component and allow different settings for each of these links based on the menu parameters.

That's it for today, as always, shoot those questions my way

Johan

practicly:
sefreltoabs("index.php?task=view");
becomes:
JRoute::_("index.php?task=view");

sefreltoabs will go into the legacy mode i presume?

Correct.

If ItemID and option are both used internally (presumably in the session), then what happens when the link is referred to from outside the session?  Can these be looked up?

Would I be correct in assuming that the first part (news-feeds, web-links and etc...) refer to the option parameter at least in some way?

Ian

The first part, what i call the application path is used to lookup the menu item in the menu database table. The information in this table is used to find out what the option is. Bascially you have two options :

1. You come in through a menu item link, which means the system will be able to find the option based on either the $Itemid in the URL (in case of a raw URL) or the application path (in case of a humanly readible URL).

Example

- http://localhost/joomla15/index.php/web-links
- http://localhost/joomla15/index.php?Itemid=x

2. You come in directly through the component, which means the option will need to be defined in the URL. At the moment we are only supporting raw URL's in this case. I might be able to get a standard rewriting algo in place that can also handle these URL's but that's not on the list at the moment.

- http://localhost/joomla15/index.php?option=weblinks

Note : in this case the system will not be able to load any specific menu item parameters because you are coming in directly throught component.

Does that make sense ?

So if I enter through a menu item link (into say, the web links component), and then browse through the component, to look at a particular weblink, then I might get to the URL:
http://localhost/joomla15/index.php/web ... omla-rocks

where joomla-dev is a weblink category and joomla-rocks is a link in that category.

This address does not depend on the session, right?  I think that is what you are saying.

I guess the bottom line is, if somebody browses through my site (well hypothetically if I were to have a site that somebody would want to browse through), and find a web link or perhaps a photo in a gallery that they found entertaining/useful/for some masochistic reason wanted to link to, could they bookmark that page, perhaps send it to their buddy Jose who lives down the street and around the corner, so that he can open up the link?

I'm assuming yes, right?  And further, I'm assuming that the first part of the URL points to a menu item (i.e. the web-links part), which in this case would point to a component, and the rest of the URL would tell the component which page to load.  Correct?

Ian

None of this information is stored in the session, it's all create at runtime based on the request URL.



Offcourse, wouldn't be any point in destroying the whole magic behind hyperlinking would it



Again correct !

Congratulations, Johan. Finally a SEF structure that is set like an API (see the Flickr URI structure and other REST-based URI APIs for this).. I'm impressed. Perhaps it's time to send across a slab of Boags express freight to Germany..

Have you considered making the Router function (or at least its output) API'able for as soon as you remove the numbers, index.php and colons, you're dealing with a pure hierarchical REST structure ?

This really is great news - one of the biggest improvements yet to emerge in 1.5 

One thing I do want to throw out for consideration is that, from an SEO perspective, Google is thought not to search any deeper than three directories, so this would be crawled:

http://mysite.com/web-links/2:joomla-sp ... omla 

But this would not:

http://mysite.com/index.php/web-links/2 ... omla 

There is no official proof or confirmation from Google, but it is a generally accepted notion in the SEO world.

Here's some pretty good proof that isn't correct:

Query: http://www.google.com/search?q=site%3A+ ... =firefox-a


That is 4 directories deep, and it's not a supplemental result either. Best of all, the site runs on Mambo.

I'd second what Doyle says.

I help co-ordinate sites that have over 7 levels deep(800+ nav items inside the stack), and Google still can leverage content out of them.

The unacceptable bit may be the redundancy of index.php referencing and the colon issue in regards to RFCs.

One of the driving principles behind having a framework driven CMS application is so that the framework IS exposed as an API.  Nearly everything in the framework is flexible and extensible.  The application router object (JRouter) can be decorated and/or replaced by any object implementing the same interface... the same is true of many of our most important and fundamental classes.

index.php is added in the event of not having the ability to use mod_rewrite or an equivalent.  If mod_rewrite is enabled then you switch support on in the global configuration (right next to switching human readable urls on and off) and index.php goes away.

Louis

seems like sefreltoabs is not yet in the legacy code, is the an oversight or just one of those things that need to be done?

It should be in there, Louis has moved the legacy code into a system plugin.

ah yes, my bad - thanks for pointing me in the right direction

yeah yeah .... blame me

Sorry Johan for posting here but my question I presume is useful for you work. The new written URL has inside small sentences like "joomla official news"... well if I use a foreign language as italian or french with accents and so on... do you think all is right? In your opinion as an expert aren't any language limit?

newart

I think its ok.

I am not expert but i checked urls of wikipedia and they use it and works perfect.

eg
http://uk.wikipedia.org/wiki/Головна_стаття
http://hi.wikipedia.org/wiki/मुखपृष्ठ
http://zh.wikipedia.org/wiki/首页

thank a lot for your idea, I've tried on wikipedia with a link for "Stabilità sistema" that in english stands for "Stability system", here is the link:

in this case there are an accented "a" and even "(" and ")"

http://it.wikipedia.org/wiki/Stabilit%C ... sistema%29

if the link was only Stabilità (in english stability)
for italian the link should be http://it.wikipedia.org/wiki/Visibilit%C3%A0
for english: http://it.wikipedia.org/wiki/Visibility

as you see there is a non-human readable link - a language gap among latin languages, italian, french, portuguese, romanian, spanish.

Moreover we have eg. in italian language, the year --> in italian : L'anno - we have this problem,too. Observe between the L and a, what we have...

You can type it this way but it looks like the real url is
http://uk.wikipedia.org/wiki/%D0%93%D0% ... 1%82%D1%8F
once displayed.

well, a bit confusing... IMHO we can use an URL from this method

http://localhost/joomla15/index.php/new ... news  (link to newsfeed)

to this

3. http://localhost/joomla15/index.php/new ... /4/1  (link to newsfeed)

or better:

3. http://localhost/joomla15/index.php/7/4/1

can we use a universal language such as numbers? If you like to see sentences, words, a plu-in could do it. But now you see a short smart link, maybe faster to render than a long URL. I know it isn't readable, but it isn't easily forgottenable. We live now among numbers and in this case they are short and more flexible.

pls think of a change of names, titles, the URL is changed, too. For you and for the search engines!

Newart -

This will be one of the few times I disagree with you since I think you are very, very bright. But, WORDS not NUMBERS, please!

Thanks! ... Amy

@Newart

I guess search engines may understand the lingo.
These Russian or Chinese sites have to be ok for them.

Would'nt the problem show more when using these urls in contents or mails, etc.
We may get extraordinary long urls that would break formatting, not speaking of the easy possibility of losing some parts in the process.

Maybe one could have the choice to use Ascii for links?

@AmyStephen

Thanx for what said about me. :) About your need for a word syntax, I understand you very well. I like to see a readable URL, me too. But the problem is a bit hidden...

For a simple comparison is like a DNS vs a domain name, numbers vs words. But the right problem is that they aren't on the same level.

The first level is logic (numbers), then human (words). So if you have an even more short URL like http://www.mysite/7/4/1 (index.php maybe you'd like to hide) I think it's easy for everyone to read. No possibility of errors, only to forget them. No problem by page not found by search engines.

But your doubt is, can I remember these URLs? Not for everyone, I presume. Well, Who wants an even more smart URL in a readable human form, can use a plug-in for doing so.

I see this URL by numbers like a readable level.

Now, if we compare the risk about a URL:
* by numbers, any risk at all;
* by words, I can remember the wrong words, I can change that URL word (search engine issues).

My post is to be intended as follows, the possibility to use "by numbers" and "by words", too. As you like. Do you agree? (Moreover I think the "construction" of a URL written by numbers is faster than to write section, title, category, title and so on...)

@Infograf768

I agree with your doubts. I hope to see expert solutions having in mind URLs like this, in french:

http://www.mysite/7:notre_site_d'actualité/4:français/1:Haïti-État

we have to see our URL with user's own eyes. If the URL is always the same, no changes, no % all around, well... I like very much the solution. But if not, is like a "not a bug" --> but a mistake, like a bug. And the user isn't interested if is a bug or not. He sees only that it isn't working!

Hi Johan,



Looks intuitive the /component/{component_name}/whatever/comes/here...

What I found out is that other URL parameters are not parsed. It looks as if the parse function in components/com_foo/router.php is not used. So '/whatever/comes/here' is ignored. Are you aware of this? Is this still work in progress?

And is it possible to let JRoute::_() optionally ignore the current Itemid, so you can force to link to /component/{component_name} ? This is very useful for linking (routing) to another view without an Itemid from view with an Itemid.

So long for now... Good luck!

Greetz, Mark

Hi all,

Good news, I think we are almost done with the Itemid refactoring. Based on the feedback in this thread I have made a few changes to the implementation :

@kenmc, Brenda : I have implemented a very basic segment encoder/decoder that is capable of rewriting the slug's. A default implementation is in place that uses a '_' to seperate the id from the name. In the future we could expose this into the configuration if the need exists to give the administrator more control over the formatting of the URL segments. This change also solved a bug in PHP 4.3.9 in the parse_url function and resolves the concerns reported by Brenda.

@newart : URL's can only use ASCII characters and thus need to encode any other characters into an ASCII format. You correctly point out that this makes the URL's less readable. Instead of converting the non-ASCII characters to their respective entity formats I have implemented a function that downgrades a character to it's ASCII equivalent. For example, é will become e, or µ will be come u. This is not a 100% perfect but it is better then using entities.  The segment encoder/decoder could be used to remove the text information from a segment and only keep the integer, for the moment this behavior is not yet implement. If somebody want's to have a go at it be my guest

@markuz : Problem with not parsing of default URL's has been fixed. JRoute can ignore the Itemid if you explicitly specify an option and the option doesn't match the option that is attached to the Itemid. In this case JRoute takes the option out of the URL. A good example are the URL's in the login module. Not sure if this is what you need ?

@Amy : you can now blog about Itemid refactoring, I'm putting a blog post up myself on the dev blog.

Thanks for all the feedback, I'm very happy with how this has turned out. If you find any bugs let us know so we can fix them for beta 2 release.

Johan

Looking forward to reading the b log on this. I'm still trying to get my head around it all (despite playing with SVN)

Hi Johan,



Good the parsing is fixed... thanks! I'll check out the next nightly build again.

The other thing is partly answered...
Since menu items usually define not only an option but also a view, I think it is logical to also ignore the Itemid in case you explicitly define another view within the same option. My router.php functions don't parse/build in the view parameter, because it can be derived from JMenu (see router.php of com_weblinks, function WeblinksParseRoute and the $item->query['view'] ).

Maybe you already considered this, though.

Kind regards, Mark

I like very much your decision, I think it is an intelligent balanced wise one. I hope that somebody can help you for full implementing the work. Johan, as you know I'm not a telented programmer, I can discuss (understand) about the code but I have poor natural skills by myself 

Thanks, Johan. You rock!