You can fixing this by forcing user- and group ownership of new pages and elements. First, find the root page of the subtree for which you want to set default owner and group. Then add something like in the example below to the page’s TSCONFIG:

TCEMAIN.permissions {
	# ID of the backend user that will own new pages
	userid = 3
	# ID of the backend group that will own new pages
	groupid = 1
 
	# This is optional, explicitly set permissions
	#user = show, editcontent, edit, delete, new
	#group = show, editcontent, edit, delete, new
}

if ( !is_admin() ) { 
    $theme  = get_theme( get_current_theme() );
    wp_register_style( 'your-style', get_bloginfo( 'stylesheet_url' ), false, $theme['Version'] );
    wp_enqueue_style( 'your-style' );
}

I don’t really like the get_theme() line, but I am not aware of a better way to get the version info. What’s good about that line is that it gets the version of the current child theme, if you’re using one.

One problem with enqueuing styles is that most themes need one or two additional CSS files inside conditional comments for a certain browser. Nacin pointed me to a solution:

if ( !is_admin() ) { 
    $theme  = get_theme( get_current_theme() );
    wp_register_style( 'your-style', get_bloginfo( 'stylesheet_url' ), false, $theme['Version'] );
    $GLOBALS['wp_styles']->add_data( 'your-style', 'conditional', 'lte IE 8' );
    wp_enqueue_style( 'your-style' );
}

See also the relevant discussion on trac. Using this could lead to script concatenation problems in the WordPress core (which doesn’t concern a theme developer) and if a website uses plugins like wp-minify. So you probably only want to use this in your own themes, not public ones.

The theme on that site wasn’t tweaked at all to make the Ajax functionality work (except some irrelevant CSS changes). It works out of the box on most WordPress themes that follow the theme coding recommendations, see the plugin’s readme.txt for details.

Downloads are available at WordPress.org.

I have another equally stupid pet bug. Basically, a CSS file can break core functionality which can lead to bugs in plugins like my theme switching plugin. It’s a rather rare bug but the sloppiness of the coding is on the same level.

I have a code-centric blog. I post a lot of code, and of course readers post code themselves from time to time. Of course WordPress has to mess with comments as well. I realize that removing potential XSS code is a good security measure. But seriously. Do not delete any content before it goes into the database (besides SQL sanitization). I can’t even recover that comment now.

WordPress rant over

One of the problems is that the WordPress Ajax handler script is located in the admin directory. So password-protecting the admin area will break all Ajax functionality your blog might be using on the frontend.

First, see this tutorial on how to password protect directories with an .htaccess file. Sivel has an example for whitelisting the Ajax handler, add these line to your .htaccess file:

# These are the lines that do the password protection.
# You probably already created them while reading through the tutorial linked above.
AuthUserFile /path/to/your/htpasswd
AuthType basic
AuthName "Restricted Resource"
require valid-user
 
# This is the whitelisting of the ajax handler
<Files admin-ajax.php>
    Order allow,deny
    Allow from all
    Satisfy any 
</Files>

Please notice that you absolutely need to create the htpasswd file, see the linked tutorial above.

Update: /wp-admin/css/install.css is also sometimes needed on the frontend, you should whitelist that as well.

Here’s the necessary configuration to whitelist a file in a password protected location in lighttpd:

$HTTP["url"] =~ "^\/wp-admin\/.*" {
    $HTTP["url"] !~ "^\/wp-admin\/(admin-ajax\.php|css\/install\.css" {
        auth.require = (
            "" => (
                "method" => "basic",
                "realm" => "Password protected area",
                "require" => "user=theuser",
            ),
        ),
    },
},

In your theme’s functions.php add something like the following code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

function mytheme_addmenus() {
	register_nav_menus(
		array(
			'main_nav' => 'The Main Menu',
		)
	);
}
add_action( 'init', 'mytheme_addmenus' );
 
function mytheme_nav() {
    if ( function_exists( 'wp_nav_menu' ) )
        wp_nav_menu( 'menu=main_nav&container_class=pagemenu&fallback_cb=mytheme_nav_fallback' );
    else
        mytheme_nav_fallback();
}
 
