Как раз для себя отвечал на этот вопрос - почему всё-таки Wordpress не только меня привлекает, но и, по состоянию на сегодня, является CMS #1 в мире.
Что нравится лично мне:
Я могу реализовать на WP проекты самой разной направленности и сложности. WP - это не CMS, это практически фреймворк с большими возможностями.
Встроено много удобных инструментов - если ими умеешь пользоваться, то можешь влиять на любой этап загрузки и работы системы, т.е. я знаю как устроено ядро и загрузка и способен изменить поведение системы в необходимом мне направлении.
Достаточно хорошо продуманная система базы данных - я, конечно, могу добавить или удалить нужные таблицы, но в большинстве случаев мне достаточно тех таблиц, что встроены в систему и я могу легко ими пользоваться. Касается это не только создания типового контента, но и контента самой различной направленности - для товаров, уроков или постов используются одни и те же таблицы и поля, и их структура покрывает потребности разработчика.
Когда вы работаете с картинками, возможно у вас возникает искушение перейти на Joomla, Opencart или, не дай бог, Битрикс. В отличии от этих систем Wordpress создал не только дружелюбный интерфейс для пользователя, но и дружелюбную среду для разработки - т.е. это и низкий порог вхождения (писать код для wordpress можно не зная всю систему досконально), и множество встроенных инструментов (шорткодов, хуков, фильтров), и расширяемые классы, и удобное встраивание в админку. При этом полно хорошей документации для начинающего разработчика.
Легко настраиваемая среда мультисайтовости
Конечно, простое администрирование и надежность. Для передачи проекта администратору мне не приходится его долго и нудно обучать и принимать экзамен (как в Битрикс). И меня не пугает выход из строя системы (не знаю как сейчас, но раньше это было большой проблемой Joomla - белый экран смерти) - всё решается просто включением и отключением плагинов или тем.
Наличие системы быстрого доступа через WP CLI.
...
Наверное много можно ещё перечислять преимуществ. Я выбрал эту CMS с точки зрения разработчика, а не администратора. Разрабатывал плагины мультивендерных систем, автопереводов, платежных систем и т.п. Во всех случаях CMS проявила себя очень хорошо. А какими картинками это обставлено - меня мало интересует.
Не могу сказать конкретно по этому функционалу - может быть есть что-то лучше (имею ввиду в других CMS). Но если брать в целом, то лучше Wordpress я не видел CMS. У меня есть опыт разработки под Joomla, Opencart, Bitrix, работал с некоторыми мелкими CMS. Помимо широкого инструментария, Wordpress очень устойчивая система, множество возможностей управления контентом, организации взаимодействия плагинов. Т.е. при правильной организации плагина я могу предоставить возможности для другого разработчика управлять всем необходимым в моём плагине, встроится в процессы другого плагина без необходимости что-то там исправлять и т.п.
ACF - это банальный пример расширения возможностей. В ближайшее время планирую несколько статей по другим аспектам разработки под Wordpress - если ознакомитесь, возможно пересмотрите своё отношение. По моему опыту - Wordpress - лучшая CMS на сегодняшний день.
Возможно мы по разному с вами видим задачи этой статьи. Я не искал философии разработчиков ACF, моей основной задачей было разобрать устройство конкретно этого плагина - я это сделал.
По поводу того, что большинство данных в WP имеет Meta надстройку - да, это так, я это использую в разработках на своём уровне. Но это никак не влияет на то, как устроен ACF.
Со своей стороны скажу, что вообще вижу мало подобной информации, поэтому и написал статью. Она приземленная, она не ищет варианты, она просто рассказывает разработчику то, что он возможно не знает где найти.
И да, поддержу вас в том, что неплохо бы написать ещё информацию об устройстве других данных в WP - в том числе все Meta надстройки неплохо было бы описать. И виджеты, и сохранение Image, и типы полей. Но это всё уже цели для следующих статей. Пока я стартовал с простого устройства ACF.
Да, у WP есть достаточно инструментов для того, чтобы добавлять и редактировать мета информацию. И да, действительно, ACF только использует тот же функционал. В этом нет ничего нового. Но иногда не хватает функционала, который есть в ACF и приходится поверх него писать свой, используя тот функционал, который он дает.
Т.е. я не предлагаю создавать поля и писать свой ACF, но в случае необходимости дописать функционал для него можно, для этого нужно понимать как поля устроены изнутри.
Для многих разработчиков такой задачи вообще может быть никогда не будет стоять.
А для большинства клиентов и версия PRO для их задач не нужна.
Наверное. Но у меня нет речи о том, что нужно добавить какие-то поля. Я вывожу заполнение полей во фронтенд и получаю из БД условия по которым эти поля будут получены. Этого нет ни в обычной версии, ни в версии "про".
По-сути, все кастомные поля пользуют функционал вордпресса и они ничего не вносят в БД, просто создают функционал для управления тем, что уже имеется.
В примере я поставил понятные условия, для которых очень часто используются кастомные поля. Но, конечно, фантазии по использованию могут быть разные.
Проблема с которой я столкнулся - это вынести заполнение полей за пределы админ панели, при этом сохранив все условия применения. Внутри админки дописывать функционал не имеет смысла, там всё великолепно.
Как раз для себя отвечал на этот вопрос - почему всё-таки Wordpress не только меня привлекает, но и, по состоянию на сегодня, является CMS #1 в мире.
Что нравится лично мне:
Я могу реализовать на WP проекты самой разной направленности и сложности. WP - это не CMS, это практически фреймворк с большими возможностями.
Встроено много удобных инструментов - если ими умеешь пользоваться, то можешь влиять на любой этап загрузки и работы системы, т.е. я знаю как устроено ядро и загрузка и способен изменить поведение системы в необходимом мне направлении.
Достаточно хорошо продуманная система базы данных - я, конечно, могу добавить или удалить нужные таблицы, но в большинстве случаев мне достаточно тех таблиц, что встроены в систему и я могу легко ими пользоваться. Касается это не только создания типового контента, но и контента самой различной направленности - для товаров, уроков или постов используются одни и те же таблицы и поля, и их структура покрывает потребности разработчика.
Когда вы работаете с картинками, возможно у вас возникает искушение перейти на Joomla, Opencart или, не дай бог, Битрикс. В отличии от этих систем Wordpress создал не только дружелюбный интерфейс для пользователя, но и дружелюбную среду для разработки - т.е. это и низкий порог вхождения (писать код для wordpress можно не зная всю систему досконально), и множество встроенных инструментов (шорткодов, хуков, фильтров), и расширяемые классы, и удобное встраивание в админку. При этом полно хорошей документации для начинающего разработчика.
Легко настраиваемая среда мультисайтовости
Конечно, простое администрирование и надежность. Для передачи проекта администратору мне не приходится его долго и нудно обучать и принимать экзамен (как в Битрикс). И меня не пугает выход из строя системы (не знаю как сейчас, но раньше это было большой проблемой Joomla - белый экран смерти) - всё решается просто включением и отключением плагинов или тем.
Наличие системы быстрого доступа через WP CLI.
...
Наверное много можно ещё перечислять преимуществ. Я выбрал эту CMS с точки зрения разработчика, а не администратора. Разрабатывал плагины мультивендерных систем, автопереводов, платежных систем и т.п. Во всех случаях CMS проявила себя очень хорошо. А какими картинками это обставлено - меня мало интересует.
Не могу сказать конкретно по этому функционалу - может быть есть что-то лучше (имею ввиду в других CMS). Но если брать в целом, то лучше Wordpress я не видел CMS. У меня есть опыт разработки под Joomla, Opencart, Bitrix, работал с некоторыми мелкими CMS. Помимо широкого инструментария, Wordpress очень устойчивая система, множество возможностей управления контентом, организации взаимодействия плагинов. Т.е. при правильной организации плагина я могу предоставить возможности для другого разработчика управлять всем необходимым в моём плагине, встроится в процессы другого плагина без необходимости что-то там исправлять и т.п.
ACF - это банальный пример расширения возможностей. В ближайшее время планирую несколько статей по другим аспектам разработки под Wordpress - если ознакомитесь, возможно пересмотрите своё отношение. По моему опыту - Wordpress - лучшая CMS на сегодняшний день.
Это был коварный план. Вы меня раскрыли :)
Возможно мы по разному с вами видим задачи этой статьи. Я не искал философии разработчиков ACF, моей основной задачей было разобрать устройство конкретно этого плагина - я это сделал.
По поводу того, что большинство данных в WP имеет Meta надстройку - да, это так, я это использую в разработках на своём уровне. Но это никак не влияет на то, как устроен ACF.
Со своей стороны скажу, что вообще вижу мало подобной информации, поэтому и написал статью. Она приземленная, она не ищет варианты, она просто рассказывает разработчику то, что он возможно не знает где найти.
И да, поддержу вас в том, что неплохо бы написать ещё информацию об устройстве других данных в WP - в том числе все Meta надстройки неплохо было бы описать. И виджеты, и сохранение Image, и типы полей. Но это всё уже цели для следующих статей. Пока я стартовал с простого устройства ACF.
Да, у WP есть достаточно инструментов для того, чтобы добавлять и редактировать мета информацию. И да, действительно, ACF только использует тот же функционал. В этом нет ничего нового. Но иногда не хватает функционала, который есть в ACF и приходится поверх него писать свой, используя тот функционал, который он дает.
Т.е. я не предлагаю создавать поля и писать свой ACF, но в случае необходимости дописать функционал для него можно, для этого нужно понимать как поля устроены изнутри.
Для многих разработчиков такой задачи вообще может быть никогда не будет стоять.
А для большинства клиентов и версия PRO для их задач не нужна.
Наверное. Но у меня нет речи о том, что нужно добавить какие-то поля. Я вывожу заполнение полей во фронтенд и получаю из БД условия по которым эти поля будут получены. Этого нет ни в обычной версии, ни в версии "про".
Поэтому я разбираю как эти поля устроены.
По-сути, все кастомные поля пользуют функционал вордпресса и они ничего не вносят в БД, просто создают функционал для управления тем, что уже имеется.
В примере я поставил понятные условия, для которых очень часто используются кастомные поля. Но, конечно, фантазии по использованию могут быть разные.
Проблема с которой я столкнулся - это вынести заполнение полей за пределы админ панели, при этом сохранив все условия применения. Внутри админки дописывать функционал не имеет смысла, там всё великолепно.
Ошибку исправил. Вы правы, это сериализованный массив.