WordPress: Настройка на свързаните публикации

WordPress

Ако използвате WordPress, един от необходимите ви плъгини трябва да бъде Свързани Post плъгин. Въпреки това забелязах, че обемът на ключовите думи, публикувани с ежедневните ми четения, наистина изкривява резултатите от свързаните публикации.

Освен това бях наистина изненадан, че приставката „Свързани публикации“ предоставя само списък на свързани публикации преди публикацията, която четете! Какво ще стане, ако промените решението си (както често правя!) ... не трябва ли да предоставите и публикации, които са били пуснати след оригинала, но все пак свързани?

В резултат на това направих някои незначителни промени в приставката. Първо, за да препращам постове както преди, така и след текущия пост, модифицирах ред 91 от:

. "И post_date> = '$ сега'" до (АКТУАЛИЗИРАНО: 11):. "И post_date! = '$ Сега'". "И дата след_ <= CURDATE ()"

Второ, Daily Reads в моя блог се публикуват автоматично от Del.icio.us под конкретен Автор (така че никога да не променя паролата и да наруша автоматизираното публикуване). За да направя това, току-що добавих друг параметър на заявката, за да пропусна този автор от публикациите, които са търсени, като вмъкна следния ред след предишния:

. "И post_author! = 4"

Намерих номера на автора просто като го потърсих в своите потребители. Предпочитам да не усложнявам нещата, като се присъединя към друга таблица - това може да намали скоростта, с която се показват тези резултати, и да забави времето за зареждане. Това ще доведе до разочарование и напускане на хората.

Ползите от показването на свързани публикации

Свързани публикации е фантастичен инструмент за всеки блог. Свързаните публикации укрепват резултатите от търсачката, като увеличават ключовите думи чрез връзки, важен елемент от алгоритмите на търсачката.

Свързаните публикации не са просто SEM инструмент, обаче. Свързаните публикации са инструмент за задържане, който ще задържи потребителите във вашия сайт. Те може да не намерят това, което търсят, където са се приземили - но ако им предоставите допълнителни препоръки, те може да останат наоколо!

