Доброй ночи, сеньориты и сеньоры! Сегодня у нас с вами речь пойдет о достаточно серьезных вещах. А если добавить конкретики, то поговорить я хочу о той мифологии, которая сложилась вокруг WordPress.
Беда очень и очень многих авторов, пишуших о WordPress, в том, что они (авторы) не дают себе труда задуматься: а что же они на самом деле пишут и насколько это соответствует действительности. Кто-то где-то что-то прочитал, кто-то откуда-то кривовато перевел гугл-переводчиком, а потом по Сети расползаются «знания», которые таковыми по сути не являются.
Сегодня я сделала для вас небольшую подборку мифов о WordPress. Предлагаю познакомиться и подумать.
Миф первый: Плагины тормозят блог
Совсем недавно мы касались этой темы в комментариях к статье о Vibe Seo Pack. Здесь же я решила высказаться по этому вопросу более развернуто и подробно.
На мой взгляд, это самый распространенный миф о WordPress. Буквально каждый, кто пишет о WordPress (да и я не исключение, что там скрывать — до недавнего времени, по крайней мере), несет в массы ту простую мысль, что плагины по возможности нужно заменять кодом. Чтобы блог не тормозили.
А теперь включаем логику.
Что такое плагин? Если не углубляться в дебри, то это просто один или несколько файлов с кодом, которые выполняют вполне определенную задачу, решение коей средствами самого движка не предусмотрено. Расширяют функционал, в общем.
Время, которое «забирает плагин» от загрузки блога в целом, отводится большей частью на исполнение php-кода, который в нем находится.
Но! Точно такое же время этот код будет исполняться и внутри файла темы оформления, куда мы его вставим вручную! А почему должно быть по-другому?
Блог тормозит не плагин как таковой, а тот функционал, который он в себе несет. И не надо думать, что реализовав стопятьсот функций кодом, вы на выходе получите легкий и шустрый блог. Нет, время загрузки уменьшится незначительно.
Так что если хотите облегчить жизнь своему WordPress, то не плагины кодом заменяйте, а думайте, от какого функционала вы готовы отказаться во имя ускорения блога.
Тут есть нюанс: если в плагине помимо php-скриптов, присутствуют его собственные JS-скрипты и таблицы стилей, то тут уже замедление скорости работы будет присутствовать однозначно. Поскольку каждый css- или js-файл — это лишний http-запрос к серверу, на него и на ожидание и получение на этот запрос ответа и тратятся драгоценные миллисекунды.
Но и здесь есть выход: вовсе не обязательно сносить такой плагин. Его можно оптимизировать, перенеся его стили в основную таблицу стилей шаблона, и аналогично поступив и с js-скриптами. Главное, это правильно сделать!
Итог: не все плагины и не всегда тормозят блог. Тормозит его только функционал, который вы добавляете. Неважно, каким способом!
Миф второй: Замена запросов в header.php на статические данные ускоряет блог
Не знаю, ребят, кто это придумал, если честно… Но совет этот вы наверняка встречали: заменить в файле header.php запрос названия блога вида
php bloginfo('name');на статическое значение, подсмотренное в исходном коде страницы. То же и для дескрипшена, и для других значений. Якобы это уменьшает число запросов к БД и ускоряет тем самым блог.
А теперь правда. А заключается она в том, что в самом начале загрузки вашего блога WordPress делает вот такой запрос к БД:
function wp_load_alloptions()
В ответ возвращается массив, в котором содержатся все основные параметры вашего блога: название, описание, кодировка и т.д. А в дальнейшем уже все запросы идут к этому массиву, а не к БД.
Поэтому такое «ускорение» не только бесполезно, но и порой вредно: сделали вот так вот и забыли, а потом при попытке изменить описание всю голову сломаете, почему оно не меняется — да оно же у вас в исходном коде жестко прописано, но кто ж об этом вспомнит!
Миф третий: Яндекс не любит WordPress
Ну это как бы не совсем миф, ибо научным путем доказано, что Яндекс не любит WordPress, ненавидит Joomla, терпеть не может Друпал и все остальные движки, а также самописные сайты на голом html 🙂
Яндекс вообще особенной любвеобильностью не отличается, однако нужно понимать: поисковый робот не видит файлы вашего движка. Он видит только тот html-код, который он генерирует.
А html-код в равной мере формируется как самим движком, так и файлами шаблона, кодом плагинов и контентом. И Яндексу, как и любому другому поисковому боту, нравится, когда этот код аккуратный, «чистый» и хорошо структурированный. А все потому, что на чтение такого кода уходит меньше времени, а значит, меньше ресурсов Яндекса.
Поэтому оптимизируйте код, выбирайте правильные шаблоны (хотя знаю как минимум одного популярного блогера, на блоге которого отлично себя чувствует творение Артистира), и будет вам счастье!
Миф четвертый: WordPress — дырявый как решето
Очередная полная ерунда. Над развитием WordPress трудится огромное количество профессиональных разработчиков со всего мира. Безопасность самого движка повышается от обновления к обновлению, разработчики плагинов так же постоянно обновляют свои детища.
В силу того, что WordPress-сообщество огромно, о прорехах и уязвимостях становится известно практически моментально, под них пишутся патчи-заплатки. А если вы сами не обновляете движок, используете старые и неподдерживаемые плагины, не защищаете свой блог, то кто вам виноват?
Миф пятый: WordPress крайне тяжелый и неповоротливый
Опять-таки, смотря чем его обвешать, друзья, и на каком хостинге пытаться запустить, какая посещаемость у вашего проекта… Конечно, WordPress потяжелее будет сайта из статичных страниц, но другим CMS по скорости работы не уступает.
А если вы хотите заставить его работать на бесплатном хостинге, имея 500-1000 уников и три десятка плагинов, то увы… Но тут не в WordPress дело, однозначно.
Миф шестой: наличие на блоге неактивных плагинов, тем оформления, черновиков, записей в корзине, ревизий тормозит блог
Прошу простить, но и это весьма далеко от истины.
По порядку:
- неактивные плагины и темы — только лишь занимают место не диске, ничего более. К ним не идет никаких обращений, их код не работает!
- черновики и записи в корзине — по сути ничем не отличаются от опубликованных записей. За исключением неважного сейчас нюанса. Тормозят блог? Да, конечно! Но у вас должен быть в общей сумме не один десяток тысяч записей, чтобы вы эти тормоза почувствовали на себе
- ревизии — займут место в вашей БД, но замедление работы будет настолько незначительно, что опять-таки вы его вряд ли когда-либо почувствуете
Вот так вот, друзья… А вы все еще верите, что смена плагина на код ускорит ваш блог? Тогда Web-Кошка идет к вам!
Наконец-то хоть где-то могу прочитать то, с чем согласна на 100%. А то такое бывает по напридумывают -)))
Смотрю ты немножко с цветовой палитрой экспериментируешь. Кстати, неплохо и ярко при открытии страниц в меню получается-))
Да, Юля, что-то изменений захотелось)
Не со всем, конечно, согласен, но в общих чертах вы правы.
Про плагины, я это уже давно понял. Большинство плагинов не оказывает заметного влияния на загрузку сайта. Есть некоторые, которые оказывают серьезное влияние. Я например, по этой причине отказался от плагина Social Share Button, а сейчас подумываю отказаться от Типограф Lite. Он делает типографское тире, каких-то других изменений от его применения, я не заметил.
Вот еще мифы — Яндекс.Метрика и древовидные комментарии.
Василий написал:
«Вот еще мифы — Яндекс.Метрика и древовидные комментарии.»
Как это? А поподробней можно?
У меня Яндекс.Метрика стоит для осознания статистики.
До древовидных комментариев дело не доходит в связи с отсутствием достаточного их количества.
Так в чём заключаются их мифы?
Вроде как Яндекс.Метрика очень губительна для блога, особенно молодого, для его продвижения, а древовидные комментарии якобы поисковиками считаются за дублирование контента на блоге…
Мне Яндекс.Метрика не мешает и не вредит. Наоборот, по ней и по Google Analitics я слежу за статистикой блога.
Древовидные комментарии широко использовались на старом блоге Елены Олейниковой. Вряд ли они его повредили.
Древовидные комментарии, Сергей, это вообще уже стандарт оформления комментариев. Так и гораздо удобнее, и выглядит логичнее. Так что говорить о их вреде вряд ли приходится.
Это широко известные мифы.
Про Яндекс.Метрику считают, что ее наличие понижает молодые блоги в поисковой выдаче. Якобы Яндекс благодаря ей анализирует такие сайты. Мне хочется спросить, а как тогда Яндекс анализирует другие сайты, где нет этого счетчика? Неужели без Метрики, Яндекс не имеет информации о сайте, а как же тогда роботы, которые сканируют сайт вдоль и поперек? Как я думаю, для помещения сайта на определенное место в поисковой выдачи, у Яндекса есть десятки, а может быть и сотни разных алгоритмов, которые, конечно, никак не связаны с наличием на таком сайте простого счетчика посещаемости.
Древовидные комментарии — это тоже примерно тоже. Якобы они влияют на посещаемость. Из-за них у сайта образовываются дубли страниц и такой сайт поисковики понижают в поисковой выдаче. Скорее всего, это тоже ложное представление. На выдачу Яндекса это никак не влияет, он это не учитывает. Про Гугл трудно сказать, что-то определенное.
Согласен с Вашими мнениями на 100 процентов.
Статья Ларисы правильно определяет истоки мифов. «Знатоков» очень много появляется после поверхностных знакомств с какими-либо знаниями.
Читал, некоторые писали, что мол удалил такие комментарии и посещаемость сразу выросла. А может это просто совпадение. Один писал, что одни древовидные комментарии не влияют, а другого типа древовидные комментарии влияют. В чем разница не знаю, он обещал написать, но не написал.
По своему опыту скажу, что такие комментарии на моем сайте стояли с самого начала и не оказывали никакого влияния на посещаемость. Например, сайт за полгода дошел до тысячи посетителей, несмотря на форму таких комментариев.
Они установлены практически у всех топовых блогеров, за редким исключением. Притом не только у нас, но и на очень популярных зарубежных блогах. Зарубежному опыту я в этом плане доверяю даже больше… Хотя бы потому, что англоязычный гугл.ком свирепствует куда сильнее, чем наш русскоязычный.
Вот про древовидные комментарии. Никогда не понимала, каким образом именно из-за них возникают дубли. Если на то пошло, то комментарии можно вообще закрыть в robots.txt. При этом индексироваться они все равно будут вместе со страницей, к которой относятся.
Объясняют, что Гугл вроде бы, из-за этого понижает сайты в выдаче. Причем Яндекс на это не обращает никакого внимания. По-моему это очень спорное мнение. Для поисковика более важны совсем другие критерии, чем возможные дубли из-за формы комментариев.
Я вот очень далека от всех этих алгоритмов, причин повышения-понижения в выдаче и т.д. Но с точки зрения здравого смысла то, что добавляет удобства пользователям, должно радовать и ПС. Ни разу не встречала практических подтверждений этому утверждению, каких-то экспериментов, поэтому полностью соглашусь, Василий.
В Google собирается уйма дублей из-за древов, но в последнее время все чаще прихожу к мысли, что вред от страниц-ответов, которые не попадают в основной индекс, но увеличивают количество «соплей» не так велик. Поэтому, если вебмастер для комментаторов хочет сделать более комфортные условия и не брезгает «соплями», может оставлять их. А я что-то брезгаю 🙂
Согласен, Василий, бред какой-то про Яндекс метрику, зачем яше понижать молодые блоги в выдаче
Еще этот плагин правит кавычки, насколько знаю. Тоже его использую.
Кавычки я уже везде сделал вручную, пару недель свободного времени на это ушло. 150 статей, а в каждой этих кавычек… Это никак не было связано с плагином.
А сейчас выходит, что он стоит только для типографского тире. Из плагинов, сейчас, он больше всего влияет на загрузку сайта.
Однако, Василий, соцкнопки же вместо него поставили какие-то? Интересно было бы сравнить скорость загрузки с плагином и без него, но с кнопками, сделанными вручную.
Скорость загрузки стала быстрее. Он, действительно, сильно нагружал сайт при загрузке. Пришлось его удалить, хотя он мне нравился.
Интересно, а если его удалить, очень сильно внешний вид статей пострадает? Надо посмотреть…
Типограф? Предполагаю, что не очень. Длинные тире хорошо видны только в заголовках, а в тексте статей никто разницы не заметит.
Отключила, особой разницы действительно пока не вижу. А то, что вижу, не принципиально. Так что спасибо за наводку, Василий)
Тоже отключил Типографа. Есть еще пара штук, о которых можно подумать, что их тоже следует отключить.
Ох уж этих мифов…полным полно. Пока на себе не проверишь, не поймешь) Но с плагинами достаточно запугали ;)) А яндекс вообще «противный» поисковик…с этим согласна. Новичку под него не подстроиться.
Почему нельзя подстроится? Вполне возможно подстроится и к Яндексу.
В поддержку этой информации скажу, что у меня на блоге много плагинов (порядка 30), но какого то замедления скорости работы блога не замечаю, наверное это больше зависит от хостинга. Счетчик Яндекса поставил, но по моему от этого Яндекс стал быстрее индексировать мои статьи. То есть минусов не видно.
Кодами не пользуюсь, так как пока не умею.
Да, мне тоже кажется, что больше влияет сам хостинг
Это точно! Мифы повсюду, особенно советы по минимальному количеству плагинов. А ревизии лучше отключить, хостинг не резиновый и бэкапы меньше будут. Ну мне они не нужны, не хочу лишнее место тратить. В остальном согласен.
Да, ревизии имеет смысл отключать только ради экономии места. А у меня хостинг резиновый, я не отключаю)))
Ревизии как раз иногда и спасают. Конечно, если статьи состоят в основном из текста, то это не проблема скопировать ее заново в редактор. А если, кроме текста, изображений 10-20 в статье? К каждому изображению нужно еще заполнить соответствующую информацию. Ревизии реально, иногда, спасали. Не нужно было заново делать столько работы, не считая еще и затрат времени.
Когда статья опубликована, включаю пару плагинов, очищаю ревизии и все остальное. А потом можно делать резервную копию сайта.
Точно абсолютно! Если бы не ревизии, то на этом блоге пары-тройки статей просто бы не было — пишу сразу в админке, а периодически подводит интернет…
Очень нравится в последней версии WP то, что при обрыве связи копию статьи недописанной сохраняет в браузере — действительно очень и очень здорово!
Я понимаю, что в очередной влажу в обсуждение тонкостей WP, имея о нем представление на уровне «Пастернака не читал, но осуждаю», тем не менее замечу, что поднятые Ларисой вопросы актуальны вообще для любых проектов. Расширяешь функциональность — понижаешь быстродействие. О вреде оптимизации давно и много пишут: убиваешь кучу времени на выигрыш в три сотых секунды в реакции процессора для десктоповских аппликаций или сервера для вебовских, а когда добиваешься задуманного эффекта — выясняется, что за то же время процессоры ускорились на порядок, а серверы даже на дешевых хостингах уже научились отбивать на порядок большее количество запросов с той же скоростью. Писать ручками код вместо использования готовых расширений целесообразно только в случае, если эти расширения действительно тормозят сайт, а тормозить его они могут по единственной причине, и причина эта — кривые руки разработчиков. Конечно, если обвесить ядро сотней плагинов — оно в ступор впадет даже на быстром железе и шустром хостинге, но использование пары десятков грамотно спроектированных расширений может сделать сайт вполне функциональным и при этом если и замедлит время отклика, то на сотые доли секунды.
А мифы всегда были, есть и будут. Их легко развенчать опытным путем. Не все склонны проделывать эти опыты, для таких и пишутся подобные статьи.
Да, Олег, точно — все, о чем писала, применимо и к другим движкам. Но вот такой истерии вокруг замены расширений кодом среди джумловодов, например, нет.
Ну тормозят все-таки плагины, а не код. Возможно, от того , что они так устроены и по другому работать не могут. А тормозят потому, наверное, что приходится кучу лишних плагиновских файлов гонять от хостинга потребителю, а если код встроить, то выполняться то он будет за то же время, а вот лишних пересылок не будет, а это реальная экономия времени. Ведь быстродействие линий передач, как и приемо-передатчиков, конечно. Если конечно грамотно плагин сделать, то вреда наверное не будет. Но ведь это надо СДЕЛАТЬ!
Андрей, рада видеть на блоге)
Вот в том-то все и дело, что неправильные представления такого плана возникают из неверного понимания сути процесса. Файлы плагина не гоняются от сервера к пользователю. Весь php-код исполняется на стороне сервера, именно на сервере к коду движка подключается код шаблона, код активных плагинов, генерируется html-код, который и передается потом пользователю. То есть единственная потеря времени, которую можно здесь заметить — это временные затраты на подключение плагина. А они настолько минимальны, что из-за них говорить о большом выигрыше при замене плагина на код просто неприлично и неверно)
Верно, плагин нужно написать… но ведь и код, на который будем заменять плагин, тоже надо написать…
Все здесь не так просто, я думаю. Просто мой уровень подготовки не позволяет мне досконально разобраться в этом процессе, но опыт кое-какой имеется. Этот вопрос у меня возникает постоянно, поэтому хочешь-не хочешь, а придется разбираться. Но сперва закончу обучение.
Многие путают принципы работы php и JavaScript забывая, что в первом случае код исполняется на стороне сервера, а не пользователя и выигрыш между кодом на странице и хорошим плагином будет практически незаметным. Но вот при смене шаблона темы придется вспоминать все места, куда дополнительный код вставлялся. При этом плагины тестирует очень много пользователей, а косяки индивидуального кода выявить будет сложнее.
Во многом с Вами согласен, но в отношении плагинов, всё-таки тут должен быть разумный предел. Потому как, если будет их переизбыток, то всё-таки загрузка страниц, как не крути, будет тормозиться по-любому…
Евгений, здравствуйте)
Верно-верно, предел должен быть. Но я все-таки настаиваю на том, что ограничивать нужно не количество плагинов, а функционал блога вообще, оставив только тот, который на самом деле нужен.
И даже если заменить все-все плагины на код, то большого выигрыша в скорости получиться все равно не удастся 🙁
Привет! Какие злободневные темы понимаешь, молодец. Вставлю свои три копейки…
По плагинам.
В основном ты права, не все плагины нагружают блог и снижают быстродействие, но… но плагин плагину рознь. Ведь по сути плагин — это код с прикрученной к нему панелью управления, вот и все, но есть плагины с таким функционалом, который не используется и на 10%. Например, плагин для обратной связи. Контакт Форм, по-моему. Это же не плагин, а комбайн различных форм, ну зачем он на блоге? К тому же к нему надо прикручивать еще один плагин капчи. Ну зачем такие сложности. Хотя обратная связь нужна, но ее можно сделать и кодом и скриптом или сторонним сервисом.
По моему опыту, тормозят не плагины, а скрипты и не оптимизированные картинки. Вот это да, это проблема.
По второму пункту. Я даже знаю кто такую мульку запустил. Но говори не буду… Догадайтесь сами.
А в остальном согласен, мифы они и есть мифы.
Экспериментируешь с оформлением? Красиво стало, только красны цвет сильно красный, на мой дилетантский взгляд
Привет, Артем)
Вот ты очень точное замечание сделал — мы часто ставим плагины, которые вроде бы и нужны, с одной стороны, а с другой, больше половины их возможностей использовать все равно не будем, но ведь круто же)))
Да, очень здорово тормозят скрипты, когда они к тому же и поставлены неправильно. Их же в футере подключать обязательно нужно, и это не миф, а действительно полезный совет. А то получается, что браузер получил JS-скрипт в хедере и начинает его исполнять, пока не исполнит — остальную часть страницы загружать не будет. А зачем его сразу исполнять, если все равно визуальные элементы не загрузил — кнопки, слайдеры и все такое…
Со скриптами еще важно, что бы доступ постоянный был. А то я себе ставил один баннер на js срипте, так такие тормоза потом были… А все из-за того что настройка скрита не правильная была
Ага, мой красный — самый красный из всех красных) Еще может, и поменяю… Зато заметь, как в главном меню кнопочки красиво меняются при наведении)))
Хе-хе, CSS3 рулит! У тебя не только в меню меняются, а еще и в комментах и еще кое где… Ты тогда градиент добавь, на анимацию. То есть, что бы при наведении не просто цвет появлялся, а был градиентом. Вот например, кнопки в меню у тебя с градиентом от светло-голубого до голубого, а ты сделай что бы при наведении был градиент от красного до светло-красного
У меня на кнопке Подписаться так сделано
Ага, я хотела, а потом что-то так лениво стало код писать))) У тебя тоже вроде много нюансов интересных появилось в дизайне. Тема начинает проявляться во всей своей красе.
Самое смешное, что эти нюансы начинаешь замечать на чужих сайтах, только когда сам такое делаешь.
Держи код для градиента, только цвета поменяй
background: #8F0E1A; /* Old browsers */
background: -moz-linear-gradient(top, #E13B50 0%, #8F0E1A 100%); /* FF3.6+ */
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#E13B50), color-stop(100%,#8F0E1A)); /*Chrome,Safari4+ */
background: -webkit-linear-gradient(top, #E13B50 0%,#8F0E1A 100%); /* Chrome10+,Safari5.1+ */
background: -o-linear-gradient(top, #E13B50 0%,#8F0E1A 100%); /* Opera 11.10+ */
background: -ms-linear-gradient(top, #E13B50 0%,#8F0E1A 100%); /* IE10+ */
background: linear-gradient(top, #E13B50 0%,#8F0E1A 100%); /* W3C */
Есть еще классный сервис, который позволяет получать код градиента, вот адрес не помню. Поищу
Артем, это случайно не автор скрипта MaxCache?
Нет, не он. Я такую статью у Борисова читал
Приветствую! Плагины не все тормозят, но все-же… К тому-же, если их действительно много, то тормоза однозначно будут. Тут, в комментах кто-то писал типа «у меня много плагинов, порядка 30″… Это разве много? У меня их 34 и я не считаю, что это много. Знаю кое-кого с 90++ плагинами… Другое дело, что далеко не всегда готовые решения (плагины) устраивают по функционалу. Даже очень известные. Такие плагины я на своем блоге заменяю собственным кодом. Например ту-же форму обратной связи или вывод связанных записей… Код минимален, на несколько порядков легче аналогичных плагинов, а главное подстроен под собственные нужды. Считаю такую замену всегда оправданной.
Так что миф про плагины — не совсем миф. Я бы разделил их на 2 условные группы — те, которые срабатывают при загрузке блога (а их почему-то большинство) и те, которые срабатывают только в определенный момент по событию. Первые — тормоза, пусть минимальные, но в сумме могут быть ощутимы. Вторые — безвредны в плане общей нагрузки и времени.
Про Яндекс Метрику… Всегда ставлю с самого начала на любой новые проект. Никаких потерь в индексации, а статистика нужна в первую очередь мне.
Александр, с точки зрения логичности и правильности порядка исполнения кода быстрее работает вариант, когда изначально подключаются плагины, код которых отрабатывается в первую очередь, а затем идет загрузка страницы. Нежели функция будет исполняться прямо по ходу загрузки.
Так что со стороны грамотности архитектуры кода использование плагинов более оправдано, чем вставка кодов вручную.
Возможно, какие-то плагины и имеет смысл заменять кодом, но это скорее в силу того, что нужен либо более узкий, либо более специфический функционал, нежели предлагает плагин. Опять-таки, нужно быть уверенным в качестве своего кода.
Позволю себе не согласиться. В чем же тут правильность и логичность? Вот скажите, зачем мне грузить плагин, который по ходу посещения блога может ни разу не сработать?
Александр, не совсем так. При загрузке определенной страницы считывается и обрабатывается только код тех плагинов, которые, «будут участвовать» в работе только данной страницы. Простой пример. Плагин для оформления текстовых блоков не будет подгружаться на те страницы, где такие текстовые блоки не используются. Точнее, не так. Код плагина обработается, но обращений к нему не будет, поэтому и выполняться тоже не будет. Во всяком случае, принцип загрузки ресурсов WordPress сейчас именно таков. Поэтому и страшилка о плагинах морально устарела — живет она еще от старых версий движка, где действительно с этим были проблемы.
Кошка, так я-же об этом и написал в первом комменте… условно разделив плагины на 2 группы. Но Вы не учитываете еще момент проверки обновления плагинов. Сколько плагинов, столько и запросов к их страницам. А это время! И хотя результат таких проверок виден только в админке, не уверен что запрос выполняется только там.
Александр, ну значит, мы с разных сторон пришли к одному выводу, и это радует) А вот по поводу проверки обновлений, это да, время тратится. Но! Это же вопрос безопасности сайта, проверять обновления и обновляться нужно обязательно. Другое дело, что можно опять-таки одним плагином деактивировать проверку обновлений остальных, и проверять вроемя от времени, деактивируя запрет. Кстати, то, что плагин обновляется, это только плюс по сравнению с ручной вставкой. То, что вставлено ручками, может не заработать после обновления движка, например. Да и все-таки большинство заменяет код на плагины, беря этот код где-то, а не написав самостоятельно. По-моему, на сайте, которым дорожим, странно использовать те вставки, смысла которых, во-первых, не всегда понимаем (ибо не все программеры), а во-вторых, нет уверенности в качестве этого кода. Проще и безопаснее уж плагин поставить, который, будучи скачан из оф.репозитория, какую-никакую проверку качества прошел, да и отзывы говорят сами за себя. И разрабы, как правило, на порядок профессиональнее, пусть и не всегда.
В конце концов, я нисколько не настаиваю на том, что плагин всегда лучше кода, нет. Просто не нужно их бояться и истерически метаться в поисках возможности все заменить кодом.
Во всем поддерживаю автора статьи. Параноидальное желание любыми способами вкрячить код любого функционала именно в код темы WP, в советах некоторых «специалистов» просто потрясает. Так и хочется сказать — «ну включите вы мозг то уже себе». Есть мастера которые вообще умудряются обходится без плагинов и гордятся этим. Потом правда, наступает прозрение когда например, приходит необходимость обновить тему 🙂
Здравствуйте, Дмитрий! Рада Вас видеть, давно читаю)
Таки да, основные проблемы начинаются, когда нужно тему обновлять. А еще — если по каким-то причинам функционал перестает работать, а куда и как код вставляли, уже никто не помнит (а комментирование кода не в наших суровых правилах 🙂 ). И если криво работающий плагин можно просто деактивировать и удалить, то хорошо зарытый код таких шансов не дает. А если он туда был изначально разработчиками вшит, как в премиум-темах, то вообще… Плюс еще плагины обновляются, а это немаловажно.
Знаю одного блогера, он живет вообще без плагинов. Зато тему не обновлял года два, боится)))
Приятный у Вас блог, Лариса. Удачи и побольше читателей!
Спасибо, Дмитрий)
Почитал , могу сказать что автору не надо писать о том что он не знает. Тестировать надо и тестировать а потом писать.
Года 2 назад я проводил тесты на тему жумла vs wp — так вот wp как выяснилось в дефолтовой конфигурации жрет больше памяти чем жумла.
Так что тесты и только тесты а не голословные высказывания.
Насчет WP два года назад утверждать не буду. Насчет Joomla, кстати, тоже. Речь не идет о абсолютно точных вычислениях, а о том, что те различия по времени загрузки весомого значения не имеют. Для обычных сайтов, коих в сети большинство. Хотите нечто, полностью оптимизированное под свои нужды — пишите движок сами, он будет идеален. Тем более что упоминание про тесты двухгодичной записи, то бишь сравнение WordPress 2… и Joomla — не помню, была ли уже 1.7? — сейчас некорректно, ибо ядро и того и другого движка было значительно переписано, а значит, сейчас эти результаты неактуальны. Есть новые тесты? Познакомлюсь с удовольствием, даже сошлюсь)
Вы diff смотрели чтоб утверждать чтоб оно значительно переписано?
А тесты сами берете и делаете — это просто =)
Мы действительно сейчас начнем обсуждать изменения в ядре Joomla от версии 1.5 к версии 3.0?
Вложенность ответов нашей полемики достигла предела, поэтому пишу здесь… 🙂
Спора, собственно как такового, у нас и нет. Вы абсолютно правы в том, что не все плагины создают пресловутые тормоза. Достаточно хотя-бы установить себе P3 и картинка сразу станет ясной. У меня, например, при 32-х активных плагинах общее время их загрузки равно 0.166… что составляет 57,8% от загрузки страницы вообще. Так, что тут и говорить даже не о чем. Так-же соглашусь, что истерить по поводу плагинов не следует. Но если их, плагинов, на порядок больше, а еще если попадается действительно тормознутый, то тут да… Анализировать, менять и возможно на код. Код, кстати может и абсолютно не зависеть от движка. В качестве примера опять же приведу свою форму связи. Она может работать на любом сайте, в т.ч. и рукописном. Но, все-же ложка дегтя есть и в плагинах — опять пример. Как-то ставил Special Text Boxes — очень красивый плагин для выделения текста в статьях. А вот после какого-то обновления он просто перестал работать. И это я заметил так-же на некоторых других блогах. И что-же? Ждать какого-то обновления? Менять все в статьях? Свой-же собственный код я при случае всегда могу и подправить. Ну это так… к слову. Кодить все подряд конечно-же нет смысла. Во всем надо знать меру.
А теперь внимание, главная мысль! У Вас очень приятный блог и я с удовольствием здесь бываю. Вы пишете очень интересно.
Спасибо, Александр)
Насчет неповоротливости ВП — знаю несколько иностранных блогов с посещаемостью более 100 тыс/уников. Нормально все работает по тестам.
У нас медленно открываются исключительно из-за удаленности сервера.
Лариса, привет!
Статья просто класс. Я абсолютно такой же точки зрения, как и ты. Тебе давно следовало об этом поведать =) Кстати, вся эта тема сейчас тоже в тренде, как я заметил =)
Привет! Так ты же меня первый на эту мысль и навел)
У тебя все в порядке?
Для того и навел =) Я же знаю тебя, ты в вопросе разберешься досконально, и статью выдашь! 😉
У меня, конечно все нормально. Иначе быть не может 🙂 В незапланированный отпуск по «горящей» слетали. Отдохнул.
Вот здорово! 🙂 А то мы с тобой последний раз в скайпе общались, помнишь, а потом ты пропал, я заволновалась)
Ага, вот на следующий день нас как раз друзья и соблазнили на поездку по горящим путевкам. Как раз 4 было. Вот вчетвером и поехали. Днем оплатили, ночью уже в самолете летели =))
А кошка?
Маме отвез. Кстати, она выздоровела 🙂
Вот, я тебя об этом и спрашивала) Хорошо 🙂
Всем привет!
А мы раньше с мистером Кликом думали, что все плагины по чуть чуть тормозят блог. Оказывается нас просто деинформировали на каком то блоге)
Привет) Вспоминайте на каком и требуйте жалобную книгу)
Ок, так и сделаем.
P.S. — Мне то все равно, а вот mr.Клик ух как не любит, когда его обманывают 🙂
Боюсь спросить, как он поступает в таких случаях)
Ну если он найдет виновника, то сотрет все килобайты информации о его существовании)
Отличная статья! Я не раз сталкивался со статьями, объясняющими, как решать первые два мифа, пытался как-то оптимизировать… А тут вон оно как 🙂 Спасибо за полезную информацию.
И категорически поддерживаю то, что мифом являются утверждения, что вордпресс — дырявый, тяжёлый и неповоротливый. Перепробовал самые разные платформы — не видел ни одной такой же удобной и «лёгкой». Да, говорят, что для создания огромных порталов Вордпресс мало подходит, но его же делали именно как движок блогов 🙂
Михаил, здравствуйте! Правильно, для создания больших порталов WordPress, может быть, и не лучший выбор… Но и мерседес — не лучший выбор, когда на рыбалку собираешься)
Выскажу свое ИМХО:
1) По 1-му мифу однозначно сказать ничего нельзя, все зависит от прямоты рук разработчика(ов) плагина
2) 2-й миф, целиком и полностью согласен. Найти бы того быдлокодера, который предложил заменять PHP-функции в теме на статические данные, да дать ему в рыло
Да и с остальным я полностью согласен
Да, общее заблуждение в том, что все плагины и всегда тормозят. К счастью, это далеко не так.
Автор поста — специалист в вопросах программирования, оптимизации БД, информационной безопасности?
Детский сад какой-то. Аргументация в стиле «не обижай мою любимую игрушку». Кто смотрел в код WP (речь о программистах), тот содрогнётся от ужаса — такого спагетти ещё поискать. О безопансоти — тоже хороший вопрос. Сам по себе WP достаточно залатан, но вот при разработке API явно не заадумывались ни о каких вопросах оптимизации и безопасности.
Истина в том, что специалис настроит и сделает стойкую и быструю блог-платформу из чего угодно (Serendipity, WordPress, Movasble Type… и ещё сто двигателей). Дилетант сделает сами-знаете-что из любой конфетки.
Но для экспертного суждения о WP сошлитесь на статьи экспертов, пожалуйста. Чтобы заставить WP летать и бодро всё делать, нужно умение. А оно не берётся из чтения блогов «как сделать в WordPress такую-то классную штуковину».
Будем здоровы.
Здравствуйте!
Нет, автор не эксперт, но и статья не рассчитана на экспертов. Мы с Вами немного в разных плоскостях. С точки зрения профессионала ни один движок не удовлетворит абсолютно всем требованиям. Однако именно вышеперечисленные «недостатки» заставляют многих начинающих отказываться от WordPress в пользу других CMS, недостатки которых не так растиражированы, а потом сталкиваться с куда более серьезными (для начинающих) проблемами, нежели безопасность при использовании API.
Впрочем, отлично понимаю Вашу позицию :).
Интересно. Наверное я где-то подсознательно начала сама догадываться о том грузят или нет блог неактивные плагины, раз уж стала искать информацию об этом 🙂 Спасибо за статью!
Рада видеть на блоге, Татьяна! 🙂
Благодарю за интересную статью… Обожаю гречискую культуру все что связано с грецией…
Прочитал с большим интересом…
Уверена, что это так, именно поэтому удалила сайт из профиля, чтобы не бросать тень сомнения на Вашу искреннюю любовь к Древней Греции.
Ну, мифы во всех областях у нас любят =) Бабушка на деревне сказала, а сороки разнесли
Спасибо за статью, понравился ваш стиль написания
А за Типографом надо понаблюдать будет…
Спасибо, Анастасия 🙂