Меню

Техники за напреднали

Влез Излез

WP::parse_request() и do_parse_request

Най-вероятно сте чували за „красивите постоянни връзки“ на WordPress (pretty permalinks), благодарение, на които адресите на страниците ви са от типа: „http://site.com/PAGE_TITLE“ или пък постовете са: „http://site.com/CATEGORY/POST_TITLE“. Използвайки Rewrite API на WordPress можете да направите значителни промени в структурата на линковете в сайта си, но истинската сила идва когато се гмурнете достатъчно дълбоко във WP::parse_request() метода.

На кратко WP е основният клас на WordPress. Той се грижи за част основната от функционалност на ядрото. Методът parse_request() на този клас се грижи за „превеждането“ на връзките, така че да може ядрото ясно да определи, че този адрес трябва да отговаря на една страница, а друг трябва да показва списък с всичко постове от даден автор (примерно).

Освен, ако не тръгнете да се ровите в source code-а на WordPress, трудно ще откриете повече информация за този метод. Ще ви спестя известно време като ви осигуря линк към документацията на този метод (забележете, че не е особено богато написана). Освен това ще ви дам и връзка към частта от source code-а на WordPress където се намира дефиницията на метода.

С какво точно ни помага този метод? Полезно е да знаем как работи вътрешно WordPress, ако искаме да направим по-драстични промени в permalink структурата.

Забележка: „драстични“ промени не се препоръчват да се правят като цяло. Подобна функционалност може да накара теми/plugin-и да не работят както се очаква.

Още в началото на метода виждаме, че се прилага филтъра do_parse_request. Този филтър дава възможност ние да парсираме permalink-овете, още преди WordPress да се заеме с тази задача. След това можем да му кажем: „Спокойно, погрижил съм се за това – от тебе не се изисква нищо повече по въпроса. Продължавай нататък“.

Асоциирайки функция към този филтър, тя получава три аргумента:

Първият, който също така трябва да върнем в нашата функция и който ще бъде резултат от самия филтър, е булева стойност която оказва дали WordPress да извърши парсиране. Ако върнем false – WordPress ще прескочи целия метод.

Вторият аргумент е самата инстанция на WP класа. Променяйки тази инстанция ние можем да окажем влияние на останалото изпълнение на кода.

Третият аргумент е масив от дапълнителни променливи, които се подават на parse_request() при извикването му.

Използвайки do_parse_request вие имате най-голям контрол върху permalink-овете и можете да създадете всякаква custom структура, но както обича да казва един от любимите ми комикс-герои: „С голямата сила идва и голяма отговорност“. Бъдете особено внимателни и предпазливи, когато използвате този филтър.

  • m1r0 каза:

    Предчувствувам как ще ми се наложи да правя нещо подобно съвсем скоро. Мерси за въведението. 🙂

  • magadanski_uchen каза:

    Не, не – това решение като цяло е твърде грубо – опитах се да засегна този момент в урока. В стандартния случай нуждата от custom permalink structure се решава с помощта на Rewrite API (http://codex.wordpress.org/Rewrite_API/add_rewrite_rule).

  • Zlatev каза:

    Добре е да се отбележи, че `do_parse_request` е наличен от версия 3.5. Отне ми известно време да го констатирам след като ползвах за референция source-а на 3.5 докато работих по инсталация от по-ниска версия!

Вашият коментар

Вашият имейл адрес няма да бъде публикуван. Задължителните полета са отбелязани с *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax