• Хороший хостинг под мои требования?

    gelot, предполагается, что для легитимного сайта здоровый человек заморачиваться поиском подобной мути не станет - нет совершенно никакого смысла / профита.
  • Стоит ли переезжать с Wordpress на статичные сайты (Gatsby, Jekyll, Hugo) и сколько это будет стоить?

    Bloodshot,
    Большая часть из них - это реклама и счетчики метрики от Яндекса и Гугла. И здесь ни вордпресс, ни статика не поможет.

    Вот я о том же. Впрочем, по ним тоже есть нюансы - посмотрите тут на тостере историю моих ответов, я не так давно отвечал по поводу того как можно "ускорить" все эти маркетинговые инструменты, обернув их в задержку инициализации. Реально полезная штука, пару строк кода.

    Также есть проблема в плагинах. Отказаться от них на 100% пока не получается, но многие из них вносят свой негативный вклад, много времени уходит на поиск и отладку.

    Ну, это проблема конкретного сайта и его сборки, как он исторически создавался и развивался. Все плагины можно либо заменить легковесными аналогами, либо написать свое. Это бич любых CMS / расширяемых инструментов - всегда будут "плагины", которые люди ставят для решения какой-то задачи, но используют реально 0.5% функциональности.

    Пока вижу только такой оптимальный сценарий - разрабатывать проект с нуля, дабы уйти от массовых решений и создать только нужный для сайта функционал

    Если проект настолько плох, что речь реально не о постепенном рефакторинге, а о переписывании с нуля - дело конечно дрянь. Но я бы советовал все-таки сделать шаг назад, выдохнуть и подумать, взвесив +/-. Можно ли постепенно, по кускам данную поделку отрефакторить, заменяя фичу за фичей на адекватную реализацию? Если да - это будет самый дешевый и оптимальный подход. Если реально нельзя - тогда может есть смысл использовать другое динамическое решение, если проект того требует? Возможно какой-нибуть Statamic или October CMS. Это же не белое-черное (статика-WP), есть и другие варианты.

    И да, не используйте пожалуйста слово функционал, это режущая ухо ошибка :) Это математический термин. То, что вы имеете в виду называется функциональность.

    Остается вопрос в основе. Остаться на Wordpress или рассмотреть что-то более перспективное. В Wordpress конечно же привлекает его размах, огромное кол-во готовых решений, разработчиков. Но может действительно - это его недостаток?

    Разумно. Взвесьте и другие варианты (см. выше). Подсуммирую так - на WordPress можно делать быстрые, удобные и производительные сайты. Даже с использованием "передовых технологий" из мира PHP - composer, очереди, CI/CD и прочие вкусняшки. Все это можно. Но 95% рынка "вордпресс-разработчиков" даже понятия не имеют что это все такое. По моим наблюдениям, из 100% WP-разработчиков, где-то 60% - вообще не разработчики, а имплементаторы - эти умеют наставить плагинов и премиум-тему, натыкать в настройках, скопировать пару кусков кода со Stack Overflow и своей записной книжки (часто - устаревшего кода лет на 5-10). Еще 25% - это фулстаки и прочие разрабы, которые шарят в другом (чистом PHP, других CMS, других языках, фронтенд) и по сути разрабы, но недостаточно знают WP чтобы эффективно с ним работать - отсюда говнокод и костыли. Еще 10% - опытные WordPress-разработчики, которые хорошо знают именно WP, но часто отстают в развитии от PHP мира в целом, слегка застряли в прошлом. И только оставшиеся 5% - реально идеальная рабочая сила, которая умеет и в PHP, и в другие языки, и в WP. И умеет объединять разные инструменты и технологии для достижения оптимального результата. Вот этих и надо искать. Это будет дороже, но в итоге оно того стоит.
  • Стоит ли переезжать с Wordpress на статичные сайты (Gatsby, Jekyll, Hugo) и сколько это будет стоить?

    ZoomLS,
    В данном случае, будет достаточно встроить поиск от Гугла.

    Хм, но я (клиент, отдел маркетинга) хочу "предиктивный поиск с полем поиска fullscreen, а также чтобы результаты красиво выводились по группам - отдельно сверху 5 найденных статей, а под ними еще из глоссария и FAQ статьи, если есть по тем же поисковым словам". Это цитата из реальности. Да, если это ваш личный небольшой контент-сайт и вы разраб, то вас вполне устроит примитивный поиск. Но для типового более-менее крупного контент-проекта - не подойдет.

    Что может быть хуже Wordpress? :) С чего вырастает монстр, да ещё и неповоротливый? Если делать нормально, то такого не будет.

    Хуже WordPress может быть все что угодно - от статики до любого другого фреймворка, CMS, CMF или самописа на любом другом языке. Вы сами говорите - секрет в том, чтобы делать нормально. Так вот, на WordPress тоже можно делать нормально. Это всего лишь инструмент. Хейтить его уже давно дурной тон.

    Смотря что за сайт. Множество сайтов, а уж особенно блогов - можно перенести на статику с Wordpress и выйграть от этого.

    Совершенно не спорю. Блоги и простые контентные сайты - однозначно да, статичные по своей природе - да. Собственно, я именно об этом и написал, это и была вся суть моего комментария :)

    С другой стороны, если уж вы разраб, то высокой производительности можно добиться и с помощью WP, не теряя при этом CMS и гибкость редактирования. Совершенно ничто не мешает вам отдавать сайт с помощью nginx fastcgi_cache и получить best of two worlds - удобный динамический бекенд для редакторов и быструю статику для посетителей.

    С переносом сайта, можно будет заодно и с этим порешить.

    Но ведь жто же можно порешать и без переноса сайта. Что так, что так код фронтенда надо ковырять. В чем профит?

    В любом случае, даже если ничего не делать - сайт все равно будет работать шустрее, чем на Wordpress.

    Заблуждение и миф. Во-первых, вы сравниваете х** с пальцем - статику, отдаваемую только веб-сервером и CMS на PHP, для которой веб-сервер делегирует запрос на интерпретатор, который поднимает CMS (или фремворк - суть та же), а потом еще и в базу стучится. Разумеется второе будет более медленным, всегда. Впрочем, смотрите выше - динамический сайт на WordPress вполне можно повесить на nginx fastcgi_cache и перейти в ту же лигу, что и статика. Фронт для пользователей будет летать ровно с той же скоростью, что и статика. Один в один. Но для редакторов / админов вы сохраните удобную админку. И самое главное - менять ничего не надо, цена вопроса - полчаса настройки и тестирования.
  • Стоит ли переезжать с Wordpress на статичные сайты (Gatsby, Jekyll, Hugo) и сколько это будет стоить?

    Для чего-то ещё, тоже можно использовать микросервисы

    А что насчет таких функций, как поиск по сайту?

    Вот тут начинается реальная жизнь, а не розовые единороги. Статика катит для простых и статических по своей природе сайтов. Если нужна дополнительная функциональность (обратите внимание - не функционал) то получается еще более неповоротливый монстр из микросервисов. Вы просто переносите complexity с одной плоскости в другую, не выигрывая ровным счетом ничего. Чаще даже наоборот - усложняете вещи там, где обычный монолит на динамической CMS является идеальным решением. Кроме того, у автора по его же собственным словам там пару сотен внешних запросов, которые и являются медленными. Я в упор не понимаю как он решит проблему медленных внешних запросов переходом с WordPress на статику. Имхо, автор решает не ту проблему.
  • Стоит ли переезжать с Wordpress на статичные сайты (Gatsby, Jekyll, Hugo) и сколько это будет стоить?

    Bloodshot,
    сильно не помогло, так как у меня много внешних запросов (~300-400)

    тогда переход на статику вам тоже не поможет. Поможет одно из двух:
    - избавиться от этих запросов
    - кешировать их
  • MustHave плагины для wordpress?

    которую кстати можно скачать бесплатно на просторах интернета

    Не стоит так делать, по 2м причинам:
    1. "Бесплатно" может вполне идти с "бонусом" в виде бекдора.
    2. Вам нравится, когда вы делаете клиенту работу, а он вам не платит за нее, потому что не считает нужным? Среди взрослых людей принято за платные услуги / товары платить, а не воровать. Тем более за те, которые являются вашим профессиональным инструментом и помогают зарабатывать деньги.

    Мне кажется пора вводить баны за рекламу вареза.
  • MustHave плагины для wordpress?

    Androp06, за DLE не скажу - мне он изначально не интересен, мы с ним в разных вселенных живем. Что касается WordPress, то тут все предельно просто:

    1. Сам по себе WordPress из коробки вполне себе быстр.
    2. Отключив ненужные фичи можно еще больше ускорить.
    3. Некоторые фичи необходимо изменить (например использовать серверный крон вместо wp-cron)
    4. Кеширование на нескольких уровнях:
    - сам код чтобы использовал механизм кеширования, где это уместно
    - object cache
    - если есть авторизованные пользователи и/или кастомизация ответов (страниц / блоков), то fragment cache
    - full page cache, желательно без участия PHP вообще (например nginx fastcgi_cache)

    И получите фантастическую скорость загрузки + реальный себе high-load.

    А дальше все остальное будет зависеть от конкретной реализации функциональности (бекенд) и верстка (бекенд). Если соберете все нужные фичи на легких плагинах или кастомном коде, то даже первичный рендеринг на бекенде или динамические запросы будут быстрыми. Если сверстаете без кучи тяжелых скриптов и стилей, без постоянных repaints и сходящих с ума 3-rd party скриптов - то и фронт будет летать.
  • Как выявить нагрузку на CPU в index.php Wordpress?

    Илья Савельев, А что именно не сходится? Я 13+ лет с WP, контрибьтор в ядро и большую тележку плагинов, включая штук 5 плагинов кеширования (и не считая кастомных решений по кешированию, написанных под сложные и высоконагруженные сайты). А еще я маниакальный фанат высокой производительности и по вопросам кеширования и оптимизации целые доклады и талмуды создавал. Сейчас вот видеокурс колбашу и целую SaaS платформу для этих целей. Этим я как бы намекаю, что с кешированием в WP немного знаком. Так вот, про d-wp слышу впервые. Не буду говорить хорош он или плох - не пробовал. Но то, что он не попадался на глаза за все эти годы нишевому специалисту именно по этой теме - весьма странно, не находите?

    А вообще не туда смотрите. Написал ответ.
  • В чем цель долбить сайт командами wp-json/oembed/1.0?

    Александр, Александр, ну серьезно. Вы совершенно не разбираетесь в теме разговора, и вместо того чтобы вникать в то, что вам советуют (пусть и не идеально вежливым тоном, как вам бы хотелось), вы реально быковать начинаете. Нехорошо.

    Еще раз, разберитесь что это за технология, зачем нужна, как используется в WordPress. И второе - вам не нужно ничего делать и тем более беспокоиться. Какой-то малолетний китайский кулхацкер играется в перебор известных уязвимостей. Если ваш сайт не использует WordPress версии 4.7.2 - просто не обращайте внимания.
  • Здравствуйте! Не могу закинуть каталог продукции в Файле пдф на сайт, что сделать?

    Александр,
    Вам такая вещь как returned user с точки зрения гугла и поведенческих - что-то говорит?
    Да, говорит. Какое это имеет отношение к физическому расположению файла в той или иной папке? Или даже по другому, внешнему урл (S3) - речь идет не о html-странице, а о скачиваемом файле. Факт скачивания отлавливается аналитикой на странице, которая никуда не перемещалась. А файл может лежать на S3.

    Если есть какие-то поведенческие факторы которые реально влияют на это все - просветите пожалуйста.
  • Что за запрос на сервере?

    Александр,
    Это логично?

    Нет, абсолютно. СЕО немножко не так работает - тут миллион факторов. И отследить реальное влияние одного конкретного фактора при том что делали вы много чего за все это время не представляется возможным. Вы в целом говорите о результатах своих усилий - и результаты хорошие, никто не спорит. Я лишь говорю, что мельниц, с которыми вы боретесь, может и не быть вовсе. Ваш шаред стоит 18 евро в год, но вы не считаете стоимость своего времени. CloudFlare вам и бесплатного хватит, базовый дроплет за $5 тоже вам норм подойдет - это 60 долларов в год. Для коммерческого проекта это ни о чем. Ну и разница с вашим шаредом всего в 40 долларов в год. Почему-то мне кажется что вы на ковыряние в апачевских конфигах и чтение доки своего времени потратили значительно больше, чем на 40 долларов.
  • В чем цель долбить сайт командами wp-json/oembed/1.0?

    Александр,
    я спросил конкретно, что за команда wp-json/oembed

    Это не команда. Это API endpoint.
    если она пройдет успешно

    Пройдет. Хотя это таки не команда, поэтому и говорить так тоже некорректно.
    каковы плюшки для того, кто ее засылает

    Очень хорошие плюшки. Вообще эти ссылка ваш сайт сам генерирует, и не просто так. Они нужны для oembed autodiscovery. Вот тут почитайте - https://wordpress.stackexchange.com/questions/2421... а также в документации WordPress по oEmbed. Ну и в гугле конечно.

    В общем, это полезная штука. Да, есть старый эксплойт по ней (https://www.cvedetails.com/cve/CVE-2017-6514/), но если у вас обновленная версия WordPress, то забудьте и спите спокойно.
    пардон, видимо я плохо умею копаться в выдаче ПС.

    Ну, вы не реагируйте так болезненно на критику. Горькая правда в том, что вы действительно не особо даже пытались разобраться что такое oembed и с чем его едят. А информации по этому поводу - пруд пруди.
  • Здравствуйте! Не могу закинуть каталог продукции в Файле пдф на сайт, что сделать?

    Александр, Я не говорил что это опасно. Просто не нужно так делать. Хотите ручками какие-то файлы заливать - не вопрос, создайте отдельную папку и туда складывайте. Мухи с котлетами смешивать не стоит, вот и все. Ну и второй момент - это то, что в большинстве случаев полезнее иметь этот файл в медиа-библиотеке.

    я отдаю файлы клиентам весом 1,4гб (висят месяц. потом убиваю) Аплоудить их через станд.средства WP - зачем...

    Загружать эти файлы в wp-content/uploads - изначально странная идея. Зачем? Для этого есть более подходящие места, тот же S3.

    одно дело Alt text для изображений, что важно для SEO сайта фотографа (к примеру) Но все же, что WP должен "знать" о вместимости папки uploads и как он вообще ее должен "сканировать"? Впервые слышу.

    Ну, сразу видно что вы не разработчик и вам ничего не известно о таких вещах как separation of concerns. По-простому - мухи отдельно, котлеты отдельно. Папка wp-content/uploads, как следует из названия, предназначена для того, чтобы WordPress загружал туда свой контент, через себя. Вы, загружающий туда файлы по ФТП - это ересь. Вас там быть не должно. Максимум - в отдельную папку, а не в автоматические папки по датам.

    Давайте отмотаем к вопросу - человек не может стандартными методами залить PDF

    И человека попросили уточнить почему - что за ошибку ему WP выдает. Варианта скорее всего 2 - либо файл слишком большой, либо какой-то плагин блокирует именно PDF как тип файла. Обе проблемы фиксятся парой строчек кода.

    Наверняка весь функционал сведется к тому, чтобы клиенты смогли этот файл открыть/загрузить

    В простой интерпретации - да. А если перестать угадывать а подождать детальное ТЗ, то вполне возможно всплывет стопочка интересных деталей - например, есть более одного сервера (стейджинг + продакшн), есть необходимость считать количество скачиваний, есть необходимость контроля доступа к файлу по ролям, есть желание удалять такие файлы по расписанию автоматически, или хотя бы вручную но не забывать об их существовании и тд. Или такое может получиться, что данные требования возникнут позже. Впрочем, их может и не быть - достаточно просто ссылку на файл. И это тоже нормально, но в этом случае нет смысла пихать этот файл в wp-content/uploads/2020/04/file.pdf, правильнее и удобнее - в какую-нибудь кастомную папку типа wp-content/uploads/shared/file.pdf

    Поэтому - вполне себе вариант.

    Да, вариант. И этот вариант называется "плохая практика". Естественно, от этого никто не умрет. Можете использовать, если вам так удобно. Но учить других людей подобным плохим практикам - не ок.

    ЗЫ:
    Наверняка весь функционал сведется к тому

    ФУНКЦИОНАЛЬНОСТЬ. Функционал - это математический термин с совершенно другим смыслом.
  • Что за запрос на сервере?

    Александр,
    Но для сайта частной коммерции на shared wordpress hosting - это самый короткий путь решения ряда проблем.

    Самый короткий путь решения этих проблем - не использовать для коммерции на WordPress shared hosting. Есть специализированные (Kinsta, WP Engine), есть VPS. Стоит это все адекватных денег. Геморроя меньше. Работает быстрее. Большая часть ваших проблем изначально существуют из-за того что вы на шареде.

    Сайт грузится 2-3сек.

    2-3 секунды это что за метрика? TTI? TTFB? На каком устройстве? На какой сети? Из какой локации? Что это за цифры?

    Все остальное о чем вы написали - какая-то сеошная черная магия, вуду-технологии и шаманские ритуалы. Проднижение, сапе и тому подобное - это какая-то весьма специфичная ниша, которая явно существует - значит кому-то это надо - но при этом вызывает больше вопросов чем ответов. Лезть туда не планирую, сорян.

    Если кратко - все эти блокировки и прочее нужно стараться делать в таком порядке:

    - сторонний сервис типа CloudFlare, через который трафик идет на сайт. Позволяет качественно фильтровать мусор еще до того, как он дойдет к вашему серверу.
    - файрвол на уровне сети/системы (тот же UFW, Fail2Ban и тд)
    - веб-сервер (Nginx, Apache и тд)

    99% вредного/левого/спам трафика должно быть отфильтровано на этих этапах. До PHP такие запросы не должны доходить, ибо делать фильтрацию на уровне PHP - дорого. А тем более если эта фильтрация требует запросов к БД. И еще не дай бог будут записи в БД (а на шареде Wordfence логи в базу точно будет писать во время самого запроса, ибо асинхронности там не предусмотрено).

    То же самое с баном по подсетям - я реализовывал это через htaccess вначале (ну что нагуглил то и юзал). Когда бан лист вырос до 100шт IP - вот тогда сайт начал тормозить и лагать.


    У меня на одном из серверов в конфиге Nginx бан-лист на несколько тысяч строк + более 3 тысяч редиректов, часть из которых - по регулярным выражениям. И оно выполняется Nginx'ом быстрее, чем запускается PHP-движок. А сервер этот - самый дешевый дроплет на Digital Ocean, за $5. Точно знаю про крупные сервисы у которых банлисты на порядки больше моего. Так что тут дело скорее всего в вашем конфиге + в дерьмовом shared хостинге, который на такие вещи не заточен от слова совсем.