commentfield-150x150

Adding Input Fields To Comment Form

Most comment forms contain the same input fields: Name, Email, URL and the comment text field. This is sufficient for most use cases but there are situations where you might want to know a bit more about your commenter: their age, the city they live in, or the color of their underwear. This article explains how to add an input field, store the data in the database and how to display the additional data in your blog if your theme uses the comment_form() function provided by WordPress. Continue reading …

Comment Form Hooks Visualized

Most themes (e.g. TwentyTen) use the comment_form() function to insert the comment form after posts. There are quite some hooks inside the function but they are hard to localize. The codex documentation isn't too helpful, neither.
To give you an easy overview the following diagrams visualize the points where the various hooks are anchored. The number of available hooks depend on the discussion settings and the user's capabilities.

In the most common scenario the user is not logged in, is allowed to comment on the article and the comments are not closed:

There are six hooks available:

  • comment_form_before
  • comment_form_top
  • comment_form_before_fields
  • comment_form_after_fields
  • comment_form
  • comment_form_after

You might have noticed that the hooks comment_form and comment_form_after seem to be anchored almost at the same point but depending on the user's role and discussion settings they are not always available so you should take care which hook you are using in your code.


User logged in
If you are logged in you have fewer hooks available since the name, email and URL input fields are not needed. The missing hooks are

  • form_comment_before_fields
  • form_comment_after fields


User is not logged and "Users must be registered and logged in to comment" activated
If your blog is configured that only registered users can comment, an unregistered user will see this comment form and additionally the hook comment_form_must_log_in_after is available. Please notice that in this case the hook comment_form is left out.


Comments closed
If the comments on the post are closed you have only one hook left (comment_form_closed) since the form is not displayed at all:

php-Console with Chrome and WordPress

Google Browser Chrome and their Chromium project are becoming more popular. Initially it was the speed of Chrome, which made it so popular but now also the extensions are getting in the focus of the users. Nowadays the extension market of Chrome is full of very useful extensions. Of course there are also many enhancements in the context of web development that have helped Firefox to fame.

In the field of PHP development, I've always looked at several solutions, played with different options and in the end I'm sitting in front of a browser with IDE, XDebug or some of my own extensions. In Firefox I have used FirePHP in various areas, more information about it can be found in this article. Alternatively I also wrote about the debugConsole. Therefore it was natural to browse for a solution in the environment of Chromium. You will be able to find some interesting topics about it and I would like to introduce php-console and show how to integrate it in WordPress via Plugin.
Continue reading …

WordPress-Christmas-2010-18

Category And Archive Dropdown With Unobtrusive JavaScript

A good website works when a user comes along with JavaScript disabled, just as well as with scripting enabled. You separate the JS layer of the site from anything else (and waived for example, onclick in HTML) and places the scripts in a way that only improves the already existing functionality of the site. So the visitors can navigate through the website with and without JS, even though it might be a little more difficult or less attractive without scripting. This approach to scripting on sites is called Unobtrusive JavaScript. Jenn Lukas gives in this talk at the JSConf 2010 reasons why it's a good thing. Besides all the good reasons, the main argument for unobtrusive JavaScript that is to be implemented with appropriate planning so easily that it would be a wasted potential if you would without it. The problem can be alone if the used CMS makes problem - which brings us to WordPress.

Occasionally you like to have in your blog sidebar drop down menus (select-elements) to navigate the categories and the archive and the WordPress Codex provides the documentation and appropriate solutions for archive in which, however, both with only activated JavaScript function. In both cases, the URL of the destination page is stored in the value-value of the built-in option elements of the drop-down menu and when you select an entry, you will be forwarded via JavaScript on the very URL. The almost same functionality could be achieved also without scripts:

  1. Create an old-fashioned GET form with submit button that sends to the base address of the site
  2. Put the select in this very form and specify name="cat"
  3. Give the option elements the slug of the categories

Submitting the form will result in a call to blog.de/?cat=category and thus the desired category, possibly with a redirect to the search engine friendly version of the URL. This works for the visitors just as good as the solution of the Codex, leaving aside the fact that you have to click on a button. But this is where you can engage with JavaScript to hide the button and sending the form via, by a script inserted, onclick handle . The end result looks like the script for users with Codex solution and all others come then just by clicking on the button to its destination and everyone is happy. So let's get to work!

The basis for the category drop forms creates a normal HTML form:

