Задать вопрос
  • Для маленькой студии или фриланса достаточно только Wordpress и woocommerce?

    avr1972,
    А как еще, кроме рекламы искать заказы?

    Начните с западных фриланс-бирж. Почему западных? Потому что если застрянете на местных, то встрянете в убогой низкокачественной нише дешевого говнокода за гроши. И вместо развития получите загнивание. И денег не заработаете, нищеброды которым надо новый стартап за $50 запилить вам счастья не принесут. Делайте клиентам хорошо, перепрыгивайте через свою же голову, и достаточно скоро сарафанное радио и постоянные клиенты закроют вопрос "кушать хочется".

    Я правильно Вас понял, что лучше не распыляться?

    Да. У Laravel свой порог входа. А чтобы на ларе делать все хорошо и по уму - там не один год опыта тоже нужен. По WP уже кое-что есть - этого достаточно чтобы начать закрывать вопрос "кушать хочется" и получать возможность развиваться дальше, параллельно.

    Ключевая мысль - развиваться надо в том направлении, которое "зажигает", а не то, где рыбка более жирная водится. Если зажигает - то будете лупить, пока не станете экспертом в этой сфере. А эксперты в любой сфере снимают сливки с рынка, это базовый закон экономики. Лучше быть высококлассным специалистом по WP, работать на самых интересных проектах с самыми толковыми клиентами и отлично зарабатывать, чем середнячком по Laravel и перебиваться тем, что перепадет, с кем попало.

    Но если Laravel прет, конечно развивайте это. Но ничто не мешает закрыть вопрос "кушать хочется" прямо сейчас с помощью более сильной стороны, которой у вас пока является WP.
  • Фуллстек веб-разработчики, какой средой пользуетесь?

    Roman Kitaev, ну, я его лично не пробовал, знаю только что он есть. Сам же на PhpStorm сижу, ибо PHP :)
  • Вывод статей в Wordpress на главной разного вида?

    Mike,
    конечно же под кастомностью я имел в виду параметры)

    В таком случае все-таки pre_get_posts :)
  • Как вставить элементы плагина в нужные места верстки?

    Артур Кудаев, Ну, вы написали "переделывать шаблоны". Обычно под переделывать имеется в виду модифицировать оригиналы. А здесь уместно "переопределять шаблоны". То есть, оригиналы вы оставляете в покое и делаете свои собственные, так как вам надо.
  • Вывод статей в Wordpress на главной разного вида?

    Mike,
    обычно когда формируют такие страницы, тянут не только посты, но и различные таксонометрии.


    Понятия не имею что такое "таксонометрии", но если вы про таксономии, то они в главном цикле (как и в любом произвольном WP_Query по умолчанию) и так тянутся с помощью update_post_caches(). Контролируются данные подзапросы с помощью параметра WP_Query 'update_post_term_cache' => bool'update_post_meta_cache' => bool для метаданных соответственно). По умолчанию стоит true, поэтому термины таксономий и метаданные получаются. Подучите матчасть.

    можно вместо if использовать switch.


    Не всегда. Switch является разумной альтернативой if/elseif/else, когда условия связаны в одну логику. В данном случае такой подход (if/elseif или switch вместо него) вполне может привести к дублированию кода. Использование серии if (без elseif/else) может быть более эффективным (вполне возможно тут надо будет row-обертки делать, например). Опять же, матчасть. Return early и прочие грамотности.
  • Вывод статей в Wordpress на главной разного вида?

    hiddenseek, да, смысл такой. Только у вас условий будет побольше, и кроме сравнений > < >= <= придется еще использовать оператор %. В общем, если хотите порешать ситуацию добавлением классов - тогда так. Если не боитесь CSS - попробуйте через nth-child
  • Как вставить элементы плагина в нужные места верстки?

    Артур Кудаев, А доку почитать тяжело? КАк вы собираетесь учиться, если не можете взять основу из официальной документации?

    Есть шорткоды фремворка, их можно переназначить или разработать свои. При переназначении создаете у себя в теме соответствующие папки и файлы, меняете все что вам нужно, и фреймворк будет использовать их вместо своих. Подробнее тут manual.unyson.io/en/latest/extension/shortcodes

    Вот вам еще пошаговая инструкция https://www.presstigers.com/adding-custom-shortcod... (правда она может быть немного устаревшая, но логику показывает)
  • Вывод статей в Wordpress на главной разного вида?

    Mike, ну если уже лезть в бекенд, то зачем кастомный WP_Query? В стандартном цикле, который идет по главному запросу все то же самое делается. Дополнительные кастомные запросы нужны для получения других постов, а не для изменения вывода стандартного запроса.
  • Вывод статей в Wordpress на главной разного вида?

    hiddenseek, Серьезно? 200+ Кб CSS, 300+ Кб JS не считая jQuery (от которого как бы не уйти, поэтому плюсуем еще его), полное наплевательство на семантику и адекватный DOM, ужасная каша из классов в HTML и тд. Одним словом - говнокод. Ну и тормоза.

    Все то же самое делается красиво и элегантно на ванильке. А если вы этим занимаетесь хотя бы год, то у вас уже есть (должны быть) свои либы / сниппеты, формируя таким образом свой собственный фреймворк, без всего этого мусора.
  • Вывод статей в Wordpress на главной разного вида?

    hiddenseek, хз, лично я бутстрап обхожу десятой дорогой, как место взрыва атомной бомбы
  • Плагин advanced custom filed pro?

    Алексей Николаев, простой тест показывает, что разница между Gallery Field и Repeater Field + Image есть, но не такая уж и разница, в контексте input_vars:

    5a708a8ae5dde012794162.jpeg

    Сверху галерея, снизу рипитер.

    И да, я полностью согласен, что если речь только о куче картинок, то 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. А все остальное - лирика :)
  • Плагин advanced custom filed pro?

    Алексей Николаев,
    как правило, когда количество однотипных строк больше 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 это выглядит приблизительно так:

    [
        'image_1' => '23',
        '_image_1' => 'field_{md5}',
        'image_2' => '24',
        '_image_2' => 'field_{md5}',    
        ...
        'image_244' => '345',
        '_image_244' => 'field_{md5}',    
    ]

    То есть, массив $_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 и более - ставьте, это абсолютно нормально.

    И еще раз, объясните почему же автор неправильно использует плагин?
  • Плагин advanced custom filed pro?

    Алексей Николаев, Что и где сделано? max_input_vars – это опция самого движка PHP, с ней рано или поздно сталкиваются все на своем жизненном пути когда начинают работать с относительно большими объемами данных. WordPress, данный плагин и то как он сделан здесь вообще ни при чем. Это такое же ограничение, как лимит на объем загружаемых файлов, который по умолчанию 2Мб, но в 99% случаев этого мало и все поднимают до необходимого уровня.

    Плагин используется абсолютно нормально и правильно. С чего вы взяли, что неправильно? У меня на одном из проектов Repeater Field используется для табличных данных, там несколько сотен строк - абсолютная норма. На другом проекте используется Flexible Content Field, который в свою очередь использует не только поля с данными, но и всякие Tab, Accordeon, Group и тому подобные, которые тоже передаются. В самом Flexible Field 2 десятка темплейтов, в каждом от 5-6 до 30-40 полей. В результате при сохранении передается сильно больше тысячи input_vars. Что в этом неправильного?
  • Плагин advanced custom filed pro?

    Это ограничение PHP, смотрите матчасть. БД пофиг, плагину пофиг. PHP, собственно, тоже пофиг, просто попросите его принимать больше переменных в запросе.
  • Почему говорят что jquery не нужен?

    Антон Мудренок, вообще-то в распакованном виде - сильно больше. Прилет по сети не принципиален - что 27, что 64. Браузер потом это дело распаковывает и охреневает от 200+ Кб жс который надо спарсить и обдумать, блокируя попутно рендеринг страницы (а часто - и загрузку других ресурсов). Особенно если jquery в head. Вот это и есть самое узкое место jQuery. Особенно когда на сайте нужно парочку простых операций с DOM, которые в нативе вылезут максимум в 50 строк кода на все про все.