In my previous article on redirecting 404 requests for favicon files, I presented an HTAccess technique for redirecting all requests for nonexistent favicon.ico files to the actual file located in the site’s web-accessible root directory:

# REDIRECT FAVICONZ
<ifmodule mod_rewrite.c>
 RewriteCond %{THE_REQUEST} favicon.ico [NC]
 RewriteRule (.*) http://domain.tld/favicon.ico [R=301,L] 
</ifmodule>

As discussed in the article, this code is already in effect here at Perishable Press, as may be seen by clicking on any of the following links:

• http://perishablepress.com/press/favicon.ico
• http://perishablepress.com/press/2007/06/12/favicon.ico
• http://perishablepress.com/press/2007/09/25/absolute…css/favicon.ico

Clearly, none of these URL requests target the “real” favicon.ico file, yet thanks to the previous method they are all happily redirected to the proper location. This is useful for a variety of reasons, including preventing excessive and unnecessary server strain due to malicious scripts.

Continue Reading

For the last several months, I have been seeing an increasing number of 404 errors requesting “favicon.ico” appended onto various URLs:

http://perishablepress.com/press/favicon.ico
http://perishablepress.com/press/2007/06/12/favicon.ico
http://perishablepress.com/press/2007/09/25/absolute-horizontal-and-vertical-centering-via-css/favicon.ico
http://perishablepress.com/press/2007/08/01/temporary-site-redirect-for-visitors-during-site-updates/favicon.ico
http://perishablepress.com/press/2007/01/16/maximum-and-minimum-height-and-width-in-internet-explorer/favicon.ico

When these errors first began appearing in the logs several months ago, I didn’t think too much of it — “just another idiot who can’t find my site’s favicon..” As time went on, however, the frequency and variety of these misdirected requests continued to increase. A bit frustrating perhaps, but not serious enough to justify immediate action. After all, what’s the worst that can happen? The idiot might actually find the blasted thing? Wouldn’t that be nice..

Continue Reading

Several days ago, I posted an article explaining how to hack your own WordPress nofollow blacklist. Immediately thereafter, I published an elaborate article focusing on automatic methods of nofollow blacklisting via WordPress plugins. In this article, I expand on the original blacklist hack by incorporating functional differentiation between commentator links, trackbacks, and pingbacks. If anything, think of this as an exercise in hacking WordPress, rewarding in and of itself, if not otherwise entirely impractical. Of course, whenever possible, you should avoid hacking the WordPress core and install a plugin instead. ;) Nonetheless, it’s so much fun to hack that we simply could not resist posting just one more article involving nofollow attributes. But alas, we really should be moving along..

Continue Reading

Before repenting of my filthy “nofollow” addiction, I experimented briefly with a “dofollow whitelist” for commentator URL links. The idea behind the whitelist is to reward frequent commentators, feed subscribers, site patrons, and other guests by selectively removing the automatically generated nofollow attributes from their associated comment-author links. For nofollow enthusiasts, a dofollow whitelist is a great way to show appreciation for people who support your blogging efforts.

Now, before we go hacking away at WordPress, keep in mind that there are a few potential shortcomings to this method. First of all, manually maintaining such a list would eventually fail. It simply would require too much work. Perhaps as an automated WordPress plugin, a dofollow whitelist would be a reasonable solution. A dofollow whitelist plugin would also eliminate the need to hack the WordPress core, which the following hack definitely requires. Other issues involve duplicate author names and user verification. Nonetheless, even as an elementary WordPress hack, a dofollow whitelist for comment signature links may prove useful. Here are a few examples:

Continue Reading

Previously, in our unofficial “WordPress dofollow upgrade” series, we dished several techniques for removing the antisocial nofollow attributes from default installations of WordPress. After an exhaustive review of available dofollow plugins, we explained how drop-dead easy it is to transform any WordPress blog into a well-standing member of the dofollow community without relying on a plugin to do the job. Our next article detailed a nofollow removal hack selectively targeting pingbacks, trackbacks, and commentator links. Then, we went off the deep end with a robust, threefold hack for sitewide nofollow extermination. Now, in this article, we merge several of these methods to implement a “nofollow blacklist” for trackback, pingback, and commentator links.

Why would you want to create a nofollow blacklist? There are several scenarios in which such a strategy would benefit a dofollow-friendly WordPress site. After upgrading to dofollow status, you should experience an increase in the number of comments left at your site. Although this is generally beneficial, there remain those gutless worms who would seek to game your generous link-love with hollow remarks, empty chatter, and other useless nonsense. Rather than waste pagerank and make a big stink, quietly blacklist offenders until they change their mindless ways. Simply put, a nofollow blacklist protects your dofollow site while reinforcing positive comments.

Continue Reading

Encourage Comments by Completely Eliminating All Nofollow Links

Want to remove all traces of the hideous nofollow attribute without having to install yet another unnecessary plugin? By default, WordPress generates nofollow links in three different ways — this article will show you how to eliminate all of them..

