Override $post adequately from my plugin

1 Views

I’m developping my first real big pluggin for wordpress and so far almost everything is going smootly. The only thing i’m having, is difficulty spoofing the current post so that the layout of the user continues working fine. Let me explain.

I’m using the Wrox Profesionnal WordPress Plugin Development book’s permalink structure strategy. To this end, i do the following:

Read More
//Used to detect when the plugin gets actuvated
public function pluginActivatedAction(){

    //Send commands to install the rewrite rules
    add_rewrite_tag('%sgmpage%', '([^/]+)');
    add_permastruct('sgmpage', 'sgm/%sgmpage%');
    flush_rewrite_rules();

}

And thus, my plugin responds to all /sgm/** urls. Which is fine cause i want to be able to do some whacky url rewritting to get something nice going. Problem is, with that technique, wordpress can’t say under which page it is and this messes up the layout done by the integrator such as the header image, the active menu item, the sidebar.

I tried hooking to several hooks without success such as:

  1. wp (global $post and override it)
  2. pre_post_selection (And change the query)
  3. template_redirect (global $post and override it)

And nothing changes… The template is using The_Id() as a function to retrieve the id of the current post which effectively uses $post->id (i think, closed the source now) but either there is something overriding the $post AFTER i change it, or my technique is not working right.

So my question is, can you hook or override in anyway the current post the url matches using the “add_rewrite_tag” technique… I’d want to do something like that: 

global $post;
$post_id = 440; //Or get_option() later obviously
$post = get_post($post_id);

But it doesn’t work.

Thanks for your help…

UPDATE 

//Used to detect when the plugin gets actuvated
public function pluginActivatedAction(){

    //Send commands to install the rewrite rules
    add_rewrite_rule('sgm(/(([a-z0-9]+)(/([a-z]+)/?)?)?)', 'index.php?p=440&sgmevent=$matches[3]&sgmpage=$matches[5]');
    flush_rewrite_rules();

}

I removed everything else and just added a rewrite rule to get that p=440 going, everything is still working fine except the P query var doesn’t seem to be there, something tells me the rewrite is not working. I pasted that same thing in both my rewriter and in the activation function and i deactivated/reactivated my pluggin.

Post Views: 1

Related posts

Leave a Reply

1 comment

  1. If that function is run only on activation, that’s going to be one major problem. add_rewrite_tag and add_permastruct both need to be run on every page load. flush_rewrite_rules should only be run on activation, as you have it here.

    I’m not sure if that will fix the 404 problem, since WordPress doesn’t know what to do with the 'sgmpage' query variable. One thing you might do is, rather than using add_rewrite_tag, add something like this:

    function your_own_add_rewrite_tag_function(){
    global $wp_rewrite, $wp;
    $wp->add_query_var('sgmpage');
    $wp_rewrite->add_rewrite_tag('%sgmpage%', '([^/]+)', 'p=440&sgmpage=');
}

    That tells WordPress exactly what using add_rewrite_tag does, except it tells WP to also interpret all sgmpage requests as having a post id of 440. No extra work for WordPress to do, no extra filtering, actions, etc., while still preserving the sgmpage query vars.

    Does that help?

    EDIT

    To stop it from redirecting to the post, you will need to hook into 'redirect_canonical'. I totally forgot about canonical… It’s always the Daleks … er … canonical redirect!

    Adding this snippet should help:

    add_filter( 'redirect_canonical', 'redirect_canonical_8886079', 10, 2 );

function redirect_canonical_8886079( $redirect_url, $requested_url ){
    global $wp;
    if(!empty($wp->query_vars['sgmpage']))
        return false;
    return $redirect_url;
}

    redirect_canonical looks for requested objects and figures out if we’re on the canonical page for that object. If not, it 301 redirects the user to the canonical url for that data. The search engines love that stuff.

    Like the honey badger, redirect_canonical don’t care and does what it wants. Unlike the honey badger, you can tell it to stop by filtering the redirect value and either returning false or $requested_url, saying, essentially: either canonical doesn’t apply here or canonical is wrong and the requested URL is, in fact, the canonical url in this case.