Mura CMS

I just setup my first Mura CMS install and I'm using Apache mod_rewrite (IIS has parallel tools you can buy) to do a little URL rewriting such that my URLs are all extremely clean and SES (search engine safe).

For example, I'm rewriting a URL like this:
http://www.domain.com/my-page/
...to something like this (without public users knowing/seeing it):
http://www.domain.com/siteid/index.cfm/my-page/

There are already two topics in this forum that cover most of this, but I ran into one additional quirk and also thought I'd share my URL rewrite rules.

I used this post from Matt to remove the siteID from the URLs.

I used this post from Tony to remove the index.cfm from the URLs.

Here are the URL rewrite rules/conditions I'm using:

RewriteEngine On

# If it's a real path, just serve it
RewriteCond  %{REQUEST_FILENAME}  -f  [OR]
RewriteCond  %{REQUEST_FILENAME}  -d
RewriteRule  .  -  [L]

# Redirect if no trailing slash
RewriteRule  ^(.+[^/])$  $1/  [R=301,L]

# Rewrite Mura CMS URL paths
RewriteRule  ^(.*)$  /index.cfm%{REQUEST_URI}  [L]

All seemed to be working great, until I tried to use the site search feature. The action for the search form was "index.cfm" which would work if you're on the home page, but otherwise you'll end up with a 404 at a URL something like this:
http://www.domain.com/my-page/index.cfm?keywords=searchtext&display=search&newSearch=true&noCache=1

I took a peak at the code and noticed that the form action is being pulled from the configBean's indexFile attribute, which is easily modified in your config/settings.ini.cfm file...

Just change this line:

indexfile=index.cfm

...to this:

indexfile=/

Best,
Jamie

@Mura Team:

These tricks work great for the most part, but I found another little quirk... If I use the on-page/public page "Edit" link (in the top yellow admin header, when logged in) and save the current page (e.g., host/about-us/) from the lightbox edit view, the browser redirects to host/default/index.cfm/about-us/ instead of host/about-us/.

Any pointers on where I can go to fix this?

Thanks!

Are you talking about when links in the site admin?

I think I got it. Try replace this file in your install and let me know if it works for you.

http://svn.blueriver.com/mura/trunk/www/admin/view/vArchitecture/dsp_close_compact_display.cfm

Are you talking about when links in the site admin?

No, but I now see that the same issue exists there with the "View" icon in the Site Manager page list.

I was referring to what happens after you edit a page from the front-end/public view. For example, while logged in to admin I browse to a public page such as host/about-us/ and click the "Edit" link in the yellow header that appears above the public page. When I then click "Publish" from the lightbox edit view, the main browser redirects to host/default/index.cfm/about-us/ instead of host/about-us/.

@Matt: That did the trick, thanks!

I've discovered a bit of a bug and wanted to share my workaround. Valid path_info for Mura pages consist of only letters, numbers, hyphens and forward slashes. If you browse to a path that doesn't exists, Mura properly throws a 404 error -- well, sometimes...

If it's a valid Mura formatted URL, you'll get a 404. For example:

http://www.getmura.com/index.cfm/i-do-not-exist/

...however, if the path_info is not "valid," Mura seems to ignore it and display the home page -- for example:

http://www.getmura.com/index.cfm/i-do-not-exist.html

I've blogged a few details here regarding how I discovered this and the potential negative effects on search engine optimization.

Also, here's an example, which is a revision of my initial post to this thread, including a workaround this time:

RewriteEngine On

# If it's a real path, just serve it
RewriteCond  %{REQUEST_FILENAME}  -f  [OR]
RewriteCond  %{REQUEST_FILENAME}  -d
RewriteRule  .  -  [L]

# Require trailing slash at this point, if otherwise valid CMS URL:
RewriteRule  ^([a-zA-Z0-9/-]+[^/])$  $1/  [R=301,L]

# Rewrite properly formatted Mura CMS URL paths:
RewriteRule  ^([a-zA-Z0-9/-]+)$  /index.cfm%{REQUEST_URI}  [L]

