After it being stuck syncing for hours and 2 out of control cpu processes (bird and cloudd) causing a blazing cpu fan for hours I decided to cancel it, which didn't go smoothly but after manually killing the 'bird' process and a few reboots it was finally disabled.

Only now the problem was my desktop was empty and all my documents were gone. As it turns out, when you enable iCloud sync it moves all your desktop and documents files to the iCloud drive, and then points the original 'Desktop' and 'Documents' folder to the iCloud folders. But when you disable iCloud sync it does not put anything back, it just leaves all your files in the iCloud drive and then creates new empty 'Desktop' and 'Documents' folders in the original location so you have to manually drag your files back from the iCloud drive to your desktop and documents folder.

earlier post

You may notice now that it is possible to post comments again but there is no CAPTCHA nor any spam. Here I will explain my new solution for preventing spam and how to do it:

Comment spam protection in less than 10 lines of JavaScript

The actual code, followed by an explanation below:

$(document).ready(function() {
	SPAM_BE_GONE = setTimeout(function() {
		$('#commentform').attr('action','###ACTION_URL###');
	}, 5000);
});

Basically what I have done removed ###ACTION_URL### from the <form> tag in the ve_guestbook template and then used the JavaScript code above to put it back in after 5 seconds when the page is loaded. This makes spam bots enter the site and submit a comment to the wrong url. In order for spam bots to bypass this they would actually have to parse JavaScript and wait 5 seconds, which I doubt will happen.

By the way, in the code above I made use of the jQuery library but it could have been done without that just as easy. Basically all you are doing is setting a timer and changing an attribute, wether its done in jQuery, protoype, yui or plain JavaScript is up to you.

You can view the source of this page to see what the code looks like after the template has been parsed.

After doing some testing I discovered that the mouse wheel scrolling would only work when the mouse cursor was hovering the text in the div tag. When the mouse cursor was hovering just some white space above or below a paragraph the scroll wheel refused to work.

At first I thought this issue was caused by FleXscroll which is a piece of javascript which I use to customize the design of scrollbars, but after disabling FleXscroll the issue remained and after doing some more testing I discovered that this bug would only occur when the page was rendered in standards-compliant-mode. After removing the DOCTYPE and thus triggering quirks-mode, the bug was gone and everything worked fine except that my page looked like shit since everyone knows quirks-mode is the root of all evil.

