Переопределить $ post адекватно из моего плагина - PullRequest
Новая
       25

Переопределить $ post адекватно из моего плагина

1 голос
/ 17 января 2012

Я разрабатываю свой первый по-настоящему большой плагин для WordPress, и пока почти все идет гладко.Единственное, что у меня есть, - это затруднение подделки текущего поста, чтобы макет пользователя продолжал работать нормально.Позвольте мне объяснить.

Я использую стратегию структуры постоянных ссылок книги Wrox Profesionnal Wordpress Plugin Development.Для этого я делаю следующее: 

//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();

}

И, таким образом, мой плагин отвечает на все / sgm / ** URL.И это хорошо, потому что я хочу иметь возможность сделать несколько странных переписываний URL, чтобы получить что-то хорошее.Проблема заключается в том, что при использовании этого метода WordPress не может сказать, под какой страницей он находится, и это портит компоновку, сделанную интегратором, такую ​​как изображение заголовка, активный пункт меню, боковая панель.

Я пытался подключитьна несколько хуков без успеха, таких как:

  1. wp (глобальный $ post и переопределить его)
  2. pre_post_selection (и изменить запрос)
  3. template_redirect (global $ postи переопределить его)

И ничего не меняется ... Шаблон использует The_Id () в качестве функции для получения идентификатора текущего сообщения, который эффективно использует $ post-> id (я думаю, закрытоисточник), но либо есть что-то, что переопределяет $ post ПОСЛЕ того, как я его изменил, либо моя техника не работает должным образом.

Так что мой вопрос, можете ли вы перехватить или переопределить в любом случае текущий пост, соответствующий URL-адресуиспользуя технику "add_rewrite_tag" ... Я хотел бы сделать что-то вроде этого: 

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

Но это не работает.

Спасибо за вашу помощь ...

ОБНОВЛЕНИЕ 

//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();

}

Я удалил все остальное и просто добавил правило перезаписи, чтобы запустить p = 440, все по-прежнему работает нормально, за исключением того, что переменная P-запроса, кажется, не существует, что-то говорит мне, что переписать не работает.Я вставил ту же самую вещь и в мой переписчик, и в функцию активации, и я деактивировал / активировал свой плагин.

1 Ответ

1 голос
/ 25 января 2012

Если эта функция запускается только при активации, это будет одной из основных проблем. add_rewrite_tag и add_permastruct оба должны запускаться при каждой загрузке страницы. flush_rewrite_rules должен запускаться только при активации, как у вас здесь.

Я не уверен, что это решит проблему 404, поскольку WordPress не знает, что делать с переменной запроса 'sgmpage'. Одна вещь, которую вы могли бы сделать, вместо того, чтобы использовать add_rewrite_tag, добавить что-то вроде этого: 

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=');
}

Это сообщает WordPress, что именно делает add_rewrite_tag, за исключением того, что WP также интерпретирует все sgmpage запросы как имеющие идентификатор записи 440. Никакой дополнительной работы для WordPress, никакой дополнительной фильтрации, действий и т. Д. , сохраняя при этом запрос sgmpage vars.

Это помогает?

EDIT

Чтобы не дать перенаправить сообщение, вам нужно подключиться к 'redirect_canonical'. Я полностью забыл о каноническом ... Это всегда Далеки ... э-э ... канонический редирект!

Добавление этого фрагмента должно помочь: 

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 ищет запрошенные объекты и выясняет, находимся ли мы на канонической странице для этого объекта. Если нет, он 301 перенаправляет пользователя на канонический URL для этих данных. Поисковики любят это.

Как медовый барсук, redirect_canonical не волнует и делает то, что хочет. В отличие от медового барсука, его можно остановить, отфильтровав значение перенаправления и вернув либо false, либо $requested_url, сказав, по сути: либо каноническое здесь не применимо, либо каноническое неверно, а запрошенный URL фактически , канонический URL в этом случае.

...