I recently had to do some upgrades on very old Joomla sites, which were running an outdated version of Joomla 1.5.
Due to the circumstances of the upgrade, I ended up having some issues with missing plugins and had to basically recreate the site.
After everything was up and running, I got an error indicating that the “onDisplay()” method was undifined.
The basic error is here:
Fatal error: Call to undefined method stdClass::onDisplay() in /wour_website_directory/libraries/joomla/html/editor.php on line 268
This error is caused by Joomla attempting to register a plugin on the editor page, which is missing or otherwise invalid. On this page, Joomla loops through installed plugins and one of the ones that it thinks is installed, as per the mysql database, is actually missing.
To fix this, you need to identify the bad plugin and disable it.
The easiest way to do this is to change line 268 to print the name of the plugin in the event of an error.
Change line 268 of editor.php from:
$resultTest = $plugin->onDisplay($editor);
To:
//$resultTest = $plugin->onDisplay($editor);
if (method_exists($plugin, 'onDisplay')) {
$resultTest = $plugin->onDisplay($editor);
}
else{
$resultTest = false;
echo '<h4>Bad Plugin: '.$plugin->name.'</h4>';
}
This comments out the original line 268, see the part with “//,” and then checks to see if the class method named “onDisplay” exists before attempting to use it.
If it is not installed correctly, you will see the plugin name printed and can disable(or reinstall) it via the plugin manager.
The plugin name printed may not be identical to its actual name as seen in the plugin manager, but you should be able to tell what it is and then disable or reinstall the missing plugin.
Blank Page when Editing Article
Many other editor related errors, including just getting a white page when editing an article, can be fixed by downloading and reinstalling the Joomla Content Editor JCE, or one of the other editors, like TinyMCE.
Using Image Buttons in an Email
April 27, 2012
I am working on a project now that integrates recent vbulletin forum posts, as well as some other items, into an email, which is then sent out to members who have subscribed to receive this daily update.
I started by cleaning up the code, fixing styling and html errors, which is especially important when sending via email. There were a bunch of miss-closed html elements, like tables that were nested incorrectly, as well as a lot of invalid css. After the cleanup, I began making the requested changes and am now fine-tuning some design issues.
Since Outlook 2007+ uses Microsoft Offices rendering engine, it is necessary to do a bit of testing/fixing just to work with the broken HTML implementation and is, of course, no surprise that the design looked pretty off.
However, one thing that did surprise me was the way that Outlook 2007, and apparently higher, retrieve and cache images. When the email was loaded in Outlook 2007, it took forever to load and there ended up being a bunch of broken images.
In this case, the folks who had worked on the email before used a set of image buttons below each post, so depending on how many subscriptions you have, you might see those buttons well over 50 times in the email, which 5 or so different buttons in a row, this means those images might appear several hundred times in the email.
Since Outlook took forever to load and when it finally did, many of the image buttons were missing, I decided to check the http access logs and see if anything weird was happening. After a few quick greps, it seems like Outlook does not cache images, but instead simply reloads them again and again and again! This falls in line with the observations below, as in the first half of the email, the buttons loaded correctly, while the second half the same buttons appeared broken.
Now, this is, of course, one very good reason not to use image buttons like this in an email and we will be changing the design to remove these. However, it would still seem like the email client would be smart enough to cache the images.
After spending a bit more time checking, I soon found that it looks like Safari for OSX does the same thing. There are several users who use it and when checking the raw access logs, the buttons were requested repeatedly over the course of a few seconds. Since there is no referrer, it would appear these are loaded via a web-mail client, but this will require some more testing.
In any-case, the take-away is that using image buttons for something that might appear many times in an email is always a bad idea!
Use Dreamhost? Check Your Websites for Malicious Code!
March 1, 2012
If you are using Dreamhost, you should check your website for malicious php code and redirects!
There is currently a prevalent hack going around that affects many websites on Dreamhost.
The most common hack seems to be the basic search bot redirect, so anytime Google bot, or other search bots, visit the website, they get served different content. Most likely it will be links to spam pharma sites, as well as links to other hacked websites.
From reading, a lot of folks seem to be waiting/expecting support to fix their website, but this is not something you should wait on!
Table of Contents
- Who is Affected?
- How did this Happen?
- Is This Specific to Dreamhost?
- Support Not Doing Anything? Or Overwhelmed?
- What to Look For?
- How to Clean Up
- My Website is Not Hacked, Should I Still Check?
- Going Forward
- You Are Speaking Gibberish! Please Help!
- Thoughts on Dreamhost
From searching twitter and Dreamhost’s forum, where a 12 page and counting thread of those affected is present, you can see that many people at dreamhost are affected.
While the default response from support is, of course, “you had outdated software or a bad plugin,” this does not wash.
For one, some people, including myself, had websites that were updated and running no plugins or only minimal plugins that were affected. Some even report having no CMS at all and still being hacked.
Further, in my case, I had the same web-shell dropped across multiple users accounts and websites. Only one of which was in sore need of updating, although it was running a 3.1+ wordpress install and had been updated within the month.
Given this, it seems much more likely that something much bigger is wrong with Dreamhost’s hosting platform. Short of a Zero Day on wordpress, in which case the hacks would probably be much more distributed, this seems like the more logical solution.
The official response from Dreamhost support seems to be “you were using vulnerable code and it is your responsibility to keep it secure.”
However, given the reports, which include those who claim that they were not running a CMS or running an up-to-date CMS and were still infected, I think there is a bigger issue at play. My anecdotal evidence, which included several reasonably updated websites, as well as finding the same web-shell dropped onto a number of unrelated websites/user accounts, seems to confirm this suspicion.
Dreamhost has had a number of issues with down-time, as well as a serious hack that exposed many user’s shell passwords, so it is not a leap to assume that their hosting platform systems were heavily compromised.
In my case, I changed my shell passwords twice, once immediately after the report and again shortly after that. I think, as I mentioned above, a zero day in WordPress might also be responsible, but this is not likely and would probably be more common across web hosts.
Is This Specific to Dreamhost?
No, if anything it is an issue that highlights problems with Shared Hosting.
I have cleaned up similar attacks on Media Temple, as well as other hosts, where, apparently, the issue was not specific to the user, but rather drive-by maleware.
Support Not Doing Anything? Or Overwhelmed?
While they do reply with a standard form letter, as well as checking your account for web-shells, they appear to be in damage control mode.
I sent them a list of 5+ other Dreamhost websites that I found that were also hacked and as of 48 hours later, I have not received a response from support, nor have these websites been fixed or disabled. Depending on the scope of the problems with Dreamhost’s platform, this may mean they are affecting other user accounts too.
With that said, I understand that Dreamhost’s support, which has always been pretty great in the past, is probably getting slammed right now.
Many people, from reading the forums, are not competent to fix the problem themselves and are instead waiting for Dreamhost to fix it. Again, depending on the scope of the problem, this might only make it worse.
Personally, if it were my server, I would be actively going in and finding/disabling web-shells and trying to clean it up, without waiting for user’s to notice their website was hacked. Maybe they are, but this does not seem likely.
Update: 72+ hours in, they responded by saying they were running scans on 2 domains that I provided. I sent over 5+, so it is unclear whether they scanned these too…
There are a few things you can check for.
If you have shell access, you can probably see by checking out the web-root and/or htaccess files, that something is amiss. You may see random files/folders that you know are not correct. However, it is possible that they may be hidden within other folders, so you will probably need to do some checking. Reviewing the logs can also help, as you may see the hidden files/folders in there.
You can also visit your website with a Googlebot User Agent. If it has been hacked, you will likely see a much different website than you are used to.
Since it is possible the hack might attempt to install maleware on your computer, you should disable javascript before you visit it. Or, use wget like so:
wget --user-agent="Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" http://www.your_website_url
wget will download the file, saving it as index.html and then you can view it in a text editor to compare it against the main website.
Even if the website is not hacked, you should still check all folders, delete and reinstall plugins/cms, and check any remaining theme files. In my case, I had several web-shells hidden in multiple websites, which appear to have not been activated yet.
Realistically, before cleaning up, you should investigate the files/folders/logs. Try to determine when the site was hacked, identify IP addresses, and check for any world-writeable files/folders.
TLDR: Backup, Delete and reinstall all software/plugins, Manually check any remaining files/databases, Ensure permissions are correct
This is a process for cleaning up wordpress, but similar concepts can be applied to other websites:
- Make a backup of your website and database
- Download the latest version of WordPress: http://wordpress.org/download/
- Check for malicious logins to your shell account*:
This Checks the most recent logins:
last -i | grep user_nameThis checks for less recent logins.
last -if /var/log/wtmp.1 | grep usernameBoth of these may take awhile to run. If you see an IP address that you do not recognize, you should be concerned!
- In your web-root, delete the wp-admin, wp-includes folders
- In your web-root, rename wp-config.php to .temp.config
- verify that you do not have any custom php files in your root web directory
- delete all *.php files in your root web directory
- delete remaining files in your root web directory, except for .temp.config and any other custom files you might have.
- rename .temp.config -> wp-config.php
- View wp-config.php for any malicious code or anything out of the ordinary. You can compare it to wp-config-sample.php from the clean wordpress version in step #2 above.
- At this point, the only thing remaining in your webroot should be the folder “wp-content”, as well as wp-config.php, unless you have custom non-wordpress files/folders in your web-root.
- View your .htaccess file for any malicious content, including redirects and allowing php to be run on different types of files
- Search your wp-content folder for malicious php files
You can start by using the find command to locate php files that might be within your uploads folder. From your web root directory, use the following command:
find . -wholename '*wp-content/uploads/*.php'The above command searches the uploads folder for any php files. There should not, typically be any.
You can automatically delete them by using this command:
find . -wholename '*wp-content/uploads/*.php' -exec rm -rf {} \;If you have a gallery folder, or any other folder, aside from plugins or themes, do the same sort of check for malicious folders/files. Make sure to check for hidden files/folders, which start with a “.”
- Grep can be very useful too. Once you identify a hacked file, you can search your entire directory like so:
grep -lnR "Some Bad Phrase" /home/user_name/A big part of it is finding patterns and it is common to see some “base64″ encoded values, as well as a php “eval”, so both of those would probably be good greps to start with.
If you end up with a ton of files, output the results to a text file, for easy searching/processing:
grep -lnR "Some Bad Phrase" /home/user_name/ > output.txt - Goto your plugins folder, wp-content/plugins.
Assuming you are NOT using a paid or custom plugin, delete and download your plugins from wordpress’s website one at a time.
If you have a custom plugin or one that you paid for, check each file/folder for malicious code.
- Goto your themes folder, wp-content/themes.
Delete any unused themes. Inspect remaining themes, checking each file for malicous code, as well as checking for any hidden files/folders.
- Using PHP My Admin, or the Mysql Command Line, inspect the database. You will want to check for any added users, malicious javascript or links added to posts, as well as comments. Also, check the wp_options table for anything out of the ordinary.
Using PHP My Admin may be easier for most folks, as it lets you visualize the database. You could also download the Mysql Workbench, but might have to configure a local Mysql Server and/or temporarily allow access remotely to the Dreamhost servers.
- Change your Mysql Password via the Dreamhost Panel and Update your wp-config.php file
- Extract new version of wordpress from step #2 and copy into web-root.
- Reset File Permissions, per WordPress’s recommendations. You can change this to be a little more strict if you want:
Change Directories to 755.
find ~/your_web_root/ -type d -exec chmod 755 {} \;Change Files to 644.
find ~/your_web_root/ -type f -exec chmod 644 {} \; - Your website should now work and you can be reasonably sure that it is free of malicious code. When in doubt, check EACH file/folder within your wp-content folder, as this should be the only remaining source of possible infection.
* If when checking for other logins, you find an IP you do not recognize, your entire account may be compromised
My Website is Not Hacked, Should I Still Check?
YES!
In my case, I found the same web-shell dropped onto several websites that were on different user accounts.
Even if you do not think you have been compromised, you should still check to be sure!
Under Users -> Manage Users -> Edit: enable enhanced user account security(http://wiki.dreamhost.com/Enhanced_User_Security) and disable FTP.
Under Domains -> Manage Domains -> Edit: Make sure the most recent version of PHP is selected, as well as “Extra Web Security”
Routinely check for errors / suspicious activity within your websites/user accounts.
Routinely Backup Your Website: Dreamhost offers the one click backup, which you can download automatically via wget by using the following command
wget -r --user=provided_username --password=provide_password http://provided_url
Just replace “provided_” with the information sent via the confirmation email.
I have been using dreamhost for some time now, and overall have been very happy with them. Their support is always friendly and responsive, aside from right now that is, and there is a lot of things I like about them.
With that said, these past few months with dreamhost have been a little rough. They have had several major outages, as well as at least one major security breach and probably bigger issues, as evidenced by this post.
While these sorts of hacks happen all over, it certainly does seem to be fairly wide-spread across dreamhost accounts.
You Are Speaking Gibberish! Please Help!
If feel comfortable making the above changes, you should be able to reverse the effects of the hack. Just make sure to backup files/database FIRST!!!
However, if you don’t feel comfortable, Dreamhost Support does seem to be helping, although in some cases not right away, so you can wait for them.
Otherwise, you can contact me and I can help you get back on track with an affordable fix.
Test Test Test
February 12, 2012
As the saying goes, you should never assume, because you make an Ass out of You and Me.
Recently, I had the opportunity to work behind a local web design company who had built a website for a local restaurant.
When they developed the website, they added a contact form, using jQuery Datepicker and Contact Form 7, so visitors could make a reservation at the restaurant.
However, the hours and dates they were open were hard-coded in a javascript file.
The web design company went in and blocked out Christmas and a few other days for the next five years, to ensure the design had a bit of a lifespan. However, if you wanted to change any of the days/times, you would need to go in and edit the custom javascript file.
I was given the job of creating a way for the restaurant owners to open/close hours and days, blocking reservations for certain times as needed, without having to use a developer for each edit.
A Nice Inexpensive Solution
Using the base javascript they developed, I used custom fields in wordpress to allow the owners to manually block days, as well as set custom hours for any given day.
They were wanting to go a little less expensive, so I did not develop a full plugin, just a simple text-based solution.
The end result was a php generated javascript file, with nice formatting, which pulled data from the custom-fields of a post to open/close days and hours.
I did it programatically, so the javascript output was controlled by a few functions, making changes easier. Although the logic behind it took a bit to get right, I think it ended up being elegant enough and easy to update.
Testing the Solution
I did a fair amount of testing, including a bunch of checking in IE8, Firefox, Chrome, Android, and iPhone.
However, I did not do as much as I would normally, because I assummed that the company I worked behind had done some testing as well.
Ultimately, IE7, slipped through the cracks and I did not check the code in Internet Explorer 7.
If I had, I would have found the disabled select options, obviously, were not working in IE7 at all and certain versions of IE8. I have run into this bug before, but let my guard down a little this time.
This is something I am not proud of, as it is out of character of my often rather obsessive website testing practices.
It Always Fails When you Need It
As is often the case with Murphy’s Law, faults in the reservation form did not become apparent for a few months when they finally started using the tool.
It soon became clear that people were able to make reservations whenever they wanted.
I added some testing and soon narrowed it down to iPad as being the main issue. So, I disabled it for the iPad and added some more checks to see what browser people were using.
However, I soon found that people in IE7 could also make reservations at any date, as well as some IE8 users. It was then that I tested for, apparently, the first time ever the design in Internet Explorer 7 and found I had overlooked a glaring bug.
The original web-design company used attr(“disabled”, “disabled”) on the select options to block out times. However, this would never work in IE7, because disabling a select that way is not supported in certain versions of Internet Explorer. The bug extends to Safari Mobile too, which is why it was not working on the iPad.
The Fix
Once I saw what I overlooked, javascript that could literally NEVER work in IE7 on XP, I had a head meets wall moment. I have run into this bug before and it is very well documented.
There are a few javascript based fixes, including adding css “disabled” class to the select or changing it to an optgroup. However, in this case, a lot of javascript was already in place and those types of solutions would have been A LOT more complicated.
So, the fix ended up just being changing the logic of how business hours were displayed.
Instead of showing ALL the hours and then disabling closed ones, I completely removed all the hours and ONLY added open times.
Looking for an Out
It is easy to want to blame someone else and for many this is human nature.
In fact, we reached out to the original Web Design company, as soon as we found the iPad issue.
They were quick to blame it on me, suggesting that his coders could fix my “patch” and “…write our own query in java…” to fix my broken code. Whether this is ignorance or he was just trying to use technical jargon to confuse my client, I do not know, but the point is he saw an out and used it.
Despite the code being broken when it shipped and me providing a test site with their original code on it, they have not yet reached out to admit any fault.
No One To Blame But Myself / Test Test Test!
At the end of the day, however, I share just as much blame as the original web design company.
I should have tested it like I do everything else I design, which is essentially EVERY browser I can get my hands on.
Even though it shipped broken, I should have checked and caught this when I rolled out my update. Instead of being lax, because I assumed they would not have shipped broken code, I should have tested it just like any of my other code.
So, the moral of the story is ALWAYS TEST TEST TEST!
The State of Background Images and HTML/CSS in Emails
February 5, 2012
**This post ended up being eight pages long and represents a good bit of testing, so I decided to split it up into two posts.
This post describes tests in various email providers/clients. You can view the background on this particular eblast here: Designing an HTML Email
As stated in my background post, if I had had input on the design, I probably would have urged a more restrained design, in order to ensure compatibility. However, as it was, the client saw a design that was basically their web-page recreated, complete with black on white text and background images.
So, to make it work as much as I could, I did significant testing in various webmail and email clients, the results are described below.
Table of Contents
- A Quick Review of the Design
- Popular Web-Mail Clients (AOL, Gmail, Hotmail, Mail.com, and Yahoo)
- Squirrel Mail Web Mail Client
- Outloook Web App
- Horde Web Mail Client
- Round Cube Web Mail Client
- Android Default Mail Client
- Blackberry Mail App
- Ipad/Apple Mail
- A Word About Outlook HTML Rendering
- Outlook Express, Outlook 2003, Windows Mail Security Settings
- Displaying PNG Files in Outlook 2003 and Outlook Express
- Outlook Express 6.0 XP
- Outlook 2003 in XP
- Microsoft Outlook 2007+
- Mozilla Thunderbird
- Thoughts on HTML in Emails
This is a bit of a recap, but my basic methods were to use “background=” and a redundant style “background-image()” definition within the table. Combined with other nested tables, I created a HTML email that used a background image and displayed correctly, for the most part, in common email situations.
I avoided using a body background declaration and instead set up a main content table, which I added the background image to, and was nested inside of a 100% width wrapper table. The wrapper table had a background color set to black, to ensure the white text(cringe, yes,) would be visible in most situations, even when the background image was blocked.
I also reworked the design to ONLY use a background image on the main content table, using images and background colors in the sidebar. For instance, had it been a webpage, I probably would have used a background image/color to draw the sidbar, which used one of those ribbon-image 3d deals. However, instead I did it a little differently, using a solid background color and then put the sidebar image under it, showing a little of the sidebar in the image itself, to create a 3d like effect.
Of course, it is best to avoid float and divs, instead using nested tables. Also, inline style declarations tend to be more compatible than css element declarations, with it often being necessary to give each element an inline style.
Popular Web-Mail Clients (AOL, Gmail, Hotmail, Mail.com, and Yahoo)
I don’t have the specific numbers off hand, but I think it is safe to say that Gmail, Hotmail, Yahoo, and AOL are probably the most popular web-mail clients. Not sure how many people use Mail.com, but it was tested as well.
Since I was being rushed by my clients, I first focused on these email providers.
For the most part, normal CSS/HTML declarations are respected, including background images. Using the method described above, I only ran into minor styling issues.
For instance, Yahoo required me to specify line-height and padding on paragraphs, to ensure the proper spacing.
Surprisingly, Hotmail ended up giving me the least issues. Aol was also pretty forgiving.
Squirrel Mail Web Mail Client
By default, my Squirrel mail was set to disable HTML display of messages.
So, the message initially was displayed as plain text and ALL images/CSS/HTML was stripped out.
However, by going to Options -> Display Preferences and setting “Show HTML Version by Default” to “Yes”, the image was displayed mostly correct.
I did not see an option to toggle this from within the message itself, so it only displayed correctly after changing the option under settings.
However, “Unsafe Images” are hidden and replaced with an image that says in big red letters “This image has been removed for security reasons”.
To show these images, the user needs to click on “View Unsafe Images”
Whether this is normally a default setting/option or something the average squirrel mail user would actually do…
Outloook Web App
Outlook Web App, which works with Microsoft Exchange Servers, filtered the email initially, removing the background image and other remote images. However, most of the style was left intact. By enabling the remote images, the background image displayed, as did the rest of the email.
There were no major style or layout issues, although spacing needed to be tweaked a little bit.
Horde Web Mail Client
Horde replaced all remote images with red backgrounds, with an option to “Show Images.”
After clicking on “Show Images” the message displayed more or less correctly.
However, there were still a few issues, like ignoring table align and adding a random(?) background color to a table.
After clicking on “Show HTML in a New Window,” however, the above issues were fixed and the email displayed correctly.
Round Cube Web Mail Client
Round Cube also displays a warning, hiding remote images. However, clicking on “Display Images” allowed the email to display mostly correct.
However, Round Cubes default style over-rode certain style declarations. For example, setting a font-size within an inline style of a “td” element was over-rode by Round Cube’s CSS, while setting a font-size within an inline style for a “p” element was not.
Full Email Clients
Android Default Mail Client
I did minimal testing on Android’s default mail app. The design displayed correctly, including background image. It ends up looking similar to Gmail.
However, it ended up being difficult to view the message, because the height/width is respected and there is only so much you can zoom out. So, with a width of around 700px, there ended up being a lot of scrolling.
Blackberry Mail App
Unlike the Android, Blackberry’s mail app, at least on the limited curve without touch-screen, ignored width statements, instead resizing it to fit on the Blackberry’s screen.
As a result, the sidebar got pushed to the bottom of the email and much of the other alignment was ignored/incorrect.
The background image displays correctly, after allowing the download of remote images. And, after reloading the email, images used in buttons, ect displayed correctly as well.
Ipad/Apple Mail
I had a co-worker test this, because the only Apple Device I own is a first gen iPhone that I use sometimes for testing, but is very under-powered and due to its age, somewhat unreliable to compare to newer models.
However, in every test, the background image and html/css were respected on iPad and I did not run into too many issues.
A Word About Outlook HTML Rendering
Before describing some of the more common Microsoft Email Clients, it is important to understand how they parse HTML.
Earlier versions of Outlook, I think anything before 2007, used Internet Explorer to render HTML. However, starting in Outlook 2007, Microsoft began using Microsoft Office Words Rendering Engine, which frankly, is a bit of a pain to work with. As a result, a custom method is required to make background images appear in Outlook 2007+.
Outlook Express, Outlook 2003, Windows Mail Security Settings
In my testing, Outlook Express, Windows Mail, and Outlook 2003 were all basically setup to block remote images.
In Outlook 2003 and Windows Mail, adding the user to the safe senders list or going to Tools->Options->Security and setting images to ALWAYS be downloaded ensured background images to display.
Some more testing is required, but, at least with Outlook Express, I do not think there was even an option to display images.
**However, the only remote image was actually the background image during testing, so this might have been a factor too.**
Displaying PNG Files in Outlook 2003 and Outlook Express
Since Outlook 2003 and Outlook Express use Internet Explorer’s rendering engine, if you have IE6 installed, PNG images do not display correctly.
I set up Outlook 2003 on a virtual machine and even after installing the Microsoft Office Service Pack 3, PNG files did not display until installing Internet Explorer 8.
However, after installing a version of Internet Explorer that supports PNG files, transparent PNGs were displayed correctly.
**Shakes fist at IE6**
Outlook Express 6.0 XP
Overall, HTML and CSS displays correctly. However, as described above in the Security Settings Section, I did not see the background image until going to Tools->Options->Security and manually enabling all remote image downloads.
I tried adding the send to my contact list too, but this did not seem to ensure the remote background image would be displayed.
Nor did I see a warning that there were any remote images to download, although the only remote image was the background in my test, so it is possible had there been others, it would have asked.
Outlook 2003 in XP
As was the case with Outlook Express, remote images were hidden and I did not see an option to display them.
However, by adding the user to the safe senders list or going to Tools->Options->Security settings, the image was displayed correctly.
However, again, the only remote image in these particular tests was the background image, so it is possible if one of the buttons had been a remote image, a prompt would have displayed.
Aside from security settings, the background image and other CSS/HTML displayed basically correct.
Windows Live Mail Windows 7
Like Outlook 2003, adding the user to the safe senders list and/or setting remote images to ALWAYS display, allowed the background image to display.
Otherwise, HTML/CSS displayed more or less correctly.
Just to be sure, I removed the Outlook 2007 conditional check, described below, and the background image still displayed correctly. So, I think it is safe to assume Windows Live Mail is also using Internet Explorer to render HTML.
Microsoft Outlook 2007+
**Note: I had a co-worker test in Outlook 2010 and only personally tested in Outlook 2007. So, 2010 info might not be 100% correct. However, background image/HTML/CSS did display correctly in 2010.**
As I mentioned above, Outlook took a turn for the worse, IMHO, after 2003, because Microsoft decided to use the Office HTML rendering Engine, instead of Internet Explorer. Of course, for security reasons, separating things from Internet Explorer is a good thing, but I digress.
In any-case, Outlook 2007 ignores background images, both the Style and Background= method on tables. To get around this, I used a conditional check, much like the conditionals you can use to test for the Internet Explorer Browser, to use a special XML object.
The conditional wrapped the inside of the table, before the first “
After using the conditional, background images displayed correctly.
There was a small spacing issue around the body of the email, basically, Outlook was adding about 20px of space between the background table and the beginning of the first content table. I got around this by creating a slightly larger Outlook specific background image, which added 20px on both sides for padding. Probably playing with the html/css would have worked too.
The Conditional, just the basic is below, removing most HTML/CSS/STYLE stuff, including height:
<table background="image.jpg" ... stlye="background-image:url(image.jpg);">
<!-- Start Outlook 2007+ Background -->
<!--[if gte mso 9]>
<v:image xmlns:v="urn:schemas-microsoft-com:vml" id="" style='behavior: url(#default#VML); display:inline-block; position:absolute; height:___px; width:___px; top:0; left:0; border:0; z-index:1; ' src="image.jpg"/>
<v:shape xmlns:v="urn:schemas-microsoft-com:vml" id="" style='behavior: url(#default#VML); display:inline-block; position:absolute; height:___px; width:___px; top:0; left:0; border:0; z-index:2;'>
<div style="">
<![endif]-->
... email content ...
<!-- End Outlook 2007+ Background -->
<!--[if gte mso 9]>
</div>
</v:shape>
<![endif]-->
Mozilla Thunderbird
As is the case with most things Mozilla, I did not run into any major issues. HTML/CSS and background images displayed as you would expect them too.
Thoughts on HTML in Emails
For the most part, as has been the case for some time, as long as you design using tables and basic CSS, most email providers/clients/webmail offer fairly adequate HTML and limited CSS support. Going with inline is best.
Testing in all browsers, like you would when doing normal website design, as well as validating the code, should ensure that it displays correctly in, at least, the majority of situations.
There are a few minor differences, largely with padding and spacing across different email providers, but these are easy to identify and get around with a little individual testing. Yahoo and Round Cube come to mind in regards to spacing issues.
So, you still need to TEST TEST TEST! As well as making sure you have alt-text and explicit height/width for images, so people can still see them even if remote images are blocked.
Aside from security issues, Microsoft Outlook 2003, Outlook Express, and Windows Live Mail preform adequately displaying both HTM/CSS and Outlook 2007+ uses the Office Rendering engine, so can be a bit of a pain, but using the v:shape hack, this was overcome.
I am still a believer that you should be designing for worst-case and lowest common denominators, so would have not went with a design like this. However, the rather complicated design showed up correctly in the email providers described above.
Time permitting, I will add some of the providers/clients I missed.
Desiging an HTML Email
February 5, 2012
**Originally, this was only going to be a single post, but it ended up being really long. You can view the “good stuff” here: State of Background Images and HTML in Emails, which describes a bunch of common email providers and their CSS/HTML support.
This post mostly provides a little background on this particular HTML email project and some concepts used when creating HTML Emails.**
While computer repair is one part of my business, I also offer a lot of web related services, including custom programming and web development/design.
So, I tend to do a lot of web-related stuff, including website design, custom web programming/javascript, and html emails. Overall, I much prefer web design even to computer repair, although Raleigh Computer Repair is still a big part of my business.
Now, anyone who has been doing web design for any amount of time, probably is aware of the stigmata attached to tables.
Many designers even goto such extremes to avoid them, that they end up completely rewriting a table in CSS using the float/box model, in order to avoid doing a table. Personally, while tables don’t make it into the main design of my themes very often, if I need them, I use them.
In any case, due to limitations by most email clients and webmail, if you are designing an email, it is best practices to use tables. Ultimately, this can be a little discouraging, especially to newer web designers, who may not remember the table/nested table/cell padding/ect world-wide-web of yesteryear.
There is a little background on email design basics and my particular situation, so fee free to jump to the actual testing/results Here
Onto the Design
When designing an email, it is best practices, especially due to the limited tool set offered by most email providers, to design for the lowest common denominator.
This means that even if the person does not allow remote images, blocks most html, and generally has a locked down email client, the email should still look more or less correct.
In fact, if you go through your junk folder, most junk mail and eblasts use a fairly simple design.
With that said, even in the past few years, most web-mail providers have added a lot more support for CSS, so aside from Outlook, which has taken steps backwards(more in next post,) you can generally get a bit more creative.
Going Overboard with the Design
Unfortunately, for me, my clients did not discuss the email design with me first.
Instead, they sent it to the graphic artist with the intention of basically recreating their website, complete with white text on a black background, as well as a rather integral background-image design.
Had they consulted me first, I would have urged a little more restraint, as there are a lot of things that can go wrong with this sort of design and, even though many of the popular email providers support this, there are many situations you can not test for.
However, they already showed it to the client, who approved it, and were unwilling to back peddle to offer a more compatible design.
Methods Used for Displaying Background Images
In this particular design, a blackish background image was used over the whole email, with white text, and otherwise a straight black background.
A sidebar, with one of those 3d-ribbon like buttons, which people are still over-using IMHO, was also present. However, I was able to use a standard background-color for the sidebar and then line up an image button to create the same effect, avoiding multiple background images.
Had this been a website, I would have done it differently, but I was able to get it down to only a single background image in the entire design.
Outlook 2007+ offers some unique challenges, which are described in the next post. However, I otherwise used standard HTML/CSS, using “background=” in the table definition and a redundant css “background-image” definition in the “style=” section.
A Quick Word on Layout
One factor, which people who are not familiar with tables might not realize, is that both height/width of tables can be kind of tricky, in part because by design the table is made to handle these on their own. As a result, sometimes height/width may be ignored.
In order to get the desired effect from a layout standpoint, it usually ends up being necessary to embed tables within tables. In most cases, you would have a single 100% width table and then nest tables inside of this main wrapper table.
In the case of this design, I added a black-background to the wrapper table, to help ensure even when the background image was blocked, the white text was still visible.
So, rather than trying to design it all in a single table, you might end up with something like this.
<table width="100%" >
<tr>
<td >
<table width="500" align="center">
<tr>
<td width="400">
<table width="400" bgcolor="#ffffff"> ... </table>
</td>
<td width="200">
<table width="200" bgcolor="#000000"> ... </table>
</td>
</tr>
</table>
</td>
</tr>
</table>
Of course, the above example leaves out a lot, but gives you an idea behind nested tables for layout.
In general, you would want to add inline style declarations to each table, and in many cases each other element. For instance, adding inline declarations to paragraphs usually is necessary, as some clients would otherwise end up using their own body style. Also, setting heights, cellpadding, cellspacing, and other table fields is necessary to ensure proper spacing and design.
Designing an HTML Email
Ultimately, if you design a solid Table based HTML template, it will be largely supported in most email clients/providers.
You will still need to do A LOT of testing and, depending on how complicated it it, a bit of hacking to make sure the email design will look okay most situations. However, if you approach it like a website, aside from NOT using float/divs and using Tables instead, you should be in a good position come testing time.
Also, don’t forget to include height/width for all images, as well as alt-text, so even if remote images are blocked, the layout is maintained and people can see what is blocked.
For the most part, it is also best practices to use inline style declarations, instead of using CSS element styling. Some clients end up ignoring CSS element styling.
Next Post in Series: State of Background Images and HTML in Emails
WordPress Removing Empty P Element’s Close Tag
January 21, 2012
Over the years, WordPress’s ability to convert text from the WYSIWYG editor into mostly valid HTML has largely improved, but it is still not perfect.
Recently, while setting up a somewhat creative FAQ page for a client, which uses the WordPress More Button to break up the different sections, I ran into an issue where WordPress was removing the closing tag from an empty paragraph.
Anyone who works with WordPress has likely run into similar issues as those described below and is probably well aware of this ‘fix’ or ‘work-around.’
WordPress’s content filters have, for the most part, significantly improved since the early days, as has TinyMCE. Even using the Visual section of the editor produces mostly acceptable html, so unless the page is doing some crazy stuff, clients are almost always able to edit pages using the visual section.
Of course, I typically avoid WYSWYG editors whenever possible, as they are far from perfect, but for non-techies, they have their place.
Problem and Solution
Essentially, after the Faq section title, I was using an empty <p> element to act as a divider between the Faq Question and the Answer.
During processing, I retrieved the un-modified content, processed it, then before printing it, used “apply_filters” to automatically add html to the content.
However, after using apply_filters, the closing tag of the <p> element was being removed.
As an aside, this is why you always run everything through w3c validation, even if there are some elements you know won't pass. At least for any sort of paying gig.
In any case, the fix is to add a Non-Breaking Space in between the empty paragraph, so something like <p> </p>.
Using Different Databases With a Single WordPress Installation
January 4, 2012
In an effort to make designing new websites easier and to reduce the amount of multiple wordpress installs I have running on my test server at any given time, I made some changes to my wordpress test server setup.
I have been using a single install per website for the past few years, mostly because it was the easiest solution.
When I start a new website, I copy over my root wordpress installation that has my base theme and plugins in it, then customize the config file. I know it is certainly not the most efficient way to do things, but it works and sometimes, taking the time to work out a new way is simply not practical.
However, in an effort to make things a little more condensed, I decided to do some playing with using a single wordpress installation for multiple websites. I am sure this has been done many times already and there are probably a number of resources available, but I usually like to figure these things out, for the most part, on my own.
Playing With a WordPress Network
I tried the built in Multi-Site Option first, to see how it worked, because I had never played with it. Setup is very easy and it basically did what I needed. It is a cool feature and makes creating a network of related wordpress sites really easy.
However, it uses a single database, creating a new set of tables for each new site. So, for example, when you add a new site, a set of tables with “wp_2_” as the prefix.
Ultimately, when I launch a client’s website, I will dump it and then upload it to their website host, I did not want to have to figure out how to convert the mult-site database into a single site database.
I am sure it is probably not too difficult and there may even be tools involved, but I can see several issues, especially with shared settings, so for development I would still prefer to have a single database for each website.
Creating a Custom WordPress Network
So, with the multi-site database structure not being exactly what I was going for, I decided to use the same htaccess rules, but simply create a dynamic wp-config.php file.
Within the config file, I use a simple if/else statement to check the REQUEST_URI variable and dynamically set the database name, based on the page request.
A basic example is below:
$ref = $_SERVER['REQUEST_URI'];
if(stristr($ref, "website_1") !== false)
define('DB_NAME', 'website_1');
else if(stristr($ref, "website_2") !== false)
define('DB_NAME', 'website_2');
else
die;
In the above example, PHP’s case-insensitive search function is used to load the correct database based off page request. If the page request includes, website_1, the website_1 database is used, ect.
I may go back and modify this a little more, to check position too, as there is a small risk of name collision using this method.
With the modified .htaccess rules shown below, which are the same as the default multi-site rewrite rules, requests to wp-includes, wp-admin, and other important folders are correctly redirected, no matter the requested ‘folder’.
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
# uploaded files
RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]
# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^[_0-9a-zA-Z-]+/(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^[_0-9a-zA-Z-]+/(.*\.php)$ $1 [L]
RewriteRule . index.php [L]
Using Custom Upload Directories
The only other hurdle was making sure each website was using a different uploads folder, as I did not want clients to be uploading files to the same directory or to have to manually remove/clean unused them each time.
I overcame this issue by changing the default upload directory under settings->media. Instead of using the default one, I changed it to something like “wp-content/uploads_1″
Potential Problems with This Setup
I currently have two different test sites setup with this config and everything seems to work well, of course only time will tell.
One potential issue is that plugins and themes are shared, so users may potentially be able to see all the current themes installed. This could cause issues if you were trying to hide themes/plugins from other clients.
There is a small chance of a name collision too within the config file, as if someone created a page called “website_2/website_1,” it would load the wrong database, so I will probably change the string search portion of the config file in the near future, probably checking the location.
Setting a custom upload directory is also not ideal, but it is not a huge deal and I may change it at a later time or when I actually launch the websites.

