все норм настроено, но в админке не добавляет поля, то-есть на данный момент есть 244 поля куда МЫ ЗАЛИВАЕМ ФОТКИ, НО ПОСЛЕ 244 не заливается, но логично, последнюю удаляем и все норм опять до 244, вопрос, в чем, есть ли лимиты или это баг? и как исправить?
Разработчики просто не думали, что кто-то будет создавать 244 однотипных поля. Это либо ограничение в БД, либо ограничение в самом плагине. Исправляется просто - создаете одно поле photo, и много записей с фотками к нему. Вы не по назначению используете плагин, я так подозреваю.
Это ограничение PHP, смотрите матчасть. БД пофиг, плагину пофиг. PHP, собственно, тоже пофиг, просто попросите его принимать больше переменных в запросе.
Игорь Воротнёв, так а я откуда знаю, как именно там все сделано? Я просто знаю, что плагин используется неправильно, а почему конкретно там 244 поля максимально возможны, мне неведомо.
Алексей Николаев, Что и где сделано? max_input_vars – это опция самого движка PHP, с ней рано или поздно сталкиваются все на своем жизненном пути когда начинают работать с относительно большими объемами данных. WordPress, данный плагин и то как он сделан здесь вообще ни при чем. Это такое же ограничение, как лимит на объем загружаемых файлов, который по умолчанию 2Мб, но в 99% случаев этого мало и все поднимают до необходимого уровня.
Плагин используется абсолютно нормально и правильно. С чего вы взяли, что неправильно? У меня на одном из проектов Repeater Field используется для табличных данных, там несколько сотен строк - абсолютная норма. На другом проекте используется Flexible Content Field, который в свою очередь использует не только поля с данными, но и всякие Tab, Accordeon, Group и тому подобные, которые тоже передаются. В самом Flexible Field 2 десятка темплейтов, в каждом от 5-6 до 30-40 полей. В результате при сохранении передается сильно больше тысячи input_vars. Что в этом неправильного?
Игорь Воротнёв, как правило, когда количество однотипных строк больше 100, уже появляется осознание, что что-то не так, и обычно при этом начинается рефакторинг и пересмотр архитектуры. Вот я вам аналогию приведу - в вашей таблице 244 колонки, она тормозит и глючит. Технически, все работает, но это неправильно.
Например, я на 99% уверен, что эти 244 поля с картинками можно было бы заменить одной галереей или списком id, которые сохранялись бы одним input_var в виде строки или сериализованного массива. Полагаю, даже есть такой плагин или дополнительное поле для ACF.
как правило, когда количество однотипных строк больше 100, уже появляется осознание, что что-то не так, и обычно при этом начинается рефакторинг и пересмотр архитектуры
Да, если есть понимание этого всего со стороны клиента, а также время и бюджет на рефакторинг. В идеале, так и должно быть. Но мы в реальном мире живем, увы.
Вот я вам аналогию приведу - в вашей таблице 244 колонки, она тормозит и глючит
У меня нет таких таблиц, и в WP таких таблиц нет. ACF по умолчанию хранит все в wp_postmeta, в которой 4 колонки. В приведенных мною примерах используется произвольный процессинг который сохраняет данные в отдельные таблицы (это и есть элемент пересмотра архитектруы), спроектированные конкретно под эти задачи. Метаданные не засоряются и не используются вообще.
Технически, все работает, но это неправильно.
Для начала, у нас тут WordPress. Слово "правильно" в контексте такого legacy приложения неуместно по определению.
Например, я на 99% уверен, что эти 244 поля с картинками можно было бы заменить одной галереей
А откуда вы знаете что там не галерея? Или Repeater с Image field, что по сути не сильно отличается друг от друга?
или списком id, которые сохранялись бы одним input_var
Вот в этом месте, как мне кажется, всплывает недоразумение. Подозреваю, вы не совсем поняли что такое input_var и откуда их так много у топикстартера.
Во-первых, это не 244 разных поля. Это скорее всего 1 ACF поле (Gallery, Repeater - не принципиально), которое дублируется и повторяется. И когда этих элементов становится 244, при сабмите в массиве $_POST это выглядит приблизительно так:
То есть, массив $_POST содержит 244 элемента для картинок (ID) + столько же элементов для сохранения уникального ID поля (так работает ACF, он использует этот ключ на выводе для форматирования данных). Отсюда получаем 244 + 244 = 488 input_vars. Добавим сюда сабмит, nonce и referrer, еще какие-нибудь скрытые поля, возможно парочка других ACF полей рядом, а также тайтл, визуальник и прочие родные WP поля. Вот мы и уперлись в max_input_vars - PHP получает, скажем, 522 input_vars от этой формы, а лимит у него 500. Значит 22 последние input_vars будут просто проигнорированы. Они будут отсутствовать в массиве $_POST, а значит не придут в обработчик, а значит не будут сохранены. Но если изменить этот параметр в php.ini, то эти переменные зайдут без проблем.
Короче говоря, проблема - между отправкой формы с клиента и получением данных в $_POST серверным обработчиком. Часть данных к обработчику просто не доходит, сам движок PHP их обрезает. Поэтому как там вы собрались сериализовать, или в строку клеить - это как бы никому не интересно. Потому что необходимых данных попросту нет. Они до обработчика не долетают.
Можно ли это обойти? Да можно конечно, и вариантов масса - можно например запилить hidden поле и в него на before_submit все картинки сериализовать, остальное удалять и даже не передавать. А потом на бекенде строку разбирать и обрабатывать. Но зачем? Просто измените дефолтную конфигурацию PHP, и вопрос изчезнет. Дефолтные конфиг не означает, что его нельзя менять. Значение в 500 input_vars - это среднестатистическое. Если вам надо 1000 и более - ставьте, это абсолютно нормально.
И еще раз, объясните почему же автор неправильно использует плагин?
Игорь Воротнёв, ну вот именно это я и имел в виду под input_vars. Гораздо легче во всех смыслах выглядит отдельная галерея, и в записи одно поле, где мы просто выбираем ее по ID.
И еще раз, объясните почему же автор неправильно использует плагин?
Под "правильно" я подразумеваю соотношение цели использования к назначению. Потому что для всего должна быть мера. Этот плагин создавался для того, чтобы расширить пользовательские поля для сущностей, дать сущностям определенные атрибуты. У него очень богатые возможности - при должном подходе на его основе можно даже формы конструировать. Например, для подписки на рассылку или какой-нибудь тест-викторину. Но наличие возможности что-то сделать еще не означает, что данный тип реализации будет технически и семантически корректным. Это все равно, что использовать table вместо p, и все вообще таблицами размечать, хотя возможность такая есть, и кому-то, может, так будет даже удобнее. Само собой, это лишь мое мнение, не претендующее на истину в последней инстанции, но мне страшно представить 200+ полей на одной странице)
Алексей Николаев, простой тест показывает, что разница между Gallery Field и Repeater Field + Image есть, но не такая уж и разница, в контексте input_vars:
Сверху галерея, снизу рипитер.
И да, я полностью согласен, что если речь только о куче картинок, то Gallery Field однозначно выигрывает. Впрочем, у автора вполне может быть что рядом с картинкой в паре идет еще какое-то поле (и не одно), тогда галерея отпадает и мы возвращаемся туда, откуда начали.
Плюс, в обеих случаях проблема совершенно в другом - получить что 1 строку, что 10 000 из wp_postmeta по ключу post_id - практически одно и то же. Это non-unique index, запрос не проблема. А получаются метаданные как раз все вместе, за один запрос в prime_meta_cache. А вот что действительно добавит нагрузки, так это получение этих картинок. В обеих случаях хранится attachment_id, а это означает дополнительный get_post на каждую картинку + все тот же prime_meta cache (ну или если кеш выключен - все равно получение всех meta для записи при первом вызове). И этого не избежать, что с галереей, что с рипитером и картинкой.
Я что имею в виду - оптимизация через тип поля ACF - это и не оптимизация вообще. Эффект несущественный. А вот что можно было бы сделать - и я делал не раз для своих проектов - так это добавить настройку в ACF Image Field СОХРАНИТЬ image path (YYYY/MM/filename.ext) в мета, а не только его ID. Вот в этом случае мы можем выводить картинки сразу из wp_postmeta, без дополнительных запросов на аттачменты и их метаданные. Да, придется еще допилить стопочку коллбеков на удаление аттачмента из библиотеки и тд, сделать оберточку для получения кропнутого размера и тд, но зато количество запросов к БД и добрый кусок лигики срезается. Вот это уже оптимизация, которая даст ощутимый эффект.
В целом, мысли то у нас правильные. Я согласен с тем, что надо думать над архитектурой в первую очередь, а в случае эволюции требований - рефакторить. Но, увы, далеко не всегда клиенты дают нам такую возможность. Вот и автор вопроса пришел с конкретной проблемой. Которая решается одной строчкой в конфиге php.ini. А все остальное - лирика :)