function mytheme_nav_fallback() {
    wp_page_menu( 'show_home=Start&menu_class=pagemenu' );
}

In line 1 we add support for the navigation menus. The mytheme_nav() function is what you will use in the theme to display the menu. Inside that function we check if wp_nav_menu() exists, that means if we’re running WordPress 3.0 (or later). If not we’ll use the fallback function mytheme_nav_fallback().

Notice that the fallback also gets called if no navigation menus have been created in the admin area. That’s what the fallback_cb parameter on line 4 does.

To keep the HTM markup and the CSS consistent you’ll have to use the container_class parameter on wp_nav_menu but the menu_class parameter for wp_page_menu.

In your template use the following code to use your new custom function:

<?php mytheme_nav(); ?>

Resources

• wp_nav_menu() reference
• wp_page_menu() reference
• Informative article on nav menus by Justin Tadlock

Ramblings

What’s good about the new menu system:

• Total control over what appears in the menu
• You can add posts, pages, categories and tags in the menu
• Very nice drag and drop interface

What’s bad:

• You will have to teach your users how to use the system properly.
• If you create new pages they won’t be added to your existing menu (except for top level pages).
• You can not control your page menus through the navigation menus interface. I think it is… very very odd that WordPress doesn’t have a simple drag-and-drop interface to arrange pages.
• The previous point means that the new menu system is useless unless you update your theme.
• The wp_nav_menu() call is inconsistent with the existing wp_page_menu() function.

By the way, I use the Ozh admin menu plugin. You might need two clicks to switch if you don’t.

Download the plugin.

In your lighttpd.conf:

$HTTP["host"] =~ "domain\.com" {
    simple-vhost.default-host = "domain.com"
    include "wpmu-rewrite.conf"
}

And wpmu-rewrite.conf:

url.rewrite-once = (
    "^/(.*/)?files/$" => "/index.php",
    "^/(.*/)?files/(.*)" => "/wp-includes/ms-files.php?file=$2",
    "^(/wp-admin/.*)" => "$1",
    "^/([_0-9a-zA-Z-]+/)?(wp-.*)" => "/$2",
    "^/([_0-9a-zA-Z-]+/)?(.*\.php)$" => "/$2",
)

What’s changed from the other site’s example is the ms-files.php rewrite rule.

   $my_query = new WP_Query( "cat=3" );
   if ( $my_query->have_posts() ) {
       while ( $my_query->have_posts() ) {
           $my_query->the_post();
           the_content();
       }
   }
   $GLOBALS['post'] =  $GLOBALS['wp_query']->post;

Restoring $post is necessary because $post->comment_status of the post in the outer loop can be wrong after running the inner loop. That was the only problem I found, by I prefer to restore $post completely just to be sure. WordPress 3.0 has a function wp_reset_postdata() that you can use to restore $post.

I use this technique to show an “excerpt cloud” in a post using a shortcode.

A client of mine wanted a plugin to log what users type into forms. I kind of didn’t see the point at first. But a few days later I was a little annoyed that there was apparently no free alternative to websites like clixpy, clicktale and similar services.

It occured to me that recording movies of visits isn’t really hard to do. And so i started a new plugin, loosely based on the unpublished form input tracking plugin.

I am very pleased with the results so far. Of course it’s no match for the professional services mentioned above. But it is good enough to gain a few insights into what can be improved on your website.

The recording script is pretty lightweight but has a rather hefty dependeny: jQuery. It also loads json2.js. I’m sure the logging could be rewritten without the jQuery dependency but that really wasn’t a priority for the first public release.

This plugin probably needs WordPress 2.8 and PHP 5. I didn’t bother to test older versions and won’t support them in the future.

Here is a sample movie of what a recorded session can look like. As you can see mouse movements, clicks, form input, select boxes, checkboxes and radio buttons are recorded.

Important: For the playback you should always use the same browser as the visitor. If you don’t, the mouse position will probably be very wrong. The plugin also doesn’t save a page’s state at the time of recording. This means if comments are added or the content changes, you will see the old movements on a new website.

Downloads at WordPress.org.