Тут проблема в том, что залогиненому админу можно подсунуть страничку с «изображением», которое на самом деле не изображение, а «правильная» ссылка — после чего все статьи пропадут. Как минимум здесь нужна проверка на POST (его без согласия пользователя уже сформировать труднее). Желательно — с генерацией уникального идентификатора для формы.
Первый код — из какого-то модуля, уже потерял. Что-то связанное с валидацией при регистрации.
Разработка и поддержка стала занимать слишком много времени и мешать другим проектам, а вот финансирование осталось прежним. Объем кода, увы, великоват для того, чтобы его кто-то подхватил (да и, признаюсь, местами я там поначалу наломал дров). Результат очевиден.
Как бы так сказать… у меня за время работы создалось впечатление, что у большинства фрилансеров задача увеличения объема продаж (в отличие от качества продаж) не стоит — рабочее время заполнить заказами (среднего и ниже среднего качества) очень легко.
> ИМХО, побитовые операции нативны для процессора и должны летать.
Есть такая штука — индексы. При их использовании сложность поиска в базе составляет, грубо говоря, O(log N). Без их использования — O(N). Порядок проигрыша в скорости поиска в такой базе на, скажем, миллионе записей ~100'000 раз. Вы еще хотите пользоваться нативными битовыми операциями в полях, по которым возможна выборка?
Первый код — из какого-то модуля, уже потерял. Что-то связанное с валидацией при регистрации.
Ай-яй-яй:
$db->query ("SELECT user_name FROM ".DB_PEREFIX."_users WHERE user_login = '".$_GET['userlogin']."'")Нереальный ай-яй-яй (а тут админа уже можно хорошо подставить правильно сформированным URL-ом, так как деструктивное действие делается через GET):
$id = $_GET['id']; ... $delete = @mysql_query ("DELETE FROM ".DB_PEREFIX."_menu WHERE link_id = '$id'"Обычно выигрывают в ресурсах и проигрывают в поддержке CSS.
Разработка и поддержка стала занимать слишком много времени и мешать другим проектам, а вот финансирование осталось прежним. Объем кода, увы, великоват для того, чтобы его кто-то подхватил (да и, признаюсь, местами я там поначалу наломал дров). Результат очевиден.
Есть такая штука — индексы. При их использовании сложность поиска в базе составляет, грубо говоря, O(log N). Без их использования — O(N). Порядок проигрыша в скорости поиска в такой базе на, скажем, миллионе записей ~100'000 раз. Вы еще хотите пользоваться нативными битовыми операциями в полях, по которым возможна выборка?