Высокая нагрузка WordPress на CPU — процессор, сервер и хостинг. Резкое увеличение нагрузки CPU на хостинг

Прошел период примерно в 30 дней, в работе сайта больше проблем нет и высокая нагрузка на сервер, процессор больше не наблюдается. Теперь следует рассказать как мне удалось справиться с периодической высокой нагрузкой WordPress на процессор и сервер.

Все началось совершенно спонтанно и с каждым днем ответ сервера становился все более долгим. Затем в один прекрасный момент в панели webmaster Yandex, появилось соответствующее критическое уведомление. В котором был указан долгий ответ сервера практически на 40 — 50 страницах сайта. Все по-порядку.

Содержание статьи:

Высокая нагрузка создаваемая WordPress сайтом на серверный процессор CPU — основные симптомы этой проблемы

На моем сайте проблема возникала совершенно спонтанно и в разные временные периоды. Толчком 100% нагрузки на CPU сервера становились переходы между страницами сайта. Примерно на 2-й странице, возникал резкий скачек в работе процессора сервера. Хочется заметить, что в этот момент оперативная память практически не имеет колебаний. А количество процессов совершенно незначительно и не должно так пагубно нагружать серверный процессор.

Основные характерные признаки нагрузки, которые встречаются у многих вебмастеров:

• Повышение лимита нагрузки процессора на хостинг-сервере.
• WordPress начал создавать недопустимую нагрузку на CPU.
• Пиковые значения, жесткая перегрузка процессора на хостинге.
• Долгий ответ сервера, варьируемое значение колеблется от 5 до 30 секунд.
• Чрезмерная нагрузка происходит спонтанно, в разные временные периоды.
• Происходит заторможенность сайта, страницы практически не загружаются или этот процесс проходит очень долго.
• Сайт в пиковых пределах крашится.
• WP создает долгий ответ сервера, сайт работает не стабильно. В пиковых скачках CPU, оперативная память работает в штатном стабильном режиме.
• Количество затронутых и исполняемых процессов в периоды скачков минимальны.
• Потоковое пакетное обращение и задействованные соединения на nginx или apache минимальны.
• Данная аномалия проходит несколько раз в день, в разные промежутки времени. Заканчивается также быстро, как и началась.

Это именно то, что происходило с моим сайтом в течении месяца. Наглядным примером будут следующие изображения:

Как видите количество задействованных процессов минимально. Оперативная память удерживается в стабильном значении, с учетом открытого браузера и огромного количества страниц. А вот все ядра CPU работают в критической нагрузке, изначально причину понять вообще невозможно.

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

Самое банальное, я грешил на плагины WP и нехватку памяти. Хотя так по-честному, движок использует всего 16 мб памяти из допустимых 512 мб которые я выделил. Что собственно я пробовал:

• Провел полное обновление Debian, затем почистил всю систему.
• Удалил 99% сохраненных ревизий баз данных на VestaCp.
• Раз двадцать просматривал конфигурационные файлы в VestaCp на наличие ошибок.
• Нашел в почтовом сервере Exim большое количество системных логов (полностью удалил).
• Проверял сайт на наличие вирусов (отсутствуют).
• Делал трассировку до сайта, проверял скорость интернет соединения.
• На сайте отключил сохранение ревизий записей, большего на сайте не предпринимал. Сайт оптимизирован под 98% смысл его проверять.

После всех проделанных действий, проблема не решилась. В течении месяца скачки и пиковые критические нагрузки WP на процессор сервера продолжились.

В чем собственно заключалась проблема чрезмерной нагрузки WP на CPU, и как я ее решил

Проблема заключалась в ошибке WP Cron (крона). Месяца четыре назад я устанавливал плагин, который запрещает обновляться движку, темам и плагинам. Первым звонком по моим пониманием, были ошибки в серверных логах сайта адресованные wp-cron.php. Ошибка заключалась в выделении памяти на процесс, а точнее нехватки памяти. Когда я вспомнил про эту ситуацию, то сразу обратил внимание.

