sargant

Thanks. Both of those should now be fixed – a last minute change messed up the logout link function.

The links are still showing up as ?page_id=xxx form links – make sure that you’ve selected a format that isn’t the default.

Edit: I should say – the permalinks page is located under Options — Permalinks

If it still doesn’t work and the links still show up with question marks, try typing this into the custom box:

/index.php/archives/%post_id%

The reason for this is that your server might not support .htaccess files, so you’ll need the index.php part.

The pages are showing up odd on the sidebar because the subset of pages are wrapped in another ul tag inside the “circuits” li tag, a nested list. You can reduce the padding/margin on uls inside lis in your sidebar to sort this.

At the moment I presume you’ve posted that information about Snetterton as a blog Post, not as a page. As it’s a static, non-time-relevant post, it’d be better off as a Page.

Provided you have *something* listed as a permalink, the Pages will create their own permalinks. You can choose the “date and name” one, but it’s unimportant if you’re not going to create blog posts.

Now you can create a page called “circuits” and put general information and maybe a list of sub links there. Then, for each track, create a page and in the right-hand column set its Page Parent to the circuits page. The url to each page will then automatically be of the form

https://www.raceaction.co.uk/circuits/snetterton/

Use the function date_i18n($date_formatting_string, $unix_timestamp). It works exactly the same way as the PHP date() function.

The first argument gives the component that goes into the “breadcrumb trail”-type-title for the window, the second gives the menu tab name. It’s the second one that is being used for both.

I’ve had a poke about in the source and it appears this behaviour is intented, the tab name is assigned to the first you create a subpage.

I’m wondering whether to file it as a bug report for enhancement, but last time I did that I was informed I had badly overlooked the codex.

I found that in order to receive extra variables over GET that I had specified in a rewrite, I had to specify them as “safe” query variables like so:

add_filter('query_vars', 'add_my_safe_query_vars');

function add_my_safe_query_vars($original_vars)
{
$extras = array('foo', 'bar');
return array_merge($original_vars, $extras);
}

You can then access them as get_query_var('foo') etc.

I’ve just realised that matched_query is a child of $wp directly and not query_vars. Oops.

Nevermind, crisis averted.

Did you disable your plugins before upgrading? If not, it looks like you’ve got an incompatible one. Make sure your plugins are all deactivated and reactivate them one-by-one until you’ve found the erroneous one.