Славка Великолепный: я как раз не удивляюсь, за 10 лет работы с WP насмотрелся такое количество говнокода и граблей, что на два поколения хватило бы. CMS "гордятся" не только этим. Во-первых, нужно смотреть в нескольких плоскостях. CMS удобна в первую очередь клиенту. CMS - дешевле и быстрее, нежели написание кастомной платформы с ноля, и для любого бизнеса (клиента) экономия расходов, как и сокращение времени на разработку - большой плюс. К тому же, при использовании CMS легче сменить подрядчика, нет привязки к чисто кастомной платформе, в которой другие программеры даже не захотят разбираться. Во-вторых, писать, толком не изучив языка, начинают и свои собственные CMS. Честно говоря, я не знаю ни одного программера, который бы в первые 2 года своего пути не пытался написать свою собственную CMS. С одной стороны это хорошо - адекватный человек в процессе поймет, что ничего толком еще не знает, увидит масштаб трагедии и начнет изучать глубже. С другой стороны, если такому горе-писаке попадется несведущий клиент, то получаем некий странный продукт, за который заплатили деньги, и программист искренне уверен в том, что проделал отличную работу. Обычно развитие на этом этапе либо сильно затормаживается, либо вообще останавливается. WordPress и ситуация с говнокодом сами по себе не уникальны. Это повсеместное явление. Количество говнокода на базе Symfony тоже превышает все разумные пределы. На базе Zend Framework - вообще мрак. И так - куда ни глянь.
naneri: гибкость WordPress позволяет делать и любые тяжелофункциональные решения. Фокус только в том, что делать это надо "WordPress way", по-вордпрессовски. А для этого уже нужно ОЧЕНЬ хорошо знать все ядро системы. И вот в этом причина того, что многие делают странные и шаткие конструкции, состоящие из граблей. Нежелание изучить систему глубоко. Пишут чисто свой кастомный код, в своем кастомном стиле, не используя функции ядра, а создавая свой функционал, не имеющий ничего общего с WP, вплоть до прописывания SQL-запросов вручную. Если же сделать все правильно, то сопровождение и доработка ЛЮБОГО функционала - просто и удобно. Если открыть папку wp-includes, по большому счету вы увидите набор низкоуровневых классов, как и в любом фреймворке. Научившись понимать структуру данных и page lifecycle (что за чем и как выполняется в процессе обработки запроса и генерации страницы), можно делать что угодно.
xmoonlight: глупости говорите. Люая CMS, CMF или фреймворк - это всего лишь инструмент. Если инструмент подходит под конкретную задачу и находится в умелых руках, если его правильно использовать - он будет выполнять свою заддачу, проект будет приносить деньги, а холивары о самих фреймворках - это бесполезное технодрочерство. Я использую Laravel, WordPress и Expression Engine. Для конкретной задачи в вопросе лично я бы взял WordPress, ибо проект по сути это - блог. Примитивный с точки зрения структуры, плоский новостной портал. Статьи, комментарии, видео (скорее всего oembed youtube), фото, рубрики, метки. Стандартный набор. Для кастомизации метаданных, коих будет много, взял бы Advanced Custom Fields. Еще парочка плагинов под нужный функционал - и готово. Далее ставим один из плагинов кеширования, даже не W3 Total Cache, а что-нибудь полегче. Праймим full-page cache, выставляем правила и интервалы на репрайм и наслаждаемся быстрым и стабильным сайтом. Естественно, для полного счастья это делается на VPS, а не shared хостинге. Банальный Digital Ocean за $5, Nginx, PHP5-FPM 5.5.9 c OPcache, MariaDB 10, Memcahced. Все это, вместе с разработкой самого шаблона, делается за выходные, дальше - собственно наполнение контентом. Проект работает и начинает приносить деньги. Профит. И никаких холиваров.
xmoonlight: за моим "не вспомню" сразу следует "идите в гугл". И ответов в гугле достаточно, как минимум более адекватных чем ваша ссылка. Это раз. Два - мой выбор WP к делу не относится, я уже давно не тинейджер, вступающий в холивары и защищающий свое болото. Использую кроме WP и другие платформы и ффреймворки, но для большинства задач WP более чем достаточно. Выбор не был спонтанным, и в любой момент он может смениться, если будет другая система - лучше. На данный момент (в течение уже многих лет) WP является идеальным выбором для большинства среднестатистических решений. Три - по поводу кеширования и алгоритма. Кеширование нельзя просто так взять и выключить. Я не говорю о full-page кешировании, а о более низкоуровневом. И тут разброс между системами такой, что мама не горюй. Drupal по умолчанию содержит бекенд, большая часть ядра на него полагается сразу из коробки. Его невозможно полностью выключить. В WordPress же наоборот - по умолчанию он выключен напрочь, но подхватывается на лету если есть требуемый класс. У Джумлы свои особенности. Ну а "голый алгоритм" тестировать - это именно то, что я вам и пытаюсь донести. Алгоритм в голом виде в каждой CMS включает в себя совершенно разный набор функционала. Это не А и Б, это вообще А и Я. Разброс ОЧЕНЬ большой. Да и голый алгоритм в реальности никто никогда не использует, он бесполезен. Поэтому тестировать такой "алгоритм" - бред. Это синтетические цифры, не имеющие ничего общего с реальностью. Это как сравнивать художественный уровень фотографий по количеству мегапикселей в камере. У кого больше мегапикселей, тот более профессиональный фотограф. Бред же :)
xmoonlight: мне на глаза попадались раньше нормальные тесты на производительность, по памяти не вспомню, искать нету времени и желания. В англоязычном инете с помощью гугла их можно таки найти. В целом, для адекватного тестирования надо брать не голые инсталляции, а делать более-менее стандартный сетап, приближенный к реальному проекту, и одинаковый на всех CMS. С использованием разных популярных плагинов/модулей. Обязательно привести к одному знаменателю кеширование и прочие элементы оптимизации. К примеру, WordPress по умолчанию не использует persistent кеширование из коробки, хотя собственно код для этого есть. Но чтобы он работал, нужно залить в wp-content класс, который и будет интерфейсом между функционалом кеширования WordPress и собственно кеширующим бекендом - Memcache, Memcached, Redis и т.д. В иделае, надо и функцонал приводить к тому же, чтобы все CMS одинаково кешировали или не кешировали все элементы страницы, запросы и т.д. И это только один из множества нюансов. Только настроив таким образом идентичный сайт на разных CMS можно проводить тесты о ожидать каких-то более-менее адекватных данных для сравнения. Во всех остальных случаях - это бесполезные синтетические тесты, не имеющие ничего общего с реальность.
Лично я разрабатываю преимущественно на WordPress. Ядро платформы за 10 лет изучил очень хорошо. У меня даже большие и сложные сайты грузятся очень быстро, выдерживают очень высокий трафик. Всегда. Ибо проблема не в CMS, а в правильном использовании тех возможностей, которые она предоставляет. Ну и вруках, конечно же.
xmoonlight: график не только не актуальный а вообще бредовый. По каким критериям скорость меряли? Скорость чего? Загрузка страниц? Обработка скриптов? На каком железе? С какими настройками? И т.д.
Все правильно. Сначала вы просто использовали дополнительный запрос, а пагинация брала данные из основного запроса. Через хук parse_query вы меняете параметры основного запроса. А вообще если это не 2й loop на странице, а единственный, то лучше полностью все аргументы вашего WP_Query выполнить через хук pre_get_posts. Тогда все необходимые данные получите собственно сразу в основном запросе.
asd111: правильный html важнее для поиска и для accessibility. А также для корректного рендеринга. Правильный css важен для корректного внешнего вида, отображения, не более. Мухи отдельно, котлеты отдельно. Советую почитать про семантику.
@nezzard: мы все еще говорим о странице? То есть, странице - как объекте post с типом "page", который хранится в бд в таблице wp_posts. Правильно? Или уже о кастомном обработчике, и страница тут - виртуальный шаблон по своей маске урл?
@nezzard: parse_request и parse_query - это два разных хука, делаеющих разные вещи. Я же ранее рекоммендовал посмотреть WordPress Page Lifecycle. Сначала выполняется init, загружается functions.php и плагины. Далее выполняется функция wp(), которая инициализирует класс WP и выполняет $wp->main(). Далее вызывается $wp->parse_request который берет часть урл (кроме домена и GET-хвоста) и парсит ее в переменные, транслирует красивый урл в обычный запрос типа index.php?ke1=value1&...&keyX=valueX. Вот тут идет хук parse_request. Далее устанавливаются все переменные is_*, уже в $wp_query->parse_query() и формируется SQL-запрос. Хук parse_query идет уже в этом классе (WP_Query).
В общем, если надо использовать проверки is_* - надо работать через parse_query или pre_get_posts, если надо раньше - тогда через parse_request.
Какой пример привести? Я не совсем понимаю что вам в конечном итоге нужно) Вы уж лучше напишите четко что вам нужно получить, при каких условиях и на какой странице. А я тогда попробую на конкретном примере показать.
@dmitrytut: именно. Это уже просто переливание из одного сосуда в другой. Главное чтобы число было одинаковые - например, 10 убрали у одного, другому 10 добавили. Вот и все.
@olmerlv: а чего вы меня спрашиваете? я вообще использую и Flickr, и Amazon S3. Яндексфотки не использовал и не собираюсь, по идеологическим причинам, но это дела не касается. Это вопрос к автору, а не ко мне. У меня на крайняк еще есть один старенький дедик с 2Тб HDD, так что вопрос места на диске меня мало беспокоит.
@FMars: хватит за $5, максимум $10. Не тратьте деньги впустую. Если вырастете и потребуется больше ресурсов - на Digital Ocean можно легко перейти на более мощный сервер. Это же облако.
Вы издеваетесь? Для 10-20к как раз базового тарифа за $5 - по самые уши хватит. У меня на 1м таком дроплете раньше крутилось 3 сайта на WP c суммарным посещением 70-80к в день. И ресурсы использовались далеко не полностью. Сейчас перешел на дроплет за $10, там 7 сайтов на WP, один из них - WordPress Multisite, в котором 4 независимых сайта сети. Суммарно идет около 200к посещений в день, при чем на 2х сайтах большая часть трафика не из статического кеша - авторизованные пользователи и полностью динамический контент. Использование процессора скачет до 40% только когда целиком репраймится кеш, в остальное время не выше 15%. Память - максимум 60%, swap не используется.
