Артем Золин

data-eio-rwidth="2084" data-eio-rheight="2084"

Намекает на плагин EWWW Image Optimizer, который ты почему-то не трогал.

Как сделать сайт на WordPress с высокой производительностью?

Вначале необходимо определить, что такое "высокая производительность". Обычно, под производительностью сервера (WP сайт это как раз тот самый сервер) подразумевается показатель RPS (Requests Per Second) - максимальное количество запросов к серверу в секунду. Именно максимальное, т.е. в какой то "час-пик". Предположим, что сайты на WP обычно используют небольшие, ну максимум средние компании, с соответствующим ожиданием по нагрузке в своем сегменте.

Возьмем голую тему без плагинов, которая выводит 10 изображений, с подключением 5 статических файлов (css/js), итого около 20 запросов от одного не кэшированного визита посетителя. Если на наш сайт зайдут 5 посетителей в секунду, они сгенерируют 100 RPS (5 * 20). Может показаться, что 5 визитов в секунду - это мало, но в минуту это будет уже 300 визитов, а в час 18000 визитов, что как бы дохрена, для малого-среднего бизнеса. Повторюсь, речь идет про "час-пик", т.к. нагрузка в другой промежуток времени нас не интересует.

По моим наблюдениям, WP без проблем выдерживает 50-100 RPS на нормальном хостинге с начальным тарифом без кэширования.

Но проблема в другом - в теме и ее плагинах, я видел темы, которые генерируют 200 запросов к серверу с одного визита, что ломает всю логику подсчетов выше, и может спокойно положить тот самый начальный хостинг.

Я придерживаюсь следующего плана оптимизации WP сайта, от простого к сложному:
1. Кэширование плагином - самое быстрое и относительно дешевое решение, гуглить WordPress caching plugins. Обычно, вместе с такими плагинами идет опция с оптимизацией изображения до .webp или .avif формата и оптимизацией css/js файлов, если же нет, то это должен быть следующим пунктом оптимизации. Например, для W3 Total Cache имеются плагины Smush и ShortPixel.
2. Хостинг - арендовать более производительный shared-хостинг и подключить CDN.
3. VDS/DS хостинг - переезд на производительный VDS/DS хостинг, настройка обратного прокси Nginx и перекладка на его плечи задачи кэширования. Иногда получается сделать так, что до WP вообще не доходит запросов, все отрабатывает Nginx (это идеальный сценарий, но не всегда выполнимый). Здесь можно снять несколько сотен-тысяч RPS, что уже очень прилично, для такого уровня сайтов.
4. Больше серверов - докупка VDS/DS серверов с балансировкой, либо руками, либо средствами хостера. Здесь можно снять ЕЩЕ несколько сотен-тысяч RPS дополнительно к п3. Обычно, такая производительность нужна каким то интернет-каталогам/магазинам.

Конечно, можно переписать саму тему с плагинами (написать с нуля), но не факт, что это будет дешевле и быстрее, чем пункты выше. Бизнесу вообще глубоко фиолетово, на чем написан инструмент (сайт), главное, чтобы он приносил деньги, стоил максимально дешево и мог быстро нарастить производительность под новую нишу, если это понадобится.

Ну и как уже сказали другие, elementor противоречит слову "производительность", хотя и его наличие можно на время закидать кэшированием-серверами-деньгами.

Рекомендую почитать:
WordPress Developer Resources - Optimization
The Ultimate Guide to Boost WordPress Speed & Perf...
Page Speed Optimization for WordPress

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

Отслеживать производительность можно плагинами New Relic и Query Monitor, а тестировать нагрузку Load Impact и Apache Benchmark. Это поможет понять, где узкие места.

Гугли css селекторы
ol > li:before

Ну вроде бы как да, всегда в конец.
https://pubs.opengroup.org/onlinepubs/9699919799/f...

Opening a file with append mode (a as the first character in the mode argument) shall cause all subsequent writes to the file to be forced to the then current end-of-file, regardless of intervening calls to fseek().

Т.е., по-русски говоря, открытие файла в режиме добавления (первый символ в аргументе режима — a) приведет к тому, что все последующие записи в файл будут принудительно выполняться в текущий конец файла, независимо от промежуточных вызовов fseek().

Вы неправильно осмыслили задачу, и получился франкенштейн. Одна задача - это вставка ссылки при событии oncopy. Это делается на чистом Javascript, абсолютно не требует PHP, и никакого отношения к WordPress не имеет. Можете эту часть спросить отдельно в хабе Javscript - хотя я подозреваю, что в интернете уже выложена куча решений.
А вторая задача у Вас уже решена; я только использую хук на другое событие:

