Во-первых, вопрос касается WordPress. Во-вторых - даже для своей системы это костыль. Если есть разные права доступа, значит эти права описаны своими сущностями - ролями, правами и т.д. - и надо делать именно через них, а не дополнительными полями в бд.
kstyle: внимательно прочтите ответ :) "Качать темы и плагины можно с родного сайта" - означает, что через админку их можно устанавливать не заморачиваясь. Зараженная тема в официальный репозиторий не попадет.
SergUnknown77: обновляться будет 100%, рано или поздно. Как минимум тогда, когда спустя Х месяцев работы сайта без обновлений он будет взломан :) Я таких клиентов не один десяток видел.
redkin: запрос на дружбу - это есть и то и другое одновременно. Это и факт дружбы (в одностороннем порядке), и действие - предложение другому пользователю подтвердить. Нюансы, о которых я упомянул - в какие стороны нужен поиск и фильтрация, группировка и т.д. Это как минимум. Где и как эти данные будут использоваться. Исходя из таких нюансов формируется архитектура. Возможно, стоит добавить в таблицу колонку-флаг "mutual" (взаимно или нет). Возможно хранить отдельными записями. Возможно, создавать объединенный индекс. Варианты есть, нужно смотреть по конкретной задаче.
Прелесть SQL-структур и абстракций данных в архитектуре как раз в том, что при правилььном планировании на начальном этапе в дальнейшем можно добавлять-удалять колонки, индексы, строить связи с другими таблицами, но при этом не ломать и не переколбашивать уже существующее. Простые relational таблицы - отличный пример подобных решений.
SergUnknown77: в nivo.css писать не стоит, при обновлении плагина это изменение будет утеряно. Пиши в style.css темы. По черной полосе - контейнер слайдера .nivoSlider имеет margin-bottom: 10px, его надо обнулить. Кроме того, обертка .slider-wrapper имеет нижний бордер 4 пикселя, его тоже нужно обнулить. В общем, тут чистый CSS, F12 в браузере и несколько точечных правок CSS.
Отдельный вопрос - зачем там ниво слайдер, если там одна картинка и никаких фич слайдера не используется?
redkin: индексы - это некие ключи для более быстрых выборок и сортировок. Учите, что это, без них никак. Если нет индексов - на каждый запрос будет делаться полное сканирование таблицы бд, всех строк. С индексами сложные выборки по одному или нескольким полям проводятся намного быстрее и эффективнее.
redkin: а зачем еще одну таблицу промежуточную и гонять данные туда-сюда, джоины лепить? Предложенная таблица - это отношение "многие к многим", полностью решает эту задачу. Есть, конечно, некоторые нюансы, но тут скорее надо исходить из конкретных требований.
Коля: совет был на конкретный вопрос, речь шла о конфигурации стека. То, что это известно одному, не означает, что все остальные тоже это знают. Более детальная конфигурация всех элементов - предмет отдельной большой статьи, если не серии. Мария - потому что это альтернативный форк с более оперативными нововведениями, лучше оптимизирован, быстрее работает. Производительность у Марии выше чем у стандартного MySQL, и даже немного выше чем у другого форка - Percona. Настраивать MySQL просто так невозможно, его нужно подстраивать под конкретный сервер, конкретный сайт (или сайты), который крутится на этом сервере - со всеми особенностями запросов к этому конкретному серверу. Для начала его нужно с месяц погонять в дефолтных настройках, а потом уже тюнить. Мемкешд тоже надо настраивать под каждый конкретный проект, дело ведь не только в объеме памяти, а в размерах slabs, факторе увеличения, методу и времени evictions и т.д. То же касается и OPcache. Batcache штука хорошая, но он подходит только для высоконагруженных сайтов. Он работает по принципу "если страницу посмотрели Х раз за Y минут - закешировать страницу на Z минут". Если страницу смотрят раз в 2 часа - толку от него 0, он всегда будет выдавать незакешированную страницу. И так далее. Тонкая настройка и оптимизация - это задача, которая делается вдумчиво и пошагово на конкретном сервере с конкретными проектами, все затачивается под конкретные особенности. Не существует одного набора оптимальных конфигов на все случаи жизни. Если есть конкретные вопросы - задавайте, можно отдельным вопросом. По мере наличия времени с удовольствием отвечу.
AndreyBerezhnoy: принято считать, что софт с пометкой stable - это стабильно и надежно, а все остальные ветки - нестабильны и не рекоммендуются для продакшн. В случае с Nginx это не так, ветка mainline стабильна и вполне подходит. От stable она отличается более актуальными фичами, скоростью. При ччем все новые фичи и улучшения никак не могут ухудшить работу сайта, только улучшить. Так почему бы не использовать? Собственно, сами разработчики Nginx советуют использовать именно mainline.
Libert: Page Speed сам по себе делает часть из того, что я перечислил, то есть, по сути, это вариант для ленивых. Все то же самое можно сделать без него руками, просто дольше. Но и контроль тоньше.
Славка Великолепный: я как раз не удивляюсь, за 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, а в правильном использовании тех возможностей, которые она предоставляет. Ну и вруках, конечно же.