<form id="kategorienform" action="<?php bloginfo('url'); ?>" method="get">
    <label for="kategorienselect">Jump to Category</label>
    <select id="kategorienselect" name="cat">
        <option value="">-- Please Select</option>
        <?php
            $categories = get_categories('hierarchical=0');
            foreach($categories as $category){
                $selected = (is_category($category->cat_ID)) ? 'selected' : '';
                echo '<option '.$selected.' value="'.$category->cat_ID.'">'.$category->cat_name.' ('.$category->count.')</option>';
            }
        ?>
    </select>
    <input id="kategorienbutton" value="Kategorie abrufen" type="submit">
</form>

You could use this in your side bar and it would work, but we still want to get rid of the submit button and start forwarding directly when selecting a category. For this purpose, it does not take more than 6 lines of JavaScript that can be inserted directly below the form:

<script type="text/javascript">
    document.getElementById('kategorienselect').onchange = function(){
        if(this.value){
            document.getElementById('kategorienform').submit();
        }
    };
    document.getElementById('kategorienbutton').style.display = 'none';
</script>

If the user changes his selection in select element, is (if not the entry "Please select" is selected) submitting the form automatically, without having to activate the with style.display = 'none' made invisible button - done is the most user-friendly and still working without JavaScript category dropdown! This is a bit more code than the three lines from the Codex, but it works guaranteed on every visitor. And the principle is quite simple, provided you plan accordingly in advance. Since this is not happening in WordPress not even happen, we need to tap a little more - or in the case of the archive dropdown even much more:

<form id="archivform" action="<?php bloginfo('url'); ?>" method="get">
    <label for="archivselect">skip to month</label>
    <select id="archivselect" name="m">
        <option value="">-- Please select</option>
        <?php
            $query = "SELECT YEAR(post_date) AS `year`, MONTH(post_date) AS `month`, COUNT(ID) as `posts`
                FROM $wpdb->posts
                WHERE post_type = 'post' AND post_status = 'publish'
                GROUP BY YEAR(post_date), MONTH(post_date)
                ORDER BY post_date DESC";
            $key = md5($query);
            $cache = wp_cache_get('select_archives', 'general');
            if(!isset($cache[$key])){
                $arcresults = $wpdb->get_results($query);
                $cache[$key] = $arcresults;
                wp_cache_set('select_archives', $cache, 'general');
            }
            else{
                $arcresults = $cache[$key];
            }
            if($arcresults){
                global $wp_locale;
                foreach((array) $arcresults as $arcresult){
                    $value = $arcresult->year.$arcresult->month;
                    $text = sprintf(__('%1$s %2$d'), $wp_locale->get_month($arcresult->month), $arcresult->year);
                    $count = ' ('.$arcresult->posts.')';
                    $selected = (is_month() && get_query_var('year').get_query_var('monthnum') == $value) ? 'selected' : '';
                    echo '<option '.$selected.' value="'.$value.'">'.$text.$count.'</option>';
                }
            }
        ?>
    </select>
    <input id="archivbutton" value="Archiv abrufen" type="submit">
</form>

The problem with the Archive, is that without a custom SQL query, you cannot get to the information, which you need for a monthly archive. So there is no other way then to manually enter the database and cache the result manually. The principle is identical: simply output a conventional form and then six small lines of JavaScript:

<script type="text/javascript">
    document.getElementById('archivselect').onchange = function(){
        if(this.value){
            document.getElementById('archivform').submit();
        }
    };
    document.getElementById('archivbutton').style.display = 'none';
</script>

To summarize: many lines of code, but the principle is not complicated. Unobtrusive JavaScript is a question of intelligent planning and if it is not included as with WordPress automatically, you have to do it. With traditional websites, there is no reason to operate completely dependent on JavaScript, and should there be more effort, it is worth the clean separation of the layers and the accessibility bonus.

Guest Post

This post was written by Peter Kröner peterkroener.de.

Peter Kröner is freelance web designer and developer and also author of the HTML5-book.
On peterkroener.de he blogs on all kind of topics in web technology.

Thank you very much from our part to Peter.

If you also like to have your interesting post published on our website, please let us know on our contact page. Of course we will appreciate your contribution!

Add Menus to the Admin Bar of WordPress


The new WordPress admin bar facilitates the access of backend and frontend to areas of the back end. Of course, this new control element of WordPress is expandable and can be adapted to the needs of the user. In some areas and for various needs, quick access to different areas is certainly interesting.

The newly created menus can be adapted as usual rights to the appropriate roles. A small example will demonstrate the integration.
Continue reading …