add_action( 'wp_enqueue_scripts', function () {
    if ( !current_user_can( 'manage_options' ) ) {
        wp_enqueue_script('oncopy_addlink', '/path/to/script.js');
    }
});

Все зависит от организации работы в конкретной конторе и конкретного разработчика, но лично у меня работает следующий подход:
1. Пишем начальное тз, минимальный необходимый перечень.
2. Говнокодим на основание п1 по принципу - "сделать быстро и чтобы работало по тз".
3. Пушим п2 в гит и разворачиваем сайт (или компонент на сайте).
4. Записываем фидбэк о компоненте, что не работает, как хотелось бы чтобы работало итп. Если это не критические замечания (безопасность или что то основное не работает), то откладываем изменения на месяц, квартал или год.
5. При накопление критической массы замечаний в п4 (ну или у Вас просто не осталось задач на настоящий момент) - добавляем рефакторинг п3 в очередь задач.
6. Повторяем 3-6 пункты до бесконечности.

При данном режиме работы решается сразу 3 задачи:
- Не требуется детальное тз на старте, в котором все равно не удастся предвидеть все наперед, соответственно сокращается общее время разработки и его стоимость.
- Сайт или компонент сайта выпускается в релиз очень быстро, а значит решает задачу бизнеса так же быстро.
- Прозрачный и прогнозируемый по срокам и стоимости режим релизов.

Важное уточнение!

Схема с минимальным ТЗ и говнокодом работает лишь с теми заказчиками, которым Вы подробно разъяснили, почему сроки и стоимость ниже, почему за каждую "хотелку" не указанную в тз придется доплачивать, и почему необходим рефакторинг.

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

Так?

$categories = get_categories([
    'taxonomy' => 'video',
    'orderby' => 'ID',
    'order' => 'DESC',
    'number' => '8',
]);

foreach ($categories as $c) {
    $vQuality = get_field('video_quality', 'category_' . $c->term_id);

    if ($vQuality === '4K') {
        echo '<img src="/image2.jpg">';
    }
    
    elseif ($vQuality === '1080') {
        echo '<img src="/image3.jpg">';
    }
    
    else {
        echo '<img src="/image1.jpg">';
    }

    echo '<p>' . esc_html($c->name) . '</p>';
}

Для этого в ВП есть произвольные поля. А для удобной работы с ними - плагины

Но если речь идёт о SEO, то лучше использовать seo-плагины

сделать небольшой блочный сайт

Что Вы подразумеваете под "блочным" сайтом?

Сейчас попросили сделать небольшой блочный сайт с готовым дизайном. Я его сверстала.

Теперь необходимо его натянуть на wp.

Как лучше организовать редактирование текстов для конечного пользователя?

Для редактирования - гутенберг, элементор или условно "без редактора" (при отключение гутенберга). Контент на странице выводится классическим образом.

У вас в .htaccess есть правило для принудительного перехода на HTTPS

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Это правило должно быть в начале файла,
если на сайте редирект с HTTP на HTTPS, это может вызывать цикличность

Вариант с экранированием:

<?php echo do_shortcode( '[gridmaster grid_style="style-2" post_type="game" posts_per_page="10" orderby="date" order="DESC" content_from="excerpt" excerpt_type="characters" excerpt_length="15" show_read_more="yes" read_more_text="Скачать" grid_image_size="medium" grid_image_width="350" grid_image_height="200" link_thumbnail="no" link_thumbnail_to="post" show_filter="yes" filter_style="default" btn_all="no" taxonomy="category" hide_empty="1" multiple_select="no" toggle_filter_items="no" pagination_type="load_more" infinite_scroll="true" animation="true" heading_font_size=\'{"xs":"16px","sm":"18px","md":"20px","lg":"22px","xl":"24px"}\' grid_col_gap=\'{"xs":"30","sm":"30","md":"30","lg":"30","xl":"30"}\' grid_row_gap=\'{"xs":"30","sm":"30","md":"30","lg":"30","xl":"30"}\' grid_item_per_row=\'{"xs":"1","sm":"2","md":"3","lg":"3","xl":"3"}\' slider_args=\'{"arrows":"1","autoplaySpeed":"3000","infinite":"1","slidesToShow":{"xs":"1","sm":"2","md":"3","lg":"3","xl":"3"},"slidesToScroll":{"xs":"1","sm":"1","md":"1","lg":"1","xl":"1"}}\']' ); ?>

