September 2003 Archives

In my Radio Userland category, I've posted a How-To for adding a Google search form that will search a single Radio Userland weblog.

In Radio Userland's discussion forum, Martin asks about adding a Google search box that will search only his Radio Userland weblog:

Hi. Sorry if this is a common question: Is there a definitive resource to show me how to add a Google search feature to my UserLand weblog? Its easy to add one to search the WWW; I'm struggling re: just my weblog. The various links through searching UserLand seem to contradict one another. A definitive resource must be useful for all ''new kids on the block' such as 'me'? Posted by Martin in the land where petrol costs just go up and up :-(

Google actually provides sample code for search boxes that can be freely included on your weblog. (This code should be added to your #homeTemplate, #template, and #desktopWebsiteTemplate templates.)

A Google search box, such as the one displayed here on my weblog, can be set up easily enough (using the code provided by Google) if you want to search a domain. Unfortunately, a Radio Userland weblog's home page is not at the root of a domain. Google's sample search box can be set up to search radio.weblogs.com (which would include *all* Radio Userland weblogs), but not radio.weblogs.com/0123456 (one specific Radio Userland weblog).

Google does provide a way to restrict search results to urls with specific words contained in the url. This is done by using the "inurl:" operator in the search query. By combining a site search of radio.weblogs.com with the inurl:usernum (where usernum is the user number of the Radio Userland weblog), Google's search results will be effectively restricted to ones only from the weblog you want to search.

Here is the sample code for a basic Google search box:

  <!-- Search Google -->
    <center>
    <form method="get" action="http://www.google.com/search">
      <table bgcolor="#FFFFFF"><tr><td>
        <a href="http://www.google.com/">
          <img src="http://www.google.com/logos/Logo_40wht.gif"
            border="0" alt="Google" align="middle" />
        </a>
        <input type="text" name="q" size="25" maxlength="255" value="" />
        <input type="submit" name="btnG" value="Google Search" />
      </td></tr></table>
    </form>
    </center>
  <!-- Search Google -->

This code will provide a search box that works exactly the same way as if you had entered a search on Google's home page.

To restrict the search results only to web pages hosted at radio.weblogs.com (the weblog's domain), this is done by adding "site:radio.weblogs.com" to a Google search query. The "site:" parameter can be included with the form's search queries by adding the following code to the search form code above:

        <input type="hidden" name="sitesearch" value="radio.weblogs.com" />

To further restrict the search results only to web pages from a single weblog hosted at radio.weblogs.com, this is done by adding 'inurl:0123456" to a Google search query (where "0123456" is your Radio Userland user number). The "inurl:" parameter can be included with the form's search queries by adding the following code to the search form code above:

        <input type="hidden" name="hq" value="inurl:0123456" />

The final code would then look like this:

  <!-- Search Google -->
    <center>
    <form method="get" action="http://www.google.com/search">
      <table bgcolor="#FFFFFF"><tr><td>
        <a href="http://www.google.com/">
        <img src="http://www.google.com/logos/Logo_40wht.gif"
            border="0" alt="Google" align="middle" /></a>
        <input type="text" name="q" size="25" maxlength="255" value="" />
        <input type="hidden" name="sitesearch" value="radio.weblogs.com" />
        <input type="hidden" name="hq" value="inurl:0123456" />
        <input type="submit" name="btnG" value="Google Search" />
      </td></tr></table>
    </form>
    </center>
  <!-- Search Google -->

And this is the search box you would see, ready to search for pages only on your Radio Userland weblog:

There are a number of ways that this form can be customized, depending on your preferences:

1. Google has a variety of logos in different sizes and background colors that can be freely used with your search form. These logos can be found on Google's Official Logos page. To use a different logo, replace the source url in the <img> tag above ("http://www.google.com/logos/Logo_40wht.gif") with the url of the logo you would like to use.

2. The width of the input box can be widened or shortened by increasing or decreasing the size="25" parameter in the line <input type="text" name="q" size="25" maxlength="255" value="" />.

3. The text on the "Search" button can be changed to whatever you want by editing the value="Google Search" parameter in the line <input type="submit" name="btnG" value="Google Search" />.

4. The sample code above displays a wide horizontal form, while many Radio Userland users may prefer a narrower, vertical form (for use in their weblog's links column, for example). The search form can be made vertical by first deleting the <table>, <td>, and <tr> tags in the form. (Delete this line: <table bgcolor="#FFFFFF"><tr><td> and this line: </td></tr></table> from the form.) Then add a <br> tag after the <img> link (after the </a> tag) and another one after the <input type="text"> tag.

5. Search results can be made to open in a new window by adding target="_blank" to the <form> tag.

Here's a sample of a customized Google search form, using all of the steps described above:

And here's the HTML code which makes the new search box:

<!-- Search Google -->
    <center>
    <form method="get" action="http://www.google.com/search" target="_blank">
      <a href="http://www.google.com/">
      <img src="http://www.google.com/logos/Logo_25wht.gif"
        border="0" alt="Google" align="middle" /></a><br>
      <input type="text" name="q" size="15" maxlength="255" value="" /><br>
      <input type="hidden" name="sitesearch" value="radio.weblogs.com" />
      <input type="hidden" name="hq" value="inurl:0123456" />
      <input type="submit" name="btnG" value="Search" />
    </form>
    </center>
  <!-- Search Google -->

Now that you know how to set up a Google search form to search only a Radio Userland weblog and how to configure its appearance, have fun with it!

New Unpublished Posts macro now available

I've written a new macro that will list all currently unpublished posts in your weblog. For instructions, details and the download link, see my Blogging category post here.

Unpublished posts macro

In this Radio Userland discussion forum thread, the subject was initially how to enter posts into Radio without having them published, then quickly changed to the creation of a macro that would list all currently unpublished posts for the weblog.

I think I've written a macro that will do the job. If you want to try it out, download it from here. The macro actually produces two lists: The first list is a list of posts that are posted with the "Post" button (using the HTML editor's 3-button mode), and the second list is a list of posts that are not posted to the Home Page and not posted to any category (categories must be enabled in order to do this).

To install it, you will need to install it into Radio. Bring your Radio application to the front. From the 'File' menu choose 'Open...' and then select the newly downloaded script. A box will open, asking "Name for imported object?" and "workspace.unpublishedPosts" will be displayed in the text box. Click OK to install the script. You will then see the script in a window.

Click Compile, then close the window. (Or take a look at the code if you want to see what is under the hood, then close the window.)

In a blank text document, enter the following: <%workspace.unpublishedPosts ()%>

Save the text file to your /www/system/pages directory as unpublishedPosts.txt. Open your browser to http://127.0.0.1/system/pages/unpublishedPosts and you should see a list of unpublished posts (if any) in your browser.

An "Edit" button is displayed next to each unpublished post that will bring up that post in the HTML editor when clicked on with the mouse.

If you need to use this page frequently, a link to http://127.0.0.1/system/pages/unpublishedPosts can be placed in your Desktop Website template. However, this link should not be created in the Navigator Links.

Feedback, comments, and suggestions to improve this macro are welcome.

New posts up in Radio Userland category

Radio weblog calendar bug

| 1 Comment | 1 TrackBack

Every so often, someone will post a question in Radio Userland's discussion forum about the link to the previous month or following month on their weblog's calendar being broken. This always seems to occur on main weblog pages and not category pages.

Julie (Sexy Magick) ran into this problem about a week and a half ago. She had published a post to a category on August 31, but did not publish any posts to her main weblog. This month, the "Aug" link in her main weblog calendar is broken - the link points to the daily archive for Aug. 31 even though Julie did not publish any posts to her main weblog that day.

To figure out why this was occurring, I examined the macro code involved with creating a calendar:

radio.weblog.drawCalendar ()
radio.weblog.getLastPostBeforeDate ()
radio.weblog.getNextPostAfterDate ()

When drawing a calendar, the macro code needs to look at category posts only for a category weblog page calendar, and home page posts only for a main weblog page calendar. The macro code for categories appears to work correctly. However, it is impossible for the macro code for main weblog (home page) posts to work correctly.

In order for these macro to correctly identify home page posts, the macros must look at the flNotOnHomePage field for each post. The getLastPostBeforeDate macro, the getNextPostAfterDate macro, and the code in the drawCalendar macro that creates the previous and next month links do not look at the flNotOnHomePage field at all. Posts that have been posted to a category only and not to the main weblog can be returned by these macros and used as the basis for links on the main weblog calendar when they should not be.

On the last day posts are posted in a given month, if they are all posted to categories and not to the main weblog, the link to that month on the next month's main weblog calendar (the previous month) will be broken.

Similarly, on the first day posts are posted in a given month, if they are all posted to categories and not to the main weblog, the link to that month on the previous month's main weblog calendar (the next month) will be broken.

It is extremely difficult to determine the best way to fix this bug. I do not know if the error is in the fact that getLastPostBeforeDate and getNextPostAfterDate do not look at flNotOnHomePage for home page posts, the fact that drawCalendar does not look at flNotOnHomePage, or both. Nor do I know whether or not a specific fix would break something else in Radio - other functions in Radio may depend on the getLastPostBeforeDate and getNextPostAfterDate macros functioning as they do now. For now, all I can do is report and document the bug.

In Part 1, I showed how the foreground and background colors of Radio's HTML editor could be changed using a javascript. After trying out that script, Julie (Sexy Magick) suggested that it would be handy to be able to set the foreground and background colors from a drop-down box on the editor itself, so she could see how her posts would appear in various categories that have different colored themes. Part 2 demonstrates how this can be done, again with javascript.

The scripts provided below are for Internet Explorer users only. To install the scripts, copy all three scripts (which can also be downloaded here) and add them to your #desktopWebsiteTemplate, below the <%radio.macros.weblogEditBox ()%> macro.

If you are using a javascript to change the colors in the font color drop-down box (described here), place this javascript *after* that one. This script copies the colors from the font color drop-down box, so by placing this script after that one, the foreground and background color drop-down boxes will show the same colors as the ones in the font color box.

At the beginning of the first script, edit the fgColor value to set the foreground (text) color you want, and edit the bgColor value to set the background color of the HTML editor. This will set the colors that the editor will use when the Desktop Website is first opened, and it will be the colors displayed after a post is published.

Save the Desktop Website template and open the Desktop Website in your browser. The new colors should be immediately visible in the HTML editor window. If you no longer want to use this script, simply delete it from your Desktop Website template.

As with the script described in Part 1, this script does not alter the appearance of published posts on your weblog - it only changes how they look in the editor window. No HTML code or style attributes are added to the text of your posts.

Note to Julie: Thanks for your suggestions on improving this script and for beta-testing the script for me. You can see Julie's post about her testing here.

Here is a screen shot of the HTML editor with the new drop-down boxes. The editor's foreground color is set to white and the background color is set to darkblue:

Here are the scripts to be added to the Desktop Website template:

Internet Explorer only:

  <script type="text/javascript">
    <!-- Begin hiding from older browsers 

      // Set colors to use in HTML editor on startup here
      var foreColor = '#000000';
      var backColor = '#FFFFFF';

      // Body tag of HTML document in editor
      var startBodyTag = '<body style=\"font-family: verdana, ' + 
        'sans-serif; font-size: 12px; margin-top: 3px; ' + 
        'margin-bottom: 3px; margin-left: 3px; margin-right: 3px;';
      var endBodyTag = '\"' + String.fromCharCode (62);

      // Increase height of div containing drop-down boxes
      document.getElementById('tb2').style.height = '45px';

      // Get reference to existing font color drop-down box
     var fontColorBox = document.forms(0).elements(5);

      // Function to perform actual switching of colors
      function chgScreenColors () {
        sHeader = startBodyTag + 
          ' color: ' + foreColor + ';' + 
          ' background: ' + backColor + ';' + endBodyTag;
        sContents = idEdit.document.body.innerHTML;
        idEdit.document.open ();
        idEdit.document.write (sHeader);
        idEdit.document.close ();
        idEdit.document.body.innerHTML = sContents;
        }

      // Make a copy of font color drop down box
      var foreColorBox = fontColorBox.cloneNode(true);
      var backColorBox = fontColorBox.cloneNode(true);

      // Set id of new drop down boxes 
      foreColorBox.id = 'fgColorBox';
      backColorBox.id = 'bgColorBox';

      // Set caption of new drop down boxes
      foreColorBox.options(0).text = 'Foreground...';
      backColorBox.options(0).text = 'Background...';

      // Add color 'white' to end of fgBox option list
      newOption = document.createElement('option');
      foreColorBox.options.add(newOption);
      newOption.text = 'white';
      newOption.style.color = 'white';
      newOption.style.background = 'black';

      // Add color 'white' to end of bgBox option list
      newOption = document.createElement('option');
      backColorBox.options.add(newOption);
      newOption.text = 'white';
      newOption.style.color = 'white';
      newOption.style.background = 'black';

      // Insert new drop-down boxes into form
      fontColorBox.insertAdjacentHTML("AfterEnd",'&nbsp;');
      fontColorBox.insertAdjacentElement("AfterEnd",backColorBox);
      fontColorBox.insertAdjacentHTML("AfterEnd",'&nbsp;');
      fontColorBox.insertAdjacentElement("AfterEnd",foreColorBox);
      fontColorBox.insertAdjacentElement("AfterEnd",document.createElement('br'));

      // Initalize HTML document with starting colors
      sHeader = startBodyTag + 
        ' color: ' + foreColor + ';' + 
        ' background: ' + backColor + ';' + endBodyTag;
      idEdit.document.open ();
      idEdit.document.write (sHeader);
      idEdit.document.close ();

    //End hiding-->
  </script>

  <script for=fgColorBox event=onchange type="text/javascript">
    <!-- Begin hiding from older browsers 
      if (!bMode) {
        alert (strErr); idEdit.focus ();
        this.selectedIndex=0;
        return;
        }
      foreColor = this[this.selectedIndex].style.color;
      chgScreenColors ();
      this.selectedIndex=0;
      idEdit.focus ();
    //End hiding-->
  </script>

  <script for=bgColorBox event=onchange type="text/javascript">
    <!-- Begin hiding from older browsers&nbsp;
      if (!bMode) {
        alert (strErr); idEdit.focus ();
        this.selectedIndex=0;
        return;
        }
      backColor = this[this.selectedIndex].style.color;
      chgScreenColors ();
      this.selectedIndex=0;
      idEdit.focus ();
    //End hiding-->
  </script>

In Radio Userland's discussion forum, Lisa asks:

Can someone point out to me where I need to drill down to change the color of the textbox for posting/editing items? I want to make it the same background color/default text color as on my blog so that I can see how it looks as I'm creating it...

According to this page, you're supposed to be able to use <%radio.macros.weblogEditBox (bgcolor)%> to set the background color of the HTML editor box. I tested this on my weblog and this does *not* work. I took a look at the code - the macro does allow for a bgcolor parameter, but it does not use it to set the editor background color at all. If a color value is supplied, it will actually set the background color for the category checkboxes below the editor.

Radio appears to not provide a way for the user to set the editor's display colors, but they can be set by using a javascript in the #desktopWebsiteTemplate.

To set the colors of Radio's HTML editor, add the following javascript to your #desktopWebsiteTemplate, below the <%radio.macros.weblogEditBox ()%> macro. (Use the correct version for your browser):

Internet Explorer

  <script type="text/javascript">
    <!-- Begin hiding from older browsers 

      // Set colors to use in HTML editor on startup here
      var fgColor = '#000000';
      var bgColor = '#FFFFFF';

      var endOfTag = '\"' + String.fromCharCode (62);
      sHeader = sHeader.replace(endOfTag,
        ' color: ' + fgColor + ';' + 
        ' background: ' + bgColor + ';' + endOfTag);
      idEdit.document.open ();
      idEdit.document.write (sHeader);
      idEdit.document.close ();

    //End hiding-->
  </script>

Mozilla / Mozilla Firebird

  <script type="text/javascript">
    <!-- Begin hiding from older browsers 

      // Set colors to use in HTML editor on startup here
      var foreColor = '#FFFFFF';
      var backColor = '#000000';

      var editFrame = document.getElementById('edit');

      // Function to set HTML editor colors
      function loadColors () {
        var editDoc = editFrame.contentWindow.document;
        var editDocStyle = editDoc.body.style;
        editDocStyle.color = foreColor;
        editDocStyle.background = backColor;
        }

      // Wait for about:blank page to load
      editFrame.contentWindow.addEventListener 
        ('load',loadColors, false);

    //End hiding-->
  </script>

In the script, edit the fgColor value to set the foreground (text) color you want, and edit the bgColor value to set the background color of the HTML editor. Save the template, then open the Desktop Website in your browser. The new colors should be immediately visible in the HTML editor window. If you no longer want to use this script, simply delete it from your Desktop Website template.

This script does not alter the appearance of published posts on your weblog - it only changes how they look in the editor window. No HTML code or style attributes are added to the text of your posts.

While these scripts do work as intended, you must edit the Desktop Website template any time you want to change the editor's colors. In Part 2, I will demonstrate a javascript that will allow you to change the editor's foreground and background colors directly from the editor window.

In my "Initial experiences with Mozilla Firebird and Radio" (Sep. 09), I described some of the problems and issues I was running into trying to use Mozilla Firebird to create and edit posts.

This is one of the problems that was really annoying me:

2. While I was trying to delete the above mentioned characters, the Mozilla editor seemed to get confused at times about what text I was trying to edit. The blinking cursor would be at a specific position in the html code, and when I pressed the BackSpace or Del key, the character that would be deleted was one character to the left of the character that should have been deleted.

This problem occurred when I was editing in "View HTML Source" mode. Initially, I thought it was a bug in the code Radio uses to control the editor, but I no longer believe this is the case.

This problem appears to be caused by the way the Mozilla editor inserts tags into the code when a user presses the Enter key. When the Enter key is pressed, the Mozilla Editor actually inserts "<br> " (a <br> tag plus a space). When the user then switches the editor into "View HTML Source" mode, these extra space characters are not accounted for when the Mozilla Editor calculates the actual character position to be edited. Text editing occurs one character position to the left of the blinking cursor for every <br> tag (and extra space) present between the beginning of the text and the location of the blinking cursor.

Here is an example to demonstrate this bug:

Open the Desktop Website in Mozilla Firebird, and enter the following in the editor window:

Now is the

time for all

good men to

come to the

aid of their

country.

The source code for this text should look something like the following (which you can see by selecting the text, then right click on the selected text and click "View Selection Source":

Now is the<br>
<br>
time for all<br>
<br>
good men to<br>
<br>
come to the<br>
<br>
aid of their<br>
<br>
country.<br>

Check on the "View HTML Source" box to view the source code in the editor. You should see something like this:

Now is the<br> <br> time for all<br> <br> good men to<br> <br> come to the<br> <br> aid of their<br> <br> country.<br>

Notice the extra spaces after each <br> tag.

Click the mouse somewhere in the middle of the source code and type or delete some characters. The character that is typed or deleted will not be the one at the blinking cursor position. The number of characters it is off should be the number of <br> tags (extra spaces) between the cursor and the beginning of the HTML code.

This does not appear to be a bug in Radio - I think it is a bug in the editor itself. Unfortunately, this bug makes the Mozilla Editor pretty useless for editing the HTML source code of posts.

One other nitpick I have with the editor: Pressing the Enter key should create <p> tags, not <br> tags. If a user wants a <br> tag, press shift-Enter. I did not see any way to create a new paragraph except for editing the HTML source code.

I have posted a follow-up to my "Tweaking Radio's HTML Editor" post in my Blogging category, describing how to change the font colors available in Radio's HTML editor, again using a javascript in the Desktop Website template.

Julie (Sexy Magick), who happens to really like lots of colors, saw my post yesterday on tweaking the available font names in Radio's HTML editor and wanted to do the same with the font colors drop-down box.

As with the script I demonstrated in my earlier post, locate the <%radio.macros.weblogEditBox ()%> macro in the #desktopWebsiteTemplate.txt file, which is what draws the HTML editor. Insert the following script into the template immediately below the weblogEditBox macro if you are using Internet Explorer:

<script type="text/javascript">
<!--
  document.forms(0).elements(5).options(1).text = 'black';
  document.forms(0).elements(5).options(1).style.color = 'black';

  document.forms(0).elements(5).options(2).text = 'darkslategray';
  document.forms(0).elements(5).options(2).style.color = 'darkslategray';

  document.forms(0).elements(5).options(3).text = 'red';
  document.forms(0).elements(5).options(3).style.color = 'red';

  document.forms(0).elements(5).options(4).text = 'maroon';
  document.forms(0).elements(5).options(4).style.color = 'maroon';

  document.forms(0).elements(5).options(5).text = 'lightpink';
  document.forms(0).elements(5).options(5).style.color = 'lightpink';

  document.forms(0).elements(5).options(6).text = 'purple';
  document.forms(0).elements(5).options(6).style.color = 'purple';

  document.forms(0).elements(5).options(7).text = 'blue';
  document.forms(0).elements(5).options(7).style.color = 'blue';

  document.forms(0).elements(5).options(8).text = 'darkblue';
  document.forms(0).elements(5).options(8).style.color = 'darkblue';

  document.forms(0).elements(5).options(9).text = 'teal';
  document.forms(0).elements(5).options(9).style.color = 'teal';

  document.forms(0).elements(5).options(10).text = 'skyblue';
  document.forms(0).elements(5).options(10).style.color = 'skyblue';

  document.forms(0).elements(5).options(11).text = 'green';
  document.forms(0).elements(5).options(11).style.color = 'green';

  document.forms(0).elements(5).options(12).text = 'seagreen';
  document.forms(0).elements(5).options(12).style.color = 'seagreen';

  document.forms(0).elements(5).options(13).text = 'olive';
  document.forms(0).elements(5).options(13).style.color = 'olive';

  document.forms(0).elements(5).options(14).text = 'orange';
  document.forms(0).elements(5).options(14).style.color = 'orange';

  document.forms(0).elements(5).options(15).text = 'darkgoldenrod';
  document.forms(0).elements(5).options(15).style.color = 'darkgoldenrod';

  document.forms(0).elements(5).options(16).text = 'gray';
  document.forms(0).elements(5).options(16).style.color = 'gray';
//-->
</script>

Mozilla and Mozilla Firebird users should not need to edit the colors available - the font color and background color toolbar buttons provide a palette of 70 colors.

In their current form, the statements in both scripts merely put the same font colors in the drop-down box as what Radio does. To change a font color listed in the drop-down box, edit the appropriate pair of lines corresponding to the drop-down entry you wish to change.

In each pair of statements, the first statement (ending in .text) is what the drop-down box displays to the user. The second statement (ending in .style.color) is the font color name that the editor will actually place in your HTML code. (Radio uses the color name for both the .text and .style.color values.)

A nice list of the 140 possible color names is available here.

If you wish to reduce the length of the script, you can safely delete the pair of statements for each color that you are not changing.

Save the #desktopWebsiteTemplate.txt file, and open the Desktop Website in your browser. Any changes made to the font drop-down box should be immediately visible. If at any time you decide you no longer want to use the script, simple delete it from the #desktopWebsiteTemplate.txt file.

Bonus Tip: You can have more than 16 colors in the font color drop-down box if you wish. The code to add a color is a little different than changing one - you have to create the entry for the color first, then set its color. To add a color, copy the following two statements into the above javascript:

  document.forms(0).elements(5)[17] = new Option('colorName');
  document.forms(0).elements(5).options(17).style.color = 'colorName';

The "new Option" sets the .text property at the time the option is created, so a statement to set it separately is not necessary. Use an option number of 17 in each statement for the first color added, and increase it by one for each additional color added.

Dean's World has come up with a great rule for handling spammers and trolls who leave messages in his blog comments:

From this point forward, if you leave either a trolling message or a spam in the comments to Dean's World, my wife Rosemary will edit your message. Purely for the purposes of correcting your grammar and making sure you said what you really MEANT to say, as opposed to whatever deranged psychobabble came out of you.

What spurred this policy? "Laura in DC" has been spamming blogs to drum up support for presidential candidate Howard Dean, and made the mistake of spamming Dean's World. Jeff Jarvis (BuzzMachine) has a sample in his comments (and Daniel Drezner has one too):

Cool site! Check out my new blog, Mousepads, Shoe Leather, and Hope - The Great Grassroots Campaign. Also, check out my Dean stores, The Great Grassroots Campaign and You Have The Power. The proceeds from the shop will be given to the new Generation Dean chapter on campus. If you feel like linking to any of the sites I gave you, I'd be happy to add a link to your site on my blog. Keep up the good work with your site.

Posted by Laura in DC at September 17, 2003 04:41 PM

So what did Laura really mean to say? Here's the re-written comment:

I just want you to know that I used to love Howard Dean. This is my website. But I just found out that Howard Dean fantasizes about being a 13 year old girl in bondage and wishes he could be Ronald Reagan's sex toy. He hates the Jews and the darkies, but especially the jews because he thinks they have all the money and won't give him any.

I really hate him now. If you hate him too, please come to the website and tell me just how much!!

He is a real rat bastard.

Email me your thoughts on this stinkin' racist anti-semite. I'd love to hear from you !

democrattotheend@yahoo.com

Posted by Laura in DC at September 17, 2003 05:26 PM

If the opportunity ever comes up, I'm going to have a lot of fun with this!

Update 20-Sep-2003: Laura hit Calpundit's comments yesterday.

I have a post up in my Radio Userland category, describing how to change the fonts that Radio's HTML editor shows in the font drop-down box, using a javascript in the Desktop Website template.

In the Radio discussion forum, Xavier Caballe asked the following:

Is there any way to change the fonts used by the built-in HTML editor? Specifically I'd like to change Courier to Courier New, since this renders much better.

Radio offers no option for this. The fonts listed in the HTML editor drop-down box are hard-coded in radio.root. To change them directly, it would be necessary to edit the code directly. This option is not recommended, as a radio.root update could wipe out any changes made there, and any mistakes made in the editing could break the HTML editor.

A safer alternative to editing the code in radio.root is to use a javascript in the #desktopWebsiteTemplate.txt file to change the values in the font drop-down box after Radio has rendered the HTML editor.

In the #desktopWebsiteTemplate.txt file, locate the <%radio.macros.weblogEditBox ()%> macro, which is what draws the HTML editor. Insert the following script into the template immediately below the weblogEditBox macro if you are using Internet Explorer:

<script type="text/javascript">
<!--
  document.forms(0).elements(3).options(1).text = 'Arial';
  document.forms(0).elements(3).options(1).value = 'Geneva,Arial,Sans-Serif';

  document.forms(0).elements(3).options(2).text = 'Verdana';
  document.forms(0).elements(3).options(2).value = 'Verdana,Geneva,Arial,Helvetica,Sans-Serif';

  document.forms(0).elements(3).options(3).text = 'Time';
  document.forms(0).elements(3).options(3).value = 'Times New Roman,Times,Serif';

  document.forms(0).elements(3).options(4).text = 'Courier';
  document.forms(0).elements(3).options(4).value = 'Courier, Monospace';
//-->
</script>

If you are using Mozilla or Mozilla Firebird, insert this script into the template immediately below the weblogEditBox macro:

<script type="text/javascript">
<!--
  document.editPostForm.fontname.options[1].text = "Arial";
  document.editPostForm.fontname.options[1].value = "Arial";

  document.editPostForm.fontname.options[2].text = "Courier";
  document.editPostForm.fontname.options[2].value = "Courier";

  document.editPostForm.fontname.options[3].text = "Times New Roman";
  document.editPostForm.fontname.options[3].value = "Times New Roman";
//-->
</script>

In their current form, the statements in both scripts merely put the same fonts in the drop-down box as what Radio does. To change a font listed in the drop-down box, edit the appropriate pair of lines corresponding to the drop-down entry you wish to change.

In each pair of statements, the first statement (ending in .text) is what the drop-down box displays to the user. The second statement (ending in .value) is the name of the font(s) that the editor will actually place in your HTML code.

In answer Xavier's question, you would edit the 4th pair of statements in the Internet Explorer javascript if you're using Internet Explorer:

  document.forms(0).elements(3).options(4).text = 'Courier New';
  document.forms(0).elements(3).options(4).value = 'Courier New, Monospace';

And if you're using Mozilla / Mozilla Firebird, you would edit the 2nd pair of statements in the Mozilla / Mozilla Firebird javascript:

  document.editPostForm.fontname.options[2].text = "Courier New";
  document.editPostForm.fontname.options[2].value = "Courier New";

Save the #desktopWebsiteTemplate.txt file, and open the Desktop Website in your browser. Any changes made to the font drop-down box should be immediately visible. If at any time you decide you no longer want to use the script, simple delete it from the #desktopWebsiteTemplate.txt file.

Post indexes are now up

| 9 Comments

My project for the day was adding post index pages (table of contents, recent titled posts, whatever you want to call them) to my weblog.

I decided to go with Rogers Cadenhead's viewPostIndex macro because

  1. It was something I didn't have to figure out and write myself (no need to re-invent the wheel here)

  2. The macro automatically groups posts by month

  3. Because the macro uses an unordered list to display the posts, each post has a bullet in front of it

  4. Built-in support for CSS classes

  5. Rogers has a companion macro (upstreamPostIndexes, available on the same page) that will automatically upstream the post index pages once a night.

I did end up customizing the viewPostIndex macro a bit. This is what I changed:

  • Added default CSS classes to the macro's parameters so I didn't have to use them in the macro calls on my templates.

  • Added another CSS class to format the month headings. I wanted them displayed in bold but didn't want to add <b> tags in the macro code, nor did I want to have to edit the macro every time I changed my mind on how I wanted it formatted.

  • Changed the format of the month header so that instead of displaying "2003/09" it now displays "September 2003".

  • Added the date of each post to the output (formatted as "Sep 16") and enclosed it with a <div style="float: right; margin-left: 10px;"> tag to force the date to the far right end of the line.

    Update: Internet Explorer does not display things correctly using "margin-left". It took me a while to figure that out, as well as how to fix it. I changed it to "padding-left" and now the index pages display correctly in both Internet Explorer and Mozilla Firebird.

My main weblog and all of my category pages now have a post index page. The links to them can be seen in my links column on the right. [Nice macros, Rogers - Thanks!]

Note for Rogers: In his Sept. 11 post, Rogers notes a comment about his picture: "nice picture you look like a bore brush for a 50mm.". When I saw Rogers' picture, the first word that immediately came into my mind was "engineer" - as in someone who *knows* how to build things. Enough said.

Albert has spoken!

Looking back through my referrals last night, one caught my eye...so I clicked on the referring link to see who was linking to me. Albert Delgado (Radio Education Weblog Portal) posted the following remark with his link to my post on "Hacking Radio's radio.macros.blogroll":

"David Philips, aka Tweezerman, should be listened to by Userland. Kudos to David for pushing the envelope on Radio."

Do you suppose Dave Winer will take my calls now? (Thanks, Albert - that made my day!)

How-To: Hacking radio.macros.blogroll

| 1 Comment

For Radio Userland users:

I've put up a How-To for some of my minor issues with the radio.macros.blogroll macro:

  1. How to use only some of your XML newsfeed subscription links in blogroll.opml.
  2. Using local copies of the mini-icons instead of pulling them from http://static.userland.com.
  3. Making the correct tooltip display in both Internet Explorer and Mozilla Firebird browsers.

#2 and #3 are not for the timid or inexperienced, but there they are if you are interested.

Hacking Radio's radio.macros.blogroll

I've been using the radio.macros.blogroll macro in my templates to display my blogroll links for some time. One thing that I wanted to do was to have my RSS subscriptions in the middle of my blogroll but not have to use separate blogroll OPML files and multiple macro calls in my template.

At the time I set up my blogroll, I didn't see any other way to do it, so I created my links manually without any subscription info. The macro thus did not display the tiny coffee cup and XML icons next to each link I subscribed to.

Another problem I didn't see a way around was that even if I did use the mySubscriptions.opml file in my blogroll, it looked to be an all-or-nothing deal. All of the links in mySubscriptions.opml are displayed, whether you want them all displayed or not.

Last night, the light bulb went off in my head. Copy only the subscription links I want to display from mySubscriptions.opml to blogroll.opml. Right click on the subscription link in mySubscriptions.opml, click "Copy", switch to the blogroll.opml window, right click on the location where the subscription link should be inserted, then click "Paste". Too easy!

If I decide to unsubscribe from a web site, I just delete the subscription link in blogroll.opml. If I add a new subscription and want to display it on my blogroll, I would just copy the new subscription link from mySubscriptions.opml (which Radio maintains automatically if it is set to do so in the Preferences) and paste it into blogroll.opml.

Today, I was checking over my weblog in both Internet Explorer and Mozilla Firebird and noticed two things I thought should be fixed:

1. The little coffee cup and XML icons displayed by radio.macros.blogroll () are not local. The macro uses these links for the icons:
* http://static.userland.com/shortcuts/images/misc/miniXmlCoffeeMug.gif
* http://static.userland.com/shortcuts/images/misc/miniXmlButton.gif

2. The tooltips for the little coffee cup icons and XML icons were displaying only the file name in Internet Explorer. Mozilla Firebird displays the correct tooltip when my "Popup ALT attribute" extension is disabled; otherwise, it displays only the file name just like Internet Explorer does.

Note: The correct tooltip for the little coffee cup icon should be 'Click to subscribe to "Site Name" in Radio UserLand.' The correct tooltip for the little XML icon should be 'Click to view the XML source for "Site Name".'

The links output by radio.macros.blogroll are actually built by html.data.standardMacros.opmlToBlogroll. I hacked the opmlToBlogroll code as follows:

1. Moved the bundle //set miniMugIcon and miniXmlButton code (3 lines including the bundle statement) from the main line code to the inside of the on addItem () subroutine, so that different tootips can be created for each link as each link is processed. I inserted the bundle just after (and inside of) the if xmlurl != "" /\/get coffee mug and xml button links statement.

2. Used a call to radio.macros.imageRef to get the local icons, instead of the link that was hard-coded into the macro.

Note: In order for this to work, it is necessary to download and save a local copy of the mini-icons. I saved mine to my /www/images directory. It would appear that Radio does not ship with these icons; I could not locate a copy anywhere within my Radio Userland directories.

3. Copied the Title attribute text assigned to the <a href> tags (the two statements now following the bundle code I inserted) and used that as the ALT attribute text in my radio.macros.imageRef call. Without an ALT parameter, radio.macros.imageRef will generate an IMG tag with an empty ALT attribute (alt=""), and this will prevent Internet Explorer from displaying any tooltip at all.

This is what the modified code looked like after I made my changes:

on addItem (text, url, xmlurl, isRecent, target="", tooltip="")
   local (xmllinks = "", targetstring = "", titlestring = "", prefix = "", 
      suffix = "")
   if xmlurl != "" /\/get coffee mug and xml button links
      bundle /\/set miniMugIcon and miniXmlButton
         miniXmlButton = radio.macros.imageRef ("/images/miniXmlButton.gif", 
            align:"middle", alt:"Click to view the XML source for &quot;" + 
            string.replaceAll (text, "\"", "&quot;") + "&quot;.")
         miniMugIcon = radio.macros.imageRef ("/images/miniXmlCoffeeMug.gif", 
            align:"middle", alt:"Click to subscribe to &quot;" + 
            string.replaceAll (text, "\"", "&quot;") + "&quot; in Radio UserLand.")
      xmllinks = "<a href=\"http:/\/127.0.0.1:5335/system/pages/subscriptions?url=" 
         + string.urlEncode (xmlurl) + "\" title=\"Click to subscribe to &quot;" 
         + string.replaceAll (text, "\"", "&quot;") + "&quot; in Radio UserLand.\">" 
         + miniMugIcon + "</a> "
      xmllinks = xmllinks + "<a href=\"" + xmlurl + "\" title=\"Click to view the 
         XML source for &quot;" + string.replaceAll (text, "\"", "&quot;") + 
         "&quot;.\">" + miniXmlButton + "</a> "

If Radio Userland comes through on my request to enhance radio.macros.imageRef so that it will support use of the Title attribute, this code should be changed so that imageRef macro calls use the Title attribute for the tooltip text instead of the ALT attribute. Until then, this hack works for both Internet Explorer and Mozilla Firebird.

Never say never

| 2 Comments

You may laugh at this.....

A long time ago (4-5 years), I swore I would never learn HTML. I never imagined myself ever wanting to have a web page and therefore saw no reason to learn something that would probably be outdated and useless in a few years anyway.

Fast forward to the end of April, 2003. I had been reading other weblogs for a few months, liked what I saw, and decided I wanted to try having one of my own. I got an account at Blogger and learned barely enough HTML to write my very basic weblog (<a href>, <b>, <i>, <blockquote>, <br>, and <p> tags).

That was actually enough for me - for a little over 2 months. I looked at various other blogging applications and decided to give Radio Userland a try. I liked Radio Userland, but I wanted to heavily customize the templates - which meant I needed to learn a lot more HTML than the little bit I knew.

Over the following month, I learned enough HTML and CSS to rebuild my templates from scratch. There's still a lot for me to learn, but I think I have the basics down. I'm even giving advice to new bloggers in Radio's forums.

What got me to remembering this is a comment in Radio Userland's forums by David Matchett:

Kool! I think I've heard of HTML somewhere...

Just a few months ago, that was about all HTML was to me too!

Additional note: One other thing I swore I would never learn is PowerPoint (MS Office). I don't think I'm in any danger on that one yet.

Movable Type license exposed

Back in June, there was a lot of discussion about Movable Type's license terms in light of the notice Six Apart sent to Kathy Kinsley at BlogHouse, alleging that she was in violation of MT's license by offering to install Movable Type for her customers.

No one has, to my knowledge, offered any definitive evidence one way or the other as to whether certain terms in MT's licenses are legal. (My Software Licensing category explores the issues to some extent.)

I did some legal research on my own and found the answer to the question of whether those license terms are legal or not. My findings, including cites of applicable law and court precedent, are in my Software Licensing category post "Yes, you can legally charge a fee to perform Movable Type installs".

Back in June, I posted two articles discussing some of the terms in Movable Type's license:

The inspiration for these articles was the notice Six Apart sent to Kathy Kinsley (BlogHouse), informing her that she was in violation of MT's license by offering to install MT for her users. A number of weblogs have commented on this situation, but to date, none that I am aware of have provided any conclusive evidence that any part of MT's license is indeed illegal.

I did some legal research on my own and I can show that certain clauses in MT's licenses are indeed illegal. I have withheld posting this information until now because Mena Trott (CEO of Six Apart) asked that I wait until Six Apart can come up with new license terms for MT. I believe that Six Apart has had more than ample time to do this, and I see no reason why MT's users should wait any longer to know what their rights are and what the law is. For the record, Six Apart has known most of the information I am posting here for 80 days.

Disclaimer: I am not a lawyer. This is not legal advice and should not be construed as such. If you have legal difficulties in this area, seek out and consult with a competent attorney.

The following four activities which are prohibited by Movable Type's Personal, Non-Commercial Use License and Limited Commercial Use License are the ones I will be focusing on:

  • receiving compensation for any service that uses the Software, including support services; (both licenses)
  • providing, or offering to provide, any service using the Software; (Personal License)
  • using the Software to provide web design or other services to commercial and non-commercial websites; (Personal License)
  • hosting, or offering to host, the Software, on any basis; (both licenses)

1. Federal copyright law - Copyright misuse

Under federal copyright law, I believe the four license terms above constitute copyright misuse - attempting to leverage a copyright monopoly into a larger monopoly or exclusive right not granted by copyright law. (See my post What is a software license supposed to protect? - Part 2 for more information about the doctrine of copyright misuse.)

None of the four clauses fall within the scope of rights granted by federal copyright law. (See my post What is a software license supposed to protect? to see what rights are granted under federal copyright law.):

  • The prohibition against receiving compensation for services grants Six Apart a monopoly in installation and support services for pay.

  • The prohibition against providing web design or any other service asserts a right to restrict Personal licensees from providing services (installation, support, and web design) to anyone, despite the fact that such services are not covered under Six Apart's copyright.

  • The prohibition against hosting grants Six Apart a monopoly in hosting services for MT, in support of Six Apart's TypePad service.

The prohibitions against providing services or receiving compensation for providing services are most certainly not a part of Six Apart's copyright. From 17 USC 102 (federal copyright law):

(b) In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.

The way I read section 102(b), various software services such as installation, support, design, etc. would likely be categorized as "procedures", "processes", or "methods of operation" and thus not protected by copyright. If such services are not protected by copyright, then Six Apart has no basis (legal authority) to grant rights to, or withhold rights from, a licensee regarding performance of those services, as those rights already fully belong to the licensee.

Courts that follow the doctrine of copyright misuse will withhold remedies for infringement of the copyright (i.e. not enforce the copyright at all) until the anti-competitive effects of the misuse have completely dissipated.

U.S. Circuit Court Case precedents on copyright misuse:

2. California state law - Restraint of trade

Movable Type's licenses are also subject to California state law. This is the Governing law clause from the MT licenses:

"This Agreement will be governed by the laws of the United States and the State of California, excluding the application of its conflicts of law rules. You consent to the personal and exclusive jurisdiction and venue of the state and federal courts located in San Francisco, California."

I believe the four prohibition clauses in MT's licenses can be viewed as prohibitions in the interest of "protecting MT's business from competition". Here's a few Six Apart quotes supporting this assertion:

From Movable Type's FAQ:

"Movable Type's development is supported from user donations, commercial License Fee payments, and our own pay installation service, and further development depends on our ability to provide related services to Movable Type users. Therefore, offering pay installation is prohibited."

Anil Dash, a Vice President at Six Apart, said this on June 20 (On The Third Hand):

"FWIW, we've let hundreds of thousands of people download the software for free, with a significant portion of the development effort being funded by our paid service installing the program for people who found the process too difficult. I don't think that's a terrible thing that we did, and I don't think we're wrong to protect the part of our business that pays for so many people to use MT at no cost at all."

Mena Trott, CEO of Six Apart, in the same discussion thread:

"We do not *currently* allow the hosting for many reasons. For one, yes, it will initially compete with TypePad, our own hosting service. The logic that we should be in competition with our own free product and not be compensated in any way is seriously flawed."

Unfortunately, California state law does not grant a business any right to protect itself from competition. This is from Section 16600 (Contracts in Restraint of Trade) of the California Business and Professions Code:

16600. Except as provided in this chapter, every contract by which anyone is restrained from engaging in a lawful profession, trade, or business of any kind is to that extent void.

This law is what makes non-compete agreements in California generally not enforceable. There a few exceptions, none of which apply here. The four activities prohibited are all lawful activities (they do not violate state or federal law), they are all activities that can be entered into as a business, and their prohibition does not protect trade secrets or confidential business information. The four clauses in MT's licenses prohibiting the activities listed above are null and void under this law.

3. California state law - Unfair business practices

In addition to violation of section 16600, I believe the four license clauses also violate laws in section 17000 (Unfair Trade Practices) of the California Business and Professions Code.

Look at Section 17000 and Section 17020 for general provisions and definitions. These are the laws that I believe are the most seriously violated by MT's license:

17043. It is unlawful for any person engaged in business within this State to sell any article or product at less than the cost thereof to such vendor, or to give away any article or product, for the purpose of injuring competitors or destroying competition.

17046. It is unlawful for any person to use any threat, intimidation, or boycott, to effectuate any violation of this chapter.

17048. It is unlawful for any manufacturer, wholesaler, distributor, jobber, contractor, broker, retailer, or other vendor, or any agent of any such person, jointly to participate or collude with any other such person in the violation of this chapter.

Section 17043 is violated by every developer and installer who performs installation, design, and support services for free in order to protect MT's business. I believe Six Apart may have liability under this section of law due to the fact that Six Apart's license requires it.

Section 17046 is violated by the MT "Termination" section of the license: "This Agreement shall terminate automatically if you fail to comply with the terms of this Agreement." This would be considered a threat or intimidation - if the licensee does not agree to the (illegal) license terms, the user will not be granted a license, or an existing licensee will have their license terminated.

Section 17048 is violated by Six Apart when a user agrees to abide by the illegal license terms and perform support services for free in order to protect MT's business.

Under Section 17051, the four clauses in MT's licenses prohibiting the activities listed above are null and void for being in violation of any one of the sections listed above (17043, 17046, 17048):

17051. Any contract, express or implied, made by any person, firm, or corporation in violation of this chapter is an illegal contract and no recovery thereon shall be had.

And for those of you who would insist that there is no crime committed:

17100. Any person, whether as principal, agent, officer or director, for himself, or for another person, or for any firm or corporation, or any corporation, who or which violates this chapter is guilty of a misdemeanor for each single violation and upon conviction thereof, shall be punished by a fine of not less than one hundred dollars ($100) nor more than one thousand dollars ($1,000) or by imprisonment not exceeding six months or by both such fine and imprisonment, in the discretion of the court.

Conclusion

MT's software licenses have no statutory (legal) authority to exert influence over any service provided by any licensee at any price (per California state law and federal copyright law). Any license term that attempts to do so can be declared null and void in court. The license clauses listed above need to be removed from MT's licenses. Plus, the restrictions on commercial licensees that prohibit licensees from installing the software on web sites that charge a fee for access or use need to be removed as well.

Bottom line: Six Apart needs to stop using MT's licenses to corner every market for themselves (especially service markets). Regardless of whether Six Apart's officers think this is fair or not, it is illegal.

Remembering the WTC towers

In remembrance of 09/11, I've posted a story along with some pictures of the WTC I took during my trip to New York City in 1979.

Today I decided that I wanted to convert a couple of stand-alone web pages on my blog into stories and use Mozilla Firebird to do it.

I ended up giving up on Mozilla Firebird for this task because of three things that happened:

1. I normally do my editing in Front Page 2000, then copy the finished post from Front Page and paste it into Radio. When I did this today, the Mozilla editor in Radio picked up all of the indents in Front Page's code and changed them all into a series of characters at the beginning of every line. It was a pain to remove them all, but I decided that I would try to figure out how to get around that issue later.

2. While I was trying to delete the above mentioned characters, the Mozilla editor seemed to get confused at times about what text I was trying to edit. The blinking cursor would be at a specific position in the html code, and when I pressed the BackSpace or Del key, the character that would be deleted was one character to the left of the character that should have been deleted.

3. When I had finished editing the html and published the story, all of the text that I had entered and edited disappeared. The story file was created in the proper directory on the disk drive, but all that was in the .txt file was #title and #postTime directives. At this point I gave up on Firebird and did everything over with Internet Explorer. I don't know the loss of my story text was just a fluke occurrence, a bug in Firebird, a bug in Radio, or what.

I also found out that Mozilla Firebird (and Mozilla) will not display tooltips for images that have alt text. In order for Mozilla Firebird to display a tooltip for an image, the img tag must have a title attribute instead. You can read all the details about this issue as well as some workarounds for it in my post here. I have also posted a programming request for Radio's programmers to fix the radio.macros.imageRef macro to address this issue, which you can see here.

I've been doing some light testing of the Mozilla Firebird browser the last few days. Today, I was making some changes to one of my stories that has some images in it and noticed that Mozilla Firebird was not displaying the tooltips for the images, even though the img tags had correct alt attributes.

I did a little research to find out if this was a bug in Mozilla Firebird. Despite the fact that this "bug" has been reported dozens of times for Mozilla and Mozilla Firebird, the developers insist this is not a bug:

Many sites uses the alt HTML property to display tooltips for images. This is wrong. The correct property to use for tooltips is title. The alt property has a very important purpose, which is to provide replacement text for images in browsers that cannot or do not (by user's choice) display images, and if graphical browsers display them as tooltips people will be discouraged from using them for their correct purpose. For more information about this, read Mozilla Bug 25537. In other words, it's up to the web developers to use the right HTML property for tooltips. If you are in doubt, read here for more information.

However, there is an extension that will enable the display of the alt property as a tooltip. You can install it from the Extensions page.

Mozilla's developers have no intention of changing Mozilla's and Firebird's behavior to display an image's alt attribute as a tooltip. Radio's radio.macros.imageRef () macro does not put a title attribute into the img tag it creates, nor does it give the user a way to supply one, so Mozilla and Firebird will not display a tooltip for an image displayed with the radio.macros.imageRef () macro.

There are a number of possible solutions to this issue, both for Radio Userland's programmers and for Radio's users.

Some options for Radio Userland's programmers:

1. Modify radio.macros.imageRef () to accept an optional title parameter. Within radio.macros.imageRef (), this title parameter should be passed to radio.images.imageRef (), which actually builds the img tag. Modify radio.images.imageRef () to accept an optional title parameter as well. Include the title attribute in the img tag output by radio.images.imageRef () if the title parameter is present.

2. Modify radio.images.imageRef () so that if an alt parameter is present, both an alt attribute and a title attribute are output. Use the text of the alt parameter as the value for both the alt and title attributes in the img tag. This would violate the spirit of what Mozilla's developers intend for web authors to do, but it does fix the problem.

An interesting note: Some of Radio's other macros (radio.macros.mailTo (), rssLink, radio.macros.xmlCoffeeMug (), for example), create a graphic link and supply a title attribute in the <a href> tag surrounding the img tag.  This is the same method as the next option described below.

Some options for Radio's users:

1. If the image in question is also a link (the img tag is surround by <a href>.....</a> tags), a title attribute can be added to the <a href> tag and Mozilla / Firebird will display the href's title attribute as a tooltip when the mouse hovers over the image.

Example:

Mozilla and Firebird will not display a tooltip using this code in your template:

<a href="LinkToSomePage.html"><%radio.macros.imageRef ("images/myImage.jpg" alt="This is tooltip text!")%></a>

Mozilla and Firebird will display a tooltip if this code is used:

<a href="LinkToSomePage.html" title="This is tooltip text!"><%radio.macros.imageRef ("images/myImage.jpg")%></a>

2. Replace <%radio.macros.imageRef ()%> in the template with different code that builds an img tag with a proper title attribute. One approach is to use the <%radio.macros.imageUrl ()%> macro instead.

Example:

Instead of using the radio.macros.imageRef () macro:

<%radio.macros.imageRef ("images/myImage.jpg" alt="This is tooltip text!")%>

Replace it with this code, using the radio.macros.imageUrl () macro:

<img src="<%radio.macros.imageUrl ("images/myImage.jpg")%>" border="0" width="130" height="150" title="This is tooltip text!">

A possible disadvantage to this approach is that radio.macros.imageUrl () macro will not automatically create a local copy of the image on your server.

3. Install the Popup ALT Attributes extension for Mozilla Firebird. (I do not know if this extension is available for Mozilla users.) This extension will force Firebird to display an image's alt attribute text as a tooltip. However, this only works for your browser. Other readers who visit your weblog with the Mozilla / Firebird browser and do not have this extension installed still will not see tool tips for images that have no title attribute.

I would prefer that Radio's programmers modify the radio.macros.imageRef () macro to support an optional title parameter (the first option I described). The programming is not that difficult. Users will then be able to generate img tags that conforms to standards, and their web pages will have the correct behavior in standards-compliant browsers such as Mozilla and Firebird.

This is part 3 in a series which explores Radio's problems in using the Mozilla Firebird browser on Radio startup and some possible solutions.

Parts in the series:
Introduction
Part 1 - Radio uses the default application to open ".htm" files
Part 2 - Radio does not parse the Mozilla Firebird command line correctly.
Part 3 - Radio does not use the correct DDE name to "talk" to Mozilla Firebird.

Part 3 - Radio does not use the correct DDE name to "talk" to Mozilla Firebird.

DDE (Dynamic Data Exchange) is a means for two programs to "talk" to each other - to pass commands, data, etc., back and forth between the two programs. When Radio starts up, it starts the default web browser and then uses DDE to tell the open browser window to open the url of the Desktop Website home page.

One of the parameters that is required in DDE is the DDE application name. The DDE application name is used to tell which DDE messages and commands an application should listen to and which ones it should ignore. If a DDE command is received by an application, but the DDE application name sent does not match the DDE application name that the application is listening for, that application will ignore the message.

Typically, the DDE application name is the same as the filename of the .exe (less the .exe), but this is not always the case. Radio assumes that the DDE application name is the same as the .exe file name, and this causes a problem in the case of Mozilla Firebird.

Mozilla Firebird's .exe name is "MozillaFirebird" (no space between the names), but its DDE application name is "Mozilla Firebird" (one space between the names).

Assuming that Radio can successfully start Mozilla Firebird (see parts 1 and 2), Radio tries to tell Mozilla Firebird via DDE to open the Desktop Website home page, using the DDE application name of "MozillaFirebird" in the communication. Since Mozilla Firebird is listening for the DDE application name of "Mozilla Firebird", it ignores all such DDE commands sent by Radio, and does not open any url at all.

There is no easy fix available to this behavior in Radio. The actual code in radio.root must be modified by Radio Userland via a radio.root update, or the user must modify the code on their own.

The code in question is within system.verbs.builtins.webBrowser.openURL:

case sys.os ()
  "MacOS"
    return (appleEvent (id, 'GURL', 'GURL', '----', string (s), 'cwin', openUrlIn))
  "Win95"
  "WinNT"
    if string.lower (id) contains \"netscape\"
      return (webBrowser.callBrowser (id, "WWW_OpenURL", s + ",,-1"))
    return (webBrowser.callBrowser (id, "WWW_OpenURL", s))

Radio is sending the DDE command to the browser in the webBrowser.callBrowser macro call. The "id" parameter is the DDE application name, "WWW_OpenURL" is the DDE command for the browser to open a specified url, and "s" is the url to open.

Mozilla Firebird needs a DDE command like Netscape's, but tailored for Mozilla Firebird. I would change the above code by adding two lines so that it looks like the following:

case sys.os ()
  "MacOS"
    return (appleEvent (id, 'GURL', 'GURL', '----', string (s), 'cwin', openUrlIn))
  "Win95"
  "WinNT"
    if string.lower (id) contains \"netscape\"
      return (webBrowser.callBrowser (id, "WWW_OpenURL", s + ",,-1"))

    if string.lower (id) contains "firebird"
      return (webBrowser.callBrowser ("Mozilla Firebird", "WWW_OpenURL", s + ",,-1"))

    return (webBrowser.callBrowser (id, "WWW_OpenURL", s))

If this change is being made by the user, don't forget to click the "Compile" button after making this change.

Once this change has been made, Radio can then successfully use DDE to tell an open Mozilla Firebird window to open a url (like the Desktop Website home page).

Without this change, it is impossible for Radio to communicate with an open Mozilla Firebird browser window. The only apparent option left to the user in this case would be to set Mozilla Firebird's home page to the Desktop Website home page. When Radio starts, the browser would open, and Mozilla Firebird would open the Desktop Website home page on its own - *not* because Radio told it to do so.

Return to Introduction.....

This is part 2 in a series which explores Radio's problems in using the Mozilla Firebird browser on Radio startup and some possible solutions.

Parts in the series:
Introduction
Part 1 - Radio uses the default application to open ".htm" files
Part 2 - Radio does not parse the Mozilla Firebird command line correctly.
Part 3 - Radio does not use the correct DDE name to "talk" to Mozilla Firebird.

Part 2 - Radio does not parse the Mozilla Firebird command line correctly.

When Mozilla Firebird is registered as the default Windows web browser, this is the command line that is registered for ".htm" files:

C:\PROGRA~1\MOZILL~1\MOZILL~1.EXE -url "%1"

Your path may vary from the above, depending on where you installed Mozilla Firebird. The above path is the equivalent DOS 8.3 short path and file name for

C:\Program Files\MozillaFirebird\MozillaFirebird.exe -url "%1"

Before Radio attempts to launch the default web browser, it tries to strip any parameters in the command line so that only the path and filename of the .exe file remain. Unfortunately, Radio does not do this correctly for this particular command line.

In looking for parameters to remove, Radio recognizes "%" characters, "/" characters, and quote characters (") as possible parameter identifiers. Radio does not recognize "-" (dash) characters as a possible parameter identifier.

When Radio strips the parameters from the Mozilla Firebird command line, this is what Radio comes up with:

C:\PROGRA~1\MOZILL~1\MOZILL~1.EXE -url

Radio then tries to locate this file name ("MOZILL~1.EXE -url") before launching it so that if the file is not there, Windows will not throw an error. There is no file with that name on the hard drive, so Radio shows the user a File Open dialog box, with "MOZILL~1.EXE -url" in the File Name box. The user selects the MozillaFirebird.exe file and clicks "Open", which gives Radio the correct name of the .exe file without the "-url" after it.

Radio also recognizes that if a path and file name are enclosed in quotes, that this quoted string is the entire path and file name and does not look any further. This provides the user with a good way to work around this bug.

In Windows Explorer (Windows XP), on the menu, click Tools, Folder Options. Click on the "File Types" tab. Scroll down through the list of extensions until you find "HTM". Click on "HTM" to select it. Click on the "Advanced" button, select the "open" action, click the "Edit" button, and enter the following command line in the "Application used to perform action:" box:

"C:\Program Files\MozillaFirebird\MozillaFirebird.exe" -url "%1"

The long file name should be used in this instance. If quotes are placed around the DOS 8.3 short path and filename, Windows recognizes that they are not necessary and will remove them.

A script set up as I described in Part 1 also gets around this bug by storing the correct path and file name (without the "-url") in user.webBrowser.winDefaultBrowserApp.

Continue to Part 3.....

This is part 1 in a series which explores Radio's problems in using the Mozilla Firebird browser on Radio startup and some possible solutions.

Parts in the series:
Introduction
Part 1 - Radio uses the default application to open ".htm" files
Part 2 - Radio does not parse the Mozilla Firebird command line correctly.
Part 3 - Radio does not use the correct DDE name to "talk" to Mozilla Firebird.

Part 1 - Radio uses the default application to open ".htm" files.

Radio stores the command line to the .exe of the browser it will use in radio.root at user.webBrowser.winDefaultBrowserApp. The user can change this value while Radio is running, but this change is lost when Radio is restarted.

This is because on every startup, Radio reads the Windows registry and gets the command line of the application registered to open ".htm" files. Radio then overwrites any value stored in user.webBrowser.winDefaultBrowserApp with the command line read from the registry.

The user has a number of ways to resolve this issue:

A. Set Mozilla Firebird to be the default Windows browser.

In Mozilla Firebird, on the menu, click Tools, Options. Click on the "General" tab/button on the left. Click on the "Set Default Browser" button.

This option sets Mozilla Firebird to be the default application to open many different file types besides ".htm" files. If the user does currently wish to set Mozilla Firebird to be the Windows default web browser, this will not be an acceptable solution.

B. Set Mozilla Firebird to be the default application to open ".htm" files.

Edit the file type for ".htm" files in Windows Explorer and set Mozilla Firebird to be the default application to open just that specific file type.

In Windows Explorer (Windows XP), on the menu, click Tools, Folder Options. Click on the "File Types" tab. Scroll down through the list of extensions until you find "HTM". Click on "HTM" to select it. Then click on the "Change" button and set Mozilla Firebird as the default application. Or click on the "Advanced" button, select the "open" action, click the "Edit" button, and set Mozilla Firebird as the default application.

C. Use a startup script to set the command line of the browser the user wishes to use.

Immediately after Radio reads the Windows registry and updates user.webBrowser.winDefaultBrowserApp, Radio then does a callback to run all user startup scripts located in user.callbacks.startup.

If a script that changes the value of user.webBrowser.winDefaultBrowserApp (or the address of such a script) is added to user.callbacks.startup, the value written by this script will be the one Radio uses to open the Desktop Website on startup. Since this value will be written last, it will be the value that stays.

The script doesn't have to be complicated at all. Add a new script under user.callbacks.startup and call the script "setDeafultBrowser". In the script window, use the following code:

on setDefaultBrowser ()
  if (system.environment.isWindows)
    user.webBrowser.winDefaultBrowserApp = 
        "C:\\Program Files\\MozillaFirebird\\MozillaFirebird.exe"
bundle // test
  setDefaultBrowser ()

The backslashes in the path name do require double backslash.

Click the Compile button after the code has been entered. If you want to set the default browser without having to restart Radio, click the Run button.

When Radio is restarted, Radio will still read the registry and overwrite the value stored in user.webBrowser.winDefaultBrowserApp, but now this script will come in right after it and change it back.

Each of these options has its advantages and disadvantages; use whatever option you are most comfortable with and bests suits your needs.

Continue to Part 2.....

I've finally gotten around to downloading the new Mozilla Firebird browser and started to play with it. A small problem I've run into (which other Radio users have run into as well) is getting Radio to use the Mozilla Firebird browser and load the Desktop Website in it on Radio startup.

There are actually three separate issues that prevent Radio from performing this seemingly simple task. This post is the introduction to a three part series which explores some of the ways each of these issues can be addressed.

These posts will be mostly of interest to Windows users, but there is some information that may be applicable to other operating systems.

Parts in the series:
Introduction
Part 1 - Radio uses the default application to open ".htm" files
Part 2 - Radio does not parse the Mozilla Firebird command line correctly.
Part 3 - Radio does not use the correct DDE name to "talk" to Mozilla Firebird.

Continue to Part 1.....

Just got nice jolt here at the house about 5 minutes ago. My table lurched sideways and hit my chair. A good scare, but no damage here. You can see the quake on a map by clicking on the "SF Quake Map" in my sidebar.

Details of trackback bug #2

I believe I have identified the code that causes the trackback error I wrote about in my previous post. If you're interested in the details, check out my post in the Radio Userland category.

This post details how and why the trackback bug described in my previous post ("Trackback bug - Trackback fails when post is not published to home page") occurs.

If you look at the structure of weblogData.posts.[postNum].trackback.outbound.urls, it is apparent that the names of the subtables are urls. The tables listed under weblogData.posts.[postNum].trackback.inbound.urls should be the same way - the names of the subtables should be urls as well.

The error message that is being received:

Can't create item "radiocommentsManilaWebsite.#newsSite.radioHosting.trackback.users.
0127252.114.trackback.inbound.urls." because "" is an illegal name.

...would seem to indicate that a new subtable under inbound.urls is trying to be created with a name (url) of "" (null or empty string).

An outbound trackback ping requires 5 parameters - the trackback url to be pinged, the title of the post originating the trackback ping, the url of the post originating the trackback ping (permalink), an excerpt of text from the originating post, and the title of the weblog.

When a post is published with a link that can be pinged by Radio's trackback, and this post is not published to the "Home Page" (main weblog), Radio is not determining the permalink url correctly - it is sending an empty permalink url string. When such a trackback ping is sent to a Radio weblog, Radio's trackback servers can't create an inbound.urls table entry on Radio's trackback servers with an empty name (url). Apparently, the trackback table structure on Radio's trackback servers is similar to the table structure on a local Radio installation. The only thing Radio's trackback servers can do is report the error shown above.

This is how the error occurs:

1. When a post is published, processing of trackbacks is started with a call to
system.verbs.builtins.radio.weblog.builtinCallbacks.publishItem.trackback.

2. Within the above callback, a call is made to system.verbs.builtins.radio.trackback.threadScript.

3. Within the above thread script, a call is made to system.verbs.builtins.radio.trackback.ping for each url that Radio has determined it can send a trackback ping to.

4. The overall purpose of radio.trackback.ping is to get the 5 parameters necessary to perform an outbound trackback ping and pass them to system.verbs.apps.trackback.ping (the code which actually performs the trackback ping).

In the code for radio.trackback.ping, the permalink url parameter is initialized:

local (url = "")

...then radio.weblog.getUrlForPost (adrpost, @url) is called to get the permalink url of the post.

5. This is the initial line of code from radio.weblog.getUrlForPost:

on getUrlForPost (adrpost, adrurl, catname="", adrdata=radio.weblog.init ())

Note that radio.weblog.getUrlForPost takes a category parameter (catname), and if one is not supplied, the default value of "" is used. radio.trackback.ping does not pass a category parameter, so the value of "" is always used for catname when this macro is called from radio.trackback.ping.

6. Near the beginning of radio.weblog.getUrlForPost, this code is encountered:

if catname == "" //get the weblog archive relative folder path
  if adrpost^.flNotOnHomePage //post is not in weblog archive
    return (false)

This code is where the bug is most apparent:

A. catname is always "" (no category) when called by radio.trackback.ping, so the first if statement is true and the next statement is executed.

B. In the case we are interested in (a post that is not published to the "Home Page" and has links that Radio will send trackback pings to), flNotOnHomePage for that post is true by definition. The second if statement is true and the next line of code is executed.

C. radio.weblog.getUrlForPost returns a value of false to radio.trackback.ping, and the url permalink parameter (adrurl in this macro's code) is never changed from its original value of "".

7. On return from radio.weblog.getUrlForPost, radio.trackback.ping takes the five trackback parameters it has gathered (including the still empty url permalink parameter) and passes them to system.verbs.apps.trackback.ping to perform the ping. Radio's trackback servers throw the error described above when they try to create a new table entry with the empty url permalink parameter as a name.

The difficulty I see here in fixing the trackback code is determining a single permalink url to use when a post is not published to the "Home Page" and the post is published to multiple categories.

Another trackback bug discovered

| 1 Comment

I've posted some information in my Blogging category about what I believe is another bug in Radio's trackback.

The nature of the bug is this: If a post is published with links that Radio will send a trackback ping to, but the post is not published to the home page, the trackback pings silently fail. In the post's outbound trackback url data in weblogData.root, an error message of this type is recorded:

Can't create item "radiocommentsManilaWebsite.#newsSite.radioHosting.trackback.users.
0127252.114.trackback.inbound.urls." because "" is an illegal name.

You can see examples of this error here and here.

Possible workaround: When first publishing a post, publish the post to the home page as well as any categories that you want to route a post to. After Radio has published the post and pinged the appropriate trackback urls, edit the post to remove it from the home page and re-publish. (This workaround is untested.)

(Hat tip to Lisa at distant, early morning for her assistance in the discovery of this bug.)

Update 04-Sep-2003: Based on what I determined to be cause of this error, the workaround I describe above will not work. If the "Home Page" (main weblog) is checked along with a category, the outbound trackback will display a link to the "Home Page" post. When the post is removed from the "Home Page" and re-published, the previously sent trackback link to the "Home Page" post is then broken because that post is no longer present on the "Home Page".

Lisa (distant, early morning) posted about problems she was having with Radio's trackback in Radio UserLand's discussion forum ("trackback? what'am i doing wrong?", "trackback really hates me, error message", and "TrackBack error persisting").

There were multiple issues present, which I believe have been resolved except for one. In a number of her posts, this error is recorded in weblogData.posts.[postNum].trackback.outbound.urls.[url].errorstring:

Can't create item "radiocommentsManilaWebsite.#newsSite.radioHosting.trackback.users.
0127252.114.trackback.inbound.urls." because "" is an illegal name.

(User number 127252 is my Radio user number - in this particular post, Lisa linked to post #114 in my weblog.)

Lisa encountered this error a number of times, but this error appeared intermittently so its cause did not appear to be easy to determine. It is not easy to look at trackback errors across a number of posts, so I wrote a macro to dump a list of all posts with trackback error messages and some detail about those posts.

This macro is available at this link: trackbackErrors.txt

Recommended usage: Place the trackbackErrors.txt file in your /www/system/pages directory and browse to http://127.0.0.1/system/pages/trackbackErrors to view the report.

trackbackErrors.txt can also be placed in the /www directory. The file will be rendered, upstreamed, and the report will then be viewable by the public.

Lisa downloaded the trackbackErrors.txt file and ran it on her weblog. She has also placed trackbackErrors.txt in a rendered directory, so that it is viewable to the public as well. Her trackbackErrors report can be viewed here.

The trackback errors report for Lisa's weblog makes it easy to see what was common in every post where she receives this error: The post is not published to the "Home Page" (flNotOnHomePage is true).

I have a link to this report for my weblog as well. It can be viewed on my weblog here.

I have two occurrences of the above error, and they both occur in a post that was not published to the "Home Page".

It would appear that there is a problem with trackback pings if a post is not published to the "Home Page".

Lisa has reported our findings on Radio's forums, and I have reported this apparent bug to the Yahoo radio-dev mailing list.

Beth at Mutated Monkeys was wondering if she should bother to keep paying into her retirement account, based on a comparison of the odds of winning the lottery to the odds of the earth being hit by a giant asteroid in 2014. I e-mailed some comments to Beth and she has added them to her post.

I really don't know what to make of this. On both Google and Yahoo Search, this blog is the #3 search result on the word "tweezer". Cool or weird? You be the judge.

Update 03-Sep-2003: A search for "tweezerman" puts me at #4 on Google and #3 on Yahoo Search.

Monthly Archives macro - Bug Fix

Fixed Home Page archive links bug that caused macro to not correctly determine if a month has posts. (Incorrectly used nameOf instead of indexOf to get index number for post.) To get the update, download the new version of the macro and follow the directions to install the new version over your old one.

Lawrence Lee at Radio Userland posted an excellent tip in Userland's forums today, in response to Lisa's question about customizing the #template.txt file differently for her weblog and her Desktop Website:

How do I customize the appearance of pages in the Desktop Website?

You can customize the desktop website home page by editing the template from the preferences page. But you can also change the appearance of the news, preferences and other desktop website pages by placing a #template.txt in the /www/system/ folder.

Note: This won't be applied to the Folder view pages on the desktop website.

Trackback bug and workaround

I've posted some detailed information in Radio Userland's forums about what I believe is a bug in Radio's implementation of trackback.

The nature of the bug is this: When a post is first published with links that Radio will send a trackback ping to, sometimes those pings are not successful on the first attempt. If the post is re-published, Radio never attempts to re-ping those failed trackback urls again.

Workaround: In weblogData.root, find the failed trackback ping data in
weblogData.posts.[postNumber].trackback.outbound.urls.[failedUrl]. Change the value of the flPinged field from true to false, then re-publish the post to force Radio to re-attempt a trackback ping.