dougv.com « Doug Vanderweide

Ran into this problem with the blog:

As previously noted, I moved my WordPress install from a subdirectory to the root of my Web site. I tried the “Giving WordPress Its Own Directory” method, but I didn’t trust it, so I decided to go ahead with a physical move of the software to root.

As a result, all permalinks to the 200+ articles in this blog became broken, since the subdirectory /blog/ was part of the permanent path root. This was bad, because Google has all those old links wrong, and so does my YOURLS install.

So, I needed a fix, stat. Thankfully, Apache has the mod_alias module, which does a better job of rewriting URLs from subdirectories to root directory than mod_rewrite does.

I specifically used the RewritePermanent directive, which allows one to specify part of a URL string, and to where URLs containing that string should be directed. In my case, I wanted to direct all URLs that contained the  /blog/ subdirectory to the root of my site. Thus:

<IfModule mod_alias.c>
RedirectPermanent /blog/ http://www.dougv.com/
</IfModule>

The first argument after RedirectPermanent is the part of the URL you want removed. The second argument is the URL to which you want found URLs redirected.

This works far better for me than the handful of mod_rewrite rules I tried to accomplish the same basic task.

Your Web server must have mod_alias installed for this to work. Most shared Web hosts will have installed mod_alias, but some might not, or might only enable it for selected domains, as a lot of rewrites and aliases can cause trouble with search engine rankings. Check with your Web service provider.

A hat tip to julianmatz at experts-exchange.com for the tip. All links in this post on delicious: http://www.delicious.com/dougvdotcom/correcting-permalinks-after-moving-content-from-a-subdirectory-to-root

CSS-Tricks, a really great Web site that explains in detail how to replicate cutting-edge Web site designs and effects, tipped a new idea: humans.txt, a metadata file to compliment robots.txt.

“It’s an initiative for knowing the people behind a website,” said the proponents, who hail from Spain. “It’s a TXT file that contains information about the different people who have contributed to building the website.”

Like Chris Coyier, the author of the CSS-Tricks article, I like the idea of having a meta data file, outside the code base of a Web site itself, that credits the people behind the site.

I find those “Web sites created by {insert Web design firm here}” links in the footer of a site to be so 2001 (although admittedly, I only stopped putting them on sites about five years ago). And sure, one can add an author meta tag to the head of a Web page, to give credit where it is due. But I revere the head element of a Web site; authors shouldn’t put any old thing in there, and everything in there should serve a specific purpose to the page itself.

So a humans.txt file makes a lot of sense, and I admire the cleverness behind calling it that, in compliment to the familiar and requisite robots.txt file.

I like the idea of being able to give extended credit to site contributors. I like the idea of being able to reveal base technologies behind a site. (But not too specific, mind you; I can just see the script kiddies out there, putting together exploit bots that scour humans.txt files to find unpatched software to attack.)

I think it makes more sense, however, to use XML. The robots exclusion standard came out in 1994, was the brainchild of one person solving a problem specific to his search engine’s needs, and effectively became a standard by fiat.

While it has a kind of schema — at least, its proper formatting is well-known — the structure of a robots.txt file isn’t efficient or elegant; it’s not easily read or manipulated, and it can be repetitive and difficult to manage multiple rules for multiple engines.

An XML document is far cleaner.

Continue reading: Meta Data For A Web Site's People: humans.txt »

I recently blogged, Using YOURLS And The Twitter API With Google Reader’s Custom SendTo Link. Since then, I have made a few improvements to the script, mostly in the error-trapping line.

• I broke out the variables for the YOURLS API signature, plus the Twitter API consumer key, consumer secret, access key and access secret, and converted them to constants.
• I removed urldecode() from the formation of the YOURLS API request. It’s not necessary.
• I have added code to trap any errors in when making the short URL.
  • I am now getting the statusCode and message node contents, in case something goes wrong with the shortening.
  • I set the script to die on a URL shortening error, which is determined by the short URL being an empty string or the statusCode node having a value other than 200.
  • The code, coupled with the message, should explain any problems adequately enough to debug shortening issues. If you find you are getting zero-length responses from your URL shortening, that’s probably due to a server misconfiguration; possibly from bad mod_rewrite rules, possibly due to a messed-up cookie on your PC.
• I strip HTML tags from the title.
  • I discovered today that some Google Reader items will have HTML markup in their titles, such as <em>.
• I check for failure in the Twitter API request.
  • TwitterOAuth will return Boolean false if it could not complete its curl request to the API, and will return an XML document in any other case, including failure of the tweet to go through.
  • If the cUrl request is good but the tweet doesn’t go through, Twitter responds with an HTTP status code other than 200. We can capture the last status code returned by our request, test it, and print the XML response describing what happened.

Continue reading: Update To The YOURLS – Twitter – Google Reader Script »

There are a couple of ways to create an RSS feed from a SQL database store. Over at 4GuysFromRolla.com, there’s a post explaining how to create an RSS feed using a regular old ASP.NET Web Form.

Another option would be to write a script that creates an actual XML file on some periodic basis (probably just before the recommended “time to live” setting of the feed). The benefit of that is, one taxes the database server a little every now and then, and a “real” XML file does the work.

But as a rule, for ASP.NET applications, Microsoft recommends using HTTP handlers or modules whenever one wants to present data other than HTML.

(Aside on handlers vs. modules: A handler is a special ASP.NET Web page; a module is a plug-in one can install in Internet Information Server. If you’ve got a lot of different, special-case Web processing, or one need that is near-constant — such as processing images stored in a database every time a specific page is called — then you’ll want to consider a module. For occasional or lightweight processing, such as serving up a low-use RSS stream, a handler will do fine. End of aside.)

So that’s what we’ll use here. Let’s begin by creating an ASP.NET HTTP handler, which is written in the same way one would write the code behind for an ASP.NET page, but uses the file extension .ashx.

Continue reading: Creating An ASP.NET RSS Feed, Using Data From SQL Server And HTTP WebHandler »

During today’s similcast of the ASP.NET Firestarter in Atlanta, G. Andrew Duthie discussed .NET 4′s new support for routing — or, what everyone in Web development calls “URL rewriting.” *

Someone online asked, “If I use routing, can I access query string variables using JavaScript?”

The question isn’t as confused as it sounds on the surface. Of course, if one uses routing / URL rewriting, it’s to remove query string variable and make them part of what appears to be a permanent file structure.

In other words, this:

http://www.server.com/path/to/file.aspx?v1=foo&v2=bar

Becomes this:

http://www.server.com/path/to/file/v1/foo/v2/bar/

The questioner really means, is there a way, after rewriting a URL, to extract key->value pairs from it via JavaScript? The answer is yes; rather than using the location.search property, which allows JavaScript to get the querystring parameters of a URL, we use location.pathname to get the part of the URL that follows the domain, and use that to create our key->value pairs.

Continue reading: Getting QueryString Values From A Rewritten URL / ASP.NET Routing URL »