Вы пытаетесь совместить несовместимое. Зачем Вам в качестве REST API использовать CMS? Это же извращение!
Нет здесь никакого извращения. Есть бекенд (WordPress) с удобной и привычной для клиентов (простых людей) админкой. Есть фронтенд, который по тысяче причин может быть реализован как SPA (Vue, React, Angular - тут уже не принципиально). И есть REST API, которые позволяет фронту забирать данные с бекенда. Все в профите - клиент работает с привычной админкой, фронт летает. В чем проблема?
Вы рассмотрели ситуацию с точки зрения технической архитектуры, но забыли про бизнес-составляющую. Потому что да, можно и на фронте запилить свою админку на Vue, и тогда WP будет не нужен, можно обойтись минималистичным беком. Но это дольше, дороже, сложнее. А у клиента бюджет и сроки. Или у клиента legacy сайт, которому сто лет, и он изначально на WP. И еще масса нюансов.
Александр: ааа) так это другое дело. В javascript прилетает html-разметка необходимых результатов (записей/товаров), или только json с данными? Если уже html, то вам нужно просто заменить контент DOM-элемента, если json - то нужно в javascript из темплейта сгенерить нужный html, и только тогда заменить его.
Что касается самой замены - допустим, html у вас находится в javascript-переменной response.data, а контейнер, в который его надо вставить (с заменой текущего контента) имеет id="content". Тогда код jQuery будет таким:
$( '#content' ).html( response.data );
Если у вас новый контент добавляется к старому, значит вы скорее всего используете append() вместо html()
Anton Antonov: если вдруг у вас не отображаются поля которые начинаются с символа _ (подчеркивание) - то так и должно быть. А вообще стандартный интерфейс весьма примитивен, поэтому рекоммендуется пилить свои метабоксы или использовать ACF. Почему не хотите его юзать?
Алексей: та когда-то делал это уже, была у клиента аналогичная задача. Четко помню, что перепробовал тогда разные методы, и такой - единственный рабочий. Порылся, но проект тот старый не нашел, пришлось написать заново :) Заодно себе в шпаргалку сохранил, на будущее может пригодиться еще.
Денис Янчевский: Да? Тогда сорян за дезу, я такого нигде не встречал, но вполне мог и пропустить эту новость. В таком случае это, конечно же, печально. Для нбеольших сайтов это было очень хорошее и шустрое решение.
Александр: Я понимаю, как работают фильтры, нет необходимости объяснять очевидные вещи :) Вопрос был в другом. У вас интернет магазин и надо товары фильтровать по характеристикам? Характеристики эти каким образом реализованы - это product attributes? Или у вас свои произвольные таксономии / произвольные поля? От всех этих технических нюансов сильно зависит конкретная реализация. А если в общем и целом, без этих данных, то ответ такой же общий - ajax. Аякс позволяет с помощью javascript отправлять запросы на сервер и получать ответ. Собираете с помощью javascript значения выбранных фильтров, и отправляете с помощью ajax запрос на сервер. Запрос идет на ваш собственный обработчик, который висит на хуке. Обработчик принимает значения фильтров, переданные ему из javascript, делает выборку товаров по ним и возвращает данные для отображения. Javascript-обработчик, отправивший этот ajax-запрос, примет ответ от сервера и заменит контент в нужной области страницы. Вот так это работает. Если вы разработчик - данного описания должно хватить, чтобы понять процесс. Ссылка, приведенная Евгений Кылин поможет реализовать это. Если вы не разработчик - ищите готовый плагин, их в сети достаточно. Например, https://facetwp.com/
RavenPo: вот это уже лучше. Только один вопрос - вы уже разобрались и все сделали? Если нет - тогда зачем поотмечали все ответы как верные, если ни один не является по сути ответом на ваш вопрос))
Денис Юдин: Далеко не всем плагинам необходимо обновление каждую неделю. Это ни о чем не говорит. Вопросы в поддержке в основном либо из-за несовместимости с другими плагинами (что чаще проблема тех плагинов), либо из-за того что люди не почитали доку. Никто не тратит время на пустые ответы идиотам != плагин плохой или заброшен. Это опен-сорс. Основная жизнь плагина тут: https://github.com/qTranslate-Team
ommunist: Починили утечки памяти, сделали пару фич (как автопоиск ID) опциональными (впрочем, через жопу - через opt-out, а не opt-in) но сама архитектура как была, так и осталась. Я с ним годами работаю, у меня десяток сайтов на WPML, среди которых есть очень крупные и с 10+ языков. Неоднократно писались надстройки над WPML как раз для оптимизации его узких мест.
А откуда дровишки, что WPML не использует native gettext?
Я писал не WPML, а WordPress. Впрочем, WPML его тоже не поддерживает. А дровишки отсюда. Тикету больше 6 лет, на минуточку. Если вы еще не сталкивались с таким интересным узким местом, значит еще толком не сталкивались с мультиязычными сайтами на WP :) И я вам даже немножко завидую - у вас еще впереди целая гамма самых интереснейших эмоций по этому поводу )))
ommunist: ну, эт вы конечно сильно загнули по поводу удваивает-утраивает) Да, у архитектуры qTranslate и всех его форков есть недостатки. Впрочем, есть и плюсы. У того же WPML недостатков тоже хватает, и с производительностью там своя кухня. В стоковом виде он тормозит сильнее чем qTranslate. Вы же понимаете, что обычный SELECT в MySQL будет намного быстрее чем SELECT с несколькими JOIN? Даже если этот простой SELECT будет получать удвоенный объем информации в каждой строке выборки, это не снизит его скорость. А вот объединение данных из нескольких таблиц, как это делает WPML - еще как сказывается на производительности. А еще учитывая, что WordPress не использует нативный php-gettext, а использует свой медленный парсер, то микроскопические потери qTranslate вообще не имеют значения. Если говорить именно о скорости работы, то qTranslate - самый быстрый из всех вариантов.
qTranslate бесплатный, но раньше был жутко глючный
Вы немножко отстали от поезда :) Тот qTranslate который был глючный, давно заброшен. Годами уже. Существует с десяток форков, предложенный Карен Мнацаканян qTranslateX - абсолютно нормален. Подходит ли он по архитектуре - другой вопрос. Но сам плагин в полном порядке.
ommunist: переход на HTTP/2 уже не может быть преждевременным по определению, за исключением сайтов, ориентированных на госслужащих, которые сидят в конторках с древними IE на старых версиях Windows, и не имеют прав на установку обновлений.
Согласно текущей ситуации, 81% пользователей без каких-либо проблем принимает HTTP/2. Впрочем, оставшиеся 19% делятся в основном между мириадой старых версий мобильных браузеров, которые по умолчанию должны получать облегченную, мобильную версию сайта без всех этих спецэффектов, тонн скриптов и тд. Поэтому там fallback на HTTP/1.1 не сильно повлияет.
Поэтому, вопрос не в том, есть ли смысл переходить на HTTP/2 - тут ответ однозначно да, а в том, насколько заморачиваться progressive enhancement и делать урезанную мобильную версию для тех, кто застрял на старом железе и софте. В идеале, конечно же, надо делать. На практике - вопрос бюджета и целесообразности. Ну и да, надо открывать конкретную статистику конкретного сайта. Не исключено, что именно для этого сайта % браузеров без поддержки HTTP/2 вообще мизерный. ЦА, как я понимаю, вполне платежеспособная.
В вашем вопросе недостаточно информации, чтобы понять, на каком этапе вы находитесь. Уточните:
- на какой странице / шаблоне вы это пытаетесь делать?
- картинки - это просто картинки, или все же это посты с заглавными картинками?
- при переходе вам надо открывать страницу, или подгружать контент аяксом?
Алексей: ирония – это немножко другое. От слова совсем. Почитайте определение в словаре (это я вам как филолог по первому образованию говорю). А у вас – неуместный комментарий, который не отвечает на вопрос, не уточняет вопрос и вообще не несет никакой пользы. Большой недостаток Тостера по сравнению с тем же StackOverflow, что здесь нельзя ответы минусовать. Тогда бы люди воздерживались от подобных вбросов в попытке продемонстрировать свое неуклюжее чувство юмора и возвыситься над топикстартером путем мокания его мордочкой в дерьмо.
Вопрошающие на Тостер приходят с разным увронем знаний. Кто-то совсем в начале пути, кто-то уже продвинулся. Уровень знаний не имеет значения. Вы либо помогаете решить / уточнить вопрос, либо проходите мимо. И уж точно вам не следует решать за специалистов, на что им тратить свое время.
Нет здесь никакого извращения. Есть бекенд (WordPress) с удобной и привычной для клиентов (простых людей) админкой. Есть фронтенд, который по тысяче причин может быть реализован как SPA (Vue, React, Angular - тут уже не принципиально). И есть REST API, которые позволяет фронту забирать данные с бекенда. Все в профите - клиент работает с привычной админкой, фронт летает. В чем проблема?
Вы рассмотрели ситуацию с точки зрения технической архитектуры, но забыли про бизнес-составляющую. Потому что да, можно и на фронте запилить свою админку на Vue, и тогда WP будет не нужен, можно обойтись минималистичным беком. Но это дольше, дороже, сложнее. А у клиента бюджет и сроки. Или у клиента legacy сайт, которому сто лет, и он изначально на WP. И еще масса нюансов.