This is what it looks like:

1. HTML

<div class="switch">
  <label for="mycheckbox" class="switch-toggle" data-on="On" data-off="Off"></label>
  <input type="checkbox" id="mycheckbox" />
</div>

The element containing the checkbox and the label should have the class switch assigned. The label element needs the class switch-toggle as well as the data-on and data-on attributes to define the label texts for the two statuses.

It is important that the .switch element contains only one checkbox and that the checkbox and the label are direct children of the .switch element.

2. CSS

label.switch-toggle {
    background: url('switch.png') repeat-y;
    display: block !important;
    height: 12px;
    padding-left: 26px;
    cursor: pointer;
    display: none;
}
label.switch-toggle.on {
    background-position: 0px 12px;
}
label.switch-toggle.off {
    background-position: 0px 0px;
}
label.switch-toggle.hidden {
    display: none;
}

Don’t forget to download the switch.png file.

3. jQuery

$(document).ready( function(){ 
    $('.switch').each(function() {
        var checkbox = $(this).children('input[type=checkbox]');
        var toggle = $(this).children('label.switch-toggle');
 
        if (checkbox.length) {
            checkbox.addClass('hidden');
            toggle.removeClass('hidden');
            if (checkbox[0].checked) {
                toggle.addClass('on');
                toggle.removeClass('off');
                toggle.text(toggle.attr('data-on'));
            } else {
                toggle.addClass('off');
                toggle.removeClass('on');
                toggle.text(toggle.attr('data-off'));
            };  
        }   
    }); 
 
    $('.switch-toggle').click(function(){
        var checkbox = $(this).siblings('input[type=checkbox]')[0];
        var toggle = $(this);
 
        // We need to inverse the logic here, because at the time of processing,
        // the checked status has not been enabled yet.
        if (checkbox.checked) {
            toggle.addClass('off');
            toggle.removeClass('on');
            toggle.text(toggle.attr('data-off'));
        } else {
            toggle.addClass('on');
            toggle.removeClass('off');
            toggle.text(toggle.attr('data-on'));
        };  
    }); 
});

Yes, I violated the DRY principle, but the logic works, so that’s good enough for now

Credits: The image used was taken from the Heise’s socialshareprivacy plugin which I’m also using on this blog.

(Sorry about forgetting to switch Diaspora to English…)

List of similarities

1. Avatar and first name in upper left corner
2. “Stream” and a textbox with some icons (image upload) above the main column
3. Avatar and full name in the header bar
4. List of contact avatars in upper right corner
5. Invitations below contact list
6. Aspects/circles on the left, right below the name
7. Tags/sparks below the aspects/circles
8. Display of receiver limiting next to the post

Well…

I’m not saying Google copied Diaspora, especially as many of those things are common and obviously chosen web design elements, but Google+ certainly looks strongly inspired by Diaspora, which – as far as I remember – didn’t change much of its layout over the last year or so.

Also, many ideas/philosophies behind Google+ that make it successful are almost identical to those of Diaspora. The concept of circles/aspects, the focus on sharing which information with whom, the concept of “unidirectional relationships” (following without being followed) etc…

Opinions?

I came up with a few must-have criteria for a good software project website:

On the very first page, state what the software does, and what the goal of the project is.

More than once, I’ve seen project websites about a software, that provide downloads and how-tos and everything else, but don’t even explain what the software does. If I hear about a software and open the website, the first thing I want to know is what the software can be used for. If I can’t find that information quickly, I lose interest.

Provide Screenshots in the main navigation

Whether you like it or not, what many users care for are screenshots. Feature lists are great, but when you see some screenshots of the program in action, you get the general Idea how it works and how user-friendly it has been designed. Great features are useless if the UI sucks.

Put the download section in the main navigation

The second most important thing on a project website is the link to the download section. It should be visible on every page, and it should provide quick, easy download possibilities. Also, redirected downloads suck. Direct (and therefore wget-able) downloadlinks are better.

Provide documentation

What users want and developers hate, is documentation. Great documentation can contribute to great success. A good example of this is the area of software frameworks. A lot of frameworks (like CodeIgniter, CakePHP and jQuery) are highly successful – not least because of the great and easy-to-understand documentation. Provide good documentation and don’t forget to share it with others. The users will thank you.