Что мне помогло:

• Я установил плагин WP Crontrol — планировщик задач wp cron. Советую установить его сразу, очень хорошее решение.
• После установки, я увидел картину в пиковую нагрузку из примерно 900 идентичных событий, которые как я понимаю касаются изображений.

Самое простое решение обнулить все события wp cron до изначального состояния, делается это в functions.php. Достаточно вставить в самом начале файла под

В результате все 900 событий пропали, сайт начал спокойно работать. Серьезных нагрузок на сервер и долгого ответа больше нет. Единственное от чего мне пришлось избавиться, это от запрета на обновление. После этого все проблемы решились. Вот как выглядят показатели нагрузки на данный момент:

Надеюсь эта статья Вам пригодиться и поможет. Если возникнут вопросы пишите в комментариях или в личку.

Сейчас я расскажу как мне наконец-то удалось снизить CPU нагрузку от моих сайтов wordpress на хостинге. Длилась эта история 3 месяца. Показатель CPU в моём аккаунте был итак на пределе и вдруг начал совсем зашкаливать.

Сколько я прочитала статей в интернете, и сколько облазила форумов — сама точно не знаю. Что я сделала за это время на своих сайтах.

• Минимизировала количество плагинов. Особенно надо обратить внимание на тяжёлые плагины со сложными скриптами. Обнаружить таких обжор вы можете при помощи плагина P3 (Plugin Performance Profiler)
• Уменьшила вес картинок. Количество тоже желательно уменьшить, но как без скриншотов, ведь будет сложно понять о чём идёт речь
• Поставила плагин кеширования — Hyper Cache
• Уменьшила нагрузку, которую создают поисковые боты

Но только моим сайтам это не помогало, как слону дробина. Проклятое CPU уже показывало более 40-50 единиц, хотя на моём тарифе допускалось – 30. Мой хостер — webhost1 , меня не беспокоил. Но зато психовала я, тем более, что в один прекрасный день мои сайты автоматически отключились – правда длилось это несколько минут. И пришлось перейти на более дорогой тариф.

А CPU на хостинге стало зашкаливать в некоторые дни даже за 50. Переходить на другой хостинг? Возня неимоверная, тем более что на Вебхосте я уже более 3-х лет. И где гарантия, что там история не повторится или не будет ещё хуже. Оставалось только закрывать сайты или платить нереальную (неокупаемую) цену. Но делать этого не хотелось и пошла я бродить по своей хостинг панели.

И о чудо, метод научного тыка как всегда помог! Зашла я в домены и сравнила PHP сайтов старых и новых. Оказалось, что старые сайты работали на устаревшей версии PHP5.3, а новые на PHP5.6!!! Переключила я своих «старичков» на PHP5.6 и уже третий месяц сплю спокойно. CPU нагрузка на хостинг — стабилизировалась.

Если у вас CPU зашкаливает, а ответа вы так и не нашли, то проверяйте на какой версии PHP работает ваш сайт. На моём хостинге для этого нужно зайти в хостинг-панели в раздел Домены. Далее нажать Настройки

В Настройках найти PHP, выбрать версию 5.6 нажатием на треугольник. И сохранить. После этого нагрузка на CPU должна снизиться. Только не выбирайте версию 7.0 , иначе у вас могут исчезнуть картинки и тема сайта.

• Не забывайте чистить базу данных каждую неделю. Плагинами: и .
• Загружать новые обновлённые версии плагинов и движка Вордпресс. Особенно если у вас не отключены обновления – этого, кстати, делать и не рекомендуется, хотя в сети встречаются статьи с советами отключать обновления. Якобы этот способ сильно снижает нагрузки – снижает, но не более чем на 3-5 единиц! А вот сайты свои вы подвергаете опасности быть взломанными, так как в каждой новой версии движка или плагинов закрываются уязвимости. Поэтому заходите хотя бы раз в неделю на свои сайты и принимайте обновления.

Рада, если смогла вам помочь и перед вами больше не стоит вопрос Как снизить нагрузку на CPU хостинга.

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

нам приходят на помощь дополнительные инструменты под названием плагины - рабочие лошадки, помощники в работе наших блогов. Что бы мы без них делали? Чтобы улучшить и ускорить загрузку блога, установим простенькие плагины для для оптимизации и ускорения загрузки блога. В сегодняшней статье установим плагин для чистки территории блога WP -Optimize. Как устанавливать плагины,

Плагины для оптимизации wordpress
1 - WP-Optimize помогает оптимизировать базу данных и таблицы сайта. Это обязательно - необходимый плагин.
Функции WP - Optimize:

• Конкретно чистит наш ресурс от всяческого мусора.
• Оптимизирует - сжимает базу данных блога и таблицы.
• Удаляет все резервные копии записей, когда мы ставим статью на блог и по несколько раз редактируем один и тот же пост, также весь опубликованный контент.
• Удаляет спам комментарии.
• Не конфликтует с другими плагинами.
• Просто и стандартно устанавливается на блог.
• Входим в админку
• Плагины
• Добавить новый
• В поисковой строке вписываем название WP-Optimize
• Устанавливаем
• Активируем

Далее еще проще: В меню слева ищем по названию WP-Optimize, заходим в настройки, видим фото людей, которые отблагодарили лайком.
Жмем лайк Нравится - отправляем на Фейсбук, лайк не отправите, плагин будет молчать и работать не начнет. Как немой и глухой ничего не слышит, так и этот плагин будет бездействовать. Со мной такая история

приключилась при установке, пока я не догадалась отправить лайк. Пока вы не отправите благодарность разработчикам плагина, плагин работать не будет. Закон Вселенной: для того, чтобы что - то получить, вначале нужно самому что - то дать. Другая аксиома: не сделав добра, не жди обратного. Далее смотрим такой скриншот

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

Акисмет переусердствовал - он же надежный охранник блога от спамщиков, загнал несколько комментариев для подстраховки в спам - папку. Отрабатывает свой хлеб. :)
А теперь можно чистить. Ставим во всех пунктах чебоксы - птички и жмем слово PROCESS.

Почистили, радуемся генеральной чистоте. Все, что было выделено красным, приобрело синий цвет. Вам сообщают: Полное оставленное свободное место: 33.105 Kb. Не много, не мало, территория чистая. Оптимизация блога прошла успешно.

После чистки плагин деактивируем и один раз в 5 - 7 дней чистим территорию блога.
2. Следующий плагин классический, который не нужно настраивать - по умолчанию он сам знает свои функции от а до я. Для этого постарался автор плагина Макаров, а плагин я нашла на сайте Дмитрия Сидаш sidash.ru/ у которого очень часто прогуливаюсь в поисках интересной и полезной информации. Заходите и вы - многое для себя почерпнете.

SSD Optimize WordPress - данный рабочий инструмент я выделяю из огромной дивизии плагинов полезных, малополезных, не очень полезных, но создающих хорошую нагрузку для сервера и блога. Разгружает от лишнего трафика и несвоевременнных запросов хостинг, на ходу оптимизирует загрузки AJAX библиотек, отключатся ненужные функции, сильно нагружающие систему и в то же время не нарушает работоспособность нашего блога.

Какую пользу имеем от этого плагина:

• Отключает проверки обновлений тем, плагинов, движка
• Отключает автосохранение редактируемой записи
• Включает автоматическую оптимизацию и восстановление Базы данных
• Отключает ревизии постов
• Отключает генераци метатегов
• Подгружает AJAX библиотеки с сайта google, для пользователей
• Снижаем нагрузку на сервер благодаря плагину
• Семь функций защищают сайт от спама
• Запрет в комментариях активных ссылок

Устанавливается аналогично всем плагинам.

Домен не исчез, сайт на месте, но этого плагина нет. Ссылки на разные темы... При нажатии на ссылку автора появляется запись:

Ошибка 404 К сожалению, здесь нет того, что Вы ищите. Это может быть по многим причинам, но расстраиваться не стоит, так как Вы можете прочитать самые популярные статьи на моем блоге, или начать поиски нужной информации с главной страницы

Появился сайт в сети, даже не знаю - когда, но почему - то сейчас находится в АГС. Ссылка будет здесь неактивной http://makarou.com/ssd-optimize-wordpress-5-0. Как скачать данный плагин: Выделяем ссылку http://makarou.com/ssd-optimize-wordpress-5-0, копируем, вставляем в адресную строку. Но выше цитаты ссылка активная, скачивайте и устанавливайте.

Настройки нашего инструмента SSD Optimize WP

Информация о плагине

Все выполняемые функции

Статистика по комментариям и трекбэкам

Мой скайп gvozdika571
Всегда рада видеть вас у себя на блоге

Как уменьшить нагрузку сайта на вордпрессе на хостинг и оптимизировать базу данных?

Начал задаваться этим вопросом после того, как служба поддержки хостинга Таймвеб написала мне, что мои сайты (их на этом хостинге размещено 10 штук) оказывают чрезмерную нагрузку на центральные процессы хостинга и на базу данных. Повышенная нагрузка была связана частично с ddos-атакой на один мой сайт, ну и в дополнении с тем, что я размещаю сайты на этом хостинге давно уже (более 1,5 года), а никакие работы по очистке мусора с и по оптимизации баз данных не проводил. А ведь сайт можно в некоторой степени сравнить с компьютером. Если не очищать его от ненужных файлов, кряков и прочей лабуды, то компьютер будет со временем поедать и требовать больше ресурсов, что приведет к замедлениям в его работы, частому зависанию. Поэтому нужно заботливо относиться к своим сайтам и периодически проводить действия по оптимизации их работы.

Как снизить нагрузку вордпресса на хостинг и оптимизировать базу данных (MySQL)?

Я провел небольшие действия (о которых расскажу далее), которые позволили мне в результате существенно уменьшить нагрузку на CPU хостинга. Если говорить обобщенно, то удалось снизить нагрузку на CPU с 30-40 до 0,34 – 0,50, а нагрузка на базу данных уменьшить с 90 до 64-70.

В результате проведенных действий по оптимизации базы данных (MySQL) – ее размер удалось уменьшить с 227 мб до 41 мб. Как видим – удалось добиться существенных показателей. А что для этого было сделано?

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

Для оптимизации базы данных понадобиться установить и активировать плагин — Optimize DB (о том, как устанавливать плагины читать ). Далее идете в раздел «Инструменты» — находите строчку «Optimize DB» и переходите по ней. Теперь для оптимизации базы данных на вашем сайте остается только нажать на кнопку «Optimize Now».

Вот такие простые действия оптимизируют вашу базу данных на вордпрессе (так сказать упорядочивают в ней хаос и раскладывают все по полочкам).Чтобы работа этого плагина в дальнейшем не создавала дополнительную нагрузку – нужно его просто выключить. Для оптимизации базы данных на вордпрессе раз в неделю или раз в месяц заходите в раздел с плагинами, активизируйте плагин Optimize DB и проводите оптимизацию MySQL (это и есть база данных). А после снова отключайте его.

Но я не ограничился для снижения нагрузки на хостинг только работой с плагином Optimize DB. Была проведена существенная работа по борьбе со спамом. Особенно много спама накопилось на нескольких сайтах (в сумме свыше 6 тыс. штук). Говоря про спам – я имею в виду комментарии спамного характера, большое количество которых также нагружает хостинг. Удалил много комментариев ожидающих проверки (точнее, чтобы полностью их удалить – отправлял их первоначально в корзину, а потом корзину очищал), также очищал папку со спамом. В в последнее время мне существенно помогает плагин «Invisible Captcha». Благодаря нему спам мгновенно отправляется в папку со спамом, а оттуда все спамные комментарии можно мгновенно удалить, очистив эту папку.

Посоветовал бы установить еще плагин «WP Super Cache» (если он не установлен), активировать, и включить кэширование. Особенно полезен он будет, если на ваши сайты уже стало заходить много посетителей. В процессе работы я установил его еще на парочку сайтов. Благодаря кэшированию нагрузка на хостинг также уменьшается.

Вот такая была проведена работа над 10 сайтами, которая заняла у меня около 2 часов. Но своего я добился – удалось существенно снизить нагрузку вордпресс на хостинг.

Также стоит отметить, что чем больше на сайте на вордпрессе активировано разных – тем больше нагрузка. Поэтому используйте только те плагины, которые вам необходимы и выключайте те, которые не используете.

Давайте наверное уже начнем оптимизировать Поехали!

Пример излишней нагрузки на сервер.

Допустим пользователь зашел на сайт, но что происходит при открытии страницы? Как информация выводится на экран? Давайте проследим сей процесс на примере заголовка сайта.

Заголовок и URL главной страницы сайта, если Вы помните, задается в настройках WordPress: адимнка -> Параметры -> Общие. Все настройки, имеющиеся во вкладке «Параметры», заносятся в базу данных, а точнее, в таблицу wp-options , откуда в последствии они запрашиваются различными функциями и выводятся на экран.

Разработчиками WordPres написано не мало функций, но сами по себе они выполняться не могут. Для полноценной их работы необходимо некое связующее звено, в роли которого выступает шаблон сайта.

Шаблон, как известно, состоит из ряда файлов, каждый из которых отвечает за отображение определенного участка сайта. Нас же сейчас интересует шапка, где выводиться заголовок, поэтому откроем файл header.php и поглядим, что там прописано.

В большинстве шаблонов, главный заголовок сайта заключен в тег h1 , поэтому ищем участок кода с данным тегом. В моем шаблоне код вывода заголовка выглядел так:

/">

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

С анкором мы разберемся немного позже, а сейчас давайте познакомимся с функцией get_option() .

Функция get_option() и нагрузка на сервер

Итак, мы вписали название и URL главной страницы сайта в настройки WordPress и они отправилось на хранение в БД, в таблицу wp-options .

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

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

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

Параметр home дает команду функции запросить из БД URL главной страницы. Стоп! Значит URL главной страницы тоже хранится в базе данных? Верно. И при открытии страницы функция его запрашивает, т.е, происходит обращение к данным, которые хранятся на сервере.

А теперь представьте, что на Ваш ресурс зашли 100 посетителей и начали «шалить», открывая все новые и новые страницы.

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

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

Вернемся к функции get_option() . Для получения из БД тех или иных данных, функция может принимать следующие параметры:

get_option("home") — URL главной страницы
get_option("admin_email") — E-mail администратора сайта;
get_option("blogname") — Название сайта;
get_option("blogdescription") — Краткое описание сайта;
get_option("blog_charset") — Кодировка сайта;
get_option("date_format") — Формат даты;
get_option("default_category") — Категория по умолчанию;
get_option("siteurl") — Адрес WordPress (см. Параметры -> Общие);
get_option("start_of_week") — Первый день недели;
get_option("upload_path") — Каталог загрузки по умолчанию (устаревшая);
get_option("posts_per_page") — максимальное число постов на странице;
get_option("posts_per_rss") — Максимальное число постов в RSS-ленте;

Большинство перечисленных типов данных указываются в настройках WordPress, во вкладке «Параметры». Исключением являются: «Кодировка сайта» — указывается непосредственно в БД и «Каталог загрузки по умолчанию «- опция была убрана из настроек с версии 3.5.

Зачем я все это рассказываю? Дело в том, что содержание файлов в шаблоне у всех разное, но если понимать, что в них прописано и как это работает, то будет гораздо легче оптимизировать WordPress и избавиться от лишних обращений к базе данных.

Как и чем заменить функцию get_option() я расскажу немного позже, а пока давайте выясним, что за bloginfo() прописана в коде вместо анкора.

Функция bloginfo() и нагрузка на сервер

Вернемся к тому моменту, когда пользователь открыл страницу. Мы выяснили, что URL адрес главной страницы был взят из базы данных, средствами функции get_option(‘home’) .

Ну хорошо, а сам заголовок откуда взялся? Заголовок также хранится в базе данных, но в нашем случаи он был получен и выведен на экран другой функцией — bloginfo() .

На заметку! bloginfo() — это тег шаблона, который активирует функцию get_bloginfo() . Может использоваться в любом месте шаблона.

Функция bloginfo() может принимать следующие параметры:

bloginfo("url") — Выводит URL сайта;
bloginfo("name") — Выводит название сайта;
bloginfo("description") — Выводит описание сайта;
bloginfo("template_url") — путь до директории текущей темы;
bloginfo("template_directory") — тоже самое, что и "template_url";
bloginfo("stylesheet_url") — путь до файла стилей текущей темы;
bloginfo("stylesheet_directory") — тоже самое, что и "stylesheet_url";
bloginfo("charset") — Выводит кодировку сайта;
bloginfo("admin_email") — Выводит e-mail адрес администратора;
bloginfo("version") — Выводит версию WordPress;
bloginfo("html_type") — Выводит данные из html_type таблицы wp-options;
bloginfo("pingback_url") — путь до файла xmlrpc.php;
bloginfo("rss2_url") — Выводит URL фида RSS 2.0 (домен/feed);
bloginfo("comments_rss2_url") — Выводит URL фида комментариев (домен/comments/feed);
bloginfo("rdf_url") — Выводит URL фида RDF-RSS 1.0 (домен/feed/rfd);
bloginfo("rss_url") — Выводит URL фида RSS 0.92 (домен/feed/rss);
bloginfo("atom_url") — Выводит URL фида Atom (домен/feed/atom);

Функция bloginfo() немного отличается от функции get_option() , но работает по схожему принципу, т.е, запрашивает из БД те или иные данные и выводит их на экран.

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

Я предпринял целый комплекс мер, после которых мой блог ускорился в два с лишнем раза.

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

Конечно, меры которые я предпринял, касаются не только сокращения запросов к БД и я постепенно обо всем расскажу, но в одну статью, сей объемный материал, мне не запихнуть.

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

Технология сокращения запросов к БД

Напомню, как выглядит код заголовка в моем файле header.php:

/">

А теперь, самое интересно. Если заглянуть в исходный код, то код заголовка там примет совершенно другой вид:

Вот такой код заголовка и должен быть прописан в файле header.php. Тогда сервер избавиться от двух совершенно лишних обращений, умноженных на количество открытых страниц.

Но тогда зачем в файлах шаблона прописываются вышеупомянутые функции?

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

Но мы то с вами знаем, как называется наш сайт и домен нам тоже известен. Выходит так, что использовать данные функции нет никакой необходимости.

Поэтому, начиная с файл header.php ищем участки кода, с вышеупомянутыми функциями, затем смотрим, как они выглядят в исходном коде и заменяем.

Для закрепления материала я приведу несколько примеров. Вот код, который выводит информацию о кодировке.

; charset=" />

Смотрим исходный код:

Копируем строчку целиком, и вставляем вместо кода с функциями.

Код подключения файла style.css:

" type="text/css" media="screen" />

Путь до таблицы стилей выведен с помощью функции bloginfo(‘stylesheet_url’) . Смотрим исходный код:

/images/fav.ico" type="image/x-icon" />