Нюанси комерційної розробки на WordPress Корисні поради для розробників на WordPress

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

Здебільшого інформація буде « технічного плану», Щодо CMS Worpdress, «по верхівках». Я розповідаю лише про наш шлях, для кого використання технологій, шляхів, прийомів та ін. питання релігії – прохання утриматися від холіварів. Приступимо.

Для початку невеликий відступ. Загалом, у нас саме, проекти поділяються на кілька типів за принципом розробки:

  • HTML шаблон з themeforest -> складання на CMS;
  • Дизайн -> верстка -> складання на CMS;
  • Розробка індивідуальних рішень.

Відразу зазначу, що розглядати в цій статті я буду лише перші два пункти, бо узагальнити третій мені видається досить складним завданням, т.к. улюблені/найкращі/всі інші поганітехнології у кожного свої та в невеликих містах буває складно знайти розробника хорошого рівняна RoR/Flask та іже з ними. І пробігу по них оглядово. Якщо виникне інтерес до цієї теми – чому б і не бути розгорнутою статті-туторіалу «Як зібрати сайт на WP за 4-8 годин, яким клієнт буде задоволений».

Чому Wordpress?

Низькі бюджети та бажання привносити у світ менше ентропії обґрунтувало вибір. Більш детально:

  • Зручність адмін-панелі для клієнтів. Я серйозно після введення цієї CMS все навчання замовників звелося до того, що ми надсилаємо пароль адміністратора. Спогади про запис відео "Як створити новину", "Як поміняти телефон на сайті" перестали мені снитися.
  • Швидкість збирання сайту. Близько 4-8 годин на проект це чудово. Конкурентна перевага.
  • Крива навчання розробників для збирання проектів. Поки що мій рекорд - 1.5 тижня навчання з нуля (тобто абревіатура HTMLздається заклинанням, що викликає Сатану) до повноцінного складання сайту за термін, який мене влаштовує.
  • Гарні графіки для клієнтів із рейтингом CMS:)
  • Freeware, немає необхідності купувати ліцензії.

І так, я не стукатиму у ваші двері з брошурою в руках і говорити “Чи не хочете ви поговорити про WP?”. Просто ми використовуємо цю CMS і про це є замітка. Фактично тут монолог у друкованому форматі, який я вимовляю всім новим веб-майстрам, які приходять до нас.

Які нюанси слід враховувати під час верстки проекту?

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

Шаблон повинен легко розділятися на "шапку сайту", власне контент та "підвал". Якщо необхідно приховувати деякі елементи шапки/підвалу - WP надає багато чудових функцій-умов. ( is front page(), is_404() etc.). Якщо потрібно змінювати зовнішній вигляд - CSS вміє, body_class()є.

Коли верстаються різні меню, які будуть керуватися через Зовнішній вигляд-> меню сайту, необхідно дотримуватися наступної структури:

З нюансів тут важливим є те, що підменю повинні мати css клас sub-menu. Це позбавить вас необхідності писати кастомний волкер при складанні сайту, для функції wp_nav_menu($args);.

Буду як капітан очевидність, але всі динамічні позиції у верстці повинні бути або окремих елементів(якщо телефон, то, наприклад + 7 XXX XXX etc. без збочень), для подальшої заміни плейсхолдера або бути схожі на наступну логічну структуру:

Верстка до списку
Верстка елемента списку

Верстка елемента списку
Верстка після списку

Обов'язково створити окреме правило CSS для контенту, який клієнти вставляють через wysiwyg в адмін-панелі. Щось на кшталт цього (нехай це буде LESS):

User-content( ... a( &:hover( ... ); &:active( ... ); &:focus( ... ); ) p( ... ) table( thead ( ... th ( ... ) ) tbody ( tr ( ... td ( ... ) ) ) ) h1, h2, h3, h4, h5, h6, h7 ( ... ) h1 ( ... ) ... h7 ( ... ) ul ( ... li ( ... ) ) img ( ... ) )

Надалі убереже від дзвінків виду "Чому я вставила картинку і в мене все поїхало!"

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

Верстка посторінкової навігації, що генерується WP, приймає приблизно наступний вигляд:

Верстка « хлібних крихт» тривіальна. Або ul li список, або , розділений ">>" і що з ними.

Ще хочу сказати, що весь блок вищесказаного вміщується в одну фразу – верстайте, стилізуючи розмітку, яку генерує WP/плагіни/сніпети-функції та буде щастя.

Чи отримали набір html/css/js файлів, що далі?

Зараз практика така, що ми маємо репозиторій, який називаємо kosher_wordpress, щоб на кожному проекті не встановлювати купу плагінів щоразу знову. Що в ньому є і що, на мою думку, зараз достатньо:

  • Найсвіжіша версія WP.
  • Чи не дефлотний пароль на адміністраторі;).
  • Білдер нових типів постів із кастомними полями з адмін панелі. Ми використовуємо Magic fields 2 . Використовується для створення елементів виду Список елементів -> Окрема сторінкаелемент. Шаблони виду archive-$type.phpі single-$type.php, або висновок за допомогою WP_Query.
  • Білдер нових полів для таксономії, використовую Tax-Meta-Class
  • Кастомізатор для редагування екранів. Використовую Advanced СustomFields. Незамінний для наступного кейсу. Є шаблон контактів, наприклад tpl-contacts.php, з прописаним усередині Template Name: Шаблон сторінки контактів. І необхідно, щоб при виборі цього шаблону в адмін-панелі на сторінці редагування контактів з'являлися додаткові поля, такі як координати карти, прив'язана форма зворотнього зв'язку etc. І тут він нам допомагає.
  • Білдер форм передзвону, зворотний зв'язок, замовлення, etc. Contact Form 7
  • Білдер глобальних налаштуваньсайту. Використовується для телефонів у шапці, соц.мереж та іншої інформації такого типу. Theme Options.
  • Functions.phpз функціями, що покривають практично весь функціонал, що залишився:
    • Підтримка меню теми. register_nav_menus();
    • Підтримка мініатюр у постів. add_theme_support ("post-thumbnails");
    • Ресайз зображень, з підтримкою з меншого->більше та кешуванням. resize_image($attach_id = null, $img_url = null, $width, $height, $crop = false)
    • Генератор хлібних крихт. the_breadcrumb().
    • wp_corenavi($wp_query)
    • Кастомний волкер для wp_nav_menu() для розширення. class My_Walker extends Walker Nav Menu ( оригінальний код WP }
    • Заділ для зміни шорткоду галереї. remove_shortcode("gallery", "gallery_shortcode");add_shortcode("gallery", "my_gallery_shortcode");function my_gallery_shortcode($attr) ()
    • Генератор посторінкової навігації. wp_corenavi($wp_query)
  • Файлик зі сніпетами, для нагадування.

І все складання проекту зводиться до наступного:

  • Створення virtual host на комп'ютері
  • git clone ...
  • Імпорт бд, введення трьох SQL команд для того, щоб сказати WP, який у нас зараз поточна URL(gist)
  • Копіювання сніпетів з другого монітора та наповнення верстки змістом.
  • Деплой на сервер і чашка кави

Зразковий вміст файлика зі сніпетами:
ID));


$ image = vt_resize (null, $ url, 220, 220, true); if (!$image["url"]) $image["url"] = "http://placehold.it/220x220&text=NO IMAGE";?> заданому алгоритму

зібрав за

останній рік вже більше сотні сайтів, в середньому за часом іде від 1 до 3 робочих днів, залежно від складності дизайну та різних моушен-ефектів. Сама збірка займає близько 4-8 годин. Можливо це і не результат, але порівнювати мені поки нема з чим, буду вдячний діалогу.Тільки зареєстровані користувачі можуть брати участь в опитуванні.

У цій статті ми поговоримо про цикл

розробки WordPress

  • , про те, хто і як його розробляє, і чим будь-хто з нас може допомогти. WordPress є проектом з відкритим вихідним кодом і належить некомерційному фонду, тому все робиться максимально публічно та прозоро.
  • Етапи розробки WordPress
  • Розробка кожної нової версії WordPress поділяється на п'ять основних етапів:
  • Планування
  • Дизайн та розробка

Бета тестування

Всього на один реліз йде приблизно 4 місяці: 2 на дизайн та розробку, 1 місяць на бета тестування та 1 місяць на реліз кандидати. Після *виходу* нової версії починається цикл її підтримки за допомогою технічних релізів, як наприклад версії 3.5.1 і 3.5.2, які не містять нового функціоналу, але усувають помилки і вразливості попередніх версій.

Паралельно з роботою над технічним релізом розпочинається планування вже наступної основної версії.

Хто розробляє WordPress

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

Крім цих людей, у розвитку проекту беруть участь понад двісті дизайнерів та розробників з усього світу: хтось у рамках своєї основної роботи, а хтось як хобі. Цей перелік зростає з кожним релізом.

Існує чимало компаній, чий бізнес якимось чином пов'язаний з WordPress, ці компанії виділяють одного або декількох співробітників для роботи над WordPress. Найкращі яскраві приклади- Це хостинг провайдери Bluehost і DreamHost, розробники тем WooThemes і The Theme Foundry, і компанія Automattic.

Subversion

Сам вихідний код WordPress зберігається у системі керування версіями під назвою Subversion. Це відкритий репозиторій, куди може заглянути кожен. Він має таку структуру:

  • /tags - в цю директорію поміщаються всі релізи: як основні, так і технічні
  • /branches - це гілки, які завжди містять останні зміниу певній основній версії. Наприклад, якщо це гілка 3.5, то вона міститиме всі зміни в 3.5.1, 3.5.2 і т.д.
  • /trunk - містить нову версію, яка знаходиться в розробці, і поки що не випущена. На сьогоднішній день це версія 3.6

Для доступу до репозиторію, вам потрібно буде Subversion клієнт, наприклад Versions для OS X, або TortoiseSVN для Windows.

Trac

Для керування проектом WordPress використовується система Trac, яка чимось нагадує звичайний форум.

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

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

Тестування

І нарешті юзабіліті-тестування. Так називається процес тестування, коли людині дають ряд завдань, а під час виконання все знімається на відео, яке потім аналізується. Це робиться для того, щоб розуміти, як люди працюють з інтерфейсом WordPress, де і які проблеми виникають.

Спілкування

Все спілкування між учасниками проекту відбувається переважно у трьох місцях. Це IRC чати, мережа блогів make і система управління проектом Trac, про яку ми вже говорили.

Кожну середу, розробники WordPressпроводять зустріч у чаті. Це канал #wordpress-dev на IRC сервері Freenode. Будь-хто може приєднатися і взяти участь у дискусії, запропонувати свої варіанти вирішення проблеми, або просто дізнатися про те, як і куди рухається розробка.

Крім чатів, є також мережа блогів під назвою make/*, наприклад make/core для розробників, make/ui для дизайнерів і т.д. На цих блогах ведеться планування. Розробники діляться ідеями, роблять нариси (скриншоти), публікують анонси та іншу інформацію.

Як ми можемо допомогти

У розвитку WordPressучасть може взяти кожен, і не обов'язково для цього бути програмістом. Ви можете вибрати область, що вас цікавить, і надати посильну допомогу.

Наприклад, якщо ви займаєтеся дизайном, ви можете передплатити блог make/ui , який присвячений створенню інтерфейсів користувачабрати участь в обговоренні і ділитися своїми ідеями. Щотижневі чати цієї групи відбуваються в IRC каналі #wordpress-ui.

Окрім дизайну, є група перекладачів. Якщо ви володієте англійською мовоюВи можете брати участь у перекладі документації, тем, плагінів і самого WordPress. У такому випадку вам варто відвідати блог make/polyglots і познайомитись із системою translate.wordpress.org.

Якщо вам подобається допомагати людям, ви можете відповідати на запитання у форумах підтримки на WordPress.org та в IRC каналі #wordpress. Завітайте до груп make/support — присвячена підтримці, і make/docs присвячена документації.

Для розробників тем і плагінів для WordPress є групи make/themes та make/plugins. Тут обговорюють репозиторії тем та плагінів на WordPress.org, правила влучення в директорії та інше.

Для розробників додатків для мобільних пристроївіснує група make/mobile. На сьогоднішній день, для WordPress вже розроблені мобільні програми платформи iOS, Android, Windows Mobileта інші. Як і саме ядро ​​WordPress, розробка мобільних додатківведеться публічно.

Для організаторів заходів, пов'язаних з WordPress, є група make/events . Тут беруть участь організатори неформальних зустрічей, мітапів, конференцій WordCamp, обговорюють ідеї та діляться досвідом.

Ну і нарешті розробники. Для розробників існує група make/core. Це основна група, де можна дізнатися, куди рухається WordPress, і коли вийде нова версія.

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

У цій серії статей ми плануємо розглянути основні моменти, які слід враховувати при розробці плагіна або WordPress.

Метою цього посібника є представити вам набір передових практик, які будуть корисні як для початківців, так і для досвідчених фахівців-розробників, які починають працювати з WordPress.

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

У цій статті ми розглянемо такі теми:

  • Стандарти кодування WordPress;
  • Як уникнути конфлікту назв функцій;
  • Код коментарів;
  • Поради щодо безпеки.

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

Зверніть увагу, що не все, що описане в цій серії, обов'язково застосовувати при розробці плагінів. Однак якщо ви вже приступаєте до навчання, чому б навчитися робити це правильно?

Я постараюся, щоб статті цієї серії були легкими для розуміння. Я включатиму в статті деякі приклади правильно складеного коду та приклади помилок. Не все, що описано тут є обов'язковим при створенні плагіна, але якщо ви починаєте роботу з WordPress , чому б не зробити це правильно?

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

Стандарти кодування WordPress

Чесно кажучи, це один із моїх найсерйозніших недоліків. Якщо ви розробляєте інструменти для WordPress, ви повинні просто слідувати Стандарти кодування WordPress. Це допомагає підвищити читання коду та уникнути поширених помилок.

WordPress є CMS з публічним використанням та підтримкою, що має на увазі таку просту річ, що всі пишуть коди, які прості для читання, редагування та підтримки всіма учасниками процесу.

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

У Керівництво WordPressстандарти діляться за чотирма основними мовами:

  1. Стандарти кодування CSS
  2. Стандарти кодування НTML
  3. Стандарти кодування JavaScript
  4. Стандарти кодування PHP

Приклади

Нижче я покажу вам кілька простих прикладів PHP- коду, щоб ви отримали загальне уявлення, про що йде мова.

Помилки:

if(condition) action0($var); if(condition) ( action1(); ) elseif(condition2) ( action2a(); action2b(); )

Приклади правильного кодування:

if (condition) ( action0($var); ) if (condition) ( action1(); ) elseif (condition2) ( action2a(); action2b(); )

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

Коли я займався написанням цієї статті, я якраз купив тему для одного свого клієнта і, коли захотів трохи змінити її код, я був вражений, як важко це зробити.

Ось те, що я маю на увазі:

>
" class="feature-link" title="!}"> ";} ?> "; foreach($categories as $tag) ( $tag_link = get_category_link($tag->term_id); $titleColor = categorys_title_color($tag->term_id, "category", false); echo "".$tag->name .""; ) echo ""; } }?>

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

Як уникнути конфліктів імен функцій

Конфлікти імен відбуваються, коли функція має те саме ім'я, що й функція, яка вже була визначена раніше. Наприклад, якщо у вас у темі є функція get_the_post_terms() , і ви встановите плагін, який містить функцію з тим самим ім'ям, ви отримаєте щось на зразок:

Fatal error: Cannot redeclare get_the_post_terms() (попередньо declared in.

На жаль, це відбувається набагато частіше, ніж варто було б. Але таких конфліктів легко уникнути.

Для цього ми маємо наступні варіанти:

1. Префікси функцій

Наприклад, якщо ваш плагін називається WordPress Cool Plugin , ви можете використовувати префікс wcc_ для всіх його функцій.

Таким чином, у наведеному вище прикладі назва нашої функції буде виглядати як wcc_get_the_post_terms() .

2. Укладіть функції до класу

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

class Wcc_Mailer ( static function send($post_ID) ( $friends = " [email protected]"; mail($friends,"New post!", "Check my new post in " . get_permalink($post_ID)); return $post_ID; ) ) add_action("publish_post", array("Wcc_Mailer", "send") );

Як бачите, у цьому прикладі я просто використав префікс для імені класу, але моя функція називається send. Це ім'я методу захищене змін через глобальну область імен, сам метод неспроможна викликатися безпосередньо. Щоб викликати його, мені потрібно буде зробити таке:

Wcc_Mailer::send($post_id);

Код коментарів

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

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

Особисто я використовую для коментування функцій синтаксис PHPDoc, із застосуванням Sublime + Docblockr це робиться дуже просто.

Давайте подивимося, як хлопці з WordPress коментують функцію wp_mail() , розташовану у файлі wp-includes/pluggable.php :

/** * Відправляє поштові повідомлення, аналогічні пошті PHP * * Значення, що повертається true не означає автоматично, що користувач отримав * лист. Це тільки означає, що використаний метод виконав запит без помилок. * * Використання звернень "wp_mail_from" та "wp_mail_from_name" дозволяє * задавати адресу відправника в наступному форматі "Name

", * якщо задані обидва звернення. Якщо використано лише звернення "wp_mail_from", * в адресі відправника вказуватиме лише електронна пошта. * * Тип контенту за замовчуванням - "text/plain", що не дозволяє використання HTML. * Однак ви можете задати тип контенту електронних повідомлень, використовуючи * фільтр "wp_mail_content_type". param string|array $to Масив або розділений комами список e-mail адрес для розсилки листів. param string|array $attachments Опціонально. Прикріплені файли. ) ([....] // Відправлено!
try ( return $phpmailer->Send(); ) catch (phpmailerException $e) ( return false; ) )

Як бачите, вони описують те, що робить ця функція, які параметри їй потрібні і що вона повертає.Досить інформативно, чи не так?

Коментарі не призначені для використання лише з PHP. У HTML , наприклад, люблю використовувати

в кінці великих блоків коду, тому мені набагато простіше потім орієнтуватися у коді.

У CSS я використовую коментарі, щоб поділити код на різні розділи.

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

Якщо ви думаєте, що я перебільшую, подивіться на дослідження Сheckmarx, проведені ними у 2013 році серед 50 найкращих плагінів WordPress .

Тепер давайте розглянемо деякі поради щодо безпеки розробки для WordPress:

XSS-уразливості

Для запобігання XSS ми маємо зробити дві речі. Перевіряти безпеку вхідних данихі перевіряти безпеку вихідних даних.

Існує кілька методів перевірки безпеки в залежності від даних і контексту, в якому вони використовуються. Загальне правило: ви не повинні довіряти будь-яким даними, що вводять, і не повинні довіряти будь-яким даними, які виводяться.

Для введення даних можна використовувати, наприклад sanitize_text_field() , яка перевіряє неприпустимий текст UTF-8 , конвертує в об'єкт одиночні символи<, убирает все теги, удаляет разрывы строк, отступы и лишние пробелы, а также убирает октеты. В зависимости от контекста, существуют разные функции, которые помогут вам обезопасить данные.

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

">

  • esc_url відкидає невірні URL-адреси, усуває неприпустимі символи та видаляє небезпечні символи;
  • esc_html кодує & «при виведенні HTML.

Знову ж таки, залежно від даних, які ви маєте, існують різні функції, які можуть допомогти. Для JavaScript можна використовувати esc_js .

Крім перевірки самих даних, не забудьте перевірити дату.

Запобігання прямому доступу до файлів

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

Щоб запобігти цьому, ви можете розмістити у верхній частині вашого скрипта дуже простий код:

// Вихід, якщо надано прямий доступ if (! defined("ABSPATH")) exit;

Це загалом завадить виконати скрипт, якщо доступ до нього отримано не через WordPress.

Видаліть усі попередження та повідомлення

Зловмисники можуть скористатися не тільки помилками PHP — сповіщення та попередження також включають багато цінної для них інформації. Кожен плагін має бути закодований з використанням режиму DEBUG.

Це також завадить зловмисникам обчислити застарілі функції у вашому плагіні. Щоб увімкнути режим DEBUG, просто знайдіть цей рядок у файлі wp-config.php і встановіть значення TRUE :

define(WP_DEBUG, true);

Використовуйте значення Nonce

Nonce -значення - це скорочення від numbers used once (одноразово використані числа), вони використовуються для захисту від помилкових запитів між сайтами, або CSRF.

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

Залежно від того, де потрібно застосувати значення Nonce , ви можете створювати його по-різному.

Для посилань використовуйте wp_nonce_url() :

$complete_url = wp_nonce_url($bare_url, "trash-post", "my_nonce");

Для форм - wp_nonce_field() :

wp_nonce_field("trash-post", "my_nonce");

В інших місцях wp_create_nonce() :

wp_localize_script("my-script", "my-var-name", array("nonce" => wp_create_nonce("trash-post", "my_nonce")));

Якщо ви подивіться на наведений вище приклад, побачите, як я використовую wp_localize_script ( про яку мова піде у наступній статті), щоб включити nonce в блок JavaScript . Я роблю це, тому що пізніше планую використовувати JQuery для виконання запиту AJAX , і ви завжди повинні включати nonce в виклики AJAX .

Після цього в скрипті, просто для перевірки nonce, використовуйте наступний код:

if(! wp_verify_nonce("trash_post" , "my_nonce")) ( die("Busted!"); )

Використовуйте функції та бібліотеки WordPress

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

Зараз всі кому не ліньки створюють сайти. Один з найпопулярніших двигунів - це WordPress. Програміст під даний двигун повинен не тільки знати php, але і знати саму структуру двигуна, вміти верстати і знати jquery (JavaScript)
Так склалося, що мені досить часто доводиться шукати розробника під Вордпрес для свого сайту. Я стикався з кількома розробниками. Дехто робить свою роботу дуже погано. А когось я можу порадити.
Ну а тепер я розповім про основні принципи, як вибрати спеціаліста з WordPress.

Студія це не завжди добре.

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

Інді-Програміст WordPress

Під інді я маю на увазі розробника, який працює сам на себе. Варто одразу поговорити з людиною, щоб з'ясувати рівень її знання Вордпрес. Коли я шукав людину, натрапив на Колесникова Сергія. Відбувся такий діалог:

Kolesnikov Sergey: Привіт
Дмитро Євгенович: Запитання
Kolesnikov Sergey: слухаю
Дмитро Євгенович: Наскільки добре знаєте вордпрес?
Kolesnikov Sergey: не мені судити напевно))
Kolesnikov Sergey: що вас цікавить?
Дмитро Євгенович: Ну припустимо, що пост відрізняється від станиці крім типу запису в бд
Kolesnikov Sergey: мені зараз ніколи іспити складати)) якщо щось конкретне я вас слухаю
Дмитро Євгенович: Секунду
мені потрібний такий плагін
Дмитро Євгенович: оцініть ціну в рублях та терміни
Дмитро Євгенович: якщо вже конкретно
Kolesnikov Sergey: ок, відпишусь

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

Потрібно шукати правильного фахівця з WordPress

Зовсім інше уявлення про себе робить Степасюк Андрій (http://stepasyuk.org.ua/)
Ціна розробки за годину від 15 доларів у принципі дуже адекватна ціна. При спілкуванні, відразу видно що знає вордпресс, т.к. ставить правильні питання після прочитання ТЗ. Не потрібно тестувати людину на знання двигуна. Робота з передоплати у фахівця одна з гарантій кидка і того, що фахівець закінчить ваш проект.
Ключова умова вибору кандидата — інтерес до вашого проекту, наявність питань перед початком проекту та під час робіт. Якщо питань немає — привід задуматися, чи йде робота.

Бувають і провали

У мене також були провали. Людина бралася за роботу і не виконувала її вчасно. Тому перед тим, як дати людині роботу, потрібно протестувати розробника і зрозуміти його рівень. Для цього можна поставити прості запитання

  1. Чим пост відрізняється від сторінки
  2. Чи може людина верстати і як добре знає JS
  3. У якій таблиці зберігаються пости
  4. Що таке доп.поля і як їх задавати

Запитань можна вигадати масу. Вони залежить від вашої технічної підкованості. Якщо ви самі не знайомі з двигуном, можна поставити інші питання:

  1. Що найскладніше у ТЗ та чому?
  2. Який найскладніший проект ви робили? Попросіть приклад та уточніть, що складного
  3. Чи розробляли ви плагіни

Зазвичай, досвід розробки плагіна для програміста під WordPress дає хороший досвід. Передоплату за роботу можна робити у розмірі 10-30 відсотків, за умови, що якщо проект затягнеться, то передоплата повертається без будь-яких зобов'язань.

Мій чорний список розробників під WordPress

Тут я наведу контакти, хто не доробив роботу до кінця або зробив її погано.
Перша конторка, про яку я писав – BVB Logic. Зробили роботу криво та дуже погано.
Друга людина: Skype: spider13_ – замість заявлених 1 тижня робив мій проект 3 тижні. У результаті відмовився від довгобуду. Постійно виникали питання щодо реалізації. Таке відчуття, що людина погано знає сам двигун, хоча за роботу взявся і начебто щось робив. На другий тиждень нічого не надав. Потім перестав відповідати на повідомлення у скайпі. Співробітництво довелося завершити.

P.S. До речі на нашому сайті все ще відкрита.

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

До речі, встановлення WordPress після прочитання кількох підручників та налаштування кількох тем не робить когось лідером у розробці. Такі люди можуть знати більше, ніж середня людина, і мають право називати себе «Експертами». Провідні розробники виходять далеко межі основних знань, вони самі розширюють межі можливого. Вони роблять інноваційний внесок у співтовариство, а також демонструють майстерність у роботі, яку вони роблять. Тому я хочу, щоб ви були більш ніж просто “Експерт”, я хочу, щоб ви були одним із найкращих.

Навіщо бути лідером у розробці?

А чому ні? Якщо ви працюєте з WordPress, то чому б просто не погодитись на середній рівень? У житті вже занадто багато “середнього” і значення слова “нормальний” надто переоцінено. Є й інші причини. Ось, наприклад, переваги провідних розробників WordPress:

  • – Заробляють більше грошей
    Існує великий попит на WordPress і клієнти готові платити більше за розробників, які є найкращими у своїй галузі.
  • – Отримують найкращих клієнтів
    Коли ви знаходитесь на вершині, у вас є можливість сказати “ні” проектам, які вас не приваблюють, та “так” проектам, які вам цікаві.
  • – Чи мають більший вплив
    Будучи визнаним фахівцем, ви маєте можливість формувати майбутнє WordPress, а також екосистем, побудованих навколо нього.

Одна година читання на день

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

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

Крім того, визначте тригодинний блок, двічі-тричі на тиждень. Сенс у тому, щоб взяти на себе зобов'язання щодо навчання та дати собі обіцянку виділити необхідний час для доведення його до кінця.

Вступ до університету WordPress


У вас ніколи не було кращого часу, щоб дізнатися та освоїти WordPress, ніж зараз. Існує безліч прекрасних ресурсів доступних для всіх, хто готовий знайти час і сили на їх використання. Перед початком набуття досвіду вам знадобиться деяка освіта. Звичайно, ви можете просто почати "розбирати" існуючі проекти. Але я пропоную вам почекати, розвивати самодисципліну та вчитися – скоро буде багато часу для експериментів. Почніть навчання із соціальних аспектів вашого досвіду.

Спілкуйтесь у правильній компанії

Ми стаємо схожими на тих, з ким взаємодіємо. Якщо ви хочете бути одним з кращих розробників WordPress, починайте проводити час з тими, хто на вершині. Читайте їхні блоги, стежте за ними у Twitter, давайте “зворотній зв'язок” на їхні думки та ідеї, побувайте на WordCamps та поспілкуйтеся з ними. Читайте інтерв'ю на CodePoet. Наслідуйте їх приклад, попросіть у них поради, дотримуйтесь їхніх порад і повідомляйте про результати.

Ось для початку невеликий список розробників WordPress:

Читайте

Існує велика кількість доступного матеріалу про WordPress. Є тисячі людей, які говорять про WordPress, тому все важче стає "фільтрувати шум". Так, є авторитети, однак, коли ви приступаєте до освоєння WordPress, ви повинні почати свій шлях з пошуку високоякісних ресурсів, концентруючи зусилля саме на них.

Ось кілька ресурсів, щоб ви зрозуміли, про що я:

  • - WordPress Codex
    WordPress Codex є громадсько-редагованим сховищем для всього, що стосується WordPress. Почніть із самих основ і зосередьтеся на освоєнні інтерфейсу WordPress з точки зору кінцевого користувача. Дізнайтеся про семантику WordPress. Читайте про дизайн тем і .
  • - Книги на WordPress
    Доступно більше десяти книг про WordPress. Почніть із тих, назва яких вас привабить. Подумайте, книга "WordPress для чайників" це просто для вас? Можливо ні? Ваші клієнти можуть читати її, вам необхідно мати уявлення про неї. Коли ви закінчите читання, подякуйте автору і напишіть відгук.
  • - Блоги на WordPress
    Знайдіть та ознайомтеся з найкращими блогами про WordPress. Підпишіться на їхнє розсилання. Читайте їх регулярно та спілкуйтеся з авторами. Ось кілька з моїх улюблених блогів WordPress на Smashing Magazine, WP Tuts+, та WP Candy.

Розумійте технології

Якщо ви збираєтеся освоїти WordPress, як розробник, ви повинні розуміти ті технології, які лежать в його основі. Якщо ви вже програміст і PHP/MySQL не є новими для вас, чудово. Переконайтеся, що ваші навички є сучасними. Якщо ви новачок у програмуванні, почніть навчання.

Ось кілька напрямків для початку:

  • - Вивчіть PHP і MySQL
    Дуже важливо знати PHP та MySQL, особливо важливо знати “найкращі практики”. Застарілі підручники не допоможуть вам у цьому. І те, що ви дізналися кілька років тому, зараз може виявитися неактуальним. Чи не впевнені з чого почати? Почніть з Lynda.com або Learnable.com. Дізнайтесь про продуктивність MySQ L.
  • – Досліджуйте Codebase
    Знайдіть час, щоб вивчити код WordPressна Trac і Xref. Прочитайте документацію, щоб зрозуміти, як усе влаштовано. Подивіться, що вам не зрозуміло і запитайте. Ознайомтеся із тим, як WordPress структурована.
  • – Поставте Nightly build (тестову версію)
    Налаштуйте локальне середовище розробки та запустіть Nightly build як засіб залишатися обізнаним про шлях розвитку WordPress.
  • – Читайте “Make WordPress”
    Хороший спосіб зрозуміти технологію – стежити за розвитком дискусій, які відбуваються на make.wordpress.org. Ви можете стежити за обговоренням ядра, плагінів та тем для початківців.

Робіть “Домашнє завдання”

Виконуйте на практиці те, чого ви навчаєтесь. Почніть із власних веб-сайтів на WordPress. Після прочитання підручника зробіть отримані знання. Експериментуйте. "Розбирайте" існуючі проекти. Контролюйте свої знання та записуйте ваші ідеї та міркування на майбутнє. Витратьте стільки часу, для власних проектів та експериментів, скільки ви можете.

Ось кілька областей для розвитку:

  • - WordPress API
    Почніть ознайомлення зі списком доступних API-інтерфейсів у Codex. Прочитайте інформацію, доступну для кожного API та експериментуйте з кожним з них (деякі виявляться легшими за інші). Шукайте підручники для кожного з API, для розуміння реальних перспектив та того, що можна зробити з кожним.
  • – Ajax у WordPress
    Навіть якщо ви вже знайомі з Ajax, дізнайтеся про його використання Ajax у WordPress. Потім переходьте до використання Ajax для розробки плагінів. Шукайте підручники для розвитку власних знань.
  • - WordPress PHP класи
    Ознайомтеся зі списком класів, створених розробниками WordPress. Експериментуйте з ними у власних проектах та опановуйте їх. Зокрема, зверніть особливу увагу на WP_Query , WP_Theme і wpdb . Шукайте посібники з кожного з класів, а також сторонні спільноти, такі як WPAlchemy .

Отримайте досвід роботи з WordPress


Ваша освіта йде повним ходом, настав час отримати реальний досвід – і у великій кількості. Ваш шлях до вершини вистелений випробуваннями та труднощами. Отримуваний на майданчиках власних проектів досвід є важливим кроком у правильному напрямку. Один із найкращих способів отримання досвіду – почати робити роботу для інших.

Знайдіть клієнтів

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

Створіть тему

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

Розробте плагін

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

Запропонуйте доопрацювання

Приєднайтесь до спільноти WordPress


Публікуйте посібники

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

Зробіть вклад у Codex

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

Беріть участь у форумах

Більшість початківців розробників WordPress ставлять питання на офіційному форумі підтримки (прим. перекладача: в оригіналі посилання на wordpress.org/support). Відповідайте на їхні запитання (навіть на безглузді, а вони основні – ми всі з чогось починали). Потім станьте активним членом WordPress Stack Exchange community . Відповідайте на запитання та вивчайте відповіді, які дають інші розробники.

Беріть участь у WordCamps

Відвідайте майбутній WordCamps. Вірною ознакою майстерності є можливість навчити когось іншого, ніж ви володієте самі. Читайте Diary Of A WordCamp. Бажаєте ускладнити завдання? Станьте організатором та проведіть WordCamp поряд з вами.

Висновок

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

Опубліковано 30.8.2012