index.suffix location scheme

Rhythmyx Technical Discussion
1

The Generic content type allows me to specify the Usage of a page, to specify whether a page is Normal or a Landing Page. I would like to use that feature to create a location scheme that determines whether a Generic page should be called “www.myschool.edu/department/index.html” or “www.myschool.edu/department/SystemTitle.html”. Actually, Dave Benua suggests using sys_pathname instead of sys_title.

The syntax of this location scheme must be wrong. My thinking may be wrong too. This publishes every page as if it were the home page of the site and ignores the Usage:

if ($sys.item.hasProperty("rx:usage")) {  $usage = $sys.item.getProperty("rx:usage").String;  } if (! empty($usage) and
$usage == 'L') {       '$sys.pub_path + $sys.template.prefix + index.html'; } else {'$sys.pub_path + $sys.template.prefix + $sys.item.getProperty('rx:sys_pathname').String + $rx.location.getFirstDefined($sys.item,'rx:activeimg_ext,rx:sys_suffix', '.html')';  }
2

The problem is that “hasProperty” returns true when the property is defined, even if the value is null.

JEXL has an “empty()” operator, so something like

if ($sys.item.hasProperty("rx:usage") && !empty($sys.item.getProperty("rx:usage").String))
{
 //do something here. 
}

Should work.

3

Thanks. I think the last part of my expression has more problems. I’m publishing every page as “www.myschool.edu/index.html” instead of “www.myschool.edu/engineering/index.html” and “www.myschool.edu/architecture/index.html” The subdirectories worked until I changed the location scheme.

4

In other words, the part I’m not sure about is the “do something here” part - $sys.pub_path + $sys.template.prefix + index.html isn’t working.

5

Any reason you’re putting tick marks (’) inside the curly braces?

For example, what you had below should be…

…{$sys.pub_path + $sys.template.prefix + “index.html”;}…

6

I’ll keep trying and let you know what I perceive.

7

I’d like to see somthing like:

if ($sys.landingPage)

in a similar way that if($sys.crossSiteLink) works

Then you could name your landing pages index.html and rest 1234.html

Cheers
James

8

Success! Here’s a Generic location scheme for the Publish context, which names pages “sys_title.html” if Usage is Normal, and “index.html” if Usage is Landing Page:

if ($sys.item.hasProperty("rx:usage") && !empty($sys.item.getProperty("rx:usage").String) &&
($sys.item.getProperty("rx:usage").String) == "L") {$sys.pub_path + $sys.template.prefix + 'index' + $rx.location.getFirstDefined($sys.item,'rx:activeimg_ext,rx:sys_suffix', '.html');} else {$sys.pub_path + $sys.template.prefix + $sys.item.getProperty('rx:sys_title').String + $rx.location.getFirstDefined($sys.item,'rx:activeimg_ext,rx:sys_suffix', '.html');}
9

I’ve still been challenged by location schemes. I ended up having to change mine to:
Home (Publish)

$sys.pub_path + $sys.template.prefix + 'index.html'

Home (Site Folder Assembly)

$sys.variables.rxs_urlroot + $sys.pub_path + $sys.template.prefix + 'index.html'

Generic (Site Folder Assembly)
(This produces landing page links such as “/procedures/” which is better than “/procedures/index.html” )

if ($sys.crossSiteLink) {$prefix = $sys.site.url;} else {$prefix = $sys.variables.rxs_urlroot;} if ($sys.item.hasProperty("rx:usage") && !empty($sys.item.getProperty("rx:usage").String) &&
($sys.item.getProperty("rx:usage").String) == "L") {$prefix + $sys.pub_path + $sys.template.prefix;} else {$prefix + $sys.pub_path + $sys.template.prefix + $sys.item.getProperty('rx:sys_title').String + $rx.location.getFirstDefined($sys.item,'rx:activeimg_ext,rx:sys_suffix', '.html');}
10

Trying to find a better location scheme, based on http://forum.percussion.com/showthread.php?t=624, I tried this one for Generic Publish:

if ($user.psoRelationships.isLandingPage($sys.item.id)) {$sys.pub_path + $sys.template.prefix;} else {$sys.pub_path + $sys.template.prefix + $sys.item.getProperty('rx:sys_title').String + $rx.location.getFirstDefined($sys.item,'rx:activeimg_ext,rx:sys_suffix', '.html');}

But it published every page of “www.myschool.edu/president/” with the site name as the filename, even the images:

srv/  	   	   	 
   www/ 	  	  	 
      vhosts/ 	  	  	 
         myschool/ 	  	  	 
            president 	
            president
            president
            president
            president
            president

instead of myschool.edu/president/[index.html], myschool.edu/president/bio.html, myschool.edu/president/images/ruler.jpg

11

I’m not sure if you can use $user.psoRelationships in the publishing tab, but someone can probably respond to that.

That said, I think what it might be doing is that it is always returning true, hence going to $sys.pub_path + $sys.template.prefix and if none of the template have a prefix defined, you just are outputting the name of the site (location)…Try putting something else (ie $sys.pub_path + "true+ $sys.template.prefix) to see if you are hitting that condition…

Have you checked error logs?

12

Strange, but inserting “true” into the location scheme didn’t seem to make any difference. The Publication Log says Success, the status of each individual item is failure, but I can successfully preview each CMS Link.

Error logs? I’ve got lots of error logs:

12:21:54,754 ERROR [PSJexlLocationGenerator] Problem in evaluting, dumping bindings:

etc.

12:29:32,830 ERROR [PSGeneratePubLocation] Problem while generating a publishing location for variant 605 and contentid 1000
com.percussion.extension.PSExtensionException: if ($user.psoRelationships.isLandingPage($sys.item.id)) {$sys.pub_path + "true" + $sys.template.prefix;} else {$sys.pub_path + "false" + $sys.template.prefix + $sys.item.getProperty('rx:sys_title').String + $rx.location.getFirstDefined($sys.item,'rx:activeimg_ext,rx:sys_suffix', '.html');}

etc.

13

Wait, obviously I must have a file name for Publish context, though I could leave out the “index.html” in the Site Folder Assembly context. But I still get the same results (location as file name) with the more sensible location scheme:

if ($user.psoRelationships.isLandingPage($sys.item.id)) {$sys.pub_path + $sys.template.prefix + 'index' + $rx.location.getFirstDefined($sys.item,'rx:activeimg_ext,rx:sys_suffix', '.html');} else {$sys.pub_path + $sys.template.prefix + $sys.item.getProperty('rx:sys_title').String + $rx.location.getFirstDefined($sys.item,'rx:activeimg_ext,rx:sys_suffix', '.html');}

The “then” portion works fine when the “if” portion looks instead for an “L” in the Usage field, as in post #8 in this thread.

14

[QUOTE=jimbo;2551]I’d like to see somthing like:

if ($sys.landingPage)

in a similar way that if($sys.crossSiteLink) works

Then you could name your landing pages index.html and rest 1234.html

Cheers
James[/QUOTE]

James, get yourself a copy of a recent PSO Toolkit. There’s a new isLandingPage function that can be used (also described in a couple of previous posts above). Here’s a quick example of it being used for a publishing context location scheme that I did recently to test its functionality:


$baseUrl = '';
$contentId = $sys.item.getProperty('sys_contentid').String; 
$filename = 'item_' + $contentId; 

if ($user.psoRelationships.isLandingPage($contentId)) { 
  $filename = 'index'; 
}
$baseUrl + $sys.pub_path + $filename + '.htm';
15

Here is a working combination of David’s PSO location scheme and the Publishing Generic one I’ve been using. It uses the page’s title in the filename, and works for non-HTML files too, such as images - and course, it depends on the PSOToolkit:

$baseUrl = '';
$filename =$sys.item.getProperty('rx:sys_title').String;
if ($user.psoRelationships.isLandingPage($sys.item.getProperty('sys_contentid').String)) { 
  $filename = 'index'; }
$baseUrl + $sys.pub_path + $filename + $rx.location.getFirstDefined($sys.item,'rx:activeimg_ext,rx:sys_suffix', '.html');

Here is the Generic location scheme for Site Folder Assembly, in which the navigation is mysite.edu/department/ instead of mysite.edu/department/index.html:

$baseUrl = '';
$filename =$sys.item.getProperty('rx:sys_title').String;
if ($sys.crossSiteLink) {$prefix = $sys.site.url;} else {$prefix = $sys.variables.rxs_urlroot;} if ($user.psoRelationships.isLandingPage($sys.item.getProperty('sys_contentid').String))
{$baseUrl + $prefix + $sys.pub_path + $sys.template.prefix;} else {$baseUrl + $prefix + $sys.pub_path + $sys.template.prefix + $filename + $rx.location.getFirstDefined($sys.item,'rx:activeimg_ext,rx:sys_suffix', '.html');}
16

[QUOTE=mdmcginn;2927]
This produces landing page links such as “/procedures/” which is better than “/procedures/index.html”[/QUOTE]
Sorry for reviving a semi-dead thread as well as hijacking it off subject, but I am curious why you think referring to the directory is better than referring directly the file in that directory?

Technically, just referring to the directory puts a larger load on the server, since it has to cross reference the files in that directory with the list of approved default pages and then serve up the appropriate match. Putting in the file name removes that need completely, resulting in a faster (though almost negligibly so) transaction.

I always use full paths whenever possible, and only let directory links be used in marketing materials, since less typing results in less room for errors.

So what am I missing?

17

Tim Berners-Lee’s classic response to that question is his article Cool URIs don’t change.

18

Interesting read, though I don’t agree with what he says.

The first problem with this article is that it is 10 years old. Since 1998, the web is nothing like it was then. Search engines have become the central hub for most web surfing. The link to Jacob Nielsen’s website even confirms as much with a 2005 update: 25% of people use a search engine to find you, even if they have an accurate URL, and that is three years ago. I am sure that has only increased with Google and Yahoo using their search engines as the hub for the rest of their services.

Second, and related to above, is that your relevance in search engine results are influenced by your URL string. Google looks there first for keywords before moving to title, then headers, then body text. Removing ‘index.html’ isn’t going to have much of an impact, but if you examine one of examples Tim advocates - http://www.w3.org/1998/12/01/chairs - you can see what sort of disaster this URL actually is in respect to searching, much less a user scanning it for relevance to their search.

Finally, eliminating all of your extensions from display really does nothing to ensure that the URL will never break. File and directory structures will change no matter how much planning goes in, because organizations themselves are always changing. Trying to plan for URLs to survive much longer than a couple of years is like trying to stop the tide.

So the proper way to survive the inevitable changes is to ensure you are helping a user along when they hit that wall. Redirects are good, but can be problematic to maintain. Using helpful 404 pages that gives a user an idea of what to do to find what they wanted are especially important. Hitting a 404 page isn’t going to discourage a user if they really believe that your site has what they want. But if you don’t provide immediate options for helping them keep going on your site, then they will leave.

Sorry for the rant, especially for being so completely off topic for the forum.

19

Good points. I should add that the number of relevant inbound links is usually more important to Google than keywords in the URL. Changing URLs is one of the most effective ways of losing inbound links.

20

Keywords in URL, title, h# tags, and throughout body determine relevance to the search. Number of (legit) links helps determine ranking within that search.