Tremo: Это функция ядра WP, которая собирает и отправляет письмо. Внутри она использует PHPMailer. Это всего лишь интерфейс для отправки почти. Письмо будет уходить тем транспортом, который настроен для PHP на уровне сервера. Есть плагины, которые позволяют слать через SMTP, альтернативным транспортом. Либо по АПИ (как SendGrid и подобные сервисы). В этом случае отправка перехватывается и уходит не через системную почту, а внешнюю. Но тут важно понимать, что это за почта. Какой-нибудь обычный SMTP вашего домена на хостинге - это 99% попадания писем в спам и в черные списки, так никто уже давно не делает. Если же у вас внешний SMTP Google или Яндекс например, то это уже лучше - они не будут сильно падать в спам, но там есть лимиты на количество писем за единицу времени. Есть и другие нюансы. А вот SendGrid (у них есть свой плагин) работает именно так как надо - не падает в спам, нету лимитов, есть дополнительные плюшки и тд. В общем, это специальный сервис, созданный конкретно для этой задачи.
Vitaliy Orlov: Вы таки не шутите? Под экосистемой я имею в виду в первую очередь родные API и функционал ядра, которые можно (и нужно) использовать.
1. Парсер? Собирает новости? Заливает в базу? Рили? Заняться нечем?
2. Виджет грабит поток? Виджет в WP - это UI и обертка для функционала. Функционал может грабить поток (я так понимаю речь об RSS-потоке). Вариант, который и я упомянул, но из вашего объяснения мало понятен.
3. Коннектиться к базе (!!!) другого проекта? Серьезно?
4. Да, JSON можно, вопрос в том, при чем тут виджеты опять? А вот как раз про самую важную часть - как этот JSON сгенерить и отдать вы умолчали.
5. Ифрейм. Ну серьезно?
Вы не с экосистемой связываться не хотите, а просто не зная возможностей платформы (как сделать правильно), пытаетесь прорубить окно топором. А потом мы годами боремся с вредными привычками типа использования query_posts и тд.
i_want_to_know_everything: Максим свое дело знает) Опять же, как я писал в комментарии к ответу Максим Тимофеев при 50к тормозить не должно и на шареде, если он адекватен. На VPS нормальном и подавно. Прелесть ES в том, что это полный off-load нагрузки и по индексации БД, и по поиску-фильтрации, что очень удобно и полезно, особенно в пиковых режимах. Сам по себе поиск идет по АПИ в другом месте, возвращаемый результат - массив ID товаров, которые выводятся одним простым WP_Query с аргументом post__in.
i_want_to_know_everything: по поводу "работают как-то так" - 100% :) По поводу скорости, увы, боюсь что нормального решения нет. Я не пилил в виде плагина, но рефакторил существующие на весьма крупных екоммерсах и делал с нуля когда проекты целиком мы делали. В конечном итоге все сводилось к тому, что Elastic Search - единственное правильное решение для крупного магазина. Но не для шареда, естественно. Впрочем, более-менее крупный магазин и шаред - вещи изначально несовместимые.
i_want_to_know_everything: Ну кроме граблей в виде промежуточных таблиц и своих кастомных SQL-запросов других вариантов на шареде нету. Выборки по таксономиям быстрые, по метаданным - нет, такова архитектура WP, поиск-фильтрация как таковые в нем не для таких задач. Для таких задач есть сторонние решения, в чем с ними проблема? Я не совсем понимаю, почему не подходит ElasticPress + ElasticSearch Cloud. Или вы свой плагин фильтрации пилите, поэтому пытаетесь сделать лучше аналогов?
в БД WordPress все нужные индексы уже есть, а запросы в целом вполне себе норм. По таксономиям все работает шустро, по мета-данным - вот там как раз индексы не особо предусмотрены и их добавление сильно ситуацию не спасет. Другое дело, что даже на шареде при 50к записей тормозить не должно еще, надо все остальное смотреть. И оbject cache таки да, заметно ускорит. Впрочем, не факт что он есть даже на дорогом шареде, или что выделенной памяти хватит, а то будет постоянная гонка за место в стеке, а не нормальный LRU. Вообще, конечно, делать такие сложные фильтры и с такой БД держаться за шаред - имхо какое-то странное решение. Тут по большому счету любая платформа может подтормаживать. Берется нормальный VPS, ставится специализированный Elastic Search и все, вопрос решен.
Георгий: у меня оно в meta и options было. поэтому легко менялось. Что касается attachment_url то да, тут так просто не избавиться. Смотрите библиотеки/плагины для offload-а на сторонние сервера
