Методи інтеграції плагін-даних із темами


17

Я хотів би отримати деякі думки щодо найкращих практик розробки плагінів WordPress, які забезпечують інтеграцію тем.

Щоб мати сенс, коли я задаю це запитання, дозвольте почати з гіпотетичного прикладу сценарію, який мені цікавий. Уявіть, що я створюю плагін під назвою "Дискографія". Дискографія реєструє три користувацькі типи публікацій: "Групи", "Альбоми" та "Доріжки". Плагін також містить мета-поля, які надають деталі для кожного типу публікації, а також спеціальні таксономії для організації кожного типу публікації. Ці типи публікацій пов’язані разом із плагіном Posts 2 Posts . У межах адміністратора користувач може додавати нові смуги, які можуть бути пов’язані з альбомами, які, в свою чергу, асоціюються з треками, і всі вони матимуть безліч інших даних, доданих до них за допомогою метаполе та систематики.

Тепер я не хочу, щоб цей плагін просто налаштував адміністратора, щоб користувачі могли вводити цю інформацію; Я хотів би, щоб він надав деякі дані за замовчуванням для даних. Більш просунутий користувач / розробник буде добре мати лише цього адміністратора. Їй було б досить легко взяти ці дані та використовувати в темі; однак без деяких переглядів за замовчуванням цей плагін був би марним для більшості користувачів. У цьому прикладі ви можете відобразити що-небудь подібне (в дужках відображається спосіб відображення інформації у порядку ієрархії шаблонів):

  • Діапазони (single-prefix-band.php, single.php, index.php, шорт-код)
  • Альбоми (single-prefix-album.php, single.php, index.php, шорт-код)
  • Доріжки (один префікс-track.php, single.php, index.php, шорт-код)
  • Лістинг діапазонів (template-band-list.php, page-band-listing.php, page- {id} .php, page.php, index.php, шорт-код)
  • Список альбомів (шаблон-альбом-list.php, сторінка-альбом-listing.php, page- {id} .php, page.php, index.php, короткий код)
  • Хронологія альбому (шаблон-альбом-timeline.php, сторінка-альбом-timeline.php, page- {id} .php, page.php, index.php, короткий код)

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

Знову мені цікаво, який найкращий спосіб вирішити цю ситуацію? Я думаю, ви могли б зробити щось із наступного.

Короткі коди

Шорт-коди можуть бути використані як дуже гнучкий і зручний для користувача спосіб, щоб дозволити нерозробникам додавати групи, альбоми, треки, списки гуртів тощо в будь-якому місці сайту. Було б корисно для показу груп на певних сторінках або створення окремих сторінок для кожного діапазону (не дуже ефективно, але деякі користувачі підходять до речей таким чином). Швидкий код створював би HTML, який би прив’язувався до наданого CSS-файлу, який би забезпечував гарний перегляд потрібних даних за замовчуванням. Все міститиметься у файлах плагінів, і нічого не потрібно робити з темою.

Файли шаблонів

Плагін також може поставлятися з файлами шаблонів. Файли шаблонів можуть бути розмічені та стилізовані для гарного перегляду за замовчуванням. Ви можете надати користувачеві інструкції щодо переміщення файлів у папку з темами, щоб ця тема знайшла правильні шаблони під час перегляду типів публікацій. Ви навіть можете зайти в такий спосіб, щоб забезпечити інтерфейс, щоб дозволити користувачеві переміщувати файли одним натисканням (зауважте: я не створював би файли в папці тем користувача під час активації, оскільки додавання файлів у їхню тему, не ініціюючи їх, це зло) .

Ви також можете використовувати фільтри, щоб використовувати ці файли, не висуваючи їх із папки плагінів, зберігаючи все самодостатнє. Я бачив фільтри "template_include" та "{$ type} _template", які використовуються для цієї мети. Насправді ви можете використовувати шаблони з папки тем, і якщо їх немає, ви можете повернутися до цих фільтрів, щоб забезпечити подання за замовчуванням.

Питання

Мені подобається знати, що найкращі практики для цих ситуацій вважають інші, якщо представлені ідеї будь-яким чином є проблематичними та будь-які альтернативи, які я не включав.

Дякую!


3
Якби всі питання щодо WPSE були б так добре продумані ... :)
scribu

@scribu ... ти просто це кажеш, тому що я включив посилання на твій плагін;) Серйозно, хоча, дякую за комплімент. Я хвилювався, що це буде дурне питання, але це мене на певний час мучить.
tollmanz

Ще один +1 від мене. Для "чому" читайте коментар @scribu.
кайзер

@kaiser & scribu ... Я сподіваюся, що ви обидва висловите свої думки з цієї теми. Я хотів би почути, що ти маєш сказати.
tollmanz

@tollmanz Вже готово. Але такий інтенсивний Q потребує трохи роздумів та часу.
кайзер

Відповіді:


4

Я не можу відповісти на кожен запитаний вами запит, оскільки читання Q займало достатньо часу;), але я намагаюся дати вам декілька розумінь щодо мого особистого досвіду розробки безкоштовних плагінів з відкритим кодом.

1. Ніколи не роби занадто багато. Особливості - смерть кожного плагіна. Створіть спочатку основну версію та протестуйте реакцію своїх користувачів. Якщо ваш плагін привертає багато уваги, ви можете інтегрувати функції, які в основному запитуються.

2. Уникайте заповнення кожного випадку використання. Вам потрібно підтримувати свій плагін. WP пропонує нову версію кожні три місяці. І іноді важко дотримуватися всіх своїх плагінів. Для прикладу: На Trac зараз обговорюється нова версія API налаштувань. Коли це буде закінчено, то є ймовірність, що багатьом розробникам плагінів чи тем потрібно змінити велику частину коду, а деякі люди - як я - навіть написали шар абстракції над API. Тож вам потрібно повернутися назад, переписати базовий / абстракційний шар, а потім переробити все, що викликає частини цього. Обіцяю, що це велика робота. І навіть більше, якщо він чітко пов'язаний з вашим кодом. Коли ви починаєте заповнювати велику кількість випадків використання, ви також отримали багато еволюції основного коду WP, який вам потрібно стежити, а також ви багато працювали над оновленням свого коду.

3. Ніколи не намагайтеся вбудувати чимало прикладів коду (або шаблонів) у ваші плагіни чи теми. Якщо ви хочете націлити розробників та кінцевих користувачів: використовуйте свій блог для документації. Розробники ненавидять такі речі, а кінцеві користувачі ніколи не задовольняються (див. Заповнення кожного випадку використання).

4. Розділіть код з розумом на окремі файли. Правило: один файл для однієї частини. Приклад. Якщо вам потрібно переписати матеріал, ви знайдете його легко. Якщо чорти щось шукають: вони знайдуть це легко. Багато добре названих файлів не шкодять вам.

5. Якщо ви отримали список основних стилів (класів), залиште його користувачеві . Шанси просто занадто високі, що стилі з теми або інших плагінів перехоплюватимуть ваші визначення (незалежно від того, яку специфічність ви кинете). Просто спробуйте пояснити це десь якомога менше тексту.

6. Любіть свій плагін. Але відпустіть, якщо вам нудно. :)


Тепер - короткими словами - детально про вашу ідею плагіна:

A. Файли шаблонів погані. Як я вже сказав: Задокументуйте це у своєму блозі, запропонуйте приклад розмітки та стилів. Ваш блог отримає прибуток (і ви також, якщо у вас з’явиться реклама).

B. Короткі коди є kool. Вони нікому не шкодять, якщо плагін відсутній (у більшості випадків) і згодом може бути розширений / перетворений на кнопки TinyMCE (які люблять люди).

C. Дайте зрозуміти, що ваш плагін потребує іншого плагіна. Піддайте сумніви це питання і додайте примітку до адміністратора_нотестів (через register_activation_hook), якщо інший плагін не виходить (зв’яжіть його в цьому випадку) або не активований (ви можете зробити це для користувача під час активації). Також зауважте, що цей плагін надходить із надійного джерела і буде підтримуватися протягом наступних років.

Примітка. Ніщо, що я писав, - це не що інше, як моя особиста думка, що відображає мій досвід.


1
+1 для кнопок короткого коду TinyMCE (або інших), ця методика настільки корисна для користувачів, які не сприймають технологій, і допомагає в усьому інтеграції теми.
Wyck

1
Дякуємо за ваші думки. Тут багато загальної мудрості плагінів. Що стосується мого питання, то, здається, ваш метод полягає в тому, щоб дати дуже мало з точки зору інтеграції тем; швидше, ви хочете, щоб користувач зрозумів це через документацію. Я можу зрозуміти, чому це розумний метод, але в той же час, я подаю, як це призведе до того, що багато користувачів відчують, що щось не вистачає в плагіні. Зі свого прикладу, я думаю, що користувачі відчують, що щось було порушено, якби не було вбудованої підтримки для показу смуг / альбомів / треків.
tollmanz

Якщо ви хочете дотримуватися, я б запропонував вам використовувати короткий код, щоб додати розмітку до CPT (або всередині десь ще). Щодо стилів: я просто перевіряю, чи є певний таблиця стилів десь у дочірній> батьківській темі. Якщо так: це мовчки перекриє / -править основну таблицю стилів. Таким чином, ви могли б задовольнити обох розробників як кінцевих споживачів.
кайзер

@kaiser ... обидва суцільні моменти є.
tollmanz

2

У деяких аспектах вам доведеться зважити баланс між створенням плагіна або теми, якщо ваш сценарій вимагає великої кількості налаштувань / функцій, зазвичай завжди краще створити тему. Таким чином, користувач може потім налаштувати з точки зору зовнішнього вигляду, що завжди простіше, ніж змусити користувача налаштувати функціональність (заклинюючи шорт-коди скрізь), у вас є більший контроль функцій, він працює з іншими плагінами тощо.

Плагін, який намагається інтегруватись у всі різноманітні теми на ринку, повинен завдати чимало клопоту і, чесно кажучи, багато роботи.

Наприклад, замість того, щоб створити дуже інтегрований плагін на основі управління музикою та дискографією, замість цього створити тему для цієї мети, це стає все більш популярним для ринкових ніш, які потребують роботи на замовлення. Прикладом реального світу може бути тема на основі нерухомості. Немає можливості використовувати плагін для цього, оскільки він має такий глибокий набір функцій, натомість він створюється з нуля як тема, оскільки теми можуть скористатися всі функції плагінів так чи інакше.

Цілком ймовірно, що з точки зору маркетингу тема ніші буде краще, ніж плагін, при балансуванні функцій переднього типу.


Хороший момент про концептуалізацію цього як плагіна (особливо для маркетингових переваг). Найбільшою проблемою в цьому є те, що не завжди так, що плагін і його дані повинні вести до цілої теми. Це може бути просто менший компонент сайту, який, на жаль, потребує тематизації. Однак я розумію, що задовольнити всі групи користувачів просто неможливо, і краще просто орієнтуватися на одну групу.
tollmanz

2

Віртуальні сторінки

Третьою технікою, яку я бачив, було призначення спеціальної сторінки як заповнювача для вашого плагіна та використання фільтра "the_content" для виведення всього необхідного для виведення.

Таким чином, ви можете створювати шаблони, які поєднуються зі структурою теми, оскільки вам не доведеться мати справу з заголовками, бічними панелями, колонтитулами та дисками-обгортками.

Чудовий приклад цього можна знайти у плагіні bbPress:

http://bbpress.trac.wordpress.org/browser/branches/plugin/bbp-includes/bbp-core-compatibility.php?rev=3434#L931


Ви б запропонували зразок коду? Я здогадуюсь, це дуже хотілося б побачити розробки плагінів. (+1).
кайзер

Ви можете подивитися приклад нового плагіна bbPress.
scribu

Це дуже цікаво. Мені доведеться подивитися кодекс, перш ніж приймати рішення.
tollmanz

@scribu: Я шукав його, щоб додати посилання, але не можу знайти його через plugins.svn. Не могли б ви опублікувати посилання для наступних читачів? Спасибі.
кайзер

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.