20 Коментари

  1. 1

    Готин трик. Не бях осъзнал Свързани публикации избира само предишни записи в блога ... Ще трябва да отида да редактирам приставката. Благодаря за вниманието и инструкциите 🙂
    …и Честита Нова Година!

  2. 2

    Добър хак - макар че лично използвам Simple Tags за свързани публикации въз основа на тагове, но съм напълно съгласен, че свързаните публикации са задължителни.

  3. 3

    уау .. това е чист трик. Въпреки че нямам плъгин за публикации, свързани с wasabi, имам плъгин Simple Tags за свързани публикации и предполагам, че той трябва да използва същото условие след дата <. Благодаря за съвета, позволете ми да проверя кода на приставката си и да видя дали мога да го променя, за да дам по-добри резултати.

  4. 4

    Chandoo, Simple Tags не използва условие за публикуване на дата - вярвам, че създава свързаните публикации на живо с всеки изглед на страница (освен ако кешът не е включен) Това не е най-ефективното нещо за сървъра, но означава, че той ще получи най-добрите съвпадения, независимо дали са публикувани преди или след гледаната публикация.

    Дъг - съжалявам, че малко се махна от темата ...

  5. 6

    Страхотен пост! Но аз искам да избера няколко гниди.

    Вашата обосновка за „(не) присъединяване към друга маса”, Защото:

    "това може да намали скоростта, с която се показват тези резултати, и да забави времето за зареждане"

    е извън базата и пример за преждевременна оптимизация, която възпрепятства поддръжката, и е жалко да се види, че хората с голяма аудитория препоръчват такива неща, защото разпространява дезинформация.

    SQL присъединяването, за което говорите, ако приемете, че разполагате с разумни индекси, ще увеличи времето за реакция най-много микросекунди. Трябва да имате тонове и тонове трафик, преди някой да забележи дори половин секунда разлика. Сега да, ако се насилите, можете да напишете толкова наистина умопомрачителен SQL код, който ще се представи ужасно, но допълнително присъединяване към ключови данни не е пример за това.

    Освен това, вместо да се застъпвам за хакване на нечий публикуван плъгин, наистина бих искал да видя, че се застъпвате за подобряването му и след това да работите, за да включите подобрението си в самия плъгин. Както е, може да получите някои аматьорски програмисти да приложат вашите промени и след това да надстроят до новата версия на приставката и те да загубят промените, но не могат да разберат какво се е объркало. Вашата промяна е доброкачествена, просто загуба на функционалност, но някои хакове могат да доведат до счупване на сайт, ако бъде използвана бъдеща ревизия на основния плъгин върху хакнатия.

    JMTCW. Продължавайте добре иначе. 🙂

    • 7

      Здравей, Майк!

      Благодаря за отговора - все пак не съм сигурен, че съм съгласен. Не съм оптимизирал преждевременно ... всъщност намерих най-добрия начин да получа цялата необходима функционалност, без да е необходимо да правя допълнителни промени. В моята книга това трябва да бъде насочено към всеки разработчик.

      Аз също го казах бих могъл повлияват производителността. Не се притеснявах да тествам или опитвам, защото не беше необходимо предвид начина, по който оптимизирах приставката. Още веднъж - получих 100% от необходимата ми функционалност, без да правя присъединяване или добавяне на индекси и т.н. Това е правилното решение в моята книга.

      Все пак съм съгласен с вас относно останалите ви бележки. Опитвам се да преиздавам плъгини, усещам, че се излагам на чужда работа. Позовавах се на блога на автора за това - така че може би той ще ги вземе предвид като функции за бъдещо издание.

      PS: Поправено редактирането! 🙂

      • 8

        @Douglas: Не съм сигурен обаче, че съм съгласен. Не съм оптимизирал преждевременно? Още веднъж - получих 100% от необходимата ми функционалност, без да правя присъединяване или добавяне на индекси и т.н.

        Е, предполагам, че това е разликата между някой, който разглежда програмирането от съвършен професия, и занаят срещу някой, който е практикуващ, просто се опитва да свърши нещо (и нямам предвид това пренебрежително; в някои пощенски списъци пускам писмо роля срещу първия. 🙂

        Подобно е на това как счетоводител или адвокат казва на собственик на бизнес „Не бих направил това”И собственикът на бизнеса, без да поема всички последствия, за които професионалистите са наясно, че са * потенциални *, пренебрегват съветите им, защото изглеждат като твърде много усилия и продължават напред. Бог знае, че в миналото съм бил собственик на този бизнес и съм изоставал срещу всички съвети, макар и много по-късно. 🙂

        @Douglas: Аз съм опитен да преиздавам плъгини, ...

        Не, не точно това казвах. Това, което казвах, е, че тъй като е с отворен код, можете да внесете промените си обратно в оригиналния автор, който те ще приемат и можете да го направите активно, като се свържете и предложите. Понастоящем работя като маркетингов консултант и разработчик на уебсайтове за издатели и употреба на печатни ниши Drupal за уеб технологии, а Drupal общността винаги се свързва с авторите на плъгини (Drupal ги нарича „модули“) и предлага да помогне за подобряването на други модули.

        Просто една мисъл.

        PS Благодаря за корекцията на редактирането.

        • 9

          Добри точки, Майк!

          Може да се забъркам с приставката, за да добавя тази опция на „Показване само на публикации преди показваната публикация“. Мисля, че втората опция е малко по-собствена за моя блог, но ще проверя и ще видя, че може да представлява интерес за автора.

  6. 11
  7. 13

    Дъг - Тук може да ми липсва нещо. Изглежда че

    AND post_date <= '$now'

    не възпрепятства включването на публикации, направени след тази конкретна публикация, дотолкова, доколкото предотвратява включването на публикации, които може да сте задали публикувани в бъдеще.

    Надявам се, че има смисъл и благодаря за страхотния блог.

    • 14

      Скот,

      Това е страхотна находка! че съм сигурен, че всеки (който пише предварително) ще оцени.

      Ще актуализирам заявката в публикацията.

      Дъг

  8. 15

    @Mike: Е, предполагам, че това е разликата между някой, който гледа програмирането от съвършена професия, и занаят срещу някой, който е практикуващ, просто се опитва да свърши нещо

    Интересно разграничение. Макар че би било хубаво всичко да работи възможно най-добре, в много случаи това изглежда непрактично. Стремя се да намеря баланс в програмирането си между това как бих искал нещо да се изпълнява и колко $ или време ще отнеме, за да го стигна там.

    Стремя се да направя минимума, необходим за постигане на целта, която се опитвам да постигна. Прекарването на повече време не би било рентабилно.

    Накратко, освен ако тази загуба на ефективност не беше забележима в моя блог, не бих отделил допълнителното време, ако това е забележимо, тогава щях да реша дали допълнителното време би струвало резултата. Съвършенството не винаги е най-доброто решение.

    • 16

      @Dwayne: Стремя се да направя минимума, необходим за постигане на целта, която се опитвам да постигна. Прекарването на повече време не би било рентабилно.

      Разбира се, ако винаги да правите минимума означава, че не научавате по-добри техники, каращи да повтаряте минимума много пъти в бъдеще, вместо да ви позволявате да го избягвате, значи сте постигнали фалшиво постижение. Да, много задачи не се нуждаят от допълнителни усилия, но в миналото бях свидетел на много хора, които използват подобни преки пътища и те бяха едни от най-малко продуктивните и / или най-малко създаващи стойност хора, които познавах (някои от тях за съжаление бяха мои служители , следователно защо наистина забелязах липсата на производителност.)

      @Dwayne: Накратко, освен ако тази загуба на ефективност не беше забележима в моя блог, не бих отделил допълнителното време, ако това е забележимо, отколкото бих решил дали допълнителното време ще си струва резултата. Съвършенството не винаги е най-доброто решение.

      Мисля, че пропусна точките ми. Първо казвах, че Дъг оптимизира за незабележима ефективност, не аз, но по-важното е, че ако въвеждате хак, който може да причини бъдещи проблеми с поддръжката, за добро, не го публикувайте за използване от други, без поне да им кажете за вид проблеми с поддръжката, които може да им причини по-късно.

      Иронията на вашия коментар е, че поемането на бързия и лесен път често ви струва много повече време в бъдеще, когато инсталирате актуализация на защитата за вашия WordPress, загубите хакнатата си функционалност и я искате обратно. Сега имате купа сено с липсваща игла и сега трябва да разберете къде е била иглата.

      Да отделяте допълнително време за изпълнение? Бах, обикновено не е необходимо. Да отделите допълнително време за поддръжка? Да, често се изплаща в дългосрочен план.

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

  9. 17

    Едно нещо трябва да кажа; Мисля, че хакът на Дъг би бил добро допълнение към WordPress, поне като потребителска опция. Изглежда доста глупаво да се ограничават свързани публикации само до тези, които са идвали преди.

    СЪЩО, бих искал да помоля Дъг да публикува за това как се публикуват ежедневните му публикации от del.icio.us; това би било интересна тема.

    • 18
      • 19

        Той Х. Добър! Предполагам, че първо трябваше да го потърся.

        BTW, изпратих ви личен имейл за това, че съм бил в Инди от 16 до 19 февруари преди около седмица, но не получих отговор. Взе ли? (не се колебайте да изтриете тази част от моя коментар.)

  10. 20

Какво мислите?

Този сайт използва Akismet за намаляване на спама. Научете как се обработват данните за коментарите ви.