The Coding Paparazzi

Solving the connection problems of Windows Live Writer (WLW), Part 1

2010-02-16T04:33:00.001-05:00

Problems connecting to a blog site using Windows Live Writer (WLW) are common; especially for PHP based systems. When this happens, you usually see an error message like this one:

• An error occurred while attempting to connect to your blog: Invalid Server Response - The response to the blogger.getUsersBlogs method received from the web-log server was invalid. You must correct this error before proceeding.

In this article, we'll see the measures that we can take to resolve many of these communication problems, especially those who are not already or are poorly explained on the Internet.

1- Introduction

The vast majority of the communication problems for WLW mentioned on the Internet are about blogging systems based on PHP scripts; not only because these systems are the most used (think about WordPress, Drupal and Joomla) but also sadly because of the way that web services - an essential component of protocols such as XML-RPC used by WLW - are implemented in PHP which makes them very sensitive to many type programming errors; even as small as an extraneous white line at the beginning or the end of a script file. The rest of this article will deal only with communication problems related to PHP. Of these blogging systems, WordPress (WP) is picking up the lion's share, so the examples used in this article are based on WP. However, this doesn't mean that you won't find anything interesting here if you are using another blogging platform than WP. Except for the first example that uses a common problem specific to WP to explain the log file of WLW, the majority of the explanations given here will fully apply to many other blogging systems using PHP.

With the exception of a particular problem related to the uploading of images and video files, the vast majority of communication problems that you'll get with WLW will happen when you'll try to create a new account. In these cases, you'll be greeted with the following error message "An error occurred while attempting to connect to your blog: Invalid Server Response - The response to the blogger.getUsersBlogs method received from the web-server log was invalid. You must correct this error before proceeding.". Less often, and error will happen when you'll try to publish a new article using an account that was working correctly in the past. In these cases, the method "blogger.getUsersBlogs" will be replaced in the error message with other methods such as metaWeblog.newPost or metaWeblog.getRecentPosts:

• The response to the metaWeblog.newPost method received from the web-log server was invalid.

• The response to the metaWeblog.getRecentPosts method received from the web-log server was invalid.

Obviously, if you can no longer publish an article using an existing account that was worked correctly before, it's quite probably because something has changed in the mean time and we can safely assume that if you now try to recreate this account, you will be greeted by the first error message, the one with "blogger.getUsersBlogs".

2- metaWeblog.newMediaObject and other well-known problems

Before continuing, we will take a look as some of the most known problems of WLW that you'll find on the Internet. This will be only a quick look because I don't want to repeat what you can already find on the Internet and also because many of these are already a thing of the past; ie., they are no longer present in the latest versions of either WLW or of the blogging systems.

The most important of these is an intermittent failure for uploading images, videos and other big media files and will usually occurs only when you will want to upload multiple files at once or a big one but not when uploading a few small files or a medium one. This problem is different from most of the other communication problems because in the mean time, all the other publishing features of WLW will keep working correctly. You can identifie this problem by the presence of the metaWeblog.newMediaObject method that will be in the error message: "The response to the metaWeblog.newMediaObject method received from the weblog server was invalid" and the name of this method says to us that the problem is clearly related to the creation of a new media file on the system and is not something like an invalid password.

This problem happend when the uploading of your media files goes over the internal memory limits of PHP and can be fixed in different ways: by reducing the image size; by reducing the total number of uploaded files in a single time; by using FTP or by increasing the memory available to PHP for the execution a script. To learn how to use FTP with WLW, take a look at the following article: "Live Writer Error – The response to the metaWeblog.newMediaObject method received from the weblog server was invalid – Invalid Response Document Returned From XmlRpc Server".

For increasing the PHP memory limit, you must either change the value of the memory_limit parameter that you will find in your "php.ini" file (or add the line if this parameter is not already there) or you could also add the following line of code « ini_set ("memory_limit", "12M"); » (without the quotes «...», of course) right after the <?php characters in the PHP script that handles either the whole XML-RPC protocol or only the uploading of images and other medial files. For example, in the case of WordPress, you could change the "wp-admin/includes/image.php file. You'll find more details about this in the article "PHP Allowed Memory Size Exchausted Fatal Error » My Digital Life". Also, the value of 12M above is your personal choice.

Before going to the next round, here a few references that will provide the list of the most common known connection problems of Windows Live Writer (WLW); although many of these are old problems and no longer exist in the latest versions of WLW:

3 - The Log File of Windows Live Writer

When you have a problem communicating XML-RPC, the log file of Windows Live Writer (WLW) is probably the first place to look into. To explain its use, we will start by taking as an example a WordPress (WP) configuration error familiar its users and which usually - but not necessarily - happens right after a new installation. Note that even if you don't use WP, the following discussion is still interesting because it's an introduction to the use of the WLW's log file.

Since version 2.7 of WP, the XML-RPC remote communication protocol is not enabled by default on a new installation of WP. Therefore, if you forget later to activate it explicitly in the configuration options, WLW will obviously not be able to the WordPress server using the XML-RPC protocol and you will be welcomed with the following error message:

This error message describes exactly the cause of the problem and clearly says that the XML-RPC remote communication protocol should be enabled; which can be done by going to the Admin Dashboard of WP under Settings | Writing | Remote Publishing and then checking the box "XML-RPC - Enable XML-RPC protocols (WordPress, Movable Type, MetaWeblog, Blogger XML-RPC)".

In this example, identifying and correcting the source of the problem was relatively easy because an explicit error message has been provided to us by the system. However, the situation will be much less clear when, instead of getting an explicit error message, you get nothing but a generic error message that, excerpt for telling you that something got wrong, will provide absolutely no clue whatsoever about the nature of the underlying problem:

"An error occurred while attempting to connect to your blog: Invalid Server Response - The response to the blogger.getUsersBlogs method received from the web-log server was invalid. You must correct this error before proceeding."

When we get this error message, you can either start trying at random solutions gleaned all over the internet - I do not recommend it and I don't think that you'll disagree with that, otherwise probably that you would not be here reading this - or go at the bottom of things and find what happens first before trying any solution and for this, there are two very effective tools: the first one is the log file of WLW and the second one would be to use an HTML protocol analyzer such as Fiddler. We shall see how to use Fiddler later but first, let's take a look at the log file of WLW.

This log file is aptly called "Windows Live Writer.log" and is created automatically by WLW in the directory "%USERPROFILE%\Local Settings\Application Data\Windows Live Writer\" or "C:\Documents and Settings\__YOUR_USER_NAME__\Local Settings\Application Data\Windows Live Writer" if you're running WinXP. In the case of Vista, you will find it in the directory "%localappdata%\Windows Live Writer". To access this directory, you can of course Use Windows Explorer or you can open the command Start | Run and copy the desired address in the dialog, eg for WinXP:

An even simpler method would be to use the dialog box "About Windows Live Writer" of WLW; available from the menu "Help" and which contains a direct link to the directory behind the link "Show log file"; as shown in the figure below (red arrow):

By default, WLW will write only a few things in the log file but it will include at a minimum any error message. This is often sufficient in many cases but to get a better view of what happened, we can activate the verbose logging mode, which will greatly increase the amount of written information and will make things easier (or more complicated!) to understand. All the examples shown in this article have been based on using the verbose logging mode. To find out how to activate this mode for WLW, please consult the following reference: "Donkblog : How to enable verbose logging in Windows Live Writer". Important: note that in the case of WLW, if you have multiple windows opened, there is still always only a single WLW processus to control them all; so you cannot change the verbose mode of WLW if you have already at least one open window so therefore, you must close any WLW windows before to be able to switch to the verbose logging mode.