Provide a way for feedback

Many open source projects grew over time because of user feedback. User feedback is important. And it needs to be quick and easy. A registration for an issue tracker is a no-go for me. If I have to register, I don’t report. Allow anonymous bugreports and feature requests, and a lot more feedback will come in.

For OSS projects: Provide easy possibilities to participate and share code

Among software users, there are many great and capable programmers. Many of them have great ideas for contributions they could make. Most of them don’t have the time and motivation to track down the owner of the source repository and to ask for the permission to contribute. And patches that can’t be shared aren’t fun. Provide an e-mail address to send in patches. Or even better, use a distributed source code management system like Git. And then host it on a platform like Github, so that users can easily contribute their changes to the main branch, without you having to manage tedious permissions.

Stay in touch with the users

Communicate. And provide information on how to reach you on all available communication channels, like e-mail, IRC, twitter, facebook, forums etc. The more there are, the better. Inform the users about updates, but don’t spam them (use newsfeeds or social networks). And answer all not-totally-stupid questions. If you communicate, and if your software rocks, users will turn into fans.

A majority of the mentioned issues should be known to most people releasing software, but apparently aren’t. The project website is the first contact with the “outer world” and in most cases best way to promote your software. Use it, don’t waste this potential.

There are probably several other important things to remember when creating a project website. The listed ones are just some important issues that came to my mind, the list is by no means complete. You are free to contribute your experiences in the comment box.

To change table column encoding:

ALTER TABLE artists
CHANGE [fieldname] [fieldname] [fieldtype]
CHARACTER SET [encoding]
COLLATE [collation];

To change table encoding:

ALTER TABLE [tablename]
CONVERT TO CHARACTER SET [encoding]
COLLATE [collation];

To change database encoding:

ALTER DATABASE [dbname]
CHARACTER SET [encoding]
COLLATE [collation];

Hier nochmal der “Gewinnerstring”:

/^([\w\!\#$\%\&\'\*\+\-\/\=\?\^\`{\|\}\~]+\.)*[\w\!\#$\%\&\'\*\+\-\/\=\?\^\`{\|\}\~]+@((((([a-z0-9]{1}[a-z0-9\-]{0,62}[a-z0-9]{1})|[a-z])\.)+[a-z]{2,6})|(\d{1,3}\.){3}\d{1,3}(\:\d{1,5})?)$/i

• __construct(): Konstruktor
• __destruct(): Destruktor
• __call(string name, array argumente): Aufruf bei unbekannter Objektmethode
• __callStatic(string name, array argumente): Aufruf bei unbekannter Klassenmethode
• __get(string name): Lesender Aufruf bei unbekannter Eigenschaft
• __set(string name, mixed wert): Schreiender Aufruf bei unbekannter Eigenschaft
• __isset(string name): Aufruf bei Verwendung von isset()
• __unset(string name): Aufruf bei Verwendung von unset()
• __sleep(): Aufruf bei Verwendung von serialize()
• __wakeup(): Aufruf bei Verwendung von unserialize()
• __toString(): Aufruf bei echo
• __clone(): Aufruf bei Klon-Vorgang

Quelle: PHP Kurzreferenz von Comelio GmbH

As you may have noticed, I wrote “should”. Although the search string was exactly the same as the title of the blogpost that I was looking for, there was no match.

I echoed the issued SQL query from the plugin and queried it directly in the database. Unfortunately, I got the following SQL error:

ERROR 1191 (HY000): Can't find FULLTEXT index matching the column list

Apparently there was some index missing. After some googling, I was able to fix the problem by issueing this query:

ALTER TABLE wp_posts ADD fulltext(post_title, post_content);

I’m not sure if that’s the right way to solve the problem, but the plugin seems to be working again.

• Custom Post Types in WordPress 3.0
• How to Add Your Plugin to the WordPress Plugin Directory
• BLANK WordPress Theme
• WordPress functions.php Template with 15 Essential Custom Functions
• 5 tips for using AJAX in WordPress
• WordPress Admin Toolbar Bookmarklet