The other day, my server crashed and Perishable Press was unable to connect to the MySQL database. Normally, when WordPress encounters a database error, it delivers a specific error message similar to the following:

Continue Reading

Note: This information is intended primarily for WordPress versions previous to 2.3, but may be applicable in other versions as well.

For those of you running an older version of WordPress that is generating errors such as:

Warning: parse_url(http://) [function.parse-url]: Unable to parse url in /home/path/to/public_html/wordpress/wp-includes/functions.php on line 1067
Warning: parse_url(http://) [function.parse-url]: Unable to parse url in /home/path/to/public_html/wordpress/wp-includes/functions.php on line 1067
Warning: parse_url(http://) [function.parse-url]: Unable to parse url in /home/path/to/public_html/wordpress/wp-includes/functions.php on line 1067 
Warning: parse_url(http://) [function.parse-url]: Unable to parse url in /home/path/to/public_html/wordpress/wp-includes/functions.php on line 1067 
Warning: parse_url(http://) [function.parse-url]: Unable to parse url in /home/path/to/public_html/wordpress/wp-includes/functions.php on line 1067 
Warning: parse_url(http://) [function.parse-url]: Unable to parse url in /home/path/to/public_html/wordpress/wp-includes/functions.php on line 1067 
Warning: parse_url(http://) [function.parse-url]: Unable to parse url in /home/path/to/public_html/wordpress/wp-includes/functions.php on line 1067 
Warning: parse_url(http://) [function.parse-url]: Unable to parse url in /home/path/to/public_html/wordpress/wp-includes/functions.php on line 1067

You can easily resolve the issue by suppressing these errors, which are automatically generated whenever the parse_url() function tries to parse an empty value for the URL. To silence the errors, open the file wp-includes/functions.php and locate the following code (around line #1067):

Continue Reading

I don’t know about you, but ever since the 2007 change in daylight savings time, my installation of Windows XP has had a difficult time (so to speak) maintaining consistently accurate time. Ever since the change, Windows XP has been randomly resetting its clock (as indicated via the Taskbar) to display time incorrectly. Specifically, WinXP will automatically (i.e., without user intervention) set the time to be one hour earlier than the actual time. For example, if the time is actually 3:00pm, Windows will suddenly display the time as 2:00pm. This has caught me off-guard on several occasions now, as I would work with an incorrect assumption concerning the time, only to find myself running an hour late to an appointment. Clearly, something needs to be done..

The first thing that comes to mind is to switch operating systems. For reasons that extend far beyond wonky time-keeping, I have been wanting to switch to open-source for years. If you have the luxury, time, and resources to accommodate such a switch, then perhaps Linux or Mac will serve you better with much more than the keeping of accurate time.

Continue Reading

After switching Perishable Press to its current home at A Small Orange, I began noticing an unusual problem with referrer data displayed in Mint. Specifically, the first item recorded in the XXX Strong Mint data panel — for both “Most Recent” and “Repeat” views — displayed several thousand hits for various site resources, all from the following IP address:

127.255.255.255 
zxw59eit.emirates.net.ae

Apparently, this particular location represents an invalid “loopback address.” The requested resources appear valid, indicating typical traffic patterns, but the loopback address is not the actual referrer. This issue was preventing Mint from accurately recording mountains of vital referral data.

Researching this issue reveals that the underlying problem involves the switching of a Mint installation between a 32-bit server and a 64-bit server. Installing Mint on either type of server without switching to the other should not trigger this problem. It is the switch from one to another that results in the generation of the loopback address.

Continue Reading

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.