So I put the DOCTYPE back in and tried to figure out some other way to fix this issue. Since the scrolling would only work when the cursor was hovering some text I thought that maybe it just needs to hover something, even if that something looks like nothing (you're thinking: what?!), so I added "background: #ffffff" to the style of the div tag and guess what? Problem solved.

Checkout this page demonstrating the bug which contains to similar content items, the only difference is the background property. If you use Internet Explorer you will notice that you cannot scroll one of the items with the mouse wheel unless your mouse cursor is over some part of the text.

This bug occurs in Internet Explorer 7 and possibly lower versions too.

As it turns out, it's not so hard to do this. Basically all that needed to be done was:

• Insert one of the standard TYPO3 form elements on a page (login or mail form for example)
• Include the script and stylesheet as provided on A List Apart
• Open the page in the front end and check the source to see which attributes and values are used for the HTML form elements.
• Create your own form as described on A List Apart but use the properties/values TYPO3 uses.
• Apply the form you just created to the TYPO3 FORM object through TypoScript

I've tried it with the login form as you can see on the right side of this page. Here's how:

Insert TYPO3 Form element

Just as you would normally do, nothing special here, just check if it works before you continue.

Include the script and stylesheet

Get the script and styles from A List Apart and include them on your page.

page.includeJS.file001 = fileadmin/newdesign/form.js
page.includeJS.file001.type = text/javascript

page.includeCSS.file001 = fileadmin/newdesign/form.css
page.includeCSS.file001.media = screen

Get the properties/values from the source

In my case for the login form the properties used were user for the username and pass for the password. There was one hidden element with the property logintype and value login, the TSref explains you change this value to logout to create a logout form. The last property was submit with value Login for the submit button.

Create your own form

Do this as described on A List Apart but use the properties and values from the previous step. It's not necesarry to include the <form .. > </form> tags.

<div id="username">
 <label for="user" class="overlabel">Username</label>
 <input id="user" type="text" name="user" title="Username" value="" tabindex="1" />
</div>
    
<div id="password">
 <label for="pass" class="overlabel">Password</label>
 <input id="pass" type="password" name="pass" title="Password" value="" tabindex="2" />
</div>
    
<div id="submit">
    <input type="hidden" name="logintype" value="login" />
    <input type="submit" name="submit" value="Login" tabindex="3" />
</div>

Apply the form through TypoScript

The TypoScript Object Browser can be used to find where FORM object is used for the forms that can be inserted (tt_content.login.20, tt_content.mailform.20 etc).

tt_content.login.20 {
    formName = login
    data >
    dataArray >
    stdWrap.wrap (
        <div id="username">
         <label for="user" class="overlabel">Username</label>
         <input id="user" type="text" name="user" title="Username" value="" tabindex="1" />
        </div>
            
        <div id="password">
         <label for="pass" class="overlabel">Password</label>
         <input id="pass" type="password" name="pass" title="Password" value="" tabindex="2" />
        </div>
            
        <div id="submit">
            <input type="hidden" name="logintype" value="login" />
            <input type="submit" name="submit" value="Login" tabindex="3" />
        </div>
    )
}

Done

Reload the page in the front-end to see the changes. Besides the login form on this website I have also have a contact form but the technique I have used for that one is a bit different and I'll probably change it to this one soon. There is one thing by the way that I have not been able to fix yet, TYPO3 automatically adds target="_top" to the <form> tag, which ofcourse is not allowed by the strict doctype so your site will not pass the validors.

Sounds pretty good right? So I tried it out and as you can probably see it works pretty good, the titles of the articles on this site are now using the Share font.

Lets try it

One of the downsides of sIFR is that you need to have Flash 8 installed to embed the font into the flash file so it can be used on the site, so if you don't have that you're a bit stuck unless there are other applications that can do the same.

First download the sIFR3 source package, I downloaded the latest nightly build but you can also check out any other version.

Read the documentation to make the required changes or download the files below and use them instead of the source package.

Files

All the files and changes needed to make it work are:

share.swf - the flash file with the Share font embedded
sifr-config.js - to configure which font to use for what
sIFR-screen.css - configure what to hide when sIFR is active (below line 48)
sIFR-print.css - no changes needed in this file
sifr.js - no changes need in this file

TypoScript

I placed the files above all in /fileadmin/sifr/ and then used some TypoScript to load sIFR:

# sIFR configuration
page.headerData.10 = TEXT
page.headerData.10.value = <script src="/fileadmin/sifr/sifr.js" type="text/javascript"></script>
page.headerData.20 = TEXT
page.headerData.20.value = <script src="/fileadmin/sifr/sifr-config.js" type="text/javascript"></script>

page.includeCSS.file003 = fileadmin/sifr/sIFR-screen.css
page.includeCSS.file003.media = screen
page.includeCSS.file004 = fileadmin/sifr/sIFR-print.css
page.includeCSS.file004.media = print

In the end, I think it works better then using TYPO3/ImageMagick to render custom fonts inside an image because search engines and screen readers will just see the regular HTML headers which they can handle better than generated images and with sIFR you are still able to select/copy the text (impossible with an image).

TYPO3 extension (gb_sifr)

After writing this article I found out that there is an extension that apparently allows you to use sIFR inside the Rich Text Editor by using custom tags, I haven't tried it out but it could be useful.

It seems that manually putting pre tags around my snippets wasn't doing the job. What I had to do was change the following setting:

RTE.default.hidePStyleItems = pre,address

to:

RTE.default.hidePStyleItems = address

So by removing pre from hidePStyleItems I could actually select my code snippet in the editor and select Preformatted from the list of paragraph types (where it was not shown before changing the setting), this way the code snippet is shown perfectly in the front-end.

Now all that was left was to give the pre tag some nice style:

pre {
 font-family: "Lucida Console", "fixedsys", sans-serif;
 font-size: 12px;
 padding: 5px;
 border: 1px solid #dedede;
 background-color: #f9f9f9;
 color: #a22100;  
 overflow: auto;
}

There you go, code snippets shown properly.

Update Jan 8, 2007:

To make it show almost exactly the same in the back-end as in the front-end, I moved the css code for pre to a different stylesheet called rte.css, I then included this stylesheet in both the PAGE object (page.includeCSS.file002 = fileadmin/rte.css) and the RTE configuration (RTE.default.contentCSS = fileadmin/rte.css).

Enabling this feature turned out to be fairly simple. Just install sr_freecap, which is an extension for TYPO3 that can generate the CAPTCHA fields. The guestbook extension (ve_guestbook) which is used for comments has support sr_freecap by default, so the only thing you need to do is update the guestbook template used by TIMTAB (default is: EXT:timtab\res\kubrick\kubrick_ve_guestbook.tmpl).

Update the template by adding the following lines:

<!--###CAPTCHA_INSERT### this subpart is removed if CAPTCHA is not enabled! -->
    <p>
        <input type="text" name="tx_veguestbook_pi1[captcha_response]" title="###SR_FREECAP_NOTICE###" value="" />
        <label for="email">
            <small>
                ###SR_FREECAP_NOTICE### ###SR_FREECAP_CANT_READ###
            </small>
        </label>
        <br />
        <br />
        ###SR_FREECAP_IMAGE###
    </p>
<!--###CAPTCHA_INSERT###-->

That's it! Your blog is now protected from comment spam.

Problem 1: Background images not being displayed

This seemed to be caused by the path defined wrong for the background images in the default kubrick template, so this was fixed by redefining the paths in TS setup like below:

page {
CSS_inlineStyle (
    body { background: url(../{$page.file.kubrickbgcolor}); }
    #page { background: url(../{$page.file.kubrickbgwide}) repeat-y top; border: none; }
    #header { background: url(../{$page.file.kubrickheader}) no-repeat bottom center; margin: 0 !important; margin: 0 0 0 1px; padding: 1px; height: 198px; width: 758px; }
    #headerimg { margin: 7px 9px 0; height: 192px; width: 740px; }
    #footer { background: url(../{$page.file.kubrickfooter}) no-repeat bottom; border: none;}
    )
}

Problem 2: Comments being displayed with the wrong template

With the default configuration it seems that the HTML template defined for the comments (ve_guestbook) refers to the default ve_guestbook template instead of the kubrick comments template. By simply redefining it like below in TS setup the problem is solved:

plugin.tx_veguestbook_pi1 {
    templateFile = EXT:timtab/res/kubrick/kubrick_ve_guestbook.tmpl
}

TIMTAB development blog

Other than the two issues mentioned above TIMTAB seems to be working nice so far. For more information regarding TIMTAB check out the author's blog at: http://www.ingo-renner.com/index.php?id=timtab.