What FURL path format should be across whole site?

It is formed by makeURL function, but it differs with some add-ons. Typically it is www.site.com/alias/...
and for main page it's www.site.com/... . Some links on main page are pointing to www.site.com/alias/..., this happens when using Articles as starting page. This inconsistency renders bad links (in this case - Tags and Archives). I'm not sure towards which starndard this should be corrected. So my question is what behaviour is correct in core of MODX:
Starting page FURLs should be with this' resource alias or without it ? [ed. note: khyrlik last edited this post 14 years, 1 month ago.]

FURL Path format is determined largely by the "link_tag_scheme" System Setting (or it used to be). If you set it to 'full', it will generate full links including the domain name. If you set it to 'abs', it will make links with the site_url excluded, and if it is "-1", it will make relative paths. This is what is supposed to happen.

Articles, however, seems to (on my installation Revo 2.2.4) make broken links and ignore this setting. So, I simply copied the Chunks from the file system and changed the hrefs to (or the appropriate field) where applicable. This fixed all issues with Articles. I also had to do this with the Comments.

As a note, makeUrl() seems to be ignoring this setting as of 2.2.4. I made my own makeUrl() and use it instead. I haven't filed the bug yet as I thought it was something in my own installation and hadn't had a chance to test it. Interestingly, [[~[[*id]]]] works correctly, though I believe it uses makeUrl() to do so. So, it only seems to happen when makeUrl() is called directly in php code. [ed. note: fuzzicallogic last edited this post 14 years, 2 months ago.]

Nobody from core developers care to add anything ?
IMHO this makes MODX look pretty bad.

The core developers are often involved and have gotten in contact with me several times. Unfortunately, they are also understaffed and busy. Sottwell and BobRay are the next best thing as they have been in the community for a long time and are often in contact with the devs.

Is there anything that was unclear about Sottwell's or my answer? Or did we miss something? If so, please ask us to elaborate and we will gladly do so.

No, your answer is good. I have not expected you will go into details as it would probably took quite a long post and digging in your code. I was going to try fix this bug by myself and needed the right direction.

My second post was about, *sigh*, how things are going with MODX and what you said was very good example of this. Kudos to every one who is able and still wants get it to work.
Thank you for your help

Make sure every template on your site has this in the head section:




------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using.
MODX info for everyone: http://bobsguides.com/modx.html

I have this set since the beginning, it doesn't help.
I have already filed an issue (http://tracker.modx.com/issues/7634) in the tracker some moths ago, but I see time is to get it done by myself as I have my site almost ready to launch. The only thing that bothers me are tags and archives not working, both of them are consequence of this bug(s).

Depending on your setup, it might help to use this (uncached) form:



But it sounds like a problem with Articles ignoring the link_tag_scheme setting or applying it incorrectly.
Doesn't Articles have it's own setting for the scheme that you could alter? I seem to recall seeing one.

BTW, in code, makeUrl() should always be called like this:




------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using.
MODX info for everyone: http://bobsguides.com/modx.html

@BobRay:

On my sites, I had to remove the base element to make it compatible with friendly urls. It simply was not working in Chrome and IE. However, I was a novice then and haven't troubleshot it since.

@BobRay:

Yes, it is uncached call already.

Articles has one FURL option:
"Articles FURL IDs" articles.container_ids=,2:arc_,3:arc_
I have no idea how it works.

Problem with Articles is it's inconsistency with FURL links and using (or not) container alias, especially when using Tags and Archives.
When Articles is start page is visible as sitename.com. Single post links use container alias, Tags in single post and in tag cloud doesn't use it. So it never works properly.
Also, in sample templates FURLs in some tags are hard set to ON (always), ignoring MODX system setting. I've pointed that to author but he ignored it and it is still broken the same way in newest version.