В данном случае, будет достаточно встроить поиск от Гугла.
Что может быть хуже Wordpress? :) С чего вырастает монстр, да ещё и неповоротливый? Если делать нормально, то такого не будет.
Смотря что за сайт. Множество сайтов, а уж особенно блогов - можно перенести на статику с Wordpress и выйграть от этого.
С переносом сайта, можно будет заодно и с этим порешить.
В любом случае, даже если ничего не делать - сайт все равно будет работать шустрее, чем на Wordpress.
Для чего-то ещё, тоже можно использовать микросервисы
А что насчет таких функций, как поиск по сайту?
сильно не помогло, так как у меня много внешних запросов (~300-400)
которую кстати можно скачать бесплатно на просторах интернета
Вам такая вещь как returned user с точки зрения гугла и поведенческих - что-то говорит?Да, говорит. Какое это имеет отношение к физическому расположению файла в той или иной папке? Или даже по другому, внешнему урл (S3) - речь идет не о html-странице, а о скачиваемом файле. Факт скачивания отлавливается аналитикой на странице, которая никуда не перемещалась. А файл может лежать на S3.
Это логично?
я спросил конкретно, что за команда wp-json/oembed
если она пройдет успешно
каковы плюшки для того, кто ее засылает
пардон, видимо я плохо умею копаться в выдаче ПС.
я отдаю файлы клиентам весом 1,4гб (висят месяц. потом убиваю) Аплоудить их через станд.средства WP - зачем...
одно дело Alt text для изображений, что важно для SEO сайта фотографа (к примеру) Но все же, что WP должен "знать" о вместимости папки uploads и как он вообще ее должен "сканировать"? Впервые слышу.
Давайте отмотаем к вопросу - человек не может стандартными методами залить PDF
Наверняка весь функционал сведется к тому, чтобы клиенты смогли этот файл открыть/загрузить
Поэтому - вполне себе вариант.
Наверняка весь функционал сведется к тому
Но для сайта частной коммерции на shared wordpress hosting - это самый короткий путь решения ряда проблем.
Сайт грузится 2-3сек.
То же самое с баном по подсетям - я реализовывал это через htaccess вначале (ну что нагуглил то и юзал). Когда бан лист вырос до 100шт IP - вот тогда сайт начал тормозить и лагать.
Вот я о том же. Впрочем, по ним тоже есть нюансы - посмотрите тут на тостере историю моих ответов, я не так давно отвечал по поводу того как можно "ускорить" все эти маркетинговые инструменты, обернув их в задержку инициализации. Реально полезная штука, пару строк кода.
Ну, это проблема конкретного сайта и его сборки, как он исторически создавался и развивался. Все плагины можно либо заменить легковесными аналогами, либо написать свое. Это бич любых CMS / расширяемых инструментов - всегда будут "плагины", которые люди ставят для решения какой-то задачи, но используют реально 0.5% функциональности.
Если проект настолько плох, что речь реально не о постепенном рефакторинге, а о переписывании с нуля - дело конечно дрянь. Но я бы советовал все-таки сделать шаг назад, выдохнуть и подумать, взвесив +/-. Можно ли постепенно, по кускам данную поделку отрефакторить, заменяя фичу за фичей на адекватную реализацию? Если да - это будет самый дешевый и оптимальный подход. Если реально нельзя - тогда может есть смысл использовать другое динамическое решение, если проект того требует? Возможно какой-нибуть Statamic или October CMS. Это же не белое-черное (статика-WP), есть и другие варианты.
И да, не используйте пожалуйста слово функционал, это режущая ухо ошибка :) Это математический термин. То, что вы имеете в виду называется функциональность.
Разумно. Взвесьте и другие варианты (см. выше). Подсуммирую так - на WordPress можно делать быстрые, удобные и производительные сайты. Даже с использованием "передовых технологий" из мира PHP - composer, очереди, CI/CD и прочие вкусняшки. Все это можно. Но 95% рынка "вордпресс-разработчиков" даже понятия не имеют что это все такое. По моим наблюдениям, из 100% WP-разработчиков, где-то 60% - вообще не разработчики, а имплементаторы - эти умеют наставить плагинов и премиум-тему, натыкать в настройках, скопировать пару кусков кода со Stack Overflow и своей записной книжки (часто - устаревшего кода лет на 5-10). Еще 25% - это фулстаки и прочие разрабы, которые шарят в другом (чистом PHP, других CMS, других языках, фронтенд) и по сути разрабы, но недостаточно знают WP чтобы эффективно с ним работать - отсюда говнокод и костыли. Еще 10% - опытные WordPress-разработчики, которые хорошо знают именно WP, но часто отстают в развитии от PHP мира в целом, слегка застряли в прошлом. И только оставшиеся 5% - реально идеальная рабочая сила, которая умеет и в PHP, и в другие языки, и в WP. И умеет объединять разные инструменты и технологии для достижения оптимального результата. Вот этих и надо искать. Это будет дороже, но в итоге оно того стоит.