Tag: bug

WordPress Error Fix(?): Increase PHP Memory for cache.php

Posted on February 17, 2008 in WordPress by Jeff Starr

This trick isn’t guaranteed to prevent all WordPress-generated PHP memory errors, but it certainly seems to help reduce their overall occurrence. For some reason, after my host upgraded their servers to Apache 1.3.41, I began logging an extremely high number of fatal PHPmemory exhausted” errors resulting from the WordPress cache.php script. Here is an example of the countless errors that are generated:

Continue Reading

How to Fix the Wonky Windows XP Clock

Posted on November 18, 2007 in Technology by Jeff Starr

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

Fixing Mint after Switching Servers

Posted on October 2, 2007 in Function, Websites by Jeff Starr

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

WP-ShortStat Slowing Down Root Index Pages

Posted on July 17, 2007 in Function, WordPress by Jeff Starr

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

Major Problem with cPanel Hotlink Protection and htaccess

Posted on July 1, 2007 in Function by Jeff Starr

There is a major problem with the “Hotlink Protection” feature of cPanel. To summarize the issue, allow me to quote a recent email sent to a completely unresponsive tech support department:

…The problem is that if I try to include any rewrite rules for permalinks, hotlinking, or blocking spambots, cPanel automatically enables its “Hotlink Protection” feature. And, even worse, it automatically adds every URL from every rewrite rule (even the ones for blocking spambots) to its “auto-discovered” list of URL’s for which image access is allowed. This means that every spammer that I am trying to block now has access to my images! If I try to remove the spammers directly from the “allow-image-access” list, the associated rewrite rules are automatically removed from my htaccess file, thus giving spammers full access to my entire site (instead of just access to images). So, it is indeed the case that I can’t add any rewrite rules to my site’s root htaccess file without cPanel automatically assuming that every URL on the page is related to hotlinking and subsequently adding them all to the “allow-image-access” list…

[ Image: Train Wreck ] In other words, cPanel screws up htaccess rewrite rules via its “Hotlink Protection” feature. More specifically, spammers and robots that are denied site access via root-htaccess rewrite rules are automatically listed in the “allow access to images” field of the Hotlink Protection panel. Not good. Even worse, disabling Hotlink Protection automatically removes every rewrite rule from the htaccess file. Such bizarre functionality forces the user to choose between complete hotlink protection and other essential features such as pretty permalinks or spam blocking. Pretty sucky if you ask us. Nonetheless, here is a concise summary of the problem with the cPanel Hotlink Protection (cHP) feature:

Continue Reading

Perishable Press Unresolved Error Log

Posted on January 15, 2007 in Perishable, Websites by Jeff Starr

This post is hereby dedicated to the official logging of all unresolved and/or unexplained errors encountered during development or implementation of various plugins, extensions, themes, scripts, and/or anything else that results in bizarre and mysterious errors, bugs, or other anomalies. Further, we will also post any potential solutions, fixes, workarounds, or explanations for any errors logged in this post. This information is provided for reference purposes only — please share any related information you may have concerning any of the errors described in this error log. Please use the comment form below or simply contact us directly. Thanks.

Continue Reading

Feed Tester

Posted on December 4, 2006 in Perishable, WordPress by Jeff Starr

Ignore this post..

[Edit] Note to WP 2.0.5 users: Everything was working fine on this site before upgrading to WP 2.0.5. After upgrading, apparently, our feeds stopped validating* and the BDP RSS Aggregator plugin refused to update our own feeds. After several hours investigating the situation, we determined that the Live Comment Preview plugin was interfering with our feeds validating, while the upgraded WordPress (2.0.5) was responsible for problems with the BDP plugin.

Here is a copy of our recent comment posted at the BDP plugin website:

Comment by m0n on Wednesday 6 December 2006 at 4:28 am

I was running BDPRSS v.0.2.2 just fine before upgrading to WP 2.0.5. After the upgrade, I noticed that feeds from my own site are no longer updated. They are apparently polled, but reflect a ‘last updated’ value of the day I upgraded WP. I have, since the WP upgrade, posted several new articles that appear fine directly, through feedburner, etc.

I have tried just about everything (restoring old BDP databases, deleting and adding new feed entries in the admin panel, deleting cache, you name it, etc.). I have also tried upgrading to BDP 0.4.10, but to no avail. My own feeds will not update either in the BDP admin panel or on the web page itself. Adding different feed formats does not work either.

So, just a note to hopefully garner some more clues concerning this. I realize it may not be an emergency, because who reads their own feeds for crying out loud. Perhaps there are others out there with the same problem. If possible, try adding any of your own feeds (on WP 2.0.5) and see if they work. Well, thanks for listening!

The whole event pretty much zapped the weekend of any free-time, but the good news is that we managed to get everything working properly (according to our needs) once again — feeds all validate and we have previews of our own feeds via the BDP plugin — and we are still running WP 2.0.5! We’ll just bill the incident as another 8-hour "learning experience"..

If anyone is experiencing anything similar to the issues mentioned in this post, we would love to hear about it — drop us a line!

Update: [ May 28th, 2007 ] - Issue resolved! After moving the Perishable Press website to a new server, our WordPress feeds once again began updating directly through our own site (via BDP plugin, et al). Apparently, as our previous host continued to disable important PHP functions (as a solution to potential security vulnerabilities), the various plugins and scripts employing the disabled functions inevitably became useless. Thus, we attribute the source our non-updating feed issue directly to server limitations (and lazy technicians). While we cannot at this point discern exactly the cause of the problem, suffice it to say that our new host provides all the functionality needed for everything to run properly (and smoothly, we might add). So cheers to everyone who helped us with suggestions and ideas for this bizarre dilemma. We now enjoy fully functional and validating WordPress feeds. Case closed.

