One easy way is of course not to use path aliases and that would be the quick work-around. However, in some cases I want users to be able to remember a URL and most don't recall 'node/1234' as well as they do 'job-applicants'. The challenge is that for privacy reasons I don't want to make evident to the operators of a server linked from the internal page that the user is an applicant (and maybe they aren't but are a prospect I want to encourage to apply).
A cursory look at the modules list didn't reveal the answer. Likely a module for this with a filter that can be applied to redirect all links through it will be the solution.
]]>One easy way is of course not to use path aliases and that would be the quick work-around. However, in some cases I want users to be able to remember a URL and most don't recall 'node/1234' as well as they do 'job-applicants'. The challenge is that for privacy reasons I don't want to make evident to the operators of a server linked from the internal page that the user is an applicant (and maybe they aren't but are a prospect I want to encourage to apply).
A cursory look at the modules list didn't reveal the answer. Likely a module for this with a filter that can be applied to redirect all links through it will be the solution.
]]>So what does this have to do with Dreamweaver? A friend recently commented that when they look at resumes they similarly discount the web credentials of anyone who lists Dreamweaver, Front Page or other similar programs on their resume for much the same reasons. Usually they've gone to a class or two on web design and don't really understand the web my friend explained. It is far more important that a person who is going to be using the web heavily and designing for the web understand how the web works, what a are key factors in search engine optimization, organic marketing, usability, content management systems and customer service than an understanding of how to use a particular piece of software. In other words the conceptual body of knowledge is far more important than how to push buttons in a software package.
Extrapolating into the mechanical world the Dreamweaver and Front Page slingers of the world are shade tree mechanics. Many of them very good and able to put together quite pretty things and make things look good. Just as many a shade-tree mechanic can do wonders on that '67 Mustang the Front Pager can put the shine on a '97 vintage website. If '97 works then you're done. When it comes to working on the '06 Prius the shade tree mechanic is at a distinct disadvantage. Though at it's heart there is a gas engine, the HTML of the automotive world, there is a much more complex system in play that takes more tools and understanding than the average shade tree mechanic possesses. If you want a '07 website that can keep and build audience and become the business tool you need then you'll do what those in the know do and use a content management system. Best of all when you want an '08 website your job will be much easier.
Of course I am far from the first to raise this point. And it would be wrong to take away the idea that Dreamweaver doesn't have a place. It is a great tool for designing a site even if it is a poor tool for maintaining the content on the site once it is designed.
]]>So what does this have to do with Dreamweaver? A friend recently commented that when they look at resumes they similarly discount the web credentials of anyone who lists Dreamweaver, Front Page or other similar programs on their resume for much the same reasons. Usually they've gone to a class or two on web design and don't really understand the web my friend explained. It is far more important that a person who is going to be using the web heavily and designing for the web understand how the web works, what a are key factors in search engine optimization, organic marketing, usability, content management systems and customer service than an understanding of how to use a particular piece of software. In other words the conceptual body of knowledge is far more important than how to push buttons in a software package.
Extrapolating into the mechanical world the Dreamweaver and Front Page slingers of the world are shade tree mechanics. Many of them very good and able to put together quite pretty things and make things look good. Just as many a shade-tree mechanic can do wonders on that '67 Mustang the Front Pager can put the shine on a '97 vintage website. If '97 works then you're done. When it comes to working on the '06 Prius the shade tree mechanic is at a distinct disadvantage. Though at it's heart there is a gas engine, the HTML of the automotive world, there is a much more complex system in play that takes more tools and understanding than the average shade tree mechanic possesses. If you want a '07 website that can keep and build audience and become the business tool you need then you'll do what those in the know do and use a content management system. Best of all when you want an '08 website your job will be much easier.
Of course I am far from the first to raise this point. And it would be wrong to take away the idea that Dreamweaver doesn't have a place. It is a great tool for designing a site even if it is a poor tool for maintaining the content on the site once it is designed.
]]>Once a site is in produciton it's best to do away with .htaccess for performance. This is simple enough as the directives in .htaccess can be put in the Apache configuration file. For these early stages, though, it is great to have a .htaccess file so you can make changes without having to restart. Drupal ships with a .htaccess file that works for re-writing URLs so one can do "clean" URLs.
The problem with the site at hand, however, is it needs to still access the old site while the new Drupal site is going up around it. Drupal's .htaccess file contains the following directives that we are concerned with:
This tells the webserver that if a client requests a file and there is no file by that name and no directory by that name to send /index.php instead and to take the requested "page" and send it as an argument. Thus /node/3 becomes index.php?q=node/3. This works fine if the user requests a regular file. However it breaks down if they request a directory. If a user requests /oldsite/ Apache doesn't know that the "if the file doesn't exist" part applies to /oldsite/index.html until it is too late. Apache merrily serves up index.php.
To solve this problem (and a couple of variations) we add the following three lines before the three above in the .htaccess file:
]]>Once a site is in produciton it's best to do away with .htaccess for performance. This is simple enough as the directives in .htaccess can be put in the Apache configuration file. For these early stages, though, it is great to have a .htaccess file so you can make changes without having to restart. Drupal ships with a .htaccess file that works for re-writing URLs so one can do "clean" URLs.
The problem with the site at hand, however, is it needs to still access the old site while the new Drupal site is going up around it. Drupal's .htaccess file contains the following directives that we are concerned with:
This tells the webserver that if a client requests a file and there is no file by that name and no directory by that name to send /index.php instead and to take the requested "page" and send it as an argument. Thus /node/3 becomes index.php?q=node/3. This works fine if the user requests a regular file. However it breaks down if they request a directory. If a user requests /oldsite/ Apache doesn't know that the "if the file doesn't exist" part applies to /oldsite/index.html until it is too late. Apache merrily serves up index.php.
To solve this problem (and a couple of variations) we add the following three lines before the three above in the .htaccess file:
These handle two specific circumstances. If the user requests a path that contains photo, such as the old photo site at http://example.com/photo they are redirected to the new photo site (separate from Drupal). Along the way specialuser setup their site using index.htm instead of index.html. The second rule solves the case of a user requesting specialuser's website. Finally the last rule says if someone makes a request that ends in a '/' redirect them to the same path but make the request '/index.html' instead. This means that if someone requests a directory like /oldsite/ they get /oldsite/index.html instead of the requesting being turned over to Drupal.
With these changes in place both sites are up and running side by side. Ask for index.php and Drupal will serve the page. Request a file or directory that exists on the webserver and that will be served. Next time we'll look at setting up the Front Page module to start serving the site's main page from Drupal while the magical transformation continues behind the scenes.
]]>