To enable this feature, go to the Advanced section in your website’s configuration panel: Websites > Configure > Advanced

As always, we love feedback, so feel free to send us your thoughts and suggestions!

Most articles on this subject tend to be very confusing, as they try to explain in detail how encoding works.  This article, however, was written for the average PHP developer who simply wants to support UTF-8 characters in their applications.  If you have additional tips, please feel free to share them in the comments below.

Note that, for the purpose of this article, the term extended characters refers to any UTF-8 character that falls outside of the ISO-8859-1 spectrum.  (I.E. Chinese characters, Russian characters, certain Polish characters, etc.)

Webpages

• First and foremost, make sure your files are UTF-8 encoded.
  • Most text editors have an option for this somewhere in the File menu or in their preferences.  Look for something called File Encoding.
  • It’s important that the files themselves be UTF-8 encoded, especially if they contain extended characters.  Otherwise, you will almost certainly run into display issues.
  • If possible, select UTF-8 without BOM.
• Make sure every page has the UTF-8 meta tag:

  <meta http-equiv="Content-Type"
      content="text/html; charset=utf-8" />

  • This works on most servers, but not all.  If the meta tag option doesn’t work, you can try adding this line to your .htaccess file:

    AddDefaultCharset UTF-8

Working with Strings

• Include this at the beginning of every page:

  mb_internal_encoding("UTF-8");

• STOP USING THE NORMAL PHP STRING FUNCTIONS ON UTF-8 INPUT!
  • Until PHP6 comes out, it’s important to use the Multibyte String Functions instead of the standard string functions.
  • Many of the MB String Functions mimic standard string functions:
    • mb_strstr
    • mb_strlen
    • mb_strpos
    • mb_substr
    • …etc…
  • Using standard string functions on strings containing extended characters will result in erroneous output!
• Stick with PCRE functions when working with regular expressions.
  • preg_match, preg_replace, etc.
  • If you absolutely need to use ereg_ functions, use their mb_ equivalents (above).
• Use htmlspecialchars instead of htmlentities.
  • Using htmlentities will cause problems with extended characters, usually leading to erroneous output!

Database Settings (MySQL)

• Set your database collation to UTF-8 (utf8_general_ci)
  • This can be done in phpMyAdmin using the Operations tab. (Make sure you have the database itself selected, not one of the tables.)
• Make sure all your database tables are UTF-8 (utf8_general_ci)
  • Again, this can be done in phpMyAdmin by selecting a table first, then selecting the Operations tab.
• Make sure all your fields are all UTF-8 (utf8_general_ci), where applicable.
  • This includes all fields of type text, varchar, enum, char, etc.  (Anything that stores textual data.)
• Always use the following immediately after opening your database connection:

  mysql_set_charset('utf8',$link);

  • If that doesn’t work on your version of PHP/MySQL, look here for a workaround.

Working with Files

In PHP5, I have yet to this day found a way to work with files that have extended characters in their filename.  I am led to believe that this is a problem within PHP itself, which is why version 6 is taking so long to develop.  (PHP6 is scheduled to have full Unicode support.)

There is absolutely no problems with reading and writing to files that contain extended characters in their content, but the filenames themselves cannot contain them.  This is currently the only limitation that I personally haven’t found a workaround for.  Fortunately, it’s usually not an issue since web-safe filenames don’t current include extended characters which cause problems.

Alright, we all know that you can’t get something for nothing.  But there’s more to the story than meets the eye.  It seems as though Adobe wants more than just your money.  They want your web hosting, too.  The following post comes directly from the InContext Editing forum:

The hosting was one of the top problems in using ICE and the shear number of FTP servers and different implementations and settings made difficult to support everything. Even for a web professional, FTP can raise problems and cause support incidents.

The integration of InContext Editing in Business Catalyst should help us solve this problem, as we’ll have a single FTP server which is in our back yard. This why I think you will not have to solve server problems and have time to focus on what’s important: creating great websites for your customers.

Adobe’s excuse for not allowing you to host your own websites in BC is that they can’t support multiple FTP servers? Ouch.  But wait, it gets better:

On the BC system hosting, you cannot run PHP, ColdFusion or ASP code.

Yes, you read that correctly.  You cannot run any type of server-side scripting on your Business Catalyst-hosted websites. Instead, Adobe believes that they can “cover most of your needs” with “predefined modules”:

The system comes with a large number of predefined modules that you can use directly. [...]  Although we’re not using or supporting PHP, I am pretty sure that we can cover most of your needs with the current system.

In essence, InContext Editing has gone from a flexible, FTP-in-and-start-editing system to a restrictive, out-of-the-box application.  Why?  Probably because it’s easier and less expensive for Adobe to support.  Unfortunately for designers, this simply isn’t acceptable for clients who are used to the flexibility of what server-side languages have to offer.  In my personal experience, 99% of the time clients want something just a little different that what “the box” has to offer.

Considering an Alternative

My suggestion to anyone using Adobe InContext Editing is to consider looking into alternative content management solutions.  Our company, A Beautiful Site, LLC., offers one of the leading simple CMS services on the web.  Here’s a quick breakdown of what you get with Surreal CMS that you will allegedly not get with the future version of InContext Editing:

• The ability to host your own websites
• The flexibility to use any type of server-side language you choose
• Access from your own domain/subdomain with the ability to theme and brand the CMS as your own solution
• An inexpensive pro plan that can manage unlimited websites
• One-on-one email support (both free and pro accounts)
• Competitive features that are continuously being enhanced and improved
• Google Analytics integration for pro users

Having been around since 2008, Surreal CMS has grown steadily because of their dedication to serving you, the designer, not a board room full of profit-seeking shareholders.  That’s why they have already begun working on supporting repeating regions, an essential InContext Editing feature, which is expected to be available as soon as this summer.

To give you an idea of what some people are saying, here are some actual quotes from Adobe InContext users:

“The only reason I bought Dreamweaver CS4 was because of InContext.”

“Unreal, we [...] purchased DreamWeaver CS4 because of the supposed “included” content manager InContext.”

“Today I made a decision for the company. We will no longer publish ANY pages for use with InContext Editing.”

“InContext is a great idea, but the price should be already included into [DreamWeaver's] price. This is where it is starting to become a little evil.”

“As creative suite owner i expected InContext Editing to come as a bonus.”

“If Adobe chooses to charge for InContext, I definitely will have to drop it.”

“There are other options out there I’m not afraid to use, since I don’t want to be nickeled and dimed to death!”

“People are upset that they paid x-amount of dollars for Dreamweaver and will be charged an extra fee to use InContext.”

“Is this bait and switch? Adobe has come down a notch in their reputation IMO.”

Those are all from the first page.  In fact, there are hundreds of other posts on the same topic, many of which reaffirm these same points.  Amidst all of the confusion, however, one thing is clear: a lot of Adobe’s customers feel like they’ve been cheated.  Many claim to have purchased InContext Editing as a service that came advertised with Creative Suite 4.  Adobe argues that was simply not the case:

Paid Dreamweaver feature?  Not really. We intend to run the service as a standalone editing service. However, we want or intend to give Dreamweaver users some integration features that would help them create editable websites faster, using Dreamweaver’s design view and InContext Editing commands. This was the message we tried to send, but seems that it needs more clarity.

Although there are some obvious ethical issues at hand here, Adobe is covered legally because their licensing agreement essentially guarantees nothing at all to end users.  Of course people aren’t going to be happy about it, but Adobe sees more money that can be made elsewhere.  Specifically in their Business Catalyst service.  From the InContext Editing website:

InContext Editing will be discontinued as a standalone service in 2011. However, InContext Editing has become a part of Adobe Business Catalyst®, a hosted application for building and managing online businesses that can also import your existing website. Find out more about Business Catalyst and how you can continue to use InContext Editing beyond 2011.

Indeed, this does seem like a classic “bait and switch” tactic, even if it was a simple miscommunication on Adobe’s part.

Enter PEAR

Fortunately, the PEAR project makes this really easy.  First, you’ll need to make sure the following PEAR packages are installed:

Mail
Mail_Mime

To do this from a terminal window, just type pear list.  If the aforementioned packages aren’t showing as installed, you’ll need to install them.  Although installing PEAR packages is beyond the scope of this article, you can usually get them installed with the following commands.  (You may need to use sudo or be logged in as root for this to work.)

pear install mail
pear install mail_mime

Preparing the Email

Once PEAR is enabled, preparing the email is really simple.  First, you’ll need to include the required PEAR classes:

include('Mail.php');
include('Mail/mime.php');

Once that’s out of the way, you can send HTML/Plain-text emails with the following code:

// The content of the message in both plain-text and HTML
$message_text = '...';
$message_html = '<html>...</html>';

// Set the message content
$message = new Mail_mime("\n");
$message->setTXTBody($message_text);
$message->setHTMLBody($message_html);

// Get the body and headers
$body = $message->get();
$headers = $message->headers(array(
	'From' => 'Surreal CMS <sender@example.com>',
	'Subject' => 'This is the subject of the message'
));

// Send the message
$mail = Mail::factory('mail');
$mail->send('recipient@example.com', $headers, $body);

Of course, if you’re using template files for your emails you could replace the first couple of lines with something like this:

$message_text = file_get_contents('message.txt');
$message_html = file_get_contents('message.html');

This, of course, will populate the email with the contents of both message.txt and message.html.

The FAQ page on Adobe’s website stated the following:

Why is Adobe discontinuing the development of InContext Editing?
Improved content management support was the most commonly requested feature from customers. To meet our customers’ demands for more advanced functionality, InContext Editing will be integrated with Business Catalyst, our online business platform. In addition to offering an advanced yet easy-to-use content management system, Business Catalyst combines more than five essential online business tools in one integrated solution. It enables web professionals to build what their clients need, whether it’s a simple informative website or a powerful online store — quickly and without programming.

Also according to their FAQ page, technical support will also be discontinued for the InContext Service.  That leaves current Adobe InContext Editor users with few options.  Either subscribe to a Standard ($995) or Premium ($1995) plan with Adobe’s Business Catalyst platform, or find themselves an alternative simple CMS solution for their websites.

It literally takes about 15-20 seconds to set this up if you already have a Google Analytics account.  We even made a short video to show you how it all works!

The other feature we released was syntax highlighting for (X)HTML, CSS, JavaScript, and XML files, courtesy of the CodeMirror project.  This is available to both free and pro users.

Keep an eye out in the coming months for more great features and, if you haven’t already, don’t forget to sign up for a free account over at Surreal CMS!

Maven is available in three variations: light, book, and bold.  Feel free to download it, design with it, and pass it along to your friends.  Just don’t forget to visit the Vissol team to tell them what you think about it!

If you’re wondering why the extensions get changed to .zip, it’s because the new Office 2007 formats are nothing more than a series of XML documents zipped up with their own special file extensions. Java .jar files and Mozilla Firefox .xpi files do mostly the same thing, so this isn’t a new concept, but it does seem to introduce a bit of a problem for Internet Explorer users.

There seem to be a number of “solutions” out there, but many of them involve telling the end user to change a setting in their browser or something like that — definitely not the best solution. Another option is to simply rename the affected file(s) to the appropriate extension(s) and open them up in Office as usual. Although this works, it’s still not a great solution since most users won’t know to do that.

The best solution I found was on a forum, where a user suggested setting the MIME types manually on the server. This is obviously a better solution, since end users get the expected behavior and are able to download files with the proper extension. For Apache servers, simply add the following to your config file or create an .htaccess file in the root directory of your website:

AddType application/vnd.ms-word.document.macroEnabled.12 .docm
AddType application/vnd.openxmlformats-officedocument.wordprocessingml.document docx
AddType application/vnd.openxmlformats-officedocument.wordprocessingml.template dotx
AddType application/vnd.ms-powerpoint.template.macroEnabled.12 potm
AddType application/vnd.openxmlformats-officedocument.presentationml.template potx
AddType application/vnd.ms-powerpoint.addin.macroEnabled.12 ppam
AddType application/vnd.ms-powerpoint.slideshow.macroEnabled.12 ppsm
AddType application/vnd.openxmlformats-officedocument.presentationml.slideshow ppsx
AddType application/vnd.ms-powerpoint.presentation.macroEnabled.12 pptm
AddType application/vnd.openxmlformats-officedocument.presentationml.presentation pptx
AddType application/vnd.ms-excel.addin.macroEnabled.12 xlam
AddType application/vnd.ms-excel.sheet.binary.macroEnabled.12 xlsb
AddType application/vnd.ms-excel.sheet.macroEnabled.12 xlsm
AddType application/vnd.openxmlformats-officedocument.spreadsheetml.sheet xlsx
AddType application/vnd.ms-excel.template.macroEnabled.12 xltm
AddType application/vnd.openxmlformats-officedocument.spreadsheetml.template xltx

Note that, if you’re updating your main config file, you’ll have to restart Apache before the changes will take affect. With .htaccess files you shouldn’t need to restart the server.

Now your users will be able to download Office 2007 files from your server without any problems.  If you’ve discovered another method for solving this problem, please share it in the comments!

That said, I stumbled across a very interesting framework today that may help bridge the gap between the present and the future — when HTML5 and CSS3 is supported by all major browsers.  52Framework boasts features such as rounded corners, text-shadow, box-shadow, HTML5 markup, a grid system, and a built-in CSS reset.  Best of all, it’s compatible with all major browsers, including the infamous IE6.  You can see a working demo of an HTML5 page using with 52Framework on their website or download the latest release from their homepage.  If you’re just curious to see what it’s all about, you can take a peak at what’s inside the box.

Although still in beta, 52Framework looks like a promising alternative for anyone looking to take advantage of the upcoming HTML5 + CSS3 specifications.  As nice as it is, however, I don’t think it’s something I would rely on for heavy production use…at least not without some very thorough testing on a lot of different browsers.