Even these days, WordPress will often mess with HTML code entered into posts or pages. The most persistent problem I’ve found has been its penchant for inserting <br /> tags inside forms.

No, I’ve not found a way to stop it. Just a slightly lateral workaround: create the following generic class in your stylesheet and apply it to any form (or other containing element) where unwanted <br />s are being slipped in:

.nobr br {display: none;}

If you’re using <br /> tags yourself in that bit… well, you can always use a bit of a margin, eh?

Being a die-hard hand-coder, WYSIWYG editors irk me. It’s partly an irrational “Get your mits off my code!” thing, but it’s often very practical.

Working with WordPress, many of the sites I deploy for clients need specific layout code within the editable content of WP-managed pages. The code is necessary, and the clients are savvy enough to work around my HTML when they edit their copy.

WP’s visual editor, however, isn’t. It switches any <div> for a <p>, and otherwise messes stuff up. Maybe there’s a way to coax it into being less interfering. But for now I just need to get the visual editor out the way.

In theory that’s fine - each user just has to uncheck the visual editor box on their WordPress profile. It’s set to be checked by default when a new user is created. It already happened several times that a client has forgotten to do this, gone to edit a tiny bit of copy on the delicately coded home page, only for the editor to mess it all up.

Can’t I just set visual editing to be “off” by default?

Here’s how. In the file wp-admin/admin-functions.php, change line 522 from this:

$user->rich_editing = ‘true’;

To (unsurprisingly) this:

$user->rich_editing = ‘false’;

One of the steps backwards taken with CSS is control of vertical stuff. Getting coloured sidebar and content areas to be equal height even when their contents are vertically unequal, and vertically centering something in a box are just two things that are (1) dead easy with tables, (2) quite common design requirements, and (3) a bit fiddly at best with current CSS standards.

Things may be changing with new CSS standards, and with the evolution of various hacks and workarounds. Anyway, I just found a solution for a site I’m working on which seems to work well in this instance. I may have reinvented some wheel or other, but here it is.

The design involves a content area and sidebar looking a bit like this (scaled down & simplified here!):

My solution is partly based on the common technique of using a vertically repeated background image to delineate the sidebar and content areas. This usually puts the image as the background of the body tag, giving top-to-bottom vertical columns. Here, I need the rounded top and bottom, and there’s the header and footer (not shown here) to account for, too.

Here’s the markup for my solution:

<div id="main-top"></div>
<div id="main">
<div id="content">
[content here]
</div>
<div id="sidebar">
[sidebar here]
</div>
<div id="main-bottom"></div>
</div>

main-top and main-bottom take care of the rounded top and bottom, with full-width background images and a fixed height (not forgetting the Expanding Box and min-height fixes for good ol’ IE 6).

main is given a vertically repeated background image, about 5px high, for the sidebar’s gradient and the white background for the content. (This design actually has a slight vertical gradient in the content area, too. Setting it as a non-repeating top-aligned background image for content, and giving content a min-height equal to the image’s height, sorted that out.)

The content and sidebar are floated right (don’t forget IE’s double float margin bug!).

The key here is setting main-bottom to clear:both and - my new (for me) innovation - placing it inside the div with the class main. It clears the content and sidebar, exposing the repeated background on main.

Hey presto, equal-height content and sidebar.

Just solved a pesky email problem that was really vexing.

Sending email from my localhost web server (usually via ColdFusion apps), for testing and other purposes, has always worked swimmingly. Recently, however, emails sometimes didn’t send. A glance at my ColdFusion log files showed the error “Invalid Addresses”.

Some addresses from some of my domains have started to be used extensively for sending spam (by other people!), so I wondered whether I’d got blacklisted somehow.

A blacklist was involved, but not for addresses. A closer look at the CF error logs showed this:

Invalid Addresses; nested exception is: class javax.mail.SendFailedException: 550-xx.xx.xx.xx is listed at zen.spamhaus.org (127.0.0.11: 550 http://www.spamhaus.org/query/bl?ip=xx.xx.xx.xx)

The x’d out bits are my current IP address. Spamhaus.org seems to be a large spam-fighting clearinghouse, with, among other things, IP blacklists. Looking up my IP address on their database found it listed.

The solution is to add SMTP authentication to your outgoing mail script. For ColdFusion, it looks something like this:

<cfmail to=”user@domain.com” from=”noreply@domain.com” subject=”Message subject” server=”smtp.domain.com” username=”noreply” password=”password”>
… message …
</cfmail>

(Obviously, with suitable bits substituted for your situation…)

I’ve just been reading about possible clashes between the CSS “image replacement” technique that I use and Google’s rules about spam techniques.

Image replacement involves using CSS to hide the text for an element (e.g. a <h1>), and setting the background-image for that element to replace it with an image. Users with visual browsers with CSS get the image; text-only browsers, bots, etc., just see plain text.

It’s not without its detractors and slight drawbacks, but it’s a widespread technique. A quick scan of big-name sites as of writing found it in evidence on stopdesign.com, mezzoblue.com and adobe.com.

However:

Hiding text or links in your content can cause your site to be perceived as untrustworthy since it presents information to search engines differently than to visitors. (Google Webmaster Help Center)

This obviously caused some panic among developers using image replacement. While Google seem to have made some comments saying that they would distinguish between legitimate usage and spamming, they’re pretty vague about what constitutes one or the other. The ever-informative 456bereastreet.com have a good summary. But while their conclusion is quite reassuring, it’s two years old - an aeon in web technology - and still vague:

While it’s good to know that sites are not currently being removed without a manual review, that could change in the future. So I would advise anyone making extensive use of CSS techniques that hide text to make sure that it can’t be mistaken for spamming.

How do you make sure? They don’t say.

More recently, SEO Critique took the approach of checking out high-profile designers with close links to Google and seeing if they used image replacement:

Rand Fishkin at SEOmoz does use CSS image replacement on the SEOmoz.org site, albeit sparingly. … I figure that Rand goes to enough conferences and has enough interaction with Googlers like Matt Cutts and Vanessa Fox that if there was a danger of imminent death by penalty he would know and would quickly order the offense removed. Hence, used sparingly and in the strict spirit of If a Blind Person Were Using a Text Reader How Would It Sound? My opinion is that using CSS image replacement is probably okay.

Probably not an issue to get panicked about, then, but one to keep your eye on. I’ll carry on using it judiciously until further notice.