Вариант с NOWDOC синтаксисом, как подсказал Ivan Ustûžanin:

<?php echo do_shortcode( '[gridmaster grid_style="style-2" post_type="game" posts_per_page="10" orderby="date" order="DESC" content_from="excerpt" excerpt_type="characters" excerpt_length="15" show_read_more="yes" read_more_text="Скачать" grid_image_size="medium" grid_image_width="350" grid_image_height="200" link_thumbnail="no" link_thumbnail_to="post" show_filter="yes" filter_style="default" btn_all="no" taxonomy="category" hide_empty="1" multiple_select="no" toggle_filter_items="no" pagination_type="load_more" infinite_scroll="true" animation="true" heading_font_size=\'{"xs":"16px","sm":"18px","md":"20px","lg":"22px","xl":"24px"}\' grid_col_gap=\'{"xs":"30","sm":"30","md":"30","lg":"30","xl":"30"}\' grid_row_gap=\'{"xs":"30","sm":"30","md":"30","lg":"30","xl":"30"}\' grid_item_per_row=\'{"xs":"1","sm":"2","md":"3","lg":"3","xl":"3"}\' slider_args=\'{"arrows":"1","autoplaySpeed":"3000","infinite":"1","slidesToShow":{"xs":"1","sm":"2","md":"3","lg":"3","xl":"3"},"slidesToScroll":{"xs":"1","sm":"1","md":"1","lg":"1","xl":"1"}}\']' ); ?>

Если использовать нормальную IDE, то она сообщит о возможных проблемах:

Но появилась идея запрашивать не все посты, а в зависимости от нужной категории. Все существующие ~ 2000 постов разделить на категории. Будет ли такая реализация работать быстрее?

Хорошая идея, конечно будет.

Либо есть какие-то другие идеи?

Не "либо", а "вместе" - почему бы не кэшировать выборку постов из БД (Transients API)?

$cache = get_transient('all_posts_cache');

if (!$cache) {
    $posts = get_posts([
        'numberposts' => -1,
        'orderby' => 'date',
        'order' => 'DESC',
        'post_type' => 'post-item',

        // Искать по слагу категории
        'category_name' => 'category_name',

        // Или искать по id категории
        // 'cat' => 123,

    ]);

    // Кэширование на 1 час
    set_transient('all_posts_cache', $posts, HOUR_IN_SECONDS);

}

else {
    $posts = $cache;
}

или будет достаточно только самой папки находящаяся в themes

Если Вы собираетесь передать лишь вёрстку натяную на wp (php файлы темы), то да, можно передать тему из директории /wp-content/themes.

Если же проект не ограничивается wp версткой, то не рекомендую так делать, т.к. многий функционал находится в плагинах и их настройках, которые Вы таким образом не перенесете. В таком случае, лучше забэкапить все файлы проекта + бд и передать этот .jar (например) заказчику. Для этого удобно использовать плагины Duplicator или Akeeba.

элементарно: присвоить ей пустое значение перед циклом:
$last_char = '';

а ещё код не будет работать для нелатиницы при нормальном конфиге PHP, лучше substr() заменить на её аналог из mbstring mb_substr()

Попробуй через sftp доступ переименовать папку плагина All-In-One Security (этим ты его выключишь), должна вернуться дефолтная страницы авторизации

Всего пока 4 сайта, на разных CMS (Wordpress, Joomla).

1. С чего нужно начинать, чтобы подготовить сайт(ы) к переезду?

Любой хостинг (shared с поддержкой MySQL и PHP) или VDS/DS.

2. Что нужно подготовить на новом пустом сервере?

Что такое "пустой сервер"? Если это VDS/DS, то гуглим, если это shared хостинг, то "создать сайты" (так обычно называется манипуляция у хостера, которая регистрирует место для расположения файлов для сайта) и MySQL БД для сайтов.

3. Нужен ли для каждого сайта (их четыре) свой виртуальный сервер (VM)?

Не нужен.

Или как эти сайты вообще размещать чтобы в случае чего они не упали все вместе?

Падение хостера достаточно редкое явление, чаще происходит дедос, который как раз и блокирует доступ к сайтам. Если критически важно, чтобы одновременно не легли все сайты, то нужны физически разные сервера и возможно, у разных хостеров.

5. ... какие советы дадите

Задавать более конкретные вопросы.