Some context please..

Note: if you are already familiar with the various functions involved in the nofollow-removal process, please feel free to skip the proceeding discussion and jump directly to the tutorial.

WordPress adds nofollow to all trackbacks, pingbacks, and commentator links

We have seen how simple it is to eradicate nofollow from comment-related content, which includes the three different types of $author URLs: trackbacks, pingbacks, and commentator links. In fact, WordPress generates hyperlinks for each of these comment-author URLs via the function get_comment_author_link(), which is conveniently located in the file wp-includes/comment-functions.php in WordPress 2.0 and wp-includes/comment-template.php in WordPress 2.1 and 2.2:

Continue Reading

After our previous article, we all know how easy it is to kill the default nofollow attributes that WordPress automatically injects into all commentator, trackback, and pingback links. Indeed, our original one-minute upgrade delivers dofollow links across the board, effectively passing the love juice to every type of response. Fine for some, but some need more..

In this article, we improve the original dofollow upgrade by differentiating between the three different response types. With our “deluxe” model, nofollow attributes may be removed selectively from trackbacks, pingbacks, commentator links, or any combination thereof. For example, you may remove nofollow from commentator links while dishing full juice to trackbacks and pingbacks.

Ready? Let’s do this thing..

Continue Reading

Want to upgrade your blog to official dofollow status but don’t want to install another unnecessary plugin? This article explains how to eliminate nofollow tags from all trackback, pingback, and commentator links in less than one minute..

After finally repenting of my nofollow sins, I began looking for the best way to eliminate the nofollow attributes that WordPress automatically injects into all commentator URL links.

Of course, the most popular technique for removing nofollow attributes from comment links involves one of the many fine dofollow plugins that are freely available to WordPress users. Beyond nofollow removal, many of these plugins also provide additional features, such as control over when and where nofollow tags should be removed. Many of these plugins are highly recommended.

After considering the various dofollow plugins, I came to the conclusion that most of them were simply overkill. My goal was to remove all nofollow attributes from commentator links — nothing more, nothing less. For this site, I just don’t need all the fancy bells and whistles. And I certainly don’t need yet another resource-draining plugin to worry about..

Continue Reading

For over a year now, I have been using Markus Kämmerer’s (Happy Arts Blog) WP-ShortStat plugin for WordPress. The plugin is relatively well-maintained and remains one of my favorite admin tools. Great for popping in on stats without logging into Mint. Nonetheless, due to its IP/country-detection functionality, WP-ShortStat has experienced its share of difficulties (e.g., read through the change log on the plugin’s home page). In this article, I describe how WP-Shortstat slows down the root index-page of a site, and then suggest a (temporary) fix for the issue.

Continue Reading

Firefox extensions enable users to customize Firefox with additional features. Generally, Firefox extensions are free, open-source, and easily downloaded as .xpi files. This article explains how to hack Firefox extensions of the .xpi variety. There are many reasons why someone would want to hack a Firefox extension — examples include: editing code, debugging errors, and learning extensions. This hack method requires a web browser, zip utility, and text editor.

Step 1: Secure an extension

By default, the Firefox browser will cache and attempt to install any "extension.xpi" file it encounters. Once Firefox installs the plugin, it becomes much more complicated to hack. Therefore, it is best to save an offline copy of the extension. This is easily accomplished with a browser such as IE that does not automatically install the extension, but rather provides an option to save a copy. With IE, simply right-click the extension.xpi link and "Save Target As..". Regardless of the method, the point here is to secure a local copy of the extension.xpi file. Remember to make a backup copy.

Step 2: Initial extraction

Once you have a willing extension.xpi file, open it with a zip utility and extract the files into some directory, say, "/xpicontents/". Within the /xpicontents/ directory there should be at least a "chrome" folder, an "install.rdf" file, and a "licence.txt" file. Certain extensions may include additional and/or different files or folders. If anything looks too unfamiliar, extrapolate the method or find a different extension to use as you follow along.

Step 3: Editing the .rdf file

At this point, you have everything needed to edit the install.rdf file. Simply open the file in a text editor, make/save changes, zip the contents of /xpicontents/ into a new file, and change the file extension from .zip to .xpi. On the other hand, editing virtually any other aspect of the extension — JavaScript, CSS, (X)HTML — requires further digging.

Step 4: Hacking the .jar file

Located within the chrome folder, the "something.jar" file contains a variety of files, including JavaScript, CSS, (X)HTML, etc. Most extension editing will ultimately find its way to one of the files contained within the extension’s .jar file. So, to begin, rename the something.jar file to "something.jar.zip". Then, using a zip utility, open the something.jar.zip file and extract its contents into a unique directory, say, "/jarcontents/". Within the /jarcontents/ directory there should be at least two folders, "content" and "skin". Now, dive into the contents folder (or the skin folder, if needed) and edit, hack, and tweak the files to your heart’s content.

Step 5: Repacking the extension

After the necessary edits have been made, it is time to put humpty back together again. The first step is to replace the original contents of the something.jar.zip file with the freshly edited contents. To do this, select both content and skin folders (or whichever contains the edited material), right-click and add the selected folders to the something.jar.zip file located within the /jarcontents/ directory. Then, rename something.jar.zip back to something.jar.

At this point, you are ready to (re)package the chrome folder, install.rdf file, and license.txt file into a new .zip file, which we will call "hacked-extension.zip". To do this, simply select all three items and zip them into a new file named hacked-extension.zip. Finally, rename hacked-extension.zip to match exactly the name of the original extension, extension.xpi.

Step 6: Installation and testing

Once the necessary edits have been made, it is time to install the extension. Open Firefox, drag-and-drop the extension, and click OK to install. Restart Firefox, activate the extension, and check its functionality. Lather, rinse, repeat. It may be a good idea to test the hacked extension under a variety of different user conditions. Or not. Whatever. At this point, it’s entirely up to you. You may also want to save a copy of the original extension together with your hacked extension along with a few notes, just in case.

Well that’s it for now — thank you for your gracious attention. God bless.

References

• Hacking Firefox Extensions Book
• GUID Generator Web Service

For those of us enjoying the stylish functionality of Lightbox or any of its many incarnations, images "magically" overlay the window and unfold, revealing navigational buttons, image count, and of course the image titles.

For those of us enjoying the stylish functionality of FancyTooltips or any of its many incarnations, title and alt attributes manifest as stylish displays of CSS brilliance.

However, for those of us employing both features, there is a potential JavaScript conflict. This conflict makes it impossible for Lightbox to display the contents of title attributes associated with images. Thus, if you are employing Lightbox (or one of its many variations) and FancyTooltips (or one of its many variations), image titles will be missing from your Lightbox-displayed images. If this is the case, everything else (nav buttons, number display, close button) will display properly, including the "fancy" tooltips. If this sounds like your situation — missing Lightbox titles — we have good news..

Fortunately, the "fix" for this "bug" is relatively simple. Before getting to that, it is important to explain two things: (1) cause of the conflict and (2) verification of the conflict. Keep in mind that we are attempting to extrapolate from several specific scenarios to many possible configurations. So, if this article fails to fix your specific setup, hopefully it will provide insight toward an individually deduced solution.

First, let's examine the cause of the conflict. Generally speaking, JavaScript-based tooltip enhancement involves replacing title and/or alt attributes with author-specified "hooks" that enable scripts to function. For example, the FancyTooltips script rewrites all title="" attributes as fancytooltip="", thereby enabling the FancyTooltips script to recognize and act upon such attributes exclusively.

The problem is that once all of the title="" attributes have been replaced with script-specific hooks, Lightbox no longer recognizes them, making it impossible to display their contents. Hence the mysteriously missing Lightbox titles. To verify this, use your browser's "Save Page As…" feature to save an offline copy¹ of a page that uses both Lightbox and FancyTooltips (or any other similarly conflicting scripts). Then, examine the source code of the offline copy and look for title="" attributes replaced by fancytooltip="". If you find that the title and/or alt attributes have indeed been rewritten, read on for the fix!

The Fix

Now that you hopefully understand the nature of the dilemma, it is time to completely eliminate the conflict.

Open your lightbox.js file and scroll down to around line #333, searching for the following:

// if image is NOT part of a set..
if((imageLink.getAttribute('rel') == 'lightbox')){
	// add single image to imageArray
	imageArray.push(new Array(imageLink.getAttribute('href'), imageLink.getAttribute('title')));			
} else {
// if image is part of a set..
	// loop through anchors, find other images in set, and add them to imageArray
	for (var i=0; i<anchors.length; i++){
		var anchor = anchors[i];
		if (anchor.getAttribute('href') && (anchor.getAttribute('rel') == imageLink.getAttribute('rel'))){
			imageArray.push(new Array(anchor.getAttribute('href'), anchor.getAttribute('title')));
		}
	}
	imageArray.removeDuplicates();
	while(imageArray[imageNum][0] != imageLink.getAttribute('href')) { imageNum++;}
}

Now, near the end of the fourth line, replace title with fancytooltip. Then, likewise, near the end of the eleventh line, replace title with fancytooltip. You're done. Upload the file and check tooltips and Lightbox images. You should now be enjoying titles in your image popups and titles in your fancy tooltips. Note that this easy fix may be generalized to any set of similarly conflicting scripts. Simply determine the rewritten attributes by saving an offline copy and then search for & replace the offending values in the corresponding scripts.

This article is a work in progress. Please contribute any helpful information by leaving a comment below or via the Contact form. God Bless.

Footnotes

• ¹ In general, offline copies are very useful troubleshooting tools, as they represent the code after scripts have acted upon it, thereby offering a more accurate view of what the browser actually interprets.