Footnotes

CSS Hack Dumpster

Posted on August 27, 2006 in Presentation by Jeff Starr

Consider this page a virtual dumpster of wonderful CSS hacks..

Commented Backslash Hack V2

This hack effectively hides anything after the “\*/” from MacIE5:

/* commented backslash hack v2 \*/
div#something {
   boder: thin solid red;
}
/* end hack */

May also be used for CSS import directives:

<style type="text/css">
/* commented backslash hack v2 \*/
   @import url(http://www.site.com/stylesheet.css);
/* end hack */
</style>

Fix Division Widths in IE

Fix IE’s crazy box rendering. The first line limits to only IE. The second line

* html div#somediv { /* limits to all IE */
   width: 300px; /* width for WinIE5.x */
   w\idth: 333px; /* width for other IE */
}
div#somediv {
	padding: 33px;
	width: 377; /* width for all other browsers */
}

IE Double Float Bug

IE doubles the margin of any divs floated in the same direction. Great. To fix it, simply display the floated element as inline.

Clearing Divisions

Here are four relatively equally effective methods for clearing unruly divisions:

<div style="clear: both;">&nbsp;</div>
<br style="clear:both;" />
<hr style="clear:both;" />
div#unrulydiv {
   overflow: auto;
   height: 100%;
}

Clearing Floats

div.fix:after {
   content: ".";
   visibility: hidden;
   display: block;
   clear: both;
   height: 0; 
}
div.fix { display: inline-table; }
/* Hides from IE-mac \*/
* html div.fix { height: 1%; }
div.fix { display: block; }
/* End hide from IE-mac */

Or, you could float the parent div, and perhaps any other parents of the parent div — i.e., the float nearly everything method.

Box Model Hacks

IE versions below 6 render element width values to include borders and padding. This hack utilizes comment hacks to hide from all IE5.x:

div#somediv {
width: 33px; /* width for all browsers */
width/**/:/**/ 77px; /* first hide from IE5.0 then hide from IE5.5 */
}

Target Safari/Webkit/KHTML

body:last-child:not(:root:root) div {
	rules: target Safari/Webkit/KHTML only;
}

Target Firefox

This hack targets the body element in Firefox 1.5 & 2.0 only, but is not valid CSS2/CSS3:

/* targets body element in Firefox 1.5 & 2.0 only - invalid CSS2 & valid CSS3 */
body:empty {}

Target/Filter only Internet Explorer 7

Here are several hacks that target IE7, some valid CSS, some not (see code comments for details):

/* targets body element in IE7 only - invalid CSS */
>body {}
/* targets IE7 only - valid CSS */
*:first-child+html {}
/* targets IE7 & modern browsers only - valid CSS */
html>body {}
/* filters IE7, targets other modern browsers - valid CSS */
html>/**/body {}

Target/Filter only Internet Explorer (IE7 and below)

Here is our growing collection of hacks targeting all Internet Explorer, including IE7 and below:

/* targets all descendants of the html element in IE7 & below - invalid CSS */
html* {}
/* applies property in IE7 & below - invalid CSS */
selector { attribute: property !ie; }
/* applies property with importance in IE7 & below - invalid CSS */
selector { attribute: property !important!; }
/* targets IE7 & below - valid CSS */
a:link:visited, a:visited:link {}
/* may be used to target any element */
#target:link:visited, #target:visited:link {}
/* targets IE7 & below - valid CSS */
*:first-child+html {} * html {}
/* applies property in IE7 & below - invalid CSS (this hack is not recommended) */
*property: value;
/* imports stylesheet in all major browsers except IE7 & below */
@import "non-ie-styles.css" all;

Target only Internet Explorer 6 and below

/* applies property in IE6 & below - invalid CSS */
_property: value;
/* applies property in IE6 & below - invalid CSS */
-property: value;
/* targets IE6 & below - valid CSS */
* html {}
selector { 
	attribute: property !important; /* targets all major browsers */
	attribute: property; /* targets IE6 & below - this value overrides previous value */
} 

Filter Opera / Target Opera

This hack filters Opera (9 and below) and targets all modern browsers including IE7:

/* selects body element with class page-body in IE7 & all modern browsers except Opera 9 & below */
body[class|="page-body"] {}

Conversely, this hack targets Opera 9 and below:

/* targets Opera 9 & below - valid CSS */
html:first-child {}

Fun with the input (disabled) element

Employing the disabled attribute of the input element, it is possible to target a wide range of specific browser types. Given this (X)HTML markup:

<input type="hidden" disabled id="dis" />
<p>target element</p>

..it is possible to target and filter our CSS by using any of these hacks:

/* filters IE7 & below - see below for more info */
input[disabled="disabled"] {} 

/* Firefox 1.5 & below, Safari 2.0 & below, Konqueror 3.5 & below (and perhaps future versions of these browsers) - valid HTML & invalid XHTML */
#dis[disabled=""]+p {}

* targets Opera 9 & below (and perhaps future versions) - valid HTML & invalid XHTML */
#dis[disabled="true"]+p {}

More to come!

Lightbox + FancyTooltips Bug Fix

Posted on July 25, 2006 in Function, WordPress by Jeff Starr

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 copy1 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

  • 1 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.