Дмитрий: о_О
в functions.php или в site-specific плагине (можно его сразу в must-use). Первое, думаю, понятно, а по второму детализировать сознательно не буду - гугл в помощь. Если самостоятельно по наводке ничего не изучать - толку будет мало :)
В 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: а зачем еще одну таблицу промежуточную и гонять данные туда-сюда, джоины лепить? Предложенная таблица - это отношение "многие к многим", полностью решает эту задачу. Есть, конечно, некоторые нюансы, но тут скорее надо исходить из конкретных требований.