In order not to be lost in a mass of useless information, the first thing to do would be obviously to delete any previous log file that's already there in order to see only the most recent and relevant events after that. There is absolutely no problem deleting this file anytime, even when WLW is already open. You can use any program such as Notepad or WordPad or your favorite text editor to open it and read it but as Notepad doesn't convert partial end of line (only chr(10) to full Windows end of line (chr(13)+chr(10)), it's a better idea to use WordPad instead; otherwise some stuff will be cramped on a single line instead of multiple lines.

If we now repeat the same test as above with the XML-RPC remote publishing configuration error on a new installation of WordPress, this is what we'll find in the log file of WLW:

WindowsLiveWriter,5612,None,00011,15-Jan-2010 22:50:50.921,"499 499",""
WindowsLiveWriter,5612,None,00012,15-Jan-2010 22:51:52.250,"XML-RPC request:
http://sylvain2/BlogueWP1/xmlrpc.php
<?xml version=""1.0"" encoding=""utf-8""?>
<methodCall>
 <methodName>blogger.getUsersBlogs</methodName>
 <params>
  <param>
   <value>
    <string>[-- Encoded password removed --]</string>
   </value>
  </param>
  <param>
   <value>
    <string>admin</string>
   </value>
  </param>
  <param>
   <value>[removed]</value>
  </param>
 </params>
</methodCall>",""
WindowsLiveWriter,5612,None,00013,15-Jan-2010 22:51:52.250,"XML-RPC response:
http://sylvain2/BlogueWP1/xmlrpc.php
<?xml version=""1.0""?>
<methodResponse>
  <fault>
    <value>
      <struct>
        <member>
          <name>faultCode</name>
          <value><int>405</int></value>
        </member>
        <member>
          <name>faultString</name>
          <value><string>Les services XML-RPC sont désactivés sur ce blog. Un administrateur peut les activer à /BlogueWP1/wp-admin/options-writing.php</string></value>
        </member>
      </struct>
    </value>
  </fault>
</methodResponse>
",""
WindowsLiveWriter,5612,None,00014,15-Jan-2010 22:53:01.437,"499 499",""

Note the presence of two XML documents in this file; as shown by the two lines beginning with <?xml ...> and followed by a serie of paremeters delimited by <...>. Each of these tags has a matching end tag delimited by </...>; for example, we have the pair <value> and </value> and between these two tags, there is some piece of information; which can include other pairs of tags. There is not matching end tag for the very first one, the <?xml ...> tag. Instead, the end of the very first thing to follow it, the root tag, which is <methodCall> in the example above, is used to indicate the end of the corresponding XML document.

The first XML document describes the connection request that has been sent to the server as somewhat indicated by the name of the root tag: <methodCall> (in yellow below). After that, we have another tag <methodName> which gives us the name of the method that have been called on the server: blogger.getUsersBlogs. The other tags that follow are simply the parameters to be used for this method.

<?xml version=""1.0"" encoding=""utf-8""?>
<methodCall>
<methodName>blogger.getUsersBlogs</methodName>
<params>

...
</params>
</methodCall>",""

There is nothing really interesting in this first XML document because it has been build by WLW to be sent to the server and doesn't contains any error in it. However and much more interesting is the second XML document that contains the server response as indicated by the name methodResponse of its root tag and which contains in this case an item called <fault> (in pink below). Clearly, this is indication from the server that something got wrong on its side. After that, you can recognise the text of the error message that has been displayed by WLW and which was telling us about the configuration error in the options of WordPress (in red below):

<?xml version=""1.0""?>
<methodResponse>
<fault>

...
<value><string>Les services XML-RPC sont désactivés sur ce blog. Un administrateur peut les activer à /BlogueWP1/wp-admin/options-writing.php</string></value>

...
</fault>
</methodResponse>
",""

In this example, it is important to pay a very special attention to the end of the XML document and specifically, to the termination tag "</methodReponse>" that I have highlighted in yellow. This ending tag might look unsignificant but we will soon see that often, it will contains the key in solving many communication problems of WLW.

For the following example, I have reproduced on my system a problem that I've had to deal with recently and seems to be quite prevalent amongst people using WordPress but that will also happen - albeit less frequently - to other bloggins system using PHP. In this particular case, the file wp-config.php has been corrupted in a very specific manner that I will describe later but many other files in WordPress or from another blogging system could be corrupted in the same way and would give the same erroneous result. The interesting part of this example is that it will precisely result in an aborted communication and WLW will then show us its infamous error message: "An error occurred while attempting to connect to your blog: Invalid Server Response -- The response to the blogger.getUsersBlogs method received from the web-server log was invalid. You must correct this error before proceeding". This example is then a perfect demonstration to show what's written in the log file when such an error occurs and how to interpret this information to solve our problem.

As we saw earlier, there is a setting for blocking the use of XML-RPC on WordPress and any attempt to use it will result in an error message sent back by WordPress; error message which is then displayed to us by WLW. However, if I attempt to repeat this test but now, with the corrupted script file in place, instead of getting this explicit error message I will get the generic error message (the one without any information).

If we take a look at the log file, we can see that the error message about the incorrect configuration has been indeed sent back by WP but now, there is something fishy about this entry: that last characters of the termination tag have now gone missing! :

<?xml version=""1.0""?>
<methodResponse>

...
<value><string>Les services XML-RPC sont désactivés sur ce blog. Un administrateur peut les activer à /BlogueWP1/wp-admin/options-writing.php</string></value>

...

</methodRespons",""

Compare this tag « </methodRespons", "" » with the previous one: « </methodReponse> ». In fact, even the end of the line characters have vanished because the comma and the two double-quotes were part of the following line.

Immediately after this truncated XML document, we can see that WLW has now wrote an entry to the effect that the received response from the server was invalid and this is this last entry that it has shown us:

WindowsLiveWriter,5612,Fail,00031,16-Jan-2010 04:27:02.953,"WindowsLive.Writer.Extensibility.BlogClient.BlogClientInvalidServerResponseException: Invalid Server Response - The response to the blogger.getUsersBlogs method received from the blog server was invalid:

...

If we still keep the corrupted script file but now retrying to connect but only after activating the protocol XML-RPC on the WordPress server, we will now see a full response back from WordPress but still, with its ending tag truncated:

<?xml version=""1.0""?>
<methodResponse>
<params>
    <param>
      <value>
        <array><data>
<value><struct>
<member><name>isAdmin</name><value><boolean>1</boolean></value></member>
<member><name>url</name><value><string>/BlogueWP1/</string></value></member>
<member><name>blogid</name><value><string>1</string></value></member>
<member><name>blogName</name><value><string>Le p&#039;tit blogue à Sylvain</string></value></member>
<member><name>xmlrpc</name><value><string>/BlogueWP1/xmlrpc.php</string></value></member>
</struct></value>
</data></array>
      </value>
    </param>
</params>

</methodRespons",""

And surely enough, because of this truncated ending tag, WLW keep telling us that the received response from the XML-RPC server was invalid and will abort the rest of the process. So even if a this stage the XML-RPC publishing protocol has now been correctly set up on the WordPress server, the problem caused by the corrupted file will still be blocking us from using WLW against this server.

Of course, the next step is to identify what is this corruption that has been introduced into the script file and for this, we will use another tool: Fiddler; which is a free tool used to capture and analyze the raw HTML traffic that passes between a client and a web server. Of couser, you could also use any other tool available for capturing and analyzing this HTML traffic HTML but Fiddler is free, simple to use and more then enough powerful to give us the solution that we are looking for. Also, the following discussion about Fiddler might look complicated at first but you'll see at the end that it's relatively easy to get the information that we need to solve our little communication problem.

4- Fiddler

You can get Fiddler on the following website: "Fiddler Web Debugger - A free web debugging tool". Once installed, you click Fiddler2 in your Windows menu to launch the program (click on the image to see a larger version) :

Again, even if the above figure might look complicated, you'll see that's relatively easy to get the information that we want and you don't have to worry about most of these parameters but I prefer to explain too much than not enough.

At the left of the previous figure, we can see a list of TCP/IP sessions, each session consisting of a request sent to the server (which may be any kind of TCP/IP server: a web server or a XML Server for example) and a response sent back by the server. This is always the case with most TCP/IP communications: for each request sent, there is a single response sent back and the pair of two forms a session. In our case, these sessions are also of the type HTTP as we can see on the figure with the light blue arrow #3. The XML-RPC protocol used by WLW to communicate with a blog use standard HTTP sessions over TCP/IP in exactly the same way as your browser (Internet Explorer, Firefox) communicate with a web server. This which means that you shouldn't have any firewall or proxy issue using this protocol if you can access your blog using any browser. At the left of each session, Fiddler will also put an icon describing its type and status. You can get a list of all these icons with their meanings at the following page: "Fiddler Web Debugger - User Interface".

At the right, we can see the details of each of these sessions if we select the Inspectors tab (#1 - orange circle). At the top is displayed the details of the request and below it the details of the response. We can also choose between a variety of formats for displayed those details: Headers, TextView, RAW HexView, etc.; as indicated by the red arrows (#2). Note that you can choose a different display format for the request and the response.

With the HTTP protocol, each request and each response are constitued of a single file (more exactly, a file for the request and a second file for the response) that contains two parts separated by a single blank line (arrows #6 and #7): the header and the text. So we have a header and text for the request and another header and text for the response; each of these two pairs separated by exactly a blank line in their respective file. If you click on either the Header or the TextView tab, only the header or the text will be shown - each of them with a special formating - but we can also choose the RAW format for displaying both of them but this time, without any special formating. This is the format that has been chosen for both the request and the response windows in the previous figure.

Finally, the HexView format will also show us both the header and the text - likes the RAW format - but will also add the hexadecimal value of each character into a second column that enable us to accurately determine the exact identification of each character, including the various *blank* and control character that might be present. Later, in the section 5, we will see an example if this hexadecimal format that will show us the identication of some strange characters coming from the corrupted file.

If we take a closer look at the header for the request shown in the previous figure, we can see that it contains first a POST parameter (#8, blue arrow) with the URL of the script file that the XML-RPC request was sent to (h ttp://sylvain2/BlogueWP1/xmlrpc.php" in this case). After a few other parameters, we find toward the end of the header this very important parameter that is the Content-Length. By the way, notice that the exact order of parameters in the header is without any signification and is not garantee to remains the same. After that, we see one last parameter ("Connection: Close") and finally, the blank line that is used as a separator between the header and the text that follows. In the case of XML-RPC, this text is a XML document that contains the information that we are sending to the server but with other requests, we could also see an ordinary HTML POST document.

If we now take a look at the detail of the Response that has been sent back by the XML-RPC server (bottom right window); we can see that it follows a similar format: an header followed by a blank line and a XML document as the text at the end. In the header, there is no POST parameter because this is a response but there's still a Content-Length parameter (#10, pink arrow) which contains the length of the text. Well, we should say that this Content-Length *should* contains the length of the following text. However, we will see later that with PHP, this is not always the case and that this little problem with the Content-Length parameter is indeed the source of many of our communication problems with WLW and that will also explains the truncated ending tag that we have saw earlier in the log file.

-- The rest of this section is for explaining some basic configuration options of Fiddler but if you want to, you can skip this reading and jump directly to the next section "5- Issue #1 - Appearance of the UTF-8 BOM" to see what happens with the Content-Length parameter. --

When we use Fiddler, the first setting to check is the Capturing mode. It's function is very simple: when the Capture mode is off, nothing is captured by Fiddler and we can see its value displayed at the bottom left of the Fiddler's window on the status bar: #4, green arrow. We switch between these two modes (ON and OFF) by either clicking displayed on the displayed value (note: only a white space is displayed when the mode is OFF but you can still click on it) or by pressing the function key F12 on the keyboard or by using the option "Capture Traffic: F12" under the File menu.

Even when the capturing mode is ON, Fiddler doesn't necessarily capture everything and there are many settings where you can adjust what will be captured and one of these settings is the second text icon directly at the right of the Capture mode text icon on the status bar, as indicated on the figure by the yellow arrow #5. This setting can be set to either "All Processes", "Web Browsers", "Non-Browser" and "Hide-All" and you can change this value simply by clicking on the text icon. In our case with WLW, this setting must be set to either "All Processes" or "Non-Browser"; otherwise, we won't be capturing the information that we need.

When Fiddler starts capturing, it is not uncommon to quickly get dozens or even hundreds of captured sessions so we must have a way to clarify this a bit and evidently, the first thing we can do is to delete all the older sessions captured from previous run. This can be done with the menu Edit | Remove | All Sessions. Besides that, Fiddler is offering us many filtering options that are found under the tab Filters which is shown in the following figure (orange circle, #1) :

Before using many of these filtering options, we must first activate them by checking ON the "Use Filters" checkbox in the upper left (#2). Note that the Filters tab will visually indicates to us when these filters are active by displaying a check mark directly on the tab itself (orange circle, #1).

The first available option is the "Keep only the most recent [200] sessions" (#7) that will automatically delete the older sessions above a certain number. You can adjust this value but it's set to 200 by default. Below that, there are the filtering options that apply to the servers - or "Hosts" in Fiddler terminology - for which capturing will be turned ON of OFF. There, we can choose to restrict the capture to the requests sent to any server (or "Hosts") or to a server either located on the local LAN (intranet) or on the Internet (Wide Areal Network (WAN)) by selecting "Show only Intranet Hosts" or "Show only Internet Hosts" on the combobox #3.

We can even be more specific than and directly name the desired servers or Hosts by selecting the option "Show only the following Hosts" on the next comobox and then indicating their names on the text box that follows right below, see #4. Here, I've set up the local server "sylvain2" as the specific host for which the capturing must be made. You can name more than one server if you want to.

Instead of filtering based on the servers (or "hosts"), you can also choose to filter based on one of the processes running on your machine and the "Client Process" is just for that. We must first check the box "Show only traffic from" (#6) and then select on the dropdown menu at the right the desired process. Here, I have chosen the process "WindowsLiveWriter: 3884 - Solutionner problème connection WLW" so that Fiddler will capture only the TCP/IP traffic initiated by Windows Live Writer. The process number (here 3884) and the shown title ("Solutionner problème connection WLW" here (in french)) will of course be different in your case. Beware: WLW always uses a single process for managing all of your windows; so even if you have multiple WLW windows opened, this selection will only show you one at a time, usually the one that's currently active. However, this choice will always be good for every opened WLW windows; regardless of the current active window.

Of course, you don't really need to select all of these options of even anyone of them. Also, be aware that some of these filtering options can also affect other things than just what will be captured or not by Fiddler and that with these, you can or could also block or change the transmission of any requests or responses related to any kind of TCP/IP activity. For example, if you check the "Block images files" option in the "Response Type and Size" section, the transmission of all the images files will be blocked not only for WLW but for the other processes as well; even including your current browser. In effect, this means that the web pagew will now be shown without any image displayed on it, as you can see from the second figure below. Therefore, you must be careful when using a program like Fiddler and you must check all the options carefully when something is not going or loking right.

5- Issue # 1 - Appearance of the UTF-8 BOM

Now that we know Fiddler, we can use it to solve our little problem: if we try again to communicate with WordPress using Windows Live Writer (WLW) but this time using Fiddler to watch the processus, we are quickly greeted by the following error message from Fiddler:

"Fiddler has detected a protocol violation in session #633. Content-Length mistmatch: Reponse Header claimed 634 bytes, but server sent 637 bytes."

Immediately after that, WLW shows us its generic error message that we have already seen previously and abort the rest of the communication. So it's looks like that the problem from a not well formated response from the server: the length of the text as indicated in the header (the Content-Length parameter) is too short of 3 characters. This difference of 3 characters explains why the text of the response recorded by WLW in its log file has been truncated: WLW stopped reading the rest of the text after reaching the total numbers of characters as indicated in the header and simply dropped the rest. So WLW is giving full precedence to the Content-Length parameter instead of trying to follow the textual layout of the XML document has it has been written in the response file by the XML-RPC server.

One way to correct that would then be to make a proper adjustement to this parameter in the PHP script where it is calculated. For example, Peter Van Eeckhoutte suggests in his blog ("Windows Live Writer unable to connect to Wordpress Blog | Peter Van Eeckhoutte's Blog") to modify the WordPress file class-IXR.php - which is the script that generates the XML response - located in the directory "wp-includes" by changing the following line located in the function output ($xml) :

$ length = strlen ($xml);

so that it will now automatically add 3 characters every time:

$ length = strlen ($xml) +3;

It doesn't need much explanation to say that this correction is not very satisfactory not only because this is a "blind" correction but also because it doesn't tell us anything about why the calculated length is invalid in the first place and, of course, doesn't correct the problem at its source at all. We don't know if this will always be the case or if the problem will get corrected at some point in time and furthermore, we don't know either what will happen is someone want to use another blog editiong software than WLW.

So this is clearly not a very good solution but to find a better one, we must first know why there is this discrepancy in the first place and this exactly what we can find if we take a deeper look at the response using the Hexadecimal mode of Fiddler by chosing the HexView tab (orange circle) :

In this mode, the information is displayed on three columns: in the first, we can see the address of each line in hexadecimal; in the second column, the hexadecimal value of each character and finally in the third, the characters themselves; with the exception the control and other non-printable characters which are replaced by a point.

If we look in the third column for the beginning of the XML document, that is, the five characters <?xml; we can see that they are preceded right before them by three strange characters : ï»¿ ; that I have highlighted in blue on the figure. These three characters are the BOM (Byte Order Mark, see "Byte order mark - Wikipedia, the free encyclopedia") for an UTF-8 (Unicode 8 bit) encoded file. Usually, a BOM marker for an Unicode file will only be present at the beginning of it and not in the middle. While this location in the middle is not really forbidden, the presence of a BOM at a location other then the beginning of the file has no signification and normally, a program should simply read past them when they are in the middle of a file.

However, for Windows Live Writer (WLW), these three characters are not totally skipped away and while they are not used to determine the encoding of the file, as it should be because they are not at its beginning, they are still counted as part of the total number of characters indeicated in the Content-Length parameter. However, a close observation of the PHP code reveals that when they are emitted, they are not be counted as part of the length of the text; which at the end gives us this truncated XML decument by three characters.

It looks that we have found the cause of our truncated response: the presence of the BOM in mid-file offset the reading of the XML document by WLW by 3 characters and there is a serious problem here: if we don't adjust the Content-Length; WLW is thrown off by three characters. However, we don't know for sure if this will always be the case and we don't know eithr what will happen if someone else will want to use another blog editing software than WLW. Furthermore, this problem with the presence of the BOM is only one of the many other possible problems that can also affect the value of the Content-Length parameter. For example, on his blog (in italian), Etrusco says that he has found a difference of 10 characters between the length specified in Content-Length and the actual length of the XML document; see "Windows Live Writer e wordpress, quando l’xmlrpc smette di funzionare! | pensando.it".

So our best solution here would be to get rid of the presence this BOM in the middle of the file and for this, we must know how and why is PHP writing this BOM in the first place and if there is any way of stopping it doing this. This is the topic of the next section.

6- BOM (Byte Order Mark), PHP and XVI32.EXE

The primary function of the BOM (Byte Order Mark) is to indicate the storage order of bytes for files that have been encoding using the 16 bit of Unicode (UTF-16); because, in the case of the 16 bit mode, two bytes are used for each character but depending of the operating system, either the high order byte or the low order by could be written first for each pair. The writing of a BOM at the beginning of the file is then useful for specifying which one of these two orders has been used. The case for the 8 bit mode of Unicode (UTF-8) is a little different because there is no byte order in this case and whatever the operating system, all files encoded with UTF-8 are always encoded in the same way. However, writing a marker at the beginning of a file encoded with UTF-8 could still be useful to distinguish it from other encoding that are not UT-8 (weither it is one of the two UTF-16 or one of the various Ascii modes or anything else).

Beside the ordering of the bytes, the big problem with UTF-16 is that for Latin alphabets, they take twice the size of files encoded with an Ascii character sets such as Windows-1252 but this is not a problem with UTF-8. English files encoded in UTF-8 occupy the same size and for other latin alphabet such as french or spanish, the difference in size is barely bigger. The advantage of size is not always there for other alphabets such as Thai but then, there is the problem is mixing multiple alphabets inside the same file; like a combination of english, french, spanish and Thai if someone want to do that. This is not a problem with UTF-8, so in recent years, it has slowly but surely started to make its way of becoming the de-facto standard for the internet and for the storage of internationalized files.

However, there is one small problem that remains and this is the question of writing or not a BOM for UTF-8 files and on this question, the of PHP 5 for UTF-8 is seriously lagging behind. While many other languages offer the option of writing or not a BOM; the developers of PHP 5 have simply chosen to automatically write or not of a BOM based on its presence in any of the PHP script files involved. So to be clear: you or the programmer doesn't decide to write a BOM or not but PHP will decide based on the fact that it will find at least one PHP script file with a BOM when it will execute a list of script files for a call. So the presence of a single file with a BOM wins it all. And to make things worst, there is not even a simple way of knowing or finding from inside a script is one will be written or not; so this is something that is totally out of our control.

However, in our case, the solution is simple: if a BOM has been written then it's because one (or more) of the PHP script files has one and all we have to do is to find this culprit and strip away its BOM marker.

There are many ways of finding this. First, you could use a program such as EGREP to scan for every files and report those who have one or you can use an editor such as NotePad++ capable of showing - and deleting - a BOM at the beginning of a file and take a look at each file one by one. Many of you probably have one favorite but for those who don't have one, I will suggest here a small program because of its simplicity of use: XVI32, a free hexadecimal editor that you can download for free and that doesn't need to be installed on your system. Once downloaded, all you have to do is unzip it and then double-click on the executable XVI32.EXE file to launch the program. You can then use the menu to open the desired file or better yet, do a Drag & Drop of the desired file directly on the program's window:

The only problem with this method is that you have to verify each file one by one until you find the culprit but in this case of Wordpress, there is one likely suspect and it's the configuration file wp-config.php. While the distributed version of this file doesn't have a BOM, this is our likely suspect because this is a file that we'll have to open in order to make change to the configuration of the WordPress installation and by doing so, we are putting ourself at the mercy of any editor that will think that it will be a good idea to add a BOM at the beginning of a file without even telling us (or by telling us while we don't understand the full implication of doing this). This is the root of the problem: even if the distributed file doesn't have any BOM, there is a lot of ways that can make this happens or, as bad, removing it. Therefore, it's a moving target and you must be careful, when you are editing this file or any other PHP script file, to not introduce inadvertantly a BOM at its beginning.

If you want to remove the BOM using XVI32, simply use the Delete key over its three characters as they are shown above. Note however that with other editors, the process for removing a BOM is not necessarily the same and that you might have to look at the options provided by the program. Again, as some programs might add one - or strip it - automatically without telling you; so you must be careful and always check before using any editing program with a PHP script file.

7- Presence of extraneous characters in a PHP script file

As we have also say earlier, the presence a BOM is not the only thing that can throw away the determination of the exact value for the Content-Length parameter in a PHP script and two others would be the presence of extraneous characters - usually newlines and blank lines - at the beginning and the end of one or more PHP script files. These extraneous characters are anything - including a blank space or a new line - that comes before the PHP starting tag <?php or the ending tag ?> (albeit we have some very little lose for the end). A PHP script used for a web page can normally have many of these starting and ending tags and also have a lot of other characters outside of these delimiters to be retranscribed verbatim on its output but the case for a script file used to build an XML-RPC response is different because these XML responses must follow a strict guideline and the presence of any illegal or extraneous character is forbidden; therefore those scripts must be constitued of a single pair of tags and have nothing else outside of them; not even a blank space or a newline at the beginning or at the end. The only disgression is one single newline after the ending ?> with maybe one or more blank space between the final ?> and its single newline but nothing else after that; not even a second newline or a blank line.

Unless by taking some very convoluted look at the output buffer, a PHP script cannot know if there is anything else outside of these two delimiters so it cannot takes these into account when calculating the length the XML document to be put in the Content-Length parameter and therefore, if there is indeed some extraneous characters in any of the script files, this parameter will be invalid and WLW will be unable to correctly read the XML response and will throw an error message. If this is the case, we cannot directly determine which script is badly written by looking at the response or in the log file; however, we can at least determine if we are in front of a problem caused by extraneous characters instead of something else such as the presence of a BOM or a error or a warning message from the script itself; thus greatly restricting the field of search for solving the communication problem. In the next two sections, we will see how to look in the Response for the presence of extraneous characters at either the beginning or the end of a script file.

8- Presence of extraneous characters at the beginning of a PHP script

We already know that when the Response is correctly formatted, one blank line (#5 and 6) separate the header from the XML response (#3 and 4); as we can see in the below figure illustrating a capture from Fiddler using the RAW mode. Remember that the top window at the right is the Request and the bottom window if the Response and that we are mainly interested only in the Response in these cases. (With most XML-RPC communication problems with WLW against a PHP server, there is no problem with the Request, only with the Response.)

If we take a look in the log file of WLW for the same correctly formated Response, we don't see the header or the blank line - because normally WLW doesn't record them - but we can see a proper and well written XML document; with no blank line before and no truncation of its ending tag </methodResponse> at the end:

Now, let's take a look at what happens if we add a single extraneous blank line (#1) at the beginning of one of the PHP script, for example wp-config.php, just before the starting tag <?php :

As expected, we will now receive an error message from WLW to the effect that the received XML-RPC response from the server is invalid and the capture from Fiddler will now show a second blank line separating the header from the XML text in the case of the Response (#2, bottom window) :

Furthermore, a look at the entry in the log file will now show a blank line before the XML document (#1, there was none in the case of a correctly formated Response) and the presence of a truncated ending tag (#2) :

Of course, if there are other extraneous characters such as additional blank lines or anything else, we will see all of these in both the capture from Fiddler in the log file. For anything more than a single extraneous blank line, Fiddler will also start telling us about a difference between the Content-Length parameter and the real length of the text. (But it won't say anything when there is only a single extraneous blank line because there is some lose for the eventual presence of an ending newline at the very end of the file.)

The problem here is that we don't know which file(s) on the server side has this or these extraneous characters; so we will have to look at them one by one. The best way of doing this would be to switch to a standard template and deactivate all the plugins. If the problem doesn't disappears, we can say that it is located in one of the file that is part of the standard distribution of blogging system; probably wp-config.php in the case of Wordpress. If it disappears, then we can say it's either in the installed template or in one of the plugins. Most likely, this will be the second case; ie, one of the plugins; so you can start re-activating them one by one until your find the culprit.

9- Presence of extraneous characters at the end of a PHP script file

Beside being possibly at the beginning of a script file, extraneous characters can also be present at the end of the file; after the final ?> ending tag. However, there is a little twist here: it's not because that they are at the end of the script file that you will find them at the end of the Reponse, after the XML document. When PHP execute the main script file (xmlrpc.php in the case of WordPress) for executing a XML-RPC call, this script file will usually include one or more other script files near its beginning in order to get access to some additional PHP functionality and often, many of these included files will also include themselves other additional files.

However, while these additional functions might be called later (or never) during the execution of the script; this is not the same for the presence of any extraneous characters: their printing will not be delayed later but instead will be done as soon as the containing file is including; which means usually before the execution of the main call in the main script file. Therefore, the presence of any extraneous characters at the end of an included file will appears before the writing of the XML document response; ie, will appear at the same place as for the presence of extraneous characters at the beginning of a script file.

For example, I have put one more blank line ad the end of the file wp-config.php; as you can see from the following figure:

I had to select the fnals character so that you can it. As expected, after this change, the XML-RPC communication between WLW and WordPress doesn't work anymore and the capture of the Response by Fiddler or the WLW's log file will now show us an extraneous white line before the XML document and a truncated ending tag; just like it was in the case with an extraneous blank line at the beginning of the script file:

So, if it's difficult or impossible to distinguish between extraneous characters at either the beginning or the end of a script file, what is our best solution? Well, there is no magic solution here and like it was the case for extraneous characters at the beginning, the first step is to identify the culprit by checking all the main files - always think first about the configuration wp-config.php in the case of WordPress - and if you don't find it, by deactivating all plugins and all installed templates and going through them one by one and carefully checking their end.

However, in this case, PHP has a nice little feature that can greatly facilitate our task of carefully checking the end of each file and it is that the ending tag ?> at the end of a PHP script file is now optional since some of the last versions. This means that instead of carefully checking their ends; we can simply delete the ending tag ?> and after that, the scripting part will automatically extend to the very end of the file; without anymore the possibility of any extraneous characters at its end:

-- Look Mom, No Hands!

This feature that the last matching closing tag ?> is optional at the end of a script file is a peculiarity of the PHP language but it comes to be very handy in this situation.

This completes the first part of this quick overview about some of the communication problems of Windows Live Writer with a PHP based blog systems using XML-RPC. In the next part, we'll see some of the other causes of communication problems that can happen and in particular, we will take a look at the presence of various warning messages that PHP can wrongly insert inside a XML Response under various conditions and that can result into a disrupted XML-RPC communication.

Solving the Google Friend Connect's display problem with Firefox

2009-12-22T05:32:00.001-05:00

On many sites, the Google Friend Connect widget (and its counterpart the Followers gadget for Blogger) will not appear at all or rarely on Firefox. A solution was published by Google (see "Why is my Google Friend Connect rarely displaying on my blog???" but it seems appropriate only for a group of sites using Prototype.js and remains without effect on other sites.

This article proposes another solution for this display problem of Google Friend Connect and of the Followers gadget on Firefox for those for whom the solution offered by Google is not appropriate. It has been tested successfully with different types of templates - including those produced by Artisteer - and for sites hosted on Blogger or not. A quick way for testing if this solution will be suitable for your site - without having to first modify it - is also provided along the way.

Note - the application of this solution requires to have some basic knowledge of javascript and also requires that you are capable to edit the template of your site but the necessary change is relatively simple and a Copy & Paste of the code provided at the end of the article should suffice in most cases. This article is provided with several examples of code to explain how it works but it is not necessary to understand them to use it and if you want, you can go straight to the end of this article to use the code.

The examples in this article have been made with the Google Friend Connect (GFC) widget on an Artisteer template hosted on Blogger but this solution is not limited to this configuration only and will also applies to the Followers gadget as well as to other types of templates and hosting services. Those who also have the compatibility issue with Prototype.js will still have to apply the solution provided by Google about JSON; all the necessary explanations for this is also provided in this article.

You can see various tests done with GFC on the demo site "Google Friend Connect and Firefox" and see by yourself the difference in results between Internet Explorer (IE) and Firefox with different possible solutions. It is normal for many of these tests to not display properly on Firefox. There is an article on this site describing quickly each of these tests but this is only for an illustrative purpose and it does not repeat the explanations already provided here.

A future article will deal specifically with the specific changes to make for the Followers gadget for those wanting to use it on Blogger instead of Google Friend Connect but overall, the solution is essentially the same as the one described here for GFC. You can see a second serie of tests done with the Followers gadget on another site: "Gadget Followers and FireFox". Remember, it is normal to see several of these tests not displaying properly with Firefox.

For those who have problems with the display of GFC on Firefox, the solution recommended by Google - and published in the post "Google friend connect social bar is blank in Chrome and Safari - Google Friend Connect Help" by Seth Fitness - is to add the following code between prototype.js and the code of the GFC widget (preferably just before the latter):

This code aims to resolve a problem of incompatibility between prototype.js and the GFC code by restoring the default JSON parser. However, if it actually solves the problem for those who have this specific problem of incompatibility, it resolves nothing for others who do not use prototype.js but still have a display problem on Firefox with GFC. Thus, we can divide the situation into three groups:

1- The problem of incompatibility with prototype.js

2- Another source of problem

3- The first two put together

Those who have only the first problem may correct their site using the Google fix and be done with it. However, for the others, you can try with the possible solution offered in this article, either in combination with or without the Google's fix. I should say that if you don't need it, using nevertheless the fix could broke the solution provided here; so you really need to test it without the fix as well if it doesn't work with it.

If we exclude the problem of incompatibility with prototype.js, I found that the display problem on Firefox seems to stem from the difficulty that it has to correctly handle the dynamic creation of an <iframe> element within one or more <div> elements when they have not yet been closed; that is to say when the terminal tag </div> have not yet been parsed:

<div>
<div>
    <div id="div-1234567890">...</div>

    <script>
         // Code javascript immédiat, créant dynamiquement un
         // élément <iframe> à l'intérieur du <div> précédent.
    </script>

... The HTML code that follows here has not yet been parsed and the first
      two <div> elements are still open at this point. The previous javascript
      code will then insert the new <iframe> element inside an open
      hierarchy of <div>; this even if the last <div> above has been closed.

</div>
</div>

In the previous example, the javascript code is inline code; that is to say that it will be run immediately by the browser before the following HTML code is to be parsed. This also means that at the time of its execution, many of <div> elements which cover it will still be open because their terminal tags </div> will have not been parsed by the browser and won't be until the inline code is finished. This is a necessary behavior because it is possible for the inline javascript code to issue (or inject) a new piece of HTML code with a call to document.write and in this case, this new piece will have te be parsed before the remaining HTML code that follows the inline javascript code.

But as we can see in the previous example, the inline javascript is contained inside two open <div> elements; alongside a previous third <div> element that has been closed but which is itself inside the two open <div>. This is into this third <div> element - with and ID likes "div-1234567899" and highlighted in yellow - that the Google Friend Connect widget will dynamically create an <iframe> (whose content is the elements for the GFC widget) and add it as a child node. So, the inline javascript code of the GFC will dynamically create an <iframe> and add it to a closed <div> element but this closed element is itself in an hierarchy of still open one or more <div> elements and that's what Firefox seems to have a problem with.

If this is really the source of the Firefox's display problem, then we can see that a possible solution would be to make sure that the <div> to receive the soon to be created <iframe> element is not located inside an open hierarchy of <div> when the code execute and this can be easily achieve by a variety of ways; for example:

1 - Moving the <div> element earlier in the HTML code, before any open open div element.

2 - Moving the inline javascript code farther away in the HTML code, after any relevant closing </div> tag; the best place probably being near the ending </body> tag.

3 - Change the javascript code so that it is no more an inline piece of code with immediat execution and instead, delay its execution at a more appropriate time; such as when the closure </div> tags have been parsed or even better, after the loading of the final <body> element.

The previous example has been made from an Artisteer template and your own personal mileage will vary but the overall principle should remain the same. However, it's now the time to take a deeper look at the GFC widget code itself. One such example of code is shown below. Some values as the ID for the principal <div> tag (in yellow), the width or the colors will change in your own case but the rest should be identical. Highlighted in yellow is the <div> designated to receive the <iframe> element and in blue is the method renderMembersGadget. This is the method that will create the <iframe> element and therefore, this is the one that we must delay in one way or another (beside moving the <div> element) if we want to try our solution.

<script type="text/javascript" src= "http://www.google.com/friendconnect/script/friendconnect.js">
    </script>



<div id="div-4539487656055420414" style="width:250px;border:1px solid
   #cccccc;"></div>


<script type="text/javascript">
var skin = {};
skin['BORDER_COLOR'] = '#cccccc';
skin['ENDCAP_BG_COLOR'] = '#e0ecff';
skin['ENDCAP_TEXT_COLOR'] = '#333333';
skin['ENDCAP_LINK_COLOR'] = '#0000cc';
skin['ALTERNATE_BG_COLOR'] = '#ffffff';
skin['CONTENT_BG_COLOR'] = '#ffffff';
skin['CONTENT_LINK_COLOR'] = '#0000cc';
skin['CONTENT_TEXT_COLOR'] = '#333333';
skin['CONTENT_SECONDARY_LINK_COLOR'] = '#7777cc';
skin['CONTENT_SECONDARY_TEXT_COLOR'] = '#666666';
skin['CONTENT_HEADLINE_COLOR'] = '#333333';
skin['NUMBER_ROWS'] = '4';

google.friendconnect.container.setParentUrl('/' /* location of rpc_relay.html
   and canvas.html */);

google.friendconnect.container.renderMembersGadget(
   { id: 'div-4539487656055420414',
     site: '16774183366910057534' },
   skin);

</script>

Note that in this example the ID for the main <div> tag is "div-4539487656055420414". It's a long number but you can change it to whatever you like (it doesn't even need for the new value to begin with "div-"); all it needs is to be unique among all the other IDs on your site. It's also interesting to see that the automatic value provided by GFC always begins with "div-"; this way, it make it easy to found it on your site if you need to. This would prove to be particularly useful in the case of the Followers gadget.

However, what's more important is that this ID's value is also passed as a parameter to the renderMembersGadget method below; so you can change its value but you must change it at both location. This is important if you want to take the below examples and try them on your own site. Beside this ID, you must also change the value identifying the site to GFC: this is the value
« site: '16774183366910057534' » in the above example which is passed as the second parameter to the renderMembersGadget method and it must be replaced with the value of your own site. Look at the code provided by GFC to find it.

The rest of the GFC widget code consists of a link to the javascript file "friendconnect.js" and of lines of code which initializes the variable skin{} with the values for the visual appearance to be displayed by the GFC widget. There is nothing particular with these lines of code and they can be executed anywhere as long as it is before the call to the renderMembersGadget method. The same is also true for the call to the setParentUrl method.

However, the reading of the file "friendconnect.js" might pose a problem in some particular situations: the javascript code for the renderMembersGadget method (which by the way is a member of the google.friendconnect object) is part of this file; so this file must have been loaded before we get the right to call this method. This is not a problem for the code as it is actually written - the browser will garantee that it has been loading before executing any inline javascript code that follows it - but if we change this inline code so that it's no longer inline, there will be no more any garanty. Later, we will take a measure to prevent this in the final example.

The examples that follow have been made using an Artisteer template for Blogger. Your own situation will likely be different if you are using something else but that's not important for the comprehension of what follow. I have highlighted in yellow the beginning and ending of two <div> elements that contain the inner <div> and the javascript code that will create the <iframe> for the GFC widget; the later two beeing highlighted in a darker shade of blue.

<div class='widget HTML' id='HTML3'>
<h2 class='title'>Google Friend Connect #1</h2>
<div class='widget-content'>


<script src= "http://www.google.com/friendconnect/script/friendconnect.js" type="text/javascript"></script>



<div id="div-7924693163980589398" style="width:250px;border:1px solid
#cccccc;"></div>


<script type="text/javascript">
var skin = {};
...

google.friendconnect.container.renderMembersGadget(
{ id: 'div-7924693163980589398',
site: '16774183366910057534' },
skin);

</script>

</div>
<div class='clear'></div>
</div>

And as already mentioned, what we need to do is to make sure that inner <div> is not inside any open <div> when the javascript executes; so the first solution would be to move it before them:

<div id="div-7924693163980589398" style="width:250px;border:1px
solid #cccccc;"></div>

<div class='widget HTML' id='HTML3'>
<div class='widget-content'>
...

google.friendconnect.container.renderMembersGadget (
{ id: 'div-7924693163980589398',
site: '16774183366910057534' },
skin);

</div>
</div>

and the second solution would be to move instead the javascript code after them:

<div class='widget HTML' id='HTML3'>
<div class='widget-content'>
      ...

<div id="div-7924693163980589398" style="width:250px;border:1px
    solid #cccccc;"></div>

</div>
</div>

google.friendconnect.container.renderMembersGadget (
{ id: 'div-7924693163980589398',
     site: '16774183366910057534' },
skin);

Finally, the third solution would be to keep both at their same locations but to change the javascript code so that it will no longer be executed immediately but only at a later time; at least after the moment that the closing </div> will have been parsed.

On the site "Google Friend Connect and Firefox", I made several tests to illustrate some of the above points to varying degrees. All these test should display correctly under IE but but of course, some of them won't do it on Firefox. I remind you that this site has been made with an Artisteer template but you won't necessary get the same result using another template. However, it's my expectation that the solution provided at the end of this article should work for you and this, whatever the template that you are using.

In the first box, with the title "Google Friend Connect", we simply have the original code as directly produced by the GFC page, without modification. Probably that if you test it with Firefox 3.5 or the latest version, Firefox 3.6 Beta 5, this widget won't display at all; unlike with IE.

The second box, titled "GFC 1", is simply an empty box excerpt for the inclusion of a comment; so it shouldn't display anything. This is not very useful but we'll put it to good use in the next article about the Followers gadget and in which we'll need to take a look at the structure of a (empty) gadget on Blogger.

The following box, titled "CFA 2", was for the tests that I did make with the solution provided by Google about the compatibility problem between GFC and prototype.js. As I do not use prototype.js, my expectation was that I would get no positive result and this is exactly what I got. However, I also found that the simple fact of using this fix when you don't need has a negative effect in the way that the following boxes with the right solution - for my case - were not working anymore after that; so I had to remove this fix from the demo site.

Then comes the first real test for a potential solution - at least! - which is the use of the defer attribute and which result is shown in the box under the title "GFC 3 - Defer". You can find more information about this attribute in the article "Deferred Javascript" but in our case, all we have to do is to add it to the script element containing the method call to renderMembersGadget:

       ...

<script type="text/javascript" defer="defer">
       ...

google.friendconnect.container.renderMembersGadget (
{ id: 'div-7924693163980589398',
     site: '16774183366910057534' },
skin);

</script>
       ...

This test is also the first one where we get tangible result because with the add of this attribute, Firefox 3.5 will now display the GFC widget correctly on this demo web site. Unfortunately, this is not the case with the latest version of Firefox, the 3.6 beta 5.

This special attribute "defer" is an index indicating to the browser that is not necessary for the script element to be executed immediately before the browser can continue the parsing of the remaining HTML elements that follow. This allows the browser to display the page and return control to the user more quickly; while the processing of the javascript is completed in the background. Many browser will interpret this as a signal to wait for the parsing of the final </body> tag before beginning the execution of the scripts with this attribut. However, this interpretion or even any interpretation about this attribute is not mandatory; which explains in part why this potential fix does work with Firefox 3.5 but not with the version 3.6 Beta 5.

Although unfortunately this does not work with the latest version of Firefox, this result is nevertheless interesting in that it tells us that basically, probably that there is no major error or problem in our template and that the display problem with GFC seems to lie more on the side of Firefox or in the code of the GFC widget instead of beeing in the template itself.

The two following examples, GFC 4 and 5, are even more interesting than #3 because we will see the the first solution which will work as well with both the Firefox 3.5 version and the 3.6 beta 5 version. For these two tests, I separated the code of the GFC widget into two different gadgets; so that the second gadget - the one with the javascript code - will come after any closing </div> that might present in the first gadget.

In the first case, the #4, I've put the second gadget right after the first while for the second case, the #5, I put it at the very end of the list of gadgets. This end of the list is not really at the very end of the template itself and many other elements such as the footer and the copyright notice still follow it but in our case, this was sufficient for the case #5 to show correctly on Firefox, including the beta 5 version!

The test didn't work in the case #4, even if its code is identical to #5; which shows us that the gadgets in this Artisteer template are themselves located inside a deeper hierarchy. However, because the #5 did work, this also tell us that probably that there is nothing fundamentally wrong in the template itself and that this problem is most likely to be caused by a bug from either Firefox or Google Friend Connect than by a design error with the template.

If all you need is a working solution, than you don't really need to search any further than the solution used in #5; which is simply to move the javascript code away, toward the end of the HTML page (the </body> tag). But there are some interesting points to find by digging deeper and in particular, we'll take a look at how we could test for these different scenarios in the easiest way possible and preferably, without to even have to modify our code and this is exactly what the test GFC 6 is all about. For this one, I've put the javascript code for calling to the renderMembersGadget method inside the clicking event of a button and by clicking it on the demo site, you can see that this method is working perfectly well; not only on IE but also on all versions of Firefox as well.

Maybe you're not that tempted to install a button for displaying the GFC widget on your site - personally, I am as this will make the loading of the site much faster! - but in reality, this is very insteresting for everyone because it gives us an easy to test this solution on any web site; without having to modify it first. All we have to do is to copy one line of code, to modify the value of the parameters for the div's and the site's iD, to add "javascript:" at its beginning and finally to paste the result into the address bar of the browser and to execute it by pressing [Enter]. Of course, in the case of the demo site, you don't have to change anything.

If everything is correct and if you don't need the Google fix, you'll see the elements of the GFC appearing on the page. In the case that you would also need the fix, all you have to do is to add it, too. A full example for both cases is given below. Also, in the case of Firefox, you don't have to remove any line break but for IE, everything must be on one line. You will find below a full example for each of these cases: without or with the fix and on multiple lines or a single one:

Without the JSON fix:

javascript:google.friendconnect.container ['renderMembersGadget'] (

{ id: 'div-6508336042659712443',
site: '10657890614271830163' },
skin);

javascript:google.friendconnect.container['renderMembersGadget']({id:'div-6508336042659712443',site:'10657890614271830163'},skin);

And with the JSON fix:

javascript: window.JSON = {
parse: function (st) { return st.evalJSON(); },
stringify: function(obj) { return Object.toJSON(obj); }
};
google.friendconnect.container ['renderMembersGadget'] (
{ id: 'div-6508336042659712443',
site: '10657890614271830163' },
skin);

javascript:window.JSON={parse: function (st) {return st.evalJSON();}, stringify: function(obj) {return Object.toJSON(obj);}}; google.friendconnect.container['renderMembersGadget']({id:'div-6508336042659712443',site:'10657890614271830163'},skin);

Remember that if you don't need the compatibility fix for prototype.js, adding it migh make the problem got worst; so you really have to test for both cases.

Finally, in the tests GFC 7, 8 and 9, we'll use the window.onload event to run the code only after the last HTML element of the <body> segment has been parsed and loaded by the browser. To do this, we first enclose the code inside a function and then we load this function in an event so that it will be run a a later time istead of being executed immediately. For the first test of this type, the #7, I've used the window.onload event. The following listing show in yellow the change that I've made to the GFC's original code:

<script src="http://www.google.com/friendconnect/script/friendconnect.js" type="text/javascript"></script>


<div id="div-7508336042659712443"
    style="width:250px;border:1px solid #cccccc;"></div>


<script type="text/javascript">

function DisplayGFC7() {

var skin = {};

skin['BORDER_COLOR'] = '#cccccc';
skin['ENDCAP_BG_COLOR'] = '#e0ecff';
skin['ENDCAP_TEXT_COLOR'] = '#333333';
skin['ENDCAP_LINK_COLOR'] = '#0000cc';
skin['ALTERNATE_BG_COLOR'] = '#ffffff';
skin['CONTENT_BG_COLOR'] = '#ffffff';
skin['CONTENT_LINK_COLOR'] = '#0000cc';
skin['CONTENT_TEXT_COLOR'] = '#333333';
skin['CONTENT_SECONDARY_LINK_COLOR'] = '#7777cc';
skin['CONTENT_SECONDARY_TEXT_COLOR'] = '#666666';
skin['CONTENT_HEADLINE_COLOR'] = '#333333';
skin['NUMBER_ROWS'] = '4';

google.friendconnect.container.setParentUrl('/' /* location of rpc_relay.html
   and canvas.html */);

google.friendconnect.container.renderMembersGadget(
{ id: 'div-7508336042659712443',
     site: '10657890614271830163' },
    skin);

}
   window.onload = DisplayGFC7;

</script>

As you can on the demo site, this method works perfectly with Firefox, all versions. However, using directly the window.onload event is possibly not the best thing to do. First, we have to think about the possibility that another event might already be enregistered on this event. Second, this event will fire not immediately after the parsing of the ending </body> tag but only when all the images on the page have also been loaded; something which could bring a significant delay on many sites. You will find more information about these point as well as about the window.onload event itself on the following articles: "Using window.onload", "Dean Edwards: The window.onload Problem - Solved!" and "How to Use window.onload the Right Way - Robert Hahn".

The article by Dean Edwards mentions the possibility of utilizing the addEventListener method in Firefox in order to accelerate the onset of the event but we must also think about the other browsers on the market. You can obviously build all the code required by yourselves to get the best option for many cases but those using Artisteer have access to the artLoadEvent() function to ensure an optimum loading:

...
<script type="text/javascript">

function DisplayGFC8() {
   ...
google.friendconnect.container.renderMembersGadget(
      { id: 'div-8508336042659712443',
         site: '10657890614271830163' },
      skin);
}

artLoadEvent.add (function() { DisplayGFC8(); });

</script>

Notice that even if the box #8 is located after the #7, it will appears before the later on the demo site because the window.onload event used for the #7 will usually fire later than the event used in the #8.

Finally, there is also the question - already mentionner earlier - that the code in the file friendconnect.js might not have been loaded yet when the event is triggered; so a call to the renderMembersGadget will fail at this point because it's to early. Remember that it's only for inline code that the browser will garantee that any previous javascript file has been loaded before attempting to execute the code; so in our case, it's not a bad ideal to add the necessary extra code to make that verification and to step back to come back later if necessary. This is exactly what's has been added in the next example. At the beginning of the function, there is a check about the presence of the google.friendconnect object. If it's not found, a timer is set for the function to be called back in two seconds and the function is then exited. (See "JavaScript Timers with setTimeout and setInterval". This process is repeated if necessary until success or up to a maximum of 10 retries; for a total maximum of 20 seconds before a timeout. After that, if the object is still not available, the display of the Google Friend Connect widget is canceled.

This example uses artLoadEvent() but the code remains the same if you want to use the window.onload instead.

<script src="http://www.google.com/friendconnect/script/friendconnect.js" type="text/javascript"></script>


<div id="div-9508336042659712443" style="width:250px;border:1px solid #cccccc;"></div>


<script type="text/javascript">

var CountGFC9 = 0;
var FlagGFC9 = false;

function DisplayGFC9() {

    if (!window.google || !google.friendconnect) {
        // Retry for up to 20 seconds.

        if (CountGFC9 ++ < 10)
            // 2 seconds of delay.
            setTimeout('DisplayGFC9()', 2000);
        else
            FlagGFC9 = true;
        return;
    }

    if (FlagGFC9 == true)
        return;

    FlagGFC9 = true;

var skin = {};
skin['BORDER_COLOR'] = '#cccccc';
skin['ENDCAP_BG_COLOR'] = '#e0ecff';
skin['ENDCAP_TEXT_COLOR'] = '#333333';
skin['ENDCAP_LINK_COLOR'] = '#0000cc';
skin['ALTERNATE_BG_COLOR'] = '#ffffff';
skin['CONTENT_BG_COLOR'] = '#ffffff';
skin['CONTENT_LINK_COLOR'] = '#0000cc';
skin['CONTENT_TEXT_COLOR'] = '#333333';
skin['CONTENT_SECONDARY_LINK_COLOR'] = '#7777cc';
skin['CONTENT_SECONDARY_TEXT_COLOR'] = '#666666';
skin['CONTENT_HEADLINE_COLOR'] = '#333333';
skin['NUMBER_ROWS'] = '4';

google.friendconnect.container.setParentUrl('/' /* location of
   rpc_relay.html and canvas.html */);

google.friendconnect.container.renderMembersGadget(
   { id: 'div-9508336042659712443',
     site: '10657890614271830163' },
    skin);
}

    artLoadEvent.add (function() { DisplayGFC9(); });
</script>

Are we there yet? Almost! There's one last minor problem remaining and this one is about IE. In my tests with the demo site and for wich there is many GFC widgets, I noticed that often IE will indicate forever that the loading of the page is not yet finished. This happens very rarely when there is a single GFC widget on the page and is only a minor hassle but still, it leaves me an uneasy feeling (and by the way, it's also an indication that the problem is probably lying inside the GFC code than with Firefox or the template) so I decided to leave the thing unchanged when IE is used. You can do this in a variety of way but for this case, I chosen to use the conditional comments feature of IE:

When using the window.onload event:

<![if !ie]>
<script type="text/javascript">
window.onload = DisplayGFC7;
</script>
<![endif]></![endif]></![if>

and for the artLoadEvent() function:

<![if !ie]>
<script type="text/javascript">
artLoadEvent.add (function() { DisplayGFC9(); });
</script>
<![endif]></![endif]></![if>

Here's is the final version that I'm curently testing on my blog The Coding Paparazzi :

<script src="http://www.google.com/friendconnect/script/friendconnect.js" type="text/javascript"></script>


<div id="div-2696609035696973039" style="width:276px;"></div>


<script type="text/javascript">
var CountFollowers = 0;
var FlagFollowers = false;

function DisplayFollowers() {

    if ((!window.google || !google.friendconnect) {
        // Retry for up to 20 seconds.
        if (CountFollowers++ < 10)
            // 2 seconds of delay.
            setTimeout('DisplayFollowers()', 2000);
        else
            FlagFollowers = true;
        return;
    }

    if (FlagFollowers == true)
      return;

    FlagFollowers = true;

var skin = {};
skin['BORDER_COLOR'] = 'transparent';
skin['ENDCAP_BG_COLOR'] = 'transparent';
skin['ENDCAP_TEXT_COLOR'] = '#333333';
skin['ENDCAP_LINK_COLOR'] = '#0000cc';
skin['ALTERNATE_BG_COLOR'] = 'transparent';
skin['CONTENT_BG_COLOR'] = 'transparent';
skin['CONTENT_LINK_COLOR'] = '#0000cc';
skin['CONTENT_TEXT_COLOR'] = '#333333';
skin['CONTENT_SECONDARY_LINK_COLOR'] = '#7777cc';
skin['CONTENT_SECONDARY_TEXT_COLOR'] = '#666666';
skin['CONTENT_HEADLINE_COLOR'] = '#333333';
skin['NUMBER_ROWS'] = '4';

google.friendconnect.container.setParentUrl('/' /* location of rpc_relay.html and canvas.html */);

google.friendconnect.container.renderMembersGadget(
{ id: 'div-2696609035696973039',
   site: '12772179594974004608' },
skin);
}
</script>



<![if !ie]>
<script type="text/javascript">
    artLoadEvent.add (function() { DisplayFollowers(); });
</script>
<![endif]></![endif]></![if>

You can use this code directly if you want to, all you have to do is to change the value for the ID of the site (in yellow).

===>> Also, if you don't use Artisteer then you must also replace the line: artLoadEvent.add (function() { DisplayFollowers(); }); with the line: window.onload=DisplayFollowers;

===>> Finally, I remind you that you might also need to add the fix for the compatibility problem with prototype.js but only if you need it; otherwise things might get worse.

The widget for Google Friend Connect can be easily changed because its code is provided to us directly; unfortunately, this is not as easy with the Followers gadget. In a following article, we will see how to proceed with this gadget.

-- Erratum, december 22, 2009 --

In the example GFC-9 and in the last listing above, the following line of code (en yellow) contained an error:

function DisplayFollowers() {

if ((!google.friendconnect) {
// Retry for up to 20 seconds.

and has been corrected with the following addition, in yellow:

function DisplayFollowers() {

if ((!window.google || !google.friendconnect) {
// Retry for up to 20 seconds.

Sub-SubMenu for Blogger with Artisteer, part 3 - Dynamic width for the sub-menus

2009-12-14T03:20:00.001-05:00

In parts 1 and 2 of this article on the sub-subMenus for Blogger with Artisteer (see "Sub-SubMenu for Blogger with Artisteer, part 1" and « Sub-SubMenu for Blogger with Artisteer, part 2 ») , we have seen how to extend the number of levels of sub menu items for the models ( "templates") created by Artisteer (version 2.3) for Blogger. In this part 3, we will improve the visual appearance of these menus by adjusting their width ( "width ") to the size of the option titles they contain. Note that even if you do not want to use multiple levels of submenus and stay in one, this visual adaptation may still be interesting for you. It may also be for other users Artisteer using other types of template for Blogger, especially pure HTML templates. Such alterations will also itself the subject of a future article in order 'clarify its use.

Without any further waiting, here's the new replacement code for the function artDisplayTopMenu below:

// New version for artDisplayTopMenu(); allowing for second and third sub-menu levels.
// First level: option name must begin with a '-'
// Second level: begin with a '-+'
// Third level: begin with a '-+='

// Not HTML escaped so // <![CDATA[ ... // ]]> must be used:
// <![CDATA[

function artDisplayTopMenu (menuitems)
{
    ComputeWidth (menuitems);

    var i = 0;
    var subList = false;
    var subList2 = false;
    var subList3 = false;

    for (i = 0; i < menuitems.length; i++) {
      var item = menuitems[i];
      var itemname = item[0];
      var itemlink = item[1];
      
      var sstyle = '';

      if (item.length >= 3)
         sstyle = item[2];

      if ( ((itemname.indexOf("=") == 2) && !subList3)
        || ((itemname.indexOf("+") == 1) && !subList2)
        || ( (itemname.indexOf("-") == 0) && !subList) ) {
          document.write('<ul>');

      } else if ( ((itemname.indexOf("=") != 2) && subList3)
	|| ((itemname.indexOf("+") != 1) && subList2)
                || ((itemname.indexOf("-") != 0) && subList) ) {

        if ( (itemname.indexOf("=") != 2) && subList3) {
          document.write("</li></ul>");
          subList3 = false;
        }

        if ( (itemname.indexOf("+") != 1) && subList2) {
          document.write("</li></ul>");
          subList2 = false;
        }

        if ( (itemname.indexOf("-") != 0) && subList) {
          document.write("</li></ul>");
          subList = false;
        }

        document.write("</li>");

      } else if (i != 0) {
        document.write("</li>");
      }
      
      document.write("<li>");

      if (itemname.indexOf("-") != 0) {
        if (window.location == itemlink) {
          document.write('<a href="'+itemlink+'" class="active"><span class="l"></span><span class="r"></span><span class="t">'+itemname+'</span></a>');

        } else if(itemlink == "http://./") {
          document.write('<a href="#"><span class="l"></span><span class="r"></span><span class="t">'+itemname+'</span></a>');

        } else {
          document.write('<a href="'+itemlink+'"><span class="l"></span><span class="r"></span><span class="t">'+itemname+'</span></a>');
        }

      } else {

        if (itemname.indexOf("=") == 2) {
          document.write('<a href="'+itemlink+'" style="'+sstyle+'">'+itemname.substr(3,itemname.length)+'</a>'); 
          subList = true;
          subList2 = true;
          subList3 = true;

        } else if (itemname.indexOf("+") == 1) {
          document.write('<a href="'+itemlink+'" style="'+sstyle+'">'+itemname.substr(2,itemname.length)+'</a>');
          subList = true;
          subList2 = true;

        } else {
          document.write('<a href="'+itemlink+'" style="'+sstyle+'">'+itemname.substr(1,itemname.length)+'</a>');
          subList = true;
        }
      }

      if (i == (menuitems.length-1)) {
        if (subList3)
          document.write("</li></ul>");
           
        if (subList2)
          document.write("</li></ul>");

        if (subList)
          document.write("</li></ul>");

        document.write("</li>");
      }
    }
}

function ComputeWidth (menuitems)
{
    // L'élément span 'ruler' doit être formaté exactement (fonte, grosseur, style (italique, caractères gras, etc.) comme les liens
    // dans vos sous-menus et vous le mettez quelque part dans votre modèle Blogger mais avant le menu.  Vous pouvez le mettre
    // visible pendant l'étape de développement pour vous assurez qu'il a le bon formatage exact.

    // The span element 'ruler' must be formated exactly (Font, Size, Style (italic, bold, etc.) as the links in your submenus and it must
    // be put somewhere in your template but before the menu.  While developing, you can make it visible to verify that it has the correct format.

    // Example: <span id="ruler" style="visibility:hidden; font-family: 'Times New Roman', Georgia, Times, Serif; font-size: 14px; font-weight: bold; letter-spacing: 1px; "></span>

    var rulerSpan = document.getElementById ('ruler');

    // If the 'ruler' <span> element is not found, we are creating a new one here but it will have the wrong formating if you don't modify
    // the following code to your exact requirement.  You can drop this but then, the default width of the submenus will be used.

    if (! rulerSpan) {
      var s = document.createElement ('span');

      // Two different ways to define the style of the element.  Don't forget that the case (lowercase and upercase) is important.
      if (true) {
        s.style.visibility = 'hidden';
        s.style.fontFamily = "'Times New Roman', Georgia, Times, Serif";
        s.style.fontSize="14px";
        s.style.fontWeight="bold";
        s.style.letterSpacing="1px";
        s.style.position = "absolute";
        s.style.top = 0;
        s.style.left = 0;
      } else {
        // Two different ways of using a string to define all the style properties.
        var sstyle = "visibility:hidden; font-family: 'Times New Roman', Georgia, Times, Serif; font-size: 14px; font-weight: bold; letter-spacing: 1px; position: absolute; top: 0px; left: 0px;";
        s.setAttribute("style", sstyle);  // Firefox only.
        s.style.cssText = sstyle;         // Firefox & IE.
      } 

      // Two different places on where to insert the new 'span' element into the DOM (Document Object Model) of the page.
      if (true) {
        // Trying to make an appendChild(s) on the 'body' will be an error because this will try to add it at the end
        // of the current list of child but there are some open tags at this point.    
        // document.body.appendChild (s);  // Error to try this!
        document.body.insertBefore(s, document.body.firstChild);
      } else {
        var b = document.getElementById ('LinkList99');
        b.insertBefore(s, b.firstChild);
      }

      rulerSpan = s;
    }

    // Main line of the menu.  We always start from this main line, so there is no need to look
    // if the current itemname has any sub-level tag ("-", ...) at its beginning at this level.
    var i;
    for (i = 1; i < menuitems.length; ) {
      var item = menuitems [i];
      var itemname = item[0];

      if (itemname.indexOf("-") != 0) {
        i++;
      } else {
        // A sub-level has been found; we go down computing it's length and the length of any sub-sub-level that it might contains.
        i = ComputeWidth2 (menuitems, i, rulerSpan);
      }
    }
}

function ComputeWidth2 (menuitems, k, rulerSpan)
{
    var i, j, g, g2, l2;
    var item, itemname;
    var maxLen = 0;

    // Scan the array from position k to find all elements at the same level and their maximum length.
    // If an element from a down level is found, the function is called recursively; if an element from an upper
    // level is found, this mark the end of the current group; the maxLen is written to all of the groups elements
    // and the function return with the index of the first element after the end of the current group.

    for (i = k; i < menuitems.length; ) {
      item = menuitems [i];
      itemname = item[0];

      if (itemname.indexOf("=") == 2)
        g2 = 2;  // Third level of submenu.
      else if (itemname.indexOf("+") == 1)
        g2 = 1;  // Second level
      else if (itemname.indexOf("-") == 0)
        g2 = 0;  // First level
      else
        g2 = -1;  // No submenu: back to the main line.

      if (i == k)
        g = g2;  // Starting point for the group.

      if (g == g2) {
        if (rulerSpan) {
          rulerSpan.innerHTML = itemname.substr (g+1, itemname.length);
          l2 = rulerSpan.offsetWidth;
       } else
          l2 = 0;

        if (l2 > maxLen)
           maxLen = l2;

        i++;

      } else if (g2 > g) {
        // Another sub-level found; we go down and came back with the index of the next element after that sub-group.
        i = ComputeWidth2 (menuitems, i, rulerSpan);

      } else {
        // An upper level element has been found, it's time to finish this group and go back.
        break;
      }
    }

    // If the ruler has not been found, we keep the default length as specified in the Artisteer template.
    if (maxLen != 0) {
      // Adjust the following value of 28px to take into account the margin around the links of your submenus.
      // Ajustez ici la valeur de 28px pour tenir compte des marges entourant les liens de vos sous-menus.
      var swidth = 'width:' + (maxLen + 28) + 'px;';

      // At this point, "i" is the index of the first element after the end of the current group (or the end of the array).
      for (j = k; j < i; j++) {
        item = menuitems [j];
        itemname = item [0];

        // We mark only the elements that are part of the current group and jump over any sub-level element.
        if (itemname.indexOf("=") == 2)
          g2 = 2;
        else if (itemname.indexOf("+") == 1)
          g2 = 1;
        else if (itemname.indexOf("-") == 0)
          g2 = 0;
        else
          g2 = -1;

        // We mark the current element with the maximum width that has been found for the current group.
        if (g == g2)
            item [2] = swidth;
      }
    }

    return i;
}
// ]]>

Obviously, this new version of the function artDisplayTopMenu is compatible with the method that we have already seen in Part 2 for replacing the use of the Blogger's "Configure Link List" with a static list of options supplied in the form of JavaScript code. All you have to do to use the other method is to rename the function in the code above from artDisplayTopMenu to artDisplayTopMenu2 and insert the new intermediary function artDisplayTopMenu as it has been described int this Part 2. (Remember that you must also add a bogus argument (dummy) in the dynamic list of Blogger as described in this Part 2.)

If we look more closely at the code provided, we see that this new version of artDisplayTopMenu first includes a call to ComputeWidth:

function artDisplayTopMenu (menuitems)
{
ComputeWidth (menuitems);
...

The role of this function is to (recursively) scan the array menuitems for calculating the required width for each sub-menu and to store at the position [2] of this array this calculated value. This is the width that needs to be written for each link <a href="..."> of each submenu; and it's stored in the format "width: NNpx;" with NN representing the number of pixels required.

Upon the return from this function, the following code will extract this new value for the width that has been calculated and add it to the writing of each HTML link <a href="..."> as a style attribut:

Let us now take a look at this function "ComputeWidth". First, we see that it is divided into two parts: the first initializes some variables and then starts analysing the array "menuitems" for elements that are part of a sub-menu (all other elements are, of course, part of the main menu). When such an item is found - which mean that we are at the beginning of a first level sub-menu -the ComputeWidth2 function is called with the index of this element passed as parameter. This second function will search for all the other elements belonging to the same sub-menu, will determine the greatest width of text needed to display them all and will then enter this value in the array "menuitems" at the position [2] for each element to be part of this same sub-menu.

"ComputeWidth2" is also the function that will call itself recursively for analysing any sub-level menu that will be encoutered while analysing a first level sub-menu. When a sub-menu if finished - with all of its sub-level sub-menus as well - the function return with the index of the next element pass the end of the current sub-menu. The calling function can then resume its analysis of the submenu or of the main menu (if the calling function was ComputeWidth) that it was analysing before encountering a sub-level menu. The whole hierarchy of the main menu with its submenus and their own submenus is in this way recursively analysed.

As this process is done recursively, you can see that it will be very easy to add additional levels if we wish too. This is something that we'll see in a forthcoming article; where we'll take a look at some more advanced functionality to add to our menus.

In order to facilitate its comprehension, I've added some more comments to the code provided for these two functions. Howeer, there are some points that need to be discusssed in much greater details. The first one is the method used to calculate the width in pixels of each option. For this I use the technique seen in the article "Determining string length in pixels [-JavaScript / Ajax / DHTML answers]"; which use an hidden <span> text element into which each piece of text is written and then its exact length in pixels found by retrieving the offsetWidth property of the <span> element.

To use this method, we must first add an element <span> - with an ID equal to "ruler" - to the template and format it exactly the same way as for the submenus' options. For doing this properly, we must not forget to add the styling properties that are beeing inherited and, of course, we are only interested int the properties related to the size of text; excluding other properties like its colors. To be sure that you have the correct formatting, you can also choose to display this <span> element instead of keeping it hidden during the development process. This way, you will quickly notice it if you have made any mistake in its formating.

If this <span> element with an ID of "ruler" is not present in the template or is not found - for example because it has been written later in the HTML code, after the menu section, the function ComputeWidth will create one, format it with a basic style and install it at the beginning of the HTML code (or DOM) of the page. Therefore, it's not strictly necessary for you to create this <span> element but in this case, you should change the basic style used in the function ComputeWidth so that the basic style will fit your needs:

function CompuetWidth (menuitems)
{
      ...
    s.style.visibility = 'hidden';
    s.style.fontFamily = "'Times New Roman', Georgia, Times, Serif";
    s.style.fontSize = "14px";
    s.style.fontWeight = "bold";
    s.style.position = "absolute";
    s.style.top = 0;
    s.style.left = 0;

    /* s.style.letterSpacing = "1px"; */
      ...

(In the code provided at the beginning of this article, two different ways for setting this style are shown and obviously, you can choose which one is better suiting your case.)

To be sure that this element will not change in anything the display of the page, its position is declared as of type "absolute" in the style. This way, its size will have no effect on the display of the HTML elements that follow. Note that even by using a position of type "absolute", this doesn't mean that you can insert this element anywhere in the HTML page. When this code for inserting the element of the menu is executing, there are many <div> elements that have been opened but not closed (these elements will be closed only after the last items of the menu have been written). Inserting a new element at the end of the list at this step means inserting it inside an open <div> element while is it beeing analysed/treated by the browser; something that many won't like. In the case of IE, most likely you<ll get an javascript error or worse, the page won't display at all as the following figure is showing:

The method used in the provided code insert the element by calling "document.body.insertBefore (s, document.body.firstChild)" and is totally safe because this new element will then be inserted at the very beginning of the DOM's hierarchy, therefore making it impossible to be inserted into an open <div> element.

The second point worth to be mentionned here is the margin required around the menu titles. The method used for calculating the exact length in pixels of each title will ignore the calculation of margin requirements; so this is something that we'll have to add. The code in the function ComputeWidth2 () takes this into account by adding a fixed value of 28 pixels, which matches the style of my menus (with margin of 14 pixels per side) but you can obviously adapt this value to your needs:

function ComputeWidth2 (menuitems)
{
      ...
    var swidth = 'width:' + (maxLen + 28) + 'px;';
      ...

Notice that if you add a proper padding to the style (of formating) of the <span> element; you won't have to correct the value for the margin because the value of this padding will be included into the length in pixel of the text element. However, if you add a margin to the style instead of a padding; its value won't be taken into account for the length in pixel.

You can see the end result of this adjustment function menus on the demo site "Test3 - Sub-SubMenu with Artisteer" :

You can see on this figure that the widths for the sub-menus of level 1, 2 and 3 have all been correctly calculated and if you take a look with either Firefox or IE6, the result is totally correct. However, on IE7 and IE8, there is a big space that appears between the second and third sub-levels (the latter being indicated by the arrow) as it's indicated by the circle in the previous figure.

The display problem with IE7 and IE8 comes from a minor problem in the stylesheet as it is generated by Artisteer and which defines for the left margin of the links <a> elements of the submenus a default value of "auto":

.art-menu ul ul a
{
margin-left: auto;
}

This has the effect of centering more or less the last submenu in its area, as you can see by comparing his position with the position of the previous sub-menu in the figure below, where I have superimposed the two:

The solution is simple: setting the left margin to zero (0) instead of "auto":

.art-menu ul ul a
{
margin-left: 0px;
}

Personally, I have no idea why the value of this margin is to "auto" by default instead of being set to 0. This value of "auto" for the margins is usually used for centering an element on the page but in the case of a sub-menu, I see no reason why this value should be variable and left to the discretion of the browser. Having a margin to be variable is probably one the last thing that you want to see in a sub-menu; especially when there are multiple levels involved.

The final result for our menu is shown on the demo site "Test 3.B - Sub-SubMenu with Artisteer":

You can see on this demo that all the sub-menus are now displaying correctly (red arrow), with a correct width and without any unwanted space between them. This is not only for Firefox and IE6 but for IE7 and IE8 as well. The screenshot above was made with IE7.

This concludes the Part 3 of the article on the sub-menus for Blogger with Artisteer. In Part 4 and 5, we will first see some more advanced techniques to enable us to create (and debug) our menus faster and then in some later parts, we'll take a look on how to add some new exciting features to our menus on Blogger. We will also take a look on how to use these menus with Artisteer templates other than Blogger.

Sub-SubMenu for Blogger with Artisteer, part 2

2009-12-10T16:04:00.001-05:00

The revised artDisplayTopMenu() function that we have seen in the first part of this article (see "Sub-SubMenu for Blogger with Artisteer, part 1") is interesting but it still has its flaws: firstly, it is not recursive, so it cannot give us an unlimited number of levels: if you need access to a fourth level, you'll have to modify it. Also, it doesn't include any control error; for example if you make a mistake about the order of tags "-", "-+" and "-+=". However, these are moot points in comparaison to its main problem: the difficulty that we'll have to manage the long series of options for the menu by using the standard configuration dialog of Blogger. In effect, if you need a second or a third level, for your menus, it's because you have tens or even hundreds of options to put there. For example, although the demonstration site Sub-SubMenu for Blogger with Artisteer contains only a tiny fraction of a menu that I'm building for another blog, manage it already requires a very long long series of clicks for inserting a new option or moving them around:

The final menu will be tens of times longer than that, with around one hundred options for the french version and the same for the engligh version; making its management prohibitively time consuming. In this part 2 of this article about sub-menus, Blogger and Artisteer, we will see how to solve this problem.

If we take a look at the widget's source code that will inserts the HTML items (<ul>, <li> tags, etc.) for the menu, we see that this is mainly a XML loop (the <b:loop ... in the figure below) that is running on the server; ie., before the HTML is sent back the client's browser. (Note: don't forget that you must first check the "Expand Widget Templates" option if you want to see this piece of code.)

This loop will builds a list of items with the Javascript code necessary to store them one by one in the dynamic array menuitems; you can see part of the final result below. This list of menuitems.push(...) is part of the javascript code inside the HTML page that is sent to the browser client. Once there, this code will be executed by the client's browser's javascript interpreter. As this part will run locally on your machine (unlike the XML loop which is executed on the server), you can see it by looking directly at the source code of the page in your browser (use the "View Source" or its equivalent on the menu of your browser):

...

                  menuitems.push(new Array('Site web (français)','http://www.sylvainlafontaine.com/'));
                
                  menuitems.push(new Array('-Blogues','http://paparazzi-codeur.sylvainlafontaine.com/'));
                
                  menuitems.push(new Array('-+Access, ADP et SQL-Server','http://access-adp-sqlserver-francais.sylvainlafontaine.com/'));
                
                  menuitems.push(new Array('-+Le Paparazzi~Codeur','http://paparazzi-codeur.sylvainlafontaine.com/'));
                
                  menuitems.push(new Array('-La Transformée de Fourier','http://transformee-fourier.sylvainlafontaine.com/'));
                
                  menuitems.push(new Array('-+Chapitre 1 - Les Séries de Fourier','http://transformee-fourier.sylvainlafontaine.com/2009/11/chapitre-1-les-series-de-fourier.html'));
                
                  menuitems.push(new Array('-+=A- Principe des Séries de Fourier','http://transformee-fourier.sylvainlafontaine.com/2009/11/chapitre-1-les-series-de-fourier.html#A- Principe des Séries de Fourier'));
                
                  menuitems.push(new Array('-+=B- Les Séries de Fourier','http://transformee-fourier.sylvainlafontaine.com/2009/11/chapitre-1-les-series-de-fourier_29.html#B- Les Séries de Fourier'));
                
                  menuitems.push(new Array('-+Chapitre 2 - La diffraction aux rayons-X','http://transformee-fourier.sylvainlafontaine.com/2009/11/chapitre-2-la-diffraction-aux-rayons-x.html'));
                
                  menuitems.push(new Array('-+=A- Loi de Laue','http://transformee-fourier.sylvainlafontaine.com/2009/11/chapitre-2-la-diffraction-aux-rayons-x.html#Loi de Laue'));
                
                  menuitems.push(new Array('-+=B- Les réseaux cristallins','http://transformee-fourier.sylvainlafontaine.com/2009/11/chapitre-2-la-diffraction-aux-rayons-x_29.html#B- Les réseaux cristallins'));
                
                  menuitems.push(new Array('Web site (english)','http://english.sylvainlafontaine.com/'));
                
                  menuitems.push(new Array('-Blogs','http://coding-paparazzi.sylvainlafontaine.com/'));
                
                  menuitems.push(new Array('-+Access, ADP and SQL-Server','http://access-adp-sqlserver.sylvainlafontaine.com/'));
                
                  menuitems.push(new Array('-+The Coding Paparazzi','http://coding-paparazzi.sylvainlafontaine.com/'));
                
                  menuitems.push(new Array('-The Fourier Transform','http://fourier-transform.sylvainlafontaine.com/'));
                
                  menuitems.push(new Array('-+Chapter 1 - The Fourier Series','http://fourier-transform.sylvainlafontaine.com/2009/11/chapter-1-fourier-series.html'));
                
                  menuitems.push(new Array('-+=A- The Principle of Fourier Series','http://fourier-transform.sylvainlafontaine.com/2009/11/chapter-1-fourier-series.html#A- The Principle of Fourier Series'));
                
                  menuitems.push(new Array('-+=B- The Fourier Series','http://fourier-transform.sylvainlafontaine.com/2009/11/chapter-1-fourier-series-section-b.html#B- The Fourier Series'));
                
                  menuitems.push(new Array('-+Chapter 2 - The X-Ray Diffraction','http://fourier-transform.sylvainlafontaine.com/2009/11/chapter-2-x-ray-diffraction.html'));
                
                  menuitems.push(new Array('-+=A- Laue\'s law','http://fourier-transform.sylvainlafontaine.com/2009/11/chapter-2-x-ray-diffraction.html#Laue'));
                
                  menuitems.push(new Array('-+=B- Crystalline networks','http://fourier-transform.sylvainlafontaine.com/2009/11/chapter-2-x-ray-diffraction-section-b.html#Crystalline networks'));
                
                artDisplayTopMenu(menuitems);
            </script></span>
</ul>
</div></div>
...

The array menuitems and the first item of the menu's list (usually "Home" but "Accueil" in the example below) have already been created by the template Artisteer in a piece of javascript code just before that:

Once the array menuitems has been completed, the artDisplayTopMenu() function is called, with the array passed in as parameter:

To get rid of the need to use the "Configure Link List" window of Blogger, what we have to do would be simply to replace the function artDisplayTopMenu() with a new one that will have the necessary static code to build this list. After that, a call to the original function artDisplayTopMenu() - renamed for the occasion artDisplayTopMenu2 - will build the HTML menu but now by using our own version of the menuitems array:

// New version for artDisplayTopMenu(); allowing for
// second and third sub-menu levels.
// First level: option name must begin with a '-'
// Second level: begin with a '-+'
// Third level: begin with a '-+='

// Not HTML escaped so // <![CDATA[ ... // ]]> must be used:
// <![CDATA[

function artDisplayTopMenu(menuitems_dummy)
{
  var menuitems = new Array();

  menuitems.push(new Array('Accueil • ','http://test-sub-submenu-artisteer-blogger.blogspot.com/'));

  menuitems.push(new Array('Site web (français)','http://www.sylvainlafontaine.com/'));
                
  menuitems.push(new Array('-Blogues','http://paparazzi-codeur.sylvainlafontaine.com/'));
                
  menuitems.push(new Array('-+Access, ADP et SQL-Server','http://access-adp-sqlserver-francais.sylvainlafontaine.com/'));
                
  menuitems.push(new Array('-+Le Paparazzi~Codeur','http://paparazzi-codeur.sylvainlafontaine.com/'));
                
  menuitems.push(new Array('-La Transformée de Fourier','http://transformee-fourier.sylvainlafontaine.com/'));
                
  menuitems.push(new Array('-+Chapitre 1 - Les Séries de Fourier','http://draft.blogger.com/http//transformee-fourier.sylvainlafontaine.com/2009/11/chapitre-1-les-series-de-fourier.html'));
                
  menuitems.push(new Array('-+=A- Principe des Séries de Fourier','http://transformee-fourier.sylvainlafontaine.com/2009/11/chapitre-1-les-series-de-fourier.html#A- Principe des Séries de Fourier'));
                
  menuitems.push(new Array('-+=B- Les Séries de Fourier','http://transformee-fourier.sylvainlafontaine.com/2009/11/chapitre-1-les-series-de-fourier_29.html#B- Les Séries de Fourier'));
                
  menuitems.push(new Array('-+Chapitre 2 - La diffraction aux rayons-X','http://transformee-fourier.sylvainlafontaine.com/2009/11/chapitre-2-la-diffraction-aux-rayons-x.html'));
                
  menuitems.push(new Array('-+=A- Loi de Laue','http://transformee-fourier.sylvainlafontaine.com/2009/11/chapitre-2-la-diffraction-aux-rayons-x.html#Loi de Laue'));
                
  menuitems.push(new Array('-+=B- Les réseaux cristallins','http://transformee-fourier.sylvainlafontaine.com/2009/11/chapitre-2-la-diffraction-aux-rayons-x_29.html#B- Les réseaux cristallins'));

  menuitems.push(new Array('Web site (english)','http://english.sylvainlafontaine.com/'));
                
  menuitems.push(new Array('-Blogs','http://coding-paparazzi.sylvainlafontaine.com/'));
                
  menuitems.push(new Array('-+Access, ADP and SQL-Server','http://access-adp-sqlserver.sylvainlafontaine.com/'));
                
  menuitems.push(new Array('-+The Coding Paparazzi','http://coding-paparazzi.sylvainlafontaine.com/'));
                
  menuitems.push(new Array('-The Fourier Transform','http://fourier-transform.sylvainlafontaine.com/'));
                
  menuitems.push(new Array('-+Chapter 1 - The Fourier Series','http://fourier-transform.sylvainlafontaine.com/2009/11/chapter-1-fourier-series.html'));
                
  menuitems.push(new Array('-+=A- The Principle of Fourier Series','http://fourier-transform.sylvainlafontaine.com/2009/11/chapter-1-fourier-series.html#A- The Principle of Fourier Series'));
                
  menuitems.push(new Array('-+=B- The Fourier Series','http://fourier-transform.sylvainlafontaine.com/2009/11/chapter-1-fourier-series-section-b.html#B- The Fourier Series'));
                
  menuitems.push(new Array('-+Chapter 2 - The X-Ray Diffraction','http://fourier-transform.sylvainlafontaine.com/2009/11/chapter-2-x-ray-diffraction.html'));
                
  menuitems.push(new Array('-+=A- Laue\'s law','http://fourier-transform.sylvainlafontaine.com/2009/11/chapter-2-x-ray-diffraction.html#Laue'));
                
  menuitems.push(new Array('-+=B- Crystalline networks','http://fourier-transform.sylvainlafontaine.com/2009/11/chapter-2-x-ray-diffraction-section-b.html#Crystalline networks'));
                
  artDisplayTopMenu2 (menuitems);
}

function artDisplayTopMenu2(menuitems) {

    var i = 0;
    var subList = false;
    var subList2 = false;
    var subList3 = false;

    for (i=0; i < menuitems.length; i++) {
      var item = menuitems[i];
      var itemname = item[0];
      var itemlink = item[1];
      
      if ( ((itemname.indexOf("=") == 2) && !subList3)
        || ((itemname.indexOf("+") == 1) && !subList2)
        || ( (itemname.indexOf("-") == 0) && !subList) ) {
          document.write('<ul>');

      } else if ( ((itemname.indexOf("=") != 2) && subList3)
	|| ((itemname.indexOf("+") != 1) && subList2)
                || ((itemname.indexOf("-") != 0) && subList) ) {

        if ( (itemname.indexOf("=") != 2) && subList3) {
          document.write("</li></ul>");
          subList3 = false;
        }

        if ( (itemname.indexOf("+") != 1) && subList2) {
          document.write("</li></ul>");
          subList2 = false;
        }

        if ( (itemname.indexOf("-") != 0) && subList) {
          document.write("</li></ul>");
          subList = false;
        }

        document.write("</li>");

      } else if (i != 0) {
        document.write("</li>");
      }
      
      document.write("<li>");

      if (itemname.indexOf("-") != 0) {
        if (window.location == itemlink) {
          document.write('<a href="'+itemlink+'" class="active"><span class="l"></span><span class="r"></span><span class="t">'+itemname+'</span></a>');

        } else if(itemlink == "http://./") {
          document.write('<a href="#"><span class="l"></span><span class="r"></span><span class="t">'+itemname+'</span></a>');

        } else {
          document.write('<a href="'+itemlink+'"><span class="l"></span><span class="r"></span><span class="t">'+itemname+'</span></a>');
        }

      } else {

        if (itemname.indexOf("=") == 2) {
          document.write('<a href="'+itemlink+'">'+itemname.substr(3,itemname.length)+'</a>'); 
          subList = true;
          subList2 = true;
          subList3 = true;

        } else if (itemname.indexOf("+") == 1) {
          document.write('<a href="'+itemlink+'">'+itemname.substr(2,itemname.length)+'</a>');
          subList = true;
          subList2 = true;

        } else {
          document.write('<a href="'+itemlink+'">'+itemname.substr(1,itemname.length)+'</a>');
          subList = true;
        }
      }

      if (i == (menuitems.length-1)) {
        if (subList3)
          document.write("</li></ul>");
           
        if (subList2)
          document.write("</li></ul>");

        if (subList)
          document.write("</li></ul>");

        document.write("</li>");
      }
    }
}
// ]]>

As we are now replacing the whole menuitems array, we must not forget to also include the option "Home" at its beginning; unless you don't want it there, of course!

However, if you try this code directly, it won't work at first as we have one last final adjustement to make: Blogger will not take the time to call the artDisplayTopMenu() (the original or our own version) if it doesn't see any created item in the Top Menu; so we have to create a dummy one to act as a trigger. As this is a dummy argument that will never make it to the client's browser, you can write anything for it:

You can see the an example of the result of this code on the demonstration site "Test2 - Sub-SubMenu with Artisteer".

When you have long menus or multiple blogs, it's much faster to manage them using this then by using the standard interface of Blogger (the "Configure Link List" dialog window).

However, there is one small problem remaining: this code will be erased if you refresh your Blogger template using Artisteer; so it is advisable to always make a backup copy of your code somewhere. Artisteer will also make a backup copy of your older template in the directory "C:\Documents and Settings\***YourUserName***\Application Data\Artisteer\Artisteer2\Library\BloggerBackup/" (for Windows XP); so you can always find a copy of your code there. Notice that this an ordinary problem that you'll always have once you start customizing your templates.

This concludes Part 2 of the article on the sub-sousMenu of Artisteer for Blogger. In Part 4 we will see a new way to write our list of options for the menu without even having to go through the form "Edit HTML" each time but first, we'll see in part 3 how to adjust the width of the boxes created for the menu by Artisteer so that they will automatically adapt their size to their content instead of having all the same width.

Quick and simple encoding of javascript ads (AdSense and others) for Blogger

2009-12-09T17:17:00.001-05:00

A question that often comes back on sites about Blogger is how to encode (or "parse") the four special characters " <> & that will often be found in the JavaScript code for Ads like Google Adsense, AdBrite, Amazon, etc... in order to make them acceptable for the Blogger's XML storage tool. This article shows a new way easier and faster than the usual recommended way to accommodate these special characters for their storage in an XML document such as the one used with Blogger's XML templating tool.

When you insert an announcement (Ad) in javascript in your Blogger template but that you leave aside the question of encoding the four characters "<> & you can find yourself, in some cases, with an error message identical or similar to the following example:

We were unable to save your template

Please correct the error below, and submit your template again.

Your template could not be parsed as it is not well-formed. Please make sure all XML elements are closed properly.

XML error message: XML document structures must start and end within the same entity.

This will not always happen and will depend on where in the Blogger template you are trying to put the Ad and, of course, on the level and type of customization that you have already done with it. You can find other examples of those error messages as well as additional information on this topic on "Parse HTML for Adsense Code and Blogger Posting", "Trick to Add AdSense, AdBrite and Other JavaScript Ad Code Directly to Blogger HTML Template" and "Trick to Add AdSense, AdBrite and Other JavaScript Ad Code Directly to Blogger HTML Template".

These error occur because a Blogger templates is stored in the format of a XML document and therefore, the four special characters "<> & must usually be encoded (if they are present) as their HTML entities: " , < , > and &. This must be done weither or not they are used inside a piece of javascript code or in another location in the XML document; with one exception as explained below; this particular exception beeing used as the basis for the technique shown in this article. On some occasion, Blogger will do the conversion automatically for you - so you don't have to do it yourself - but this won't always happen and will depend on where you are trying to insert your javascript Ads.

In those cases where Blogger won't do the conversion for you, you must then do it either manually or by using a site such "Escape HTML - Blogrowds Resources" that will translate those specials characters present in your javascript Ads into their HTML entities.

Encoding these special characters individually works quite well but unfortunately, you can make mistakes if you do this operation manually or you must continually go on encoding site every time you want to make a modification to your Ads; something that will quickly become tedious if you want to change your ads regularly or to test different configurations.

However, another, simpler solution exists than individually encoding these characters: this would be to use the global escaping sequence of XML <! [CDATA [... ]]> around the javascript code. If you install this sequence the JavaScript code, between the <script>...</scripts> tags, it must itself be hidden from the view of the JavaScript parser by using one of the two javascript comments: // or /*...*/ :

But these ads are often composed of more than one single segments <script> ...</ script>. Furthermore, the attribute for designing the language inside these tags can itself use the double quote " instead of the single quote; for example with « language="javascript" » or « type="text/javascript" » instead of « language='javascript' ». Having to change them every time will be as tedious and error-prone than the other two previous methods.

Moreover, some of these affiliate programs prohibit to make any changes other than minor to the javascript code provided for their ads (reference: Tips and Tutorials to Make Money Online: Blogger How to ). Although I personally consider the previous amendments as minor and thereby, remaining within the limits of the terms of use for these ads, some people may not agree or simply have some fear to put their AdSense account or any other account with a restricted set of rules at jeopardy.

So the best solution would be to put the whole block - including the <script> tags themselves - inside the global escape sequence. In this way, no change at all whatsoever will be made to the provided javascript code for the ads. In fact, by doing this way, it will be even better than the usual way of encoding the individual characters "<> & because absolutely no change will be made to the code at all; not even a simple encoding of some of the characters.

To this end, a first attempt at a solution would be to simply try to write the sequence <! [CDATA [... ]]> directly around the block; as shown in the following example:

<![CDATA[

<script type="text/javascript"></script><script src=http://www.assoc-amazon.com/s/ads.js type="text/javascript"></script>

]]>

Unfortunately, the <[CDATA [... ]]> sequence will be seen by the browser and because of that, will be displayed on the screen; something that we don't want to see. A second attempt could be to try to enclose these codes inside HTML comments:

<script type="text/javascript"></script><script src="http://www.assoc-amazon.com/s/ads.js" type="text/javascript"></script>

But unfortunately (again!), the XML comments are identical to the HTML comments; so that in the previous example, the sequence <![CDATA[ ... ]]> will be interpreted as a XML comment by the Blogger XML template engine and will not be effective.

Finally, the real solution is simply to use javascript comments instead of HTML comments (or not comment at all) to hide to the browser the <![CDATA[ ... ]]> sequence:

In this example, both lines:

and:

will be seen by the browser as two separate javascript(s); each containing only a single comment so they will not affect the final result displayed. Moreover, as these are two separate scripts, you can put anything between these two; including other javascript tags! Furthemore, those those tags can now contain anything, including the use of the double quote around the languge attribute. Thre is now absolutely no limit to what you can put inside this global escaping sequence and this is not limited to javascript code. For example, you could use to include an IMPORT statement inside the Blogger template; something that I will put to use in another article about using MathML with Blogger.

To facilitate reading the previous examples, I've put white spaces around the tags but of course, you can remove them if necessary.

Write these two lines at the beginning and the end of your ad's block might seems a little more complicated at first but remember that you don't have to edit or retouch them in any way whatsoever after that. All you have to do aftward is a simple Copy&Paste of the provied javascript code for the ad; without any modification or parsing to do and this, no matter what special characters these piece of codes could contain.

You can even, if you wish, put them in your favorite macros program to be pasted anywhere. Ultimately, the maintenance of your ad units will be much easier and faster since you will not have to make any change anymore. All that will remain to do will be to remove a site such as "Escape HTML - Blogrowds Resources" from your list of favorite bookmarks!

You can see the final result on the demonstration site "Quick escape of javascript Ads on Blogger" where I've put four Amazon ads at different locations in the Blogger template - I did not formatted so you can well see that I put them anywhere anyhow:

Note: In this article, I used an ad from Amazon as an example instead of AdSense simply because changing the AdSense code in order to displayed it instead of running it - so that you can see the javascript code - goes against the Terms of Services (TOS) of AdSense; which are very strict. There is also the question of the limit of three AdSense ads by article that could have been a problem here.

But nevertheless, this technique will works as well with AdSense ads and its use does not go against the AdSense's TOS because you bring no change at all to the code itself or the way it is displayed on the browser. This technique will also works with all other types of javascript ads because it leaves completely unchanged the code and in all cases, the code returned to the browser will remains completely identical to the original code provided with the ad.

Sub-SubMenu for Blogger with Artisteer, part 1

2009-12-07T21:49:00.001-05:00

Currently, we can get only one level of submenu with the standard templates for Blogger created with Artisteer, version 2.3; Hopefully, the possibility of having second and third levels (sub-subMenu and sub-sub-subMenu) will be made in a future release of Artisteer but now, we are reduced to the obligation of doing the required modifications to the template ourselves if we want those. This is the object of this article and it can be made pretty well as you can see from the following figure illustrating an example of sub-menus expanding on three levels:

This article is divided into three parts. The first part shows how to modify the JavaScript code in the template for getting second and third levels of sub-menus. The second part deals with more advanced changes to the code for making our job easier when we have to create very long menus, having tens or even hundred of sub-options; something that is not easy to manage with the standard interface of Blogger for editing the menu. Finally, the third party shows how to style the submenus so that their width is related to their content in in order to have a more pleasing look to the eye.

Note that even if you're not interested in the menu interface for Blogger created by Artisteer; some of the techniques discussed in this three parts article could still be interesting for you to read.

Before we can make the changes seen in this article, we must first be able to know how to make modifications to the template once it has been installed (or published) on Blogger. To do this, you must use the "Edit HTML" tab of the "Layout" option that you'll find in the settings of your blog from your Blogger's Dashboard. Most of this has already been discussed many times on the various blogs about customizing Blogger so I won't repeat the process here but if you need to have some references, you can start with "Can I edit the HTML of my blog's layout? - Blogger Help" and "Layout Guide - Blogger Help".

When someone wants to change the Blogger template code to include several levels of submenus, the first thing to think would probably be to simply edit the template code in order to include the various submenus in ordinary (without any javascript) HTML code; like we must already do for the standard HTML templates produced by Artisteer. For a quick reference on this standard procedure, see Artisteer Add-ons - Cheat Sheet: Part 3 - Navigation. Unfortunately, it's not easy to do the same thing on Blogger because the required code to edit is included in a not easily editable widget; as you can see from the following extract (notice that in order to see this piece of code on your own template, you must check the option "Expand Widget Templates"; as it's also shown below in the upper right par of the figure) :

Also, writing and editing the long list of the required <ul> and <li> tags necessary to express the CSS menu of Artisteer is not an easy task and is very prone to errors; especially when the number of options reach many tens. In my opinion, the method that we'll see in this article is a better solution but of course, you must not forget about the possibility of simply adding your own custom HTML code; especially if you have it already ready at your hand.

From the code illustrated in the previous figure, we can see that once the list of options for the menu has been inserted into the dynamic array "menuitems", the function artDisplayTopMenu() is called. This is the function that will generates the HTML code required for displying the menu using the information provided in the passed array "menuitems" and evidently, is also the one that we must modify in order to allow for the display of second and third level of sub-menus. You can find this function by searching for "artDisplayTopMenu" or simply for "artD" (use [Ctrl]+F to access the Find box) but for your convenience, I reproduce the original source code here :

function artDisplayTopMenu(menuitems){
    var i=0;
    var subList = false;
    var menu = new Array();
    for(i=0; i &lt; menuitems.length; i++){
      var item = menuitems[i];
      var itemname = item[0];
      var itemlink = item[1];
      
      if ( (itemname.indexOf(&quot;-&quot;) == 0) &amp;&amp; !subList) document.write(&quot;&lt;ul&gt;&quot;);
      else if ( (itemname.indexOf(&quot;-&quot;) != 0) &amp;&amp; subList) { document.write(&quot;&lt;/ul&gt;&lt;/li&gt;&quot;); subList = false; }
      else if (i != 0) document.write(&quot;&lt;/li&gt;&quot;);
      
      document.write(&quot;&lt;li&gt;&quot;);
      
      if (itemname.indexOf(&quot;-&quot;) != 0){
        if (window.location == itemlink) 
            document.write(&#39;&lt;a href=&quot;&#39;+itemlink+&#39;&quot; class=&quot;active&quot;&gt;&lt;span class=&quot;l&quot;&gt;&lt;/span&gt;&lt;span class=&quot;r&quot;&gt;&lt;/span&gt;&lt;span class=&quot;t&quot;&gt;&#39;+itemname+&#39;&lt;/span&gt;&lt;/a&gt;&#39;);
        else if(itemlink == &quot;http://./&quot;)
            document.write(&#39;&lt;a href=&quot;#&quot;&gt;&lt;span class=&quot;l&quot;&gt;&lt;/span&gt;&lt;span class=&quot;r&quot;&gt;&lt;/span&gt;&lt;span class=&quot;t&quot;&gt;&#39;+itemname+&#39;&lt;/span&gt;&lt;/a&gt;&#39;);
        else
            document.write(&#39;&lt;a href=&quot;&#39;+itemlink+&#39;&quot;&gt;&lt;span class=&quot;l&quot;&gt;&lt;/span&gt;&lt;span class=&quot;r&quot;&gt;&lt;/span&gt;&lt;span class=&quot;t&quot;&gt;&#39;+itemname+&#39;&lt;/span&gt;&lt;/a&gt;&#39;);
      } else {
        document.write(&#39;&lt;a href=&quot;&#39;+itemlink+&#39;&quot;&gt;&#39;+itemname.substr(1,itemname.length)+&#39;&lt;/a&gt;&#39;);
        subList = true;
      }
      if (i==(menuitems.length-1)) document.write(&quot;&lt;/li&gt;&quot;);
    }
}

The first thing we notice is that all the four characters "<> & have been escaped (translated) into their equivalent HTML entities; which makes reading or changing the JavaScript code more difficult. A Blogger template is stored as a XML document; which means that these four characters must be obligatory be escaped. However, instead of escaping them individually, we could also chose to use the global XML escape sequence <![CDATA[ ... ]]>. As this special sequence must be used in a piece of JavaScript code, it must itself be escaped from the view of the JavaScript parser by using either // or /* ... */; which at the final gives us:

// <![CDATA[

... javascript code containing the following caracters: " < > &

// ]]>

By using this special sequence, we can rewrite the code of the function in a much cleaner and lisible way:

// <![CDATA[

function artDisplayTopMenu(menuitems){
    var i=0;
    var subList = false;
    var menu = new Array();
    for(i=0; i < menuitems.length; i++){
      var item = menuitems[i];
      var itemname = item[0];
      var itemlink = item[1];
      
      if ( (itemname.indexOf("-") == 0) && !subList) document.write("<ul>");
      else if ( (itemname.indexOf("-") != 0) && subList) { document.write("</ul></li>"); subList = false; }
      else if (i != 0) document.write("</li>");
      
      document.write("<li>");
      
      if (itemname.indexOf("-") != 0){
        if (window.location == itemlink) 
            document.write('<a href="'+itemlink+'" class="active"><span class="l"></span><span class="r"></span><span class="t">'+itemname+'</span></a>');
        else if(itemlink == "http://./")
            document.write('<a href="#"><span class="l"></span><span class="r"></span><span class="t">'+itemname+'</span></a>');
        else
            document.write('<a href="'+itemlink+'"><span class="l"></span><span class="r"></span><span class="t">'+itemname+'</span></a>');
      } else {
        document.write('<a href="'+itemlink+'">'+itemname.substr(1,itemname.length)+'</a>');
        subList = true;
      }
      if (i==(menuitems.length-1)) document.write("</li>");
    }
}
// ]]>

Note that the escaping sequence <![CDATA [ ... ]]> can be used for other purposes, such as for fast encoding of javascript ads (AdSense, AdBrite, Amazon, etc.., see the article "Simple and fast encoding of javascript ads (AdSense and others) for Blogger") or for inserting the XML statement <? IMPORT>, as discussed in another article on the use of MathML with Blogger.

To create a sub-menu in Blogger using this function, we must place an hyphen ("-" or dash) at the beginning of the name of each sub-item of the menu's "Link List" configu/ation window:

The new version that I made uses something similar: the second level requires a "-+" at the beginning of each option's name and the third level a "-+="; as you can see in the below figure. I've chosen these labels because they were making the code and the hierarchy of the menu easier to read and understand but of course, you could use anything else; provided that you adapt the code of the function.

And now, without any further delay, here's the revised version of the function artDisplayTopMenu() :

// New version for artDisplayTopMenu(); allowing for
// second and third sub-menu levels.
// First level: option name must begin with a '-'
// Second level: begin with a '-+'
// Third level: begin with a '-+='

// Not HTML escaped so // <![CDATA[ ... // ]]> must be used:
// <![CDATA[

function artDisplayTopMenu(menuitems) {

    var i = 0;
    var subList = false;
    var subList2 = false;
    var subList3 = false;

    for (i=0; i < menuitems.length; i++) {
      var item = menuitems[i];
      var itemname = item[0];
      var itemlink = item[1];
      
      if ( ((itemname.indexOf("=") == 2) && !subList3)
        || ((itemname.indexOf("+") == 1) && !subList2)
        || ( (itemname.indexOf("-") == 0) && !subList) ) {
          document.write('<ul>');

      } else if ( ((itemname.indexOf("=") != 2) && subList3)
	|| ((itemname.indexOf("+") != 1) && subList2)
                || ((itemname.indexOf("-") != 0) && subList) ) {

        if ( (itemname.indexOf("=") != 2) && subList3) {
          document.write("</li></ul>");
          subList3 = false;
        }

        if ( (itemname.indexOf("+") != 1) && subList2) {
          document.write("</li></ul>");
          subList2 = false;
        }

        if ( (itemname.indexOf("-") != 0) && subList) {
          document.write("</li></ul>");
          subList = false;
        }

        document.write("</li>");

      } else if (i != 0) {
        document.write("</li>");
      }
      
      document.write("<li>");

      if (itemname.indexOf("-") != 0) {
        if (window.location == itemlink) {
          document.write('<a href="'+itemlink+'" class="active"><span class="l"></span><span class="r"></span><span class="t">'+itemname+'</span></a>');

        } else if(itemlink == "http://./") {
          document.write('<a href="#"><span class="l"></span><span class="r"></span><span class="t">'+itemname+'</span></a>');

        } else {
          document.write('<a href="'+itemlink+'"><span class="l"></span><span class="r"></span><span class="t">'+itemname+'</span></a>');
        }

      } else {

        if (itemname.indexOf("=") == 2) {
          document.write('<a href="'+itemlink+'">'+itemname.substr(3,itemname.length)+'</a>'); 
          subList = true;
          subList2 = true;
          subList3 = true;

        } else if (itemname.indexOf("+") == 1) {
          document.write('<a href="'+itemlink+'">'+itemname.substr(2,itemname.length)+'</a>');
          subList = true;
          subList2 = true;

        } else {
          document.write('<a href="'+itemlink+'">'+itemname.substr(1,itemname.length)+'</a>');
          subList = true;
        }
      }

      if (i == (menuitems.length-1)) {
        if (subList3)
          document.write("</li></ul>");
           
        if (subList2)
          document.write("</li></ul>");

        if (subList)
          document.write("</li></ul>");

        document.write("</li>");
      }
    }
}
// ]]>

You can see and test the final result by going at the following blog that I've setup for testing purpose: Sub-SubMenu for Blogger with Artisteer.

This concludes Part 1 of this article. In parts 2 and 3, we will elaborate on this feature by first replacing the need to use the dialog window "Link List" in order to manage the menu's options menu (replacing this dialog window is very useful because it's far from beeing to be the best in the world to use when you have dozens of options to adjust) and second, we will see in the last part how to adjust the widths of the boxes in order to adapt them to their content.

A final word of caution: this is custom modification to the template, so if you republish your template from Artisteer, you'll have to remake this modification to your template again.

Windows Live Writer, Blogger and Picasa albums

2009-11-22T22:11:00.001-05:00

When you use Windows Live Writer (WLW) with Blogger, WLW will default all the pictures you download to a single Picasa album. We will see in this article how to configure WLW so that the images for each article will be published into separate albums.

INTRODUCTION

At this moment, I have only first article published (Coding Paparazzi - Title menu on two lines for Joomla & Artisteer) and I'm already buried beneath the images. There are of course all these screenshots I took here and there for what to be my first article as well as for the followings but there is also a place where the images have spread like hot cakes and this place is called Picasa. Although that this first article that I wrote - this one being the second - does not contain more than fifteen images, I find myself with more than one hundred images in the Picasa album created by WLW:

And as you can see, many of these images are duplicates and all this, with only one single article! I can hardly imagine what it would when I will a few dozen articles - if ever I go that far, of course! I don't know about you but I guess that if you reading this article, it's probably because you are yourself in exactly the same situation. Even if we can erase those images that have become redundant and move others into new albums without risk of breaking the HTML links of the blog (the links created by WLW don't use the album names, only their ID), this is obviously a task work we would could spare ourself of, without counting the risk of accidentally erasing images that are still useful.

Moreover, the maximum number of images per album in Picasa seems to be 500. As the links posted by WLW use the ID and not the Picasa album, simply renaming the album "Windos Live Writer" under another name - like "Windows Live Writer 01" for example - will be sufficient to restart a new sequence of 500 but obviously this is not is an ideal solution. (Reference: "Revitize - WLW upload image error", "Blogger.com Issue | Google Groups"). We could of course upload these images separately and then link them manually one by one or we could use something like the Picasa plugin for WLW (Windows Live Gallery - Picasa Image Plugin) but again, this requires additional time and furthermore, will prevent us from the image manipulation tools of WLW; which are precisely one of its strengths.

METHOD

When we publish our pictures to another service than Picasa, FTP for example, WLW has no problem to separate them by article into different repertories; it has therefore the ability to do so already builtin. In searching the Internet for a solution to this problem, I came across the following articles which refer to the registry key "fileUploadNameFormat":

By adding this fileUploadNameFormat key in the registry below the branch HKLM \ Software \ Microsoft \ Windows Live \ Writer \ Weblogs \ {blog-id} \ UserOptionOverrides \ and where {log-id} is the blog's GUID as it has been registered under WLW, it is possible to redefine the default behavior of WLW when it uploads new images to Picasa. If you have multiple blogs, you will obviously have several {log-id} in the registry but by browsing the list, you can easily find the one that you are interested into by observing the properties at the right:

By looking at the BlogName property on the right of the above picture, you can see that the key {11ff...} is associated with the blog named "blogger - Sauvegarde - Sylvain Lafontaine (11)". In the same way, the HomePageUrl property give us its home page.

Quick little trick: when you have multiple blogs enregistred with WLW, it is convenient to add at the end of the name of each blog the first letters of its GUID; like you can see below. This way, you can find their associated registry quickly. This is useful not only for redefining the default name of the Picasa albums but also for other things such as fixing the theme preview in WLW; which will be the subject of a forthcoming article.

To return to the new registry key to add, it must be of type String, with the exact name fileUploadNameFormat (note the distinction between uppercase and lowercase as it is important!) and it must be created under the key UserOptionOverrides of the corresponding blog; as it is illustrated below. In these screenshots, the key fileUploadNameFormat has already been created so you can see exactly where it should be made but of course, you won't see it on your machine until you have created it.

You can use the following tokens to define the name of the new albums:

{PostTitle}
{PostRandomizer}
{Randomizer}
{FileName}
{AsciiFileName}
{AsciiFileNameWithoutExtension}
{FileExtension}
{WindowsLiveWriter}

This property must be of type String and it must end with a "/" as illustrated above. Excerpt for the tokens, all the rest of the string will be transcribed verbatim to the name of the new album. You can use special characters like blank spaces, underscores, hyphens or even other "/". The two most interesting tokens to use are {PostTitle} and {PostRandomizer}. With the others, you may find yourself with a photo album created for each image. Here is an example of what I use personally:

Brouillons - {PostTitle} {PostRandomizer}/

"Brouillons" here is for designating my private blog "Brouillons" and you can see the final result in Picasa; where a new album with the name "Brouillon - WLWBloggerPicasaetlesAlbums 5C20" (the original title was in french) has been automatically created for this article:

Obviously, the name "Brouillon - WLWBloggerPicasaetlesAlbums 5C20" is not the prettiest and the title has been stripped from its blank spaces and other special characters such as the comma ((the original title was in french and it was "WLW, Blogger, Picasa et les Albums") but nothing prevents you from renaming it to your liking after that. Remember that with the type of link created by WLW to Blogger, the name of the album which is a linked image does not matter and you can rename these albums or move an image from one album to another with no impact on the blog itself and that the main point here is that each article get its own album in Picasa when published by WLW.

Also, when you change the key "fileUploadNameFormat", it is not necessary to restart WLW each time before testing it. By adding a new image, so you can quickly make several tests to see what you like best. For those who prefer not to forage in the registries base, there are two alternatives for creating or changing the registry key "fileUploadNameFormat". The first is to use a custom configuration file WLWManifest.XML to redefine the default properties of a blog to WLW. This technique will be the subject of a separate article as the file wlwmanifest.xml can be used for many other purposes.

The third method is to use the Writer Tweak Helper program by Joe Cheng, available here: WriterTweakHelper.exe. Download and run this program (it does not require to be installed but .NET is required) and you can then add, modify or delete any properties of the branch UserOptionsOverrides for each of your blogs without having to open the registries base:

LAST TIP

Finally, a little trick: When you create a new blog, it is easy to forget to set the registry key for name the Picasa albums. If you already have an album "Windows Live Writer, you will then end up with your new images in this album, something that can be annoying if it contains several hundred of images. So even if you intend not to use this album anymore and to group your pictures by article, it will still be useful to change the name of the album "Windows Live Writer" to something else like "Windows Live Writer 01". That way, if you forget to set the key when you create a new blog on Blogger, your images will still be uploaded to a new album - "Windows Live Writer" - instead of the old one.

Joomla navigational menu's titles on two lines with an Artisteer template

2009-11-15T06:01:00.001-05:00

In this article, we see a method to display the navigation menu Joomla on two or more lines, using for this a template from Artisteer as the basic example:

Although illustrated with an Artisteer template, this method should also apply or be adapted very well for other types of template.

ADDENDUM dated January 6, 2010:

The HTML code described in this article uses the insertion of a block <div> within an area <span>. Although this seems to work properly with both Firefox and Internet Explorer, further study has allowed me to conclude that a better approach would be to use another <span> instead of the <div> but by attaching to it the style "display: inline-block". This second method will be the object of an upcoming article.

Yes, after much procrastination, I finally decided to start my first blog and for my very first article, I chose a recurring problem among users of Joomla and Artisteer: how to get a title in the Menu navigation to appear on more than a single line. As this is my very first blog, you'll excuse me if you find that throughout this article the writing and the formating are less than stellar.

The following figure show us the starting point, with an expansion of the tab we are interested in below:

And this is the result that we want to obtain:

Notice that the menu title "Sylvain Lafontaine.com" is now written on two lines in height and is well centered in the middle of the tab. Although it may seem at first glance easy to accomplish, the solution to this problem is more complicated than it seems. The first thing that most people will probably try to do would be to simply add the XHTML tag "<br/>" (or its HTML equivalent "<br>") directly in the middle of the title of the menu in the Joomla configuration:

Detail for the title:

Sylvain<br />Lafontaine.com

Unfortunately, the result that we get is not what we were expecting:

Instead of causing a line break, the <br /> tag is simply displayed in the browser! That would have worked with Joomla 1.0 but for Joomla 1.5, the HTML tags are no longer interpreted by Joomla and instead are rendered as such in the browser; hence the visible display of the <br /> tag in the above figure. Note that we would have obtained exactly the same result here even if we would have used the HTML tag <br> instead of the XHTML tag <br />.

To solve this problem of displaying the tag with Joomla, we must use a Joomla plugin that will allow us to directly insert the tag <br> into the HTML code created by Joomla. The plugin that I'm suggesting is yvBBCode but you'll get the same result if you use any other plugin. This plugin allows us to replace BB codes with our own HTML markup. BB codes are special codes enclosed in square brackets [] - like [br] for example - that we can insert into any Joomla text and that will get converted into HTML markup by the yvBBCode pluging when the page is served by the web server (Joomla). For example, the code "[br]" will be transformed into "<br />" (less the quotes).

Moreover, with the yvBBCode plugin, we can define our own BB codes - allowing us to display any HTML code that we want - but unfortunately, we cannot define them directly from the Joomla admin interface and instead, we must change the source code of the yvBBCode plugin. We shall see later how to perform this change. The most recent version of yvBBCode already contains the BB code required for inserting the tag <br/>, so that when we are finished installing the yvBBCode plugin on the Joomla site, we can directly try to change the title to introduce the tag <br> into the output of the HTML markup, using this time the code [br] in order to bypass the mechanism used by Joomla that prevents us to insert any HTML tags directly into the HTML markup for the page:

Sylvain[br]Lafontaine.com

which gives us the following result:

The solution seems to be determined to be delayed. This time, one gets a newline but only the first line is visible. Furthermore, this title does not seem to be centered horizontally.

There are several things to identify here. The first is that the menus in the templates of Artisteer are of a fixed height, so the first thing to do is to increase the height of tabs in the template Artisteer. This operation is relatively easy to perform and gives us the following result:

What happened here? There are two problems. The first is the height of lines of text in the menu as defined by Artisteer. In order to center vertically the line of text, Artisteer assigns a high value for the line-height property - here it has been set to 47px but the value for your own template might be different - as we can see from the following CSS snippet:

.art-menu a .t
{
font-family: Arial, Helvetica, Sans-Serif;
font-size: 12px;
font-style: normal;
font-weight: normal;
    color: #C7E2F0;
    padding: 0 17px;
    margin: 0 6px;
    line-height: 47px;
    text-align: center;
}

To better understand the following explanation, we have to mention here that the HTML produced by Artisteer to produce the menu is a "no table" or "tableless" type; which means that the "table" tag is not used for displaying the horizontal strip of tabs. Instead, the template generates a list of <li> tags, each one containing a single tab from the menu. In order to produce the graph rounded button with the text at the center, these tags contain a list of <span> tags: one for the left side of the button (class = "l"), one for the right side (class = "r") and finally one to contain the title text itself (class = "t"):

<ul class="art-menu">
...
   <li id="current" class="active item47">
      <a href="..." class="active">
         <span class="l"> </span>
         <span class="r"> </span>
         <span class="t">Sylvain<br />Lafontaine.com</span>
      </a>
   </li>
...
</ul>

By taking advantage of the fact that Joomla has added the ID of each menu as a class to each <li> tag of the menu (here the "item47", see below), we can introduce the following CSS style to make a quick test:

.art-menu li.item47 a .t
{
font-family: Arial, Helvetica, Sans-Serif;
font-size: 12px;
font-style: normal;
font-weight: normal;
    color: #C7E2F0;
    padding: 0 17px;
    margin: 0 6px;
    line-height: normal;
    text-align: center;
    position:relative; top:8px;
}

Ah! Finally, we can see now that we are approaching the goal:

We see that the two lines of the title are now visible but they are not well centered. This is because the tags <span> - used to display text - are not HTML blocks like the tag <div> and therefore they can not be centered. It's more easy to see the phenomenon if we complete the first line by adding the text "blablabla" at its end: the first line finish at the right margin of the enclosing block while the second line begin at the left margin:

So there is absolutely no effect of centering here inside the <span> tag when more than a single line is displayed. The solution is to introduce a <div> block directly inside the <span>...</span> if we want to center the title when it's written on more than a single line. This <div> block can easily be added using the same technique as before for the <br> tag by using again the yvBBCode plugin. However, this time, the <div> tag is not part of the standard list of BB codes offered by the yvBBCode plugin, so we must first add it to the list.

To do this we must change the file Extended.php that you'll find in the directory .\www\plugins\system\yvbbcode\BBCodeParser\Filter if you change the installation Zip file of the plugin directly or in the directory .\plugins\system\yvbbcode\BBCodeParser\Filter of your Joomla installation if you want to edit the file after the installation.

The piece of code below highlighted below in yellow is what you need to add in the HTML_BBCodeParser_Filter function of the HTML_BBCodeParser_Filter_Extended class that you'll find in the file. You must also be careful to add a comma at the end of the previous code as it is shown below in red. Notice that with some older versions of the yvBBCode plugin, the [br] code is also absent, so you must add it too. Simply use the same code as below for 'br'.

class HTML_BBCodeParser_Filter_Extended extends
HTML_BBCodeParser_Filter {
        ...
'h6' => array('htmlopen' => 'h6',
      'htmlclose' => 'h6',
      'allowed'   => 'all',
      'attributes'=> array()),
'br' => array('htmlopen' => 'br',
      'htmlclose' => '',
      'allowed'   => 'all',
      'attributes'=> array()),

'div' => array('htmlopen' => 'div',
      'htmlclose' => 'div',
      'allowed'   => 'all',
      'attributes'=> array())
);

We then add the following CSS style template for Internet Explore (for FireFox, see the proper CSS code at the end of this article) to format the <div> tag:

.art-menu a .t div
{
font-family: Arial, Helvetica, Sans-Serif;
font-size: 12px;
font-style: normal;
font-weight: normal;
    color: #C7E2F0;
    padding: 0 17px;
    margin: 0 6px;
    line-height: normal;
    text-align: center;
    position:relative; top:8px;
}

.art-menu a:hover .t div {
    color: #131B20;
}

.art-menu li:hover a .t div {
    color: #131B20;
}

.art-menu li:hover>a .t div {
    color: #131B20;
}

.art-menu a.active .t div {
    color: #2E424C;
}

Finally, we can now use our new BB code to enclose our title menu in a <div>...</div> block and with an embedded line break so that our title will now be correctly displayed on two lines:

[div]Sylvain[br]Lafontaine.com[/div]

with the final result:

One can see that the title now appears correctly on two lines, is well centered but horizontally and vertically and that the other tabs remain unchanged.

One last word before finishing. In the case of Firefox, the code above does not work directly as is. This is because Firefox will introduce a line break before the start of the display of the <div> block nested inside the < span> with the effect that the title will now be positioned below the tab and will most likely invisible. To correct this, just put a CSS code specific to Firefox which will raise the text. Here, this can be done easily by simply replacing the "top: 8px;" with a "top: -38px;" for Firefox.