Может есть смысл в таких случаях взять парсер от готового и проверенного временем движка? В последних версиях учтены и искорены и SQL-инъекции и XSS. Из платных запрещает брать авторское право, а вот из опен-сорсных можно.
Не всегда есть возможность такое сделать, зато .htaccess с deny from all не позволит смотреть файлы в папках. Равно как и используемая в том-же DLE защита-
При просмотре файла напрямую, а не если он вызван инклудом из index.php- интерпритатор завершит работу. Кстати, такой способ защиты библиотек тоже стоит добавить в топик.
С чего бы? Ток в электрической сети пульсирует с частотой 50 Гц, такие частоты недостаточны для возникновения кавитации в жидкостях. Или вы считаете, что там будет возникать магнитное поле в пару Тесла? :))))
0: Отсутствие системы хуков для интеграции модулей, код приходится вписывать прямо в ядро. При наличии документации к модулю- в принципе дел на 5 минут, а вот заказали мне недавно обновление DLE с рукописными модулями… Пережил кучу веселых моментов, сначала пока искал версию ДЛЕ 5.6 (именно такую древнюю), потом еще кучу когда искал все правки кода, сдланные предыдущим кодером.
1: Шаблонизатор использует хранение шаблонов на винте сервера, вместо хранения шаблонов в БД. Отсюда куча лишних I/O операций при генерации страницы. В принципе эту проблему можно решить кэшированием байт-кода шаблонов с помощью акселлераторов, но этим еще надо заниматься, а хранение в базе позволяет выбирать шаблоны из кэша mySQL (при кэшировании SQL-запросов) практически мгновенно.
2: Роли пользователей. В админку должны иметь доступ только админы. И она должна быть максимально скрыта и защищена. А в DLE в админку можно пускать кучу народа из разных ролей на сайте.
Если на сайте не предполагается широкая регистрация пользователей (только три-четыре админа, которые будут сайт наполнять), то проще написать свою CMS. Я например когда начинал учить PHP где-то за неделю написал свой простенький движок с админкой и кэшированием готовых страниц (БД не используется вообще). Пусть простая, зато я знаю как она работает и что куда писать. Задумайтесь, есть ли смысл ставить тяжелые CMS, которые требуют БД и которые потянет не каждый халявный хостинг, или сделать что-нибудь простое для себя.
Вот вкратце требования:
Система нужна для клёпки простых сайтов. Статичные страницы, новости, обратная связь ну максимум каталог.
До поры до времени сидели на своей CMS
Что же это была за CMS, если не удовлетворяла таким простым требованиям?
Ну все-таки я считаю CMF более правильным, ведь Друпал предоставляет возможность свободного выбора модулей, вплоть о смены шаблонизатора, и стандартная поставка довольно бедна функционалом- для планирующегося проекта уже собрал около 100 модулей. Да и структура по умолчанию скорее пример как надо строить свою таксономию.
Давайте дальше меряться хуями в том, что каждый знает и умеет лучше :) АСМ это хорошо, сложно и быстро (в смысле скорости выполнения), но зная его хорошо не стоит опускать другие языки из-за их высокого уровня или кажущейся простоты.
Друпал это CMF а не CMS. Отсюда и сложность разработки конечного продукта. Друпал это заготовка, а не готовый движок на который можно просто натянуть дизайн и будет работать.
Думаю стоило положить перед заказчиком два проектных плана- с рефакторингом и с использованием текущего кода, в каждом расписать временные затраты, цену и преимущества/недостатки способа. И пусть клиент сам решает, что для него важнее.
Я сомневаюсь что в телик можно будет ставить софт :) Да и возможности его перепрошить тоже вряд-ли можно будет. Так что рекламодатели смогут творить что хотят. Впрочем я буду за, если реклама будет подбираться в зависимости от моих данных и предпочтений, авось что-то полезное проскочит. Думаю в этом будущее рекламы- максимальная точность в соответствии рекламы потребностям человека. Я даже готов вести список желаний (есть такие сервисы) для этого.
А как на счет архитектуры вашего сервера? Стоит ли nginx как фронт-энд? Просто видел кучу случаев, когда вроде бы рабочий скрипт не работает из-за того, что nginx передает апачу файл только после полного кэширования. В описании скрипта заявлена его работа на основе аякса, а значит данные он получает от апача.
Не смешивайте понятия, вектор и растр созданы для абсолютно разных ниш и для абсолютно разных целей. Фотографии к примеру навсегда останутся в растре, а иконки обычно рисуются в векторе и только потом растеризуются, поскольку вектор на сегодняшний день браузеры не поддерживают. Вектор намного удобнее для работы с формой объекта, кривыми, заливкой, а растр- для работы с уже готовыми фотографиями. Как по мне, то именно РИСОВАТЬ удобнее в векторе.
Заглянув глубже в архитектуру vBulletin понимаешь, что решение с хранением шаблонов в базе выглядит красивее. В начале каждого модуля есть массив, который заполняется в зависимости от того, какие шаблоны необходимы для генерации страницы в зависимости от get-параметров и потом одним SQL-запросом из базы выбираются все необходимые шаблоны. Если грамотно использовать кэширование запросов mySQL, то вся пачка шаблонов отдается практически мгновенно. Нет, конечно же можно кэшировать в shared memory сервера и код файлов шаблонов, но мне такое решение нравится больше (хотя-бы тем, что оно не требует установки акселлераторов, а строится на стандартном фнкционале сервера).
На сайте mootools при выборе того, что нужно включить в пакет перед упаковкой пакером показываются зависимости библиотеки. Так вот, конкретно эффект toggle тянет за собой 13 библиотек на сколько я помню (включая естественно core). В итоге вес такой либы ради одного эффекта приближается к 40 кб.
Так же размер зависит от требуемой функциональности и самой реализации. А еще, с библиотеками писать гораздо удобнее.
Я с этим целиком согласен, просто фреймворки обеспечивают избыточную функциональность, которая полностью никогда не будет использоваться ценой избыточного веса скрипта. Скорость разработки безусловно намного выше, для большинства задач уже написаны готовые плагины, достаточно только собрать все в кучу и подключить к фреймворку. Правда и весить это все будет тоже прилично.
Предвижу аргумент «фреймворк можно почистить и выкинуть из него лишнее»- а не проще написать 5 кило кода, чем ворошить 50, не зная на все 100% особенностей архитектуры фреймворка?
Dell поставляет свои ноуты с Free Dos или, что мне даже больше нравится, с линуксом (с убунтой). Так что стоит обратить на них внимание. Правда если стоит Free Dos, то как следует ноут не потестить перед покупкой, стоит найти знакомых с таким ноутом или версию с линуксом. Правда довольно часто в магазинах менеджеры ставят на Dell'ы ХР, потому что их тоже надо продавать, а консоль Free Dos покупателей однозначно не привлекает :) Слышал что некоторые путали Free Dos с выводом kernel panic :))
Во-первых просили просто пример, а во-вторых, по статистике, важна именно самая первая загрузка страницы, пока перед юзером просто белый экран, а прогресс-бар загрузки показывает «500 кб / 50%». У меня мегабитный канал, и мне как-то все равно, но я еще живо помню сидение перед экраном когда инет обеспечивает смарт и GPRS. Так что юзер может и не дождаться самой первой загрузки сайта, когда в кэше еще пусто.
С какой скоростью будет работать такая конструкция?
0: Отсутствие системы хуков для интеграции модулей, код приходится вписывать прямо в ядро. При наличии документации к модулю- в принципе дел на 5 минут, а вот заказали мне недавно обновление DLE с рукописными модулями… Пережил кучу веселых моментов, сначала пока искал версию ДЛЕ 5.6 (именно такую древнюю), потом еще кучу когда искал все правки кода, сдланные предыдущим кодером.
1: Шаблонизатор использует хранение шаблонов на винте сервера, вместо хранения шаблонов в БД. Отсюда куча лишних I/O операций при генерации страницы. В принципе эту проблему можно решить кэшированием байт-кода шаблонов с помощью акселлераторов, но этим еще надо заниматься, а хранение в базе позволяет выбирать шаблоны из кэша mySQL (при кэшировании SQL-запросов) практически мгновенно.
2: Роли пользователей. В админку должны иметь доступ только админы. И она должна быть максимально скрыта и защищена. А в DLE в админку можно пускать кучу народа из разных ролей на сайте.
Что же это была за CMS, если не удовлетворяла таким простым требованиям?
А вот и нихуя подобного.
Я с этим целиком согласен, просто фреймворки обеспечивают избыточную функциональность, которая полностью никогда не будет использоваться ценой избыточного веса скрипта. Скорость разработки безусловно намного выше, для большинства задач уже написаны готовые плагины, достаточно только собрать все в кучу и подключить к фреймворку. Правда и весить это все будет тоже прилично.
Предвижу аргумент «фреймворк можно почистить и выкинуть из него лишнее»- а не проще написать 5 кило кода, чем ворошить 50, не зная на все 100% особенностей архитектуры фреймворка?