Re:CMS Solutions (Friendly URL's)
The free version of ISAPI Rewrite works wonderfully for friendly URLs such as: http://www.mydomain.com/dyn/something/product/432/category/8 instead of: http://www.mydomain.com/something.cfm?product=432category=8 Using the httpd.ini rule: [ISAPI_Rewrite] RepeatLimit 20 # A note RewriteRule (/dyn/.*?)(\?[^/]*)?/([^/]*)/([^/]*)(.+?)? $1(?2$2:\?)$3=$4?5$5: [N,I] RewriteRule /dyn(.+?)/?(\?.*)? $1.cfm$2 [I] Jack Mod_rewrite is your best friend, if you've got Apache.Someone has mentioned a port for IIS in the form of an ISAPI filter, I belive, but I don't know. I've had wonderful success with ISAPI_Rewrite, although I don't *think* it's an actual port of mod_rewrite. Can't say how useful the freebie version is, but the paid version hasn't given me a moment's trouble. http://www.isapirewrite.com/ -- Roger Benningfield JournURL: http://journurl.com/ blog: http://admin.support.journurl.com/ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re:CMS Solutions (Friendly URL's)
All in all, dynamic URLS should be mapped to static ones, and this mapping should be be done by your marketing department while I agree dynamic urls should be mapped to static ones and that search engine positioning is a whole other chapter, why would marketing be the ones to decide if it is mymag.com/issues/2003/november/19 instead of mymag.com/2004/11/19 or something else? do marketers do url usability? by the way, anyone knows of a good dynamic-to-static url mapping in cf (windows and linux) resource? mauricio [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re:CMS Solutions (Friendly URL's)
Whether shallow directory trees containing lots of files and more descriptive, structured filenames are better than deep heirarchical structures with fewer files per folder and shorter names is an ancient and endless debate, so I ain't going there :-). i wasnt talking about the shallow vs deep situation but more the how would users expect to find my content situation... but maybe marketers could be more user-centric than developers. but i think it should be in hands of someone else instead of marketers or developers... well... thats just really off-topic :) - mga [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re:CMS Solutions (Friendly URL's)
While we're on the subject - does anyone know of any good resources/mailings lists - I've been out of the SEO loop for a while I second that... Any references to mapping dynamic urls to static ones? [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re:CMS Solutions (Friendly URL's)
Speaking of friendly URLs and CMS solutions, I am looking to implement the FarCry CMS for a client and am wondering about the plugin for creating friendly URLs. Does anyone know if this is something I can set up later on, after I have the design and application working? Gabriel [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re:CMS Solutions (Friendly URL's)
Mod_rewrite is your best friend, if you've got Apache.Someone has mentioned a port for IIS in the form of an ISAPI filter, I belive, but I don't know. I've had wonderful success with ISAPI_Rewrite, although I don't *think* it's an actual port of mod_rewrite. Can't say how useful the freebie version is, but the paid version hasn't given me a moment's trouble. http://www.isapirewrite.com/ -- Roger Benningfield JournURL: http://journurl.com/ blog: http://admin.support.journurl.com/ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re:CMS Solutions (Friendly URL's)
I dunno... if you just use an index.cfm and put a ? in your url's, wouldn't that have roughly equivalent effect? For instance, my blog: http://www.turnkey.to/ontap/blog/?20040107 Not that there aren't other uses for mod rewrite or isapi rewrite, but just in terms of mapping virtual paths to real paths... This particular path maps to another virtual path, but that's another story. :) Mod_rewrite is your best friend, if you've got Apache. Someone has mentioned a port for IIS in the form of an ISAPI filter, I belive, but I don't know. I've had wonderful success with ISAPI_Rewrite, although I don't *think* it's an actual port of mod_rewrite. Can't say how useful the freebie version is, but the paid version hasn't given me a moment's trouble. http://www.isapirewrite.com/ -- Roger Benningfield JournURL: http://journurl.com/ blog: http://admin.support.journurl.com/ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re:CMS Solutions (Friendly URL's)
Referring to URL's or URI's (assumed to mean Unique Resource Identifier as opposed to Unique Resource Locator) Uniform Resource Identifier. Personally, I'm fine with the old-fashioned URL... it's in the name of my business, after all. :) But when it comes to technical discussions, I try to use the W3C's preferred terminology, and they like URI. Your critique helps me think about the problem much better. Thanks. No problem. I've been spending a lot of time in the virtual company of hypertext junkies over the last year or so, and I've picked up on a few things along the way. Much of which runs in direct opposition to the way I've been building my apps, unfortunately. :D -- Roger JournURL: http://journurl.com/ blog: http://admin.support.journurl.com/ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re:CMS Solutions (Friendly URL's)
Though I'm not sure why it's such an issue... Isaac, It isn't, IMO... not across the board. It's just one more piece of the URI design puzzle. FWIW, while I've come to increasingly respect the tenets of orthodox hypertext religion, I'm far from devout. And I have no desire to preach at people who are just trying to do their jobs and earn some cash for tacos and rent. :) First, the extension may not have anything to do with the technology in use... The argument would be: if it isn't conveying useful information, and isn't required by the particular server environment, why keep it in your URIs? People in restricted, shared environments may be stuck, but if you *can* rid yourself of cruft like file extensions, it's worth considering. I could perform a case-insensitive multi-file regex search for \.cfm[^[:alnum:]] and find all the places where I would change the extension if I were to migrate to another technology. URI design debates are seldom focused on what you can or can't do on your own server... it's more about the impact you're having on the Web. Search-and-replace won't change the links that exist on other folks' sites, and it won't update every RDF database out there that references a given page. (Though as a rule I think migrating between technologies with existing sites or products when not absolutely requiredis foolish. Agreed. If it ain't broke... has always seemed a pretty compelling argument to me. Perhaps because I'm prone to break things. :) Not every page on a site needs to be ranked highly on search engines. I think probably the most important thing for me has been to realize that search engine ranking is among the last things I need to consider when designing a URI. At this point in the evolution of blogging, syndication, and microcontent, I'm not building tools that produce web pages or sites... I'm building web services that just happen to display HTML with some frequency. Once I started viewing things that way, I began to see URI decisions in the same light that I'd normally reserve for, say, method and parameter names in a CFC. After all, on a given day, 25% of my traffic is coming from non-browser tools like RSS aggregators, XML-RPC clients, and REST services like Trackback. The app is a document, and the document is an app. Yep, thanks Roger... You're very welcome. -- Roger Benningfield JournURL: http://journurl.com/ blog: http://admin.support.journurl.com/ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re:CMS Solutions (Friendly URL's)
Just out of curiosity, but why is the URL awful? Bearing in mind that I create ugly URIs as often as anyone, that I am simply answering a question, and that I don't want to pick on someone else's work: (1) URIs should describe the resource they identify, not the technology used to create it. (Data persists, but technology changes.) So ideally, .cfm and .html file extensions are no-nos. (2) Similarly, the URI in question spends most of its length describing the internal functions of the application, not the data itself. (3) Speaking of length... that's a long URI, which will all-too-often be mangled when passed around in email. (4) The query names that matter to the user are either opaque (Gindex, Pindex) or tightly coupled to the nature of the request (ID_FIRM_ABOUT). All other things being equal, you're better off with the far simpler group, person, and firm. (Chances are gindex and pindex don't translate to group and person, of course, but the URI design encourages such bad guesses.) (5) In a broader sense, query-string URIs are troublesome in and of themselves. A good URI can be used as a unique, unchanging identifier... a primary key for the Web, in other words. Since query name/value pairs can appear in any order, it's very easy to have the same application linking to ?foo=barbar=foo in one place and ?bar=foofoo=bar in another. Will the application still work? Sure. But the Web thinks you're pointing to different pages, which is only a good thing if you're trying to spam Google. Having said all of that, thre are valid reasons to dispense with any of the above principles in a given situation, and no one is a Bad Person for doing so. But it's all worth bearing in mind as you develop. -- Roger JournURL site: http://journurl.com/ blog: http://admin.support.journurl.com/ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re:CMS Solutions (Friendly URL's)
Roger thanks for the excellent critique. Referring to URL's or URI's (assumed to mean Unique Resource Identifier as opposed to Unique Resource Locator)as unique identifiers (or primary Key) is just what I needed to hear to broaden how I was conceptualizing the problem.Your critique helps me think about the problem much better. Thanks. Just out of curiosity, but why is the URL awful? Bearing in mind that I create ugly URIs as often as anyone, that I am simply answering a question, and that I don't want to pick on someone else's work: (1) URIs should describe the resource they identify, not the technology used to create it. (Data persists, but technology changes.) So ideally, .cfm and .html file extensions are no-nos. (2) Similarly, the URI in question spends most of its length describing the internal functions of the application, not the data itself. (3) Speaking of length... that's a long URI, which will all-too-often be mangled when passed around in email. (4) The query names that matter to the user are either opaque (Gindex, Pindex) or tightly coupled to the nature of the request (ID_FIRM_ABOUT). All other things being equal, you're better off with the far simpler group, person, and firm. (Chances are gindex and pindex don't translate to group and person, of course, but the URI design encourages such bad guesses.) (5) In a broader sense, query-string URIs are troublesome in and of themselves. A good URI can be used as a unique, unchanging identifier... a primary key for the Web, in other words. Since query name/value pairs can appear in any order, it's very easy to have the same application linking to ?foo=barbar=foo in one place and ?bar=foofoo=bar in another. Will the application still work? Sure. But the Web thinks you're pointing to different pages, which is only a good thing if you're trying to spam Google. Having said all of that, thre are valid reasons to dispense with any of the above principles in a given situation, and no one is a Bad Person for doing so. But it's all worth bearing in mind as you develop. -- Roger JournURL site: http://journurl.com/ blog: http://admin.support.journurl.com/ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re:CMS Solutions (Friendly URL's)
Just out of curiosity, but why is the URL awful? Bearing in mind that I create ugly URIs as often as anyone, that I am simply answering a question, and that I don't want to pick on someone else's work: (1) URIs should describe the resource they identify, not the technology used to create it. (Data persists, but technology changes.) So ideally, .cfm and .html file extensions are no-nos. I suppose that could be considered an ideal... Though I'm not sure why it's such an issue (unless you have a significant reason to want to make people guess what you're using or to appear unbiased toward any given technology)... First, the extension may not have anything to do with the technology in use, since the webserver is responsible for determining what server engine executes which pages, so I can have my whole site done up with .aspx files and run ColdFusion on the back end. Second, even assuming I'm using shared hosting and don't have access to make changes to the web server, or even with the largest sites, I could perform a case-insensitive multi-file regex search for \.cfm[^[:alnum:]] and find all the places where I would change the extension if I were to migrate to another technology. (Though as a rule I think migrating between technologies with existing sites or products when not absolutely requiredis foolish. Imho in most cases you start contemplating migrating to another technology when there's no community support for the current tech 5 yrs after the only manufacturer goes out of business. Unlike Baylor Hospital here locally who decided to spontaneously migrate large numbers of large, functional ColdFusion applications on their intranet to ASP.NET and C#. I decided not to interview for the job because the recruiter was a jerk to me when I talked to him. Pablo ended up working on that project and said I was probably better off.) (3) Speaking of length... that's a long URI, which will all-too-often be mangled when passed around in email. Yea, that's an important thing... My CMS has pretty short urls, even after redirection... the products page on my own site for instance: http://www.turnkey.to/79.cfm No it's not very descriptive, but it works pretty well, and you can always create stubs for important pages. Not every page on a site needs to be ranked highly on search engines. Having said all of that, thre are valid reasons to dispense with any of the above principles in a given situation, and no one is a Bad Person for doing so. But it's all worth bearing in mind as you develop. Yep, thanks Roger, there was some good stuff in there that hadn't occurred to me. s. isaac dealey 214-823-9345 team macromedia volunteerhttp://www.macromedia.com/go/team chief architect, tapestry cmshttp://products.turnkey.to onTap is open sourcehttp://www.turnkey.to/ontap [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
