В WordPress все, абсолютно ВСЕ функции, работающие с БД, проходят через родные функции sanitize_*, которые, в свою очередь, прогоняют данные через функции, о которых вы упомянули, и не только через них. Запросы в WordPress тоже правильно строятся и никакой угрозы иньекций нет. На то это и фреймфорк/цмс, там эти базовые вещи давно решены на уровне ядра.
maxxannik: в целом согласен. Но overhead на прочность имеет смысл только в крупных и сложных проектах. У топикстартера явно не тот масштаб. Проще в одном месте под конкретную задачу подкрутить.
maxxannik: да, это немного усложняет, но не критично. Я так понимаю, на главной надо не выводить первый пост в основном лупе, ибо он, вероятнее всего, выводится в слайдере или что-то в этом роде, отдельно. Вообще, в этом случае разумнее сделать его sticky, но это уже отдельная история. А прятать в рубрике - я в первую очередь не понимаю в какой вселенной это может понадобиться :) Но если уж надо такие тонкости, то лучше идти методом исключения - добавить проверки "если это не Х, Y, Z - во всех остальных случаях первый пост не показываем. Так будет надежнее.
В общем, согласен - можно придумать несколько сложных случаев, но это чистая теория, скорее всего в реальной жизни такое не понадобится.
ЗЫ: а мы на WP пишем платформу для организации и проведения спортивных событий, ведения учетной базы ассоциаций и федераций, клубов, в том числе личные профайлы всех спортсменов и их карьера / история. Тоже, кагбэ, проект не мелкий. С граблями та же тема - за версту чую )) Столько их было :)
maxxannik: не обязательно, можно в if() в этой функции добавить проверку && is_home() например, тогда вырезать первый пост будет только на главной странице. В общем, все условия и фильтры можно спокойно вписать там. Не надо дополнительных запросов, не усложняйте себе жизнь :)
Данил Загорский я вас умоляю, забудьте о существовании query_posts(). Это утилитарная функция, от которой больше проблем, чем пользы. И уж точно не стоит ее юзать для основного и альтернативных лупов. Никогда! Поищите в сети видео выступления Константина Ковшенина по поводу WP_Query.
Ефим Соколов: в вопросе, насколько я понял, конкретно спрашивается про доступ в админку wordpress. По поводу же прав в целом - в сети туча уроков. Подходы разные. Тот же wordpress делает весьма неплохо, код задокументирован - концепцию можно получить оттуда.
Во-первых, вопрос касается 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 - вообще мрак. И так - куда ни глянь.
