KOBZAR_09: видео-уроков не видел. Уверен, на ютубе что-то должно валяться (правда, на английском - на русском вероятность найти стремится к нулю). Если вам надо совсем просто, поищите еще плагины в стиле Wiki, FAQ - их много бесплатных в родном репозитории wordpress.org/plugins
Pshkll: Pods не менее мощный чем ACF, по некоторым фичам даже мощнее. Хотя с точки зрения UI и удобства интерфейса для простого пользователя - похуже, попроще. Для разработчиков же лучше - там внутри много полезного на уровне кода. Ну и, самое главное, он бесплатный. Что из них использовать - дело ваше. У меня ACF Pro, хотя все чаще делаю ручками, через свой код.
Pshkll: для этого нужен ACF Pro (платная версия), в котором есть Option pages. Поля добавленные на эту страницу будут храниться в wp_options и доступны через get_option() или get_field( 'field_name', 'options' ). У Pods эта фича бесплатная. У CMB2 кажется тоже.
WP Panda: Ну, я исхожу из той позиции, что если автор вообще задает подобный вопрос, то текущего функционала Customizer API + Kirki ему должно хватить с головой. К тому же, future proof.
По поводу settings api / frameworks - в этом и смысл. Можно сделать чисто под себя на базе АПИ, а можно взять готовый инструмент. Имхо, какой использовать - дело субъективное. И, хоть я согласен по поводу Redux, остальные пользуются огромной популярностью. Тот же Titan, например, для начинающих оказывается удобнее в освоении.
По ACF, Pods etc - если говорить с позиции разработчика, то соглашусь, конечно же. Но, тем не менее, эти плагины, являясь мощными комбайнами, решают вопрос настроек - с помощью своих Options pages и произвольных полей, значения которых, например, тот же ACF хранит в wp_options. Учитывая разнообразие полей + удобный интерфейс + отсутствие необходимости быть разработчиком или нанимать такового (noob friendliness) данный вариант вычеркивать нельзя.
stas3k: Это называется "кастомный функционал". Он был, есть и будет в любом проекте, это нормально. У того же WooCommerce прекрасная система хуков и фильтров, которая позволяет включиться в нужном месте и выполнить нужное действие (взять комиссию, например).
Inwork277: если делать с бесплатной версией ACF то да, можно и так. Хотя, ИМХО, это костыль. Например, если используется меню с автоматическими ссылками на страницы - придется добавлять эту страницу в игнор. Значение данного поля не кешируется "из коробки", то есть, +1 запрос в БД, еще парочка частных случаев (не факт, что они всплывут, но потенциально узкие места таки есть). Как по мне, то проще сделать через Settings API (см. мой ответ). С помощью генератора делается за 2 минуты, работает заметно лучше - с флагом autoload = yes грузится на раннем этапе и складывается в кеш, откуда с ним намного удобнее работать. Ну и своя страничка настроек как-то логичнее для такой задачи.
ACF в версии PRO (платной) поддерживает создание Option pages (страниц настроек), к которым и делаются нужные поля, которые должны быть доступны на уровне сайта, а не одного поста или страницы. Но это платный плагин. Для бесплатного решения см. мой ответ.
Mishko_kun: недавно несколько раз была проблема с доступностью BitBucket. В англоязычном твиттере активно обсуждалось дублирование, использование двух сервисов одновременно. Мы с недавних пор экспериментируем с таким дублированием. Одновременно 2 внешних репо, origin (BitBucket) и backup (GitLab). Ну и GitHub / BitBucket для open source.
Installation is a three-step process. First install the nagiosgraph files, then configure Nagios for data collection, and finally customize the graphs and links as needed. Installation can be done manually by copying files and modifying configuration files, or automatically using the install.pl script.
un1t: Графики не умеет? Да вы что :) Посмотрите, хотя бы, вот тут. Мы юзаем Nagiosgraph. New Relic очень даже realtime, просто за деньги. Именно поэтому я перечислил несколько сервисов. Ну а вообще, Linux Dash - самый легкий и удобный мониторинг в реальном времени. Поэтому я его тоже указал.
dimasmagadan: вы мою позицию немного не поняли и вцепились в REST API. Я вообще-то изначально помогал автору именно с отладкой и правками *текущей* версии. А про API упомянул как один из вариантов. Полностью поддерживаю мысль о том, что надо исходить из стоимости таких правок и бизнес-логики, а не "как надо по документации". С другой стороны, расходы надо считать не тактически, на данный момент, а стратегически - с горизонтом минимум на 1 год. А при учете такого горизонта - это версии 4.4, 4.5 (уже полное включение REST API), а также 4.6 и 4.7. Автор рискует застрять на 4.3-4.4 со старым, глючным кодом, и не сможет обновляться дальше без риска поломать сайт. То есть, глобальные правки неизбежны, рано или поздно их придется делать. Так вот, чем раньше начать - тем меньше риск потерь в будущем.
