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 со старым, глючным кодом, и не сможет обновляться дальше без риска поломать сайт. То есть, глобальные правки неизбежны, рано или поздно их придется делать. Так вот, чем раньше начать - тем меньше риск потерь в будущем.
Rokis: next_post_link() существует только НА СЕРВЕРЕ, это PHP. На клиенте (в браузере) выполнется Javascript. И вместо next_post_link() там будет уже сгенерированный HTML-код. Связывать надо с ним.
Rokis: Логика такая - при нажатии кнопки (какой - определяете сами в скрипте) вызывается нужный урл. Конкретных примеров в гугл - тонны. Я вам ключевые слова специально для этого написал. Если вы не знаете javascript и надеетесь найти готовый "плагин на jquery" - так и говорите.
dimasmagadan: Так, не надо передергивать и сравнивать с какими-то другими плагинами, которые не срослись. REST API уже давно стабильна и используется на тысячах крупных сайтов, в production. Включение в ядро официально пошло только сейчас, неофициально работа над этим (и тестирование) идет уже очень давно. Долго и частями - только потому, что это достаточно массивная склейка. Качайте плагин REST API и пользуйтесь на здоровье. В декабре часть АПИ уже будет в ядре, остальное - останется в плагине. На работу никак не повлияет.
По поводу версий вы путаетесь. Есть ветка v1, есть v2. И есть ответвление v2, которое урезано и совместимо уже с WP 4.4 - по сути, вырезали часть v2 и внедрили в ядро, остальное оставили в v2a (название мое, условное).
> Смотря по каким параметрам подбирать)
Я не про холивары и параметры. Если вам надо под каждую новую версию WP или плагина кучу всего своего переписывать - у вас большая проблема с архитектурой вашего кода.
> бывают случаи, когда подойдет только нестандартный код
Я в курсе. Но и в 9 случаях из 10 этот нестандартный код не надо изобретать.
REST API вполне подходит, зря вы его откидаете. Если вы ждете релиза - у вас действительно не очень хорошо с архитектурой и планированием. Вы должны к релизу быть готовы заранее. На крупных и сложных проектах, тем более с кучей кастомного кода, у вас уже давным давно должен быть staging сервер, на котором полная копия вашего сайта УЖЕ крутится на WP 4.4 alpha / beta.
