Canonical URL links in Revo 2.0 RC-1

I have a test site running MODx Revolution 2.0.0-rc-1 rev6614 and had a question regarding Canonical URL links in Revo.

FYI, my site is NOT installed in the root of the domain, and I am also running with Friendly URLs, Friendly Aliases, and Friendly Alias Path all set to Yes

The following code appears to work as expected for all pages except the home page:



Output on home page:

http://domain.com/~username/modx/revolution//~username/modx/revolution/

Output on other pages:

http://domain.com/~username/modx/revolution/alias.html

I was able to find a solution by altering the output when on the home page using:



I am curious why I have to do it this way? Why does [[~[[*id]]]] come through differently on the home page than the other pages on the site?

/~username/modx/revolution/ vs. alias1.html or alias2.html

Is there a better way to go about outputting the valid page URL (minus query string) in Revo? Even if [[~[[*id]]]] came through as /, you’d end up with a trailing double slash // if only using [[++site_url]][[~[[*id]]]], so is the conditional check on the home page required either way?


NOTE: This same behavior is occurring for my homepage entry in my XML sitemap generated from 3PD Add-on: googlesitemap-1.1-rc1

Hmm, because the default behavior for the site_start is to render at the root of the site (i.e. site_url), which is where the base points you to, and folks were confused that it did not output anything at all. Originally it was rendering blank and we modified it to output the base_url.

Quote from: OpenGeek at May 14, 2010, 10:15 AM

Hmm, because the default behavior for the site_start is to render at the root of the site (i.e. site_url), which is where the base points you to, and folks were confused that it did not output anything at all. Originally it was rendering blank and we modified it to output the base_url.

Hmm...I see. I came across a post from BobRay with these settings:



Perhaps there is a use case for an alternate system setting e.g. [[++page_url]]


instead of using


Either way, it’s not a big deal to have to do the conditional check, but admittedly was confused at first when expecting similarly formatted output. Thank you for the clarification.

FYI, here is the patch to correct this behavior in googlesitemap-1.1-rc1 add-on:

Quote from: "googlesitemap.class.php"

$url = ( $this->modx->getOption(’site_start’) == $id ) ? ’’ : $this->modx->makeUrl($id); // Update line 112 in googlesitemap.class.php 

That’s a good feature request Mike. Can you stick it in JIRA please?

Quote from: rthrash at May 14, 2010, 11:00 AM

That’s a good feature request Mike. Can you stick it in JIRA please?

All set!

http://svn.modxcms.com/jira/browse/MODX-1970

Actually, I’m wondering if I should add a scheme property for link tags, i.e. Would that make it easier? This would avoid the whole prefixing with tags issue.

This will also allow creation of https links and anything else done with the scheme parameter to modX::makeUrl().

Quote from: OpenGeek at May 14, 2010, 01:12 PM

Actually, I’m wondering if I should add a scheme property for link tags, i.e.

[[~[[++site_start]]? &scheme=`full`]]

Would that make it easier? This would avoid the whole prefixing with tags issue.

Jason,

I really like this idea, the ability to extend the default link tag behavior sounds really cool.

However, it may be arguably easier to simply type [[++page_url]] or

$modx->getOption(’page_url’); // PHP Code

...but I think you’re on to something here, "https links" via scheme property would also be awesome. However, what I like about your proposed direction is that it could be used for any Resource ID, not just the current request.

Committed to SVN and will be available in RC2.