# Anything else must be a 404 error:
RewriteRule  .  /index.cfm/this-will-force-a-404/  [L]

UPDATE (5/6/2010): My buddy, Ilya, was just having trouble using the above rewrite stuff (CF8/JRun/Apache/JRun connector), and I was able to fix it, so thought we better share here... There were two issues. I've seen unexpected results from the %{REQUEST_FILENAME} environment variable. So, in the RewriteCond lines that check for a real file or directory, I've instead used %{DOCUMENT_ROOT}%{REQUEST_URI}. The second issue was resolved by adding a PT (pass through) flag to each RewriteRule, with the exception of the one with a 301 redirect flag. The PT may or may not be necessary, depending upon what application server and connector you're using. Anyway, here's what worked for Ilya with a standard CF8/JRun/Apache install:

RewriteEngine On

# If it's a real path, just serve it
RewriteCond  %{DOCUMENT_ROOT}%{REQUEST_URI}  -f  [OR]
RewriteCond  %{DOCUMENT_ROOT}%{REQUEST_URI}  -d
RewriteRule  .  -  [L,PT]

# Require trailing slash at this point, if otherwise valid CMS URL:
RewriteRule  ^([a-zA-Z0-9/-]+[^/])$  $1/  [R=301,L]

# Rewrite properly formatted Mura CMS URL paths:
RewriteRule  ^([a-zA-Z0-9/-]+)$  /index.cfm%{REQUEST_URI}  [L,PT]

# Anything else must be a 404 error:
RewriteRule  .  /index.cfm/this-will-force-a-404/  [L,PT]

More 5/6/2010 update: As long as we're on the topic of updates, remember that Mura 5.2+ has two simple settings.ini.cfm properties that take care of getting rid of the siteid and index.cfm from URLs, siteidinurls=0 and indexfileinurls=0. You no longer need to edit any code at all, just those two settings and the URL rewriting at the Web server level. Cheers!
* Last updated by: jamiekrug on 5/6/2010 @ 9:38 PM *

I followed all the instructions (the dsp_close_compact_display.cfm in my distribution was functionally identical to the one posted above, so no action there.) I had to tweak them a bit as noted in the other two threads, but I still have an issue.

The logout link generated in the front end controls at the top of the screen (the Mura bar that includes edit, add, site manager, etc. on top of the rendered page) emits as:
<li id="adminLogOut"><a href="index.cfm?doaction=logout">Log Out</a></li>
which means that unless you're on the home page, it tries things like:
www.mydomain.com/nav-item-1/page-2/index.cfm?doaction=logout

which dunna woik good.

Did I miss something, or is this a new issue?

I started a new thread here:
http://getmura.com/forum/messages.cfm?threadid=E4E6DA88-2C0A-4FCD-B0DC67A58A0520A8
'cause I really need to figure this out.
It happens with password protected pages too - the ?display= part is missing leaving just /login&returnUrl=

@8riaN,

I fixed the Logout link in the on-site editing bar up top by making a quick edit to admin/modal/dsp_modal_edit.cfm -- it was line 228 for me, and I changed from this:
href="index.cfm?doaction=logout"
to this:
href="?doaction=logout"

Or, if you want to go to the home page upon logout, you could use this:
href="#application.configBean.getIndexFile()#?doaction=logout"

I haven't used the member/access stuff in Mura yet, so not sure what to tell you there, but hopefully the Mura team can help out. A global search for "doaction=logout" in the Mura code turned up just 6 instances in 5 files. The one above was the only one with a hard-coded "index.cfm" in there.

Another factor in this may be the "Custom Login URL" setting in your site's settings. I tells Mura where to go when a user needs to login. It's default is "index.cfm?display=login". You may want to change it to "?display=login".

This is also where you can configure Mura to send the user to a third party authentication system id needed or specific Mura page that has a specific login template.

Excellent!

Those two together solved all the problems I've found so far!

Any chance we could get the dsp_modal_edit.cfm change incorporated somehow, eventually? I'll be fine, but seems like a good thing for everybody.

Thanks very much, Jamie and Matt!

EDIT - The dsp_modal_edit.cfm change has been incorporated into the main distribution by version 5.1.1102
n.b. Don't forget to preserve the www\index.cfm change when you upgrade versions.
* Last updated by: 8riaN on 11/23/2009 @ 11:38 PM *

PS - Don't forget to change the edit profile link to "?display=editProfile" also... Can't believe how long it took me to figure that out...

Another note on this subject:

Jamie had success changing this line:

indexfile=index.cfm

...to this:

indexfile=/

But I found it causes all kinds of tiny trouble with modules that need to know what directory they are in - e.g. the forms module list's link to the response detail needs to have the current url path for ?fuseaction=detail to work. Fortunately, the fix is really, really easy :D
Just change it to this instead:

indexfile=./

et. viola!
* Last updated by: 8riaN on 9/22/2009 @ 10:28 AM *

Another little tweak:
Calendar next/previous month buttons don't work unless you use the IndexFile attribute we set above.
In {siteid}\includes\display_objects\calendar\dsp_dp_showmonth.cfm, change (was lines 48-50 for me) from:

<th title="#dateLong#" id="previousMonth"><a href="index.cfm?month=#previousmonth#&year=#previousyear#&categoryID=#htmlEditFormat(request.categoryID)#&relatedID=#htmlEditFormat(request.relatedID)#">&laquo;</a></th>
<th colspan="5">#dateLong#</th>
<th id="nextMonth"><a href="index.cfm?month=#nextmonth#&year=#nextyear#&categoryID=#htmlEditFormat(request.categoryID)#&relatedID=#htmlEditFormat(request.relatedID)#">&raquo;</a></th>

to

<th title="#dateLong#" id="previousMonth"><a href="#application.configBean.getIndexFile()#?month=#previousmonth#&year=#previousyear#&categoryID=#htmlEditFormat(request.categoryID)#&relatedID=#htmlEditFormat(request.relatedID)#">&laquo;</a></th>
<th colspan="5">#dateLong#</th>
<th id="nextMonth"><a href="#application.configBean.getIndexFile()#?month=#nextmonth#&year=#nextyear#&categoryID=#htmlEditFormat(request.categoryID)#&relatedID=#htmlEditFormat(request.relatedID)#">&raquo;</a></th>

The only difference is that index.cfm is replaced with #application.configBean.getIndexFile()# in both links

I also made a similar change in {siteid}\ucbr\includes\display_objects\nav\calendarNav\navTools.cfc I changed the "next month" link to match the "previous month" link (was line 97):

<th id="nextMonth"><a href="index.cfm?month=#nextmonth#&year=#nextyear#&categoryID=#htmlEditFormat(request.categoryID)#&relatedID=#htmlEditFormat(request.relatedID)#&filterBy=releaseMonth">&raquo;</a></th>

to:

<th id="nextMonth"><a href="#navPath#?month=#nextmonth#&year=#nextyear#&categoryID=#htmlEditFormat(request.categoryID)#&relatedID=#htmlEditFormat(request.relatedID)#&filterBy=releaseMonth">&raquo;</a></th>

The only difference being that index.cfm? is changed to #navPath#?
* Last updated by: 8riaN on 11/23/2009 @ 12:16 PM *

Another tweak - this time it's not in a nice place, though. The "edit profile" button is broken in admin after the above changes, fix it by passing the current siteid from the session in \admin\view\layouts\header.cfm (was line 65)

<li id="navEditProfile"><a href="#application.configBean.getContext()#/admin/index.cfm?fuseaction=cEditProfile.edit&siteid=#session.siteid#">#application.rbFactory.getKeyValue(session.rb,"layout.editprofile")#</a></li>

Difference is that &siteid=#session.siteid# was added to the end of the url.