Wabsnasm

Thanks, that seemed to work!

Nope, did not work.

So, back to square one. Anyone else got any ideas how I can tackle this?

Thanks, I’ll give it a go and report back.

I was able to solve this problem by renaming the folder Twig to twig. Since most web servers are case sensitive, I’m going to say this a bug with the plugin.

Thanks for this, solved the problem for me.

Solved

I was hooking into pre_get_posts and modifying the query there. That was preventing the menu from being output on the pages where I was doing that.

To resolve this, I added a &query->is_main_query conditional. So,

add_filter('pre_get_posts', 'my_filter');
function my_filter(&$query) {
  if ($query->is_main_query() && (is_single() || is_home())) {
    // Modify query here
  }
}

Once I’d added that, my wp_nav_menu started working. Solution presented here in case anyone else comes up against the same issue.

An update –

wp_nav_menu(array('menu' => 'Footer menu name'));

Does not get the correct menu, and changing ‘container’ and ‘container_class’ arguments make no difference.

Ok, thanks. I think it’s not exactly what I’m after (mine can be one of several post-types) but from it I saw that I might be able to use get_page_by_title() by parsing the first part of the url as the post-type, and the second as the slug to look for…

I would have thought that this would be VERY easy, seeing as WordPress already gets the current post by parsing the URL.

Sorry, don’t have a link to that. But it seems such a widely-encountered problem, I’m surprised that there’s not a definitive answer or fix in the core.

Here’s a temporary fix that I don’t really like

function shortcode_func($attr, $content) {
    return fix_shortcode( do_shortcode($content) );
}

function fix_shortcode($content) {
    return preg_replace(array('/^<\/p>/i', '/<p>$/i'), array('', ''), $content);
}

how did you downgrade? I have no access to the admin-panel.

Personally, as I was creating a site from scratch, I removed the ai1ec tables from the database, deleted the plugin folder via FTP then uploaded version 1.7.1, again via FTP.

To make things accessible to me I’ve downgraded to version 1.7.1. I’ll await a solution here before upgrading…

Your main post page will use the index.php template file, so a check to see if it is the main posts page is unnecessary.

Well, my code is in sidebar.php, which is why I asked. Anyway, your last post has made the penny drop in that I can simply use is_home() and is_archive() to achieve what I want (to test whether I’m on one of those pages). If I’m on one of those, then I’ll just use the posts page id retrieved as in the code above.

Thanks for the help!

CORRECTION: changed is_front_page() to is_home() above.

See my code example above.

That only gives me the ID of the posts page. It doesn’t let me test whether we’re currently on that page.

At the moment, when we’re on the posts page, $post->ID is 1. I can’t get the children of 1, so when $id === 1, I get the $id of the posts page (using the code above taken from your example), and get the children of that instead, giving me what I want. You’re saying I shouldn’t rely on that test. How else can I determine that we’re on the posts page?

You might want to re-think that approach. It may produce unpredictable results – especially in future versions of WordPress.

OK, then, I need to develop some other kind of test. So, at the moment, I’ve got $id, which is either

1. The ID of a normal page, or
2. 1 when I’m on the posts page

How can I test without involving the 1 === $id line?

Brilliant. It appears that on the posts page, $post->ID is 1, even though the ‘real’ ID of the page is not. So I use that as a part of my test:

if( 1 === $id && get_option( 'show_on_front' ) == 'page' ) {
    $id = get_option( 'page_for_posts' );
}

So it slots nicely into the rest of my code that uses $id (I’ve got it all wrapped in a ‘subnav’ class).

Thanks for your help!

Cheers esmi, I’ll give it a go. Hopefully I only need to find the current page ID and my own existing code can pick up the rest, so first I’ll try

$blog_page_id = get_option( 'page_for_posts' );

The code will also have to live with the existing page subnav code, something like:

if( this is a page ) {
    get the page id
} else if( this is a posts page ) {
    get 'page_for_posts'
} else {
    fallback
}

Anyway, I will try something with your suggestion and post back.