Існує кілька типів розробників WordPress. Деякі з них створюють дрібні одноразові проекти, інші працюють над глобальнішими речами. Усі використовують різні інструменти та методи залежно від того, що вимагає від них клієнт. Дуже багато хто при розробці тем на замовлення використовують стартові теми, і ми повинні відзначити, що в деяких випадках абсолютно не дарма.
Дивіться також:
Що таке стартова тема?
Стартова тема – це тема, де замість того, щоб створити дочірню тему, ви просто змінюєте назву і випускаєте свою власну тему. Вона не буде батьківською темою. Це просто основа з кількома базовими файлами для вашої нової теми користувача. Якщо ви не використовуєте стартову тему, щоразу при створенні теми вам доведеться писати один і той же базовий код для style.css, header.php, index.php и footer.php - Обов'язкових файлів для будь-якої теми.
Отже, якщо ви ще не використовували стартову тему, варто замислитись про це в майбутньому.
Навіщо використати стартову тему?
Ми не намагатимемося переконати вас, що використовувати стартові теми — це добре чи погано. Але ми можемо сміливо сказати, що дуже зручно розпочинати роботу над новою темою вже з готовими цими 4 файлами. До того ж існує безліч дійсно класних стартових тем, наприклад, такі як roots.io (sage) або _s (undercores) від Automattic.
Тим не менш, у нас виникла проблема під час роботи з цими темами. Вони виявилися надто «роздутими». Коли ми вперше взяли до рук проект roots.io, і познайомилися з їх СУХИЙ (Do not Repeat Yourself - не повторюйтесь) філософією, ми були дуже заінтриговані. Там було все зроблено добре, якісно, але, чесно кажучи, розібратися в усьому було досить складно. І це явно не схоже на "WP-метод".
Примітка: Ми ніколи не вважали, що "WP метод" – це єдиний вірний підхід на всі випадки життя, проте при створенні теми виявилося, що метод DRY значно уповільнив процес розробки.
Перегляньте весь код
Якщо ви робите тему на замовлення, то швидше за все, вона матиме унікальний дизайн, а значить і унікальний макет. Тому коли ми почали працювати з темою _s, виявилося, що потрібно витратити купу часу на рефакторинг DOM (HTML), щоб він відповідав нашому макету. Після цього нам довелося самостійно створювати кожен шаблон на основі одного макета (index.php).
Причому тут не йдеться лише про один вбудований шаблон. У таких стартових темах дуже багато необхідної базової функціональності. Тому файли стають роздутими або перевантажені функціями настільки, що ви не завжди будете розуміти, чи потрібно вам це все.
Коли зручно працювати зі стартовими темами
У деяких випадках можна дуже ефективно використовувати роздуті стартові теми. Наприклад, якщо ви переконалися, що нові теми відповідають DOM, який вже вбудований в тему. Навіть якщо там не буде макета, це можна легко виправити, зробивши лише кілька маніпуляцій над стилем. Тому, якщо ви можете постійно використовувати той самий DOM або, якщо у вас є відповідна таблиця стилів, то, можливо, це гарне рішення для вас.
Ну і оскільки ці теми вже мають багато шаблонів, ви зможете з їх допомогою швидко і легко створювати нові потужні теми. Таким чином, слід визнати, що так, безумовно, бувають випадки, коли при можливих тимчасових обмеженнях роздуті стартові теми можуть дуже допомогти.
Коли не рекомендується використовувати роздуті стартові теми
Дуже часто буває так, що теми, які були створені для економії часу, вимагають від вас набагато більше витрат, та й підігнати налаштування DOM не так вже й легко.
Наприклад, якщо при створенні нової теми ви любите створювати все з нуля, то DOM повинен бути порожнім. Вас може дратувати, що необхідно редагувати всі ці файли шаблонів, які вже створені в index.php (або, можливо, page.php), щоб вони відповідали DOM. Говорячи про методи DRY, я не проти зробити копі-паст з одного шаблону в інший, але краще створювати їх самому.
Інша проблема полягає в тому, що більшість тим я намагаюся монетизувати, але іноді є ті, за які клієнт не платить мені. Наприклад, сторінка архіву. Якщо існує СРТ, то немає жодної необхідності створювати і сторінку архіву, але WordPress створить її в будь-якому випадку зі стартовою темою, яка стилізована, і у якої представлений готовий DOM, але яка не зовсім правильно відповідає решті моєї нової теми користувача. Так що тепер я маю файли, які насправді негативно впливають на весь проект. Замість повернення назад до index.php, WordPress показує archive.php, який може виглядати «зламаним» або просто незакінченим.
Також, ми вважаємо, що більшість цих стартових тем не підходять для роботи з такими технологіями, як ковтати, нмм і т.д. Нам не подобається, коли більшість тем включають скомпіловані скрипти і стилі, оскільки було б непогано це зробити самим.
Наступний рівень
Ми зрозуміли, що чим вище стає професійний рівень розробника, тим менше він вкладає стартові теми. Більшість розробників-сеньйорів мають свої власні стартові теми, які виглядають так само, як і наші. Здебільшого це package.json, gulp.js, style.css (З певними основними класами WordPress), header.php, footer.php и index.php. Щоб почати нову тему, перейменуйте тему в style.css, змініть те, що ви хочете в header.php (author і т.д.), зробіть npn установку і запустіть gulp, щоб поставити все на свої місця.
Можливо, це просто збіг, а можливо дійсно, чим вищий рівень розробника, тим сильніше він мінімізує начинку своєї стартової теми.
Висновок
Ми в жодному разі не говоримо щоразу починати з нуля, коли ви сідаєте працювати над новою темою. Але перед початком роботи проаналізуйте: чи справді ви заощадите час, використовуючи стартову тему. Якщо так, то впевнено приступайте до створення нового шедевра за допомогою цього інструменту. Успіхів!
Джерело: roysivan.com
Коментарі до запису: 6
Схоже, автор не в курсі, що таке DOM
Та схоже, що він взагалі інопланетянин…. )))) Чому взагалі такі люди вважають, що можуть втирати (і нав'язувати) розробникам щось своє.
Кожен має сам «дійти» до певних висновків і методів вирішення будь-яких завдань, а подібні «типу-ради», збивають стільки не лише початківців, а й багатьох досвідчених розробників, тим самим ставлячи під сумнів свої сили та методи роботи.
Останній рік у всіх своїх проектах використовую sage. Довелося посидіти, розібратися, але мій скілл у розробці дуже виріс завдяки цій темі. Довелося освоїти gulp, bower, assets, sass, browser sync та деякі інші речі, які лежать в основі sage. І підхід DRY у цій темі справді економить час. Єдина річ, яку я ще не зрозумів у sage – це необхідність використання composer для менеджменту плагінів.
По composer. З ним зручніше встановлювати усі необхідні компоненти. Нічого не забудеш не пропустиш, і версії компонентів будуть потрібні.
А ось ці коментарі стандартні чи плагін?
https://hostenko.com/wpcafe/plugins/decomments/