50% прозрачность.
DiAksID, не рядовые, а сотрудники ПС.
Вот так. А что, побродя с таким юзерагентом по любимых сайтах или по сайтах из топа, можно увидеть кое-что интересное. :)
ivan-lev, спрашивайте что интересует. Фреймворки я не использую, поэтому, не знаю как назвать. Я называю это модулем типизации и валидации входящих параметров. Он, во-первых, проверяет корректность полученных данных, во-вторых, устанавливает возможные варианты по умолчанию (например, если страница может получить параметры day, month, year, но ни один из параметров не пришел, в объект $_GET будут установлены сегодняшний день, месяц и год; может получить номер страницы, но номер страницы не пришел со стороны пользователя - будет установлена 1 страница. С одной стороны, и без этого в нужном модуле можно установить значения по-умолчанию. Но если здесь они устанавливаются из карты один раз, то в ином случае, нам придется каждый раз проверять на isset($_GET['page']) or $_GET['page'] = 1. Также, модуль подготавливает HTML (для POST роутинга), экранирует SQL, сводит к нужному типу переменные (например, 1.1 в объект GET будет установлен как float, а не string). Это позволяет в одном месте определить переменные (в случае нарушений со стороны пользователя вывести соответствующую ошибку) и пользоваться объектом GET как обычным локальным объектом без последующих проверок на isset, min-max, PREPARE и так далее, вести учет удаленных страниц, выводить подсказки об ошибках в URL (с помощью словаря возможных опечаток), вводить локализацию URI, управлять структурой URI (больше не нужно писать page перед вводом страницы, и так далее). Также, в случае определенных ошибок со стороны клиента (попал на страницу 404 (не 410!), ввел неправильный URI), модуль устанавливает индекс хакинга, который при преодолевании значения 50%, переводит пользователя на статическую версию сайта + принудительно замедляет работу скрипта. Мой вариант может работать совместно с AJAX, благодаря использованию JSON. Я могу запретить на уровне валидации URI, переход по определенному адресу для определенных групп. Например, чтобы запретить видеть файлы robots.txt, sitemap.xml обычным пользователям, мне стоит добавить GROUP: "robots". Я это не использую, но вы можете догадываться об удобности использования этого модуля. Не нужно копаться в коде, перечитывать код, достаточно подправить один файл, и вся структура сайта будет изменена. :)
Вообще, ничего подобного я не встречал. Видел варианты роутеров в виде классов, но это далеко не то. В них либо не было типизации, либо какой-то замудренный вызов.
6666, правильно ли я понимаю, вы пытаетесь фильтровать GET? Поделюсь своим решением. У меня GET строго типизированный. То-есть, все возможные варианты REQUEST_URI заданы в карте GET (иллюстрация). Тут мы можем задать статическое значение, либо тип динамического значения и способ валидации (например, проверка на EXISTS в базе данных), проверка на min-max скаляра. Если переданные данные корректны, составляется URI страницы. В случае, если переданы лишние данные, либо они переданы не в том регистре, REQUEST_URI будет отличатся от составленного URI и мы выводим ошибку. Если все нормально, мы очищаем $_GET и с помощью цикла устанавливаем новые отвалидированные данные в массив $_GET. Если, например, мне нужно удалить страницу, я устанавливают DEFAULT: false и пользователь при переходе на удаленную страницу получит уже не 404, а 410, что страница удалена. Все это работает и для POST, COOKIE. В случае с POST, я добавил тип HTML.
Кстати, ссылки у меня строятся тоже с помощью той же карты. Битые ссылки можно контролировать на уровне системы. :)
Конечно, WP настроить таким образом вряд ли удастся, но возможно идея кому-то будет полезна.
LEOnidUKG, это всем известная практика. Я лично для себя выполнял много бенчамарков по миллион итераций. Поверьте, иногда банальная проверка через (!= null) добавляла +3000% к времени выполнения скрипта по сравнению с isset(). Это касается абсолютно всего кода, даже регулярных выражений. Например, регулярное выражение с модификатором U в 200% медленнее аналога без этого модификатора. Проблема в том, что используют функционал направо и налево. Задумывается ли кто-то что в echo лучше писать запятую ежели точку для объединения строки? Задумывается ли кто-то о строгой типизации? О проверки через === вместо ==? О запуске strpos перед preg_match или str_replace? Это ведь в большинстве случаев выгодно.
У меня недавно был заказ на оптимизацию самописной системы сайта недвижимости. 10000 хостов в сутки, а в 503 уходило по 5 раз на день. Проблема нашлась довольно быстро. Я включил показ E_ALL, и обнаружил большую кучу NOTICE. Обычно об NOTICE программист даже не догадывается. Только опытный программист додумается составить карту выполнения скрипта и проверить NOTICE. После исправления всех предупреждений, и улучшения синтаксиса (в том числе or вместо ||), поверхностной оптимизации архитектуры страница генерировалась за 70 миллисекунд вместо прошлых 800-1200. Разница очевидна. Остается догадываться сколько дыр еще я закрыл, добавив строгую фильтрацию входящих данных. И стоит заметить, никаких Nginx, никаких кешеров я не добавлял. Стоило только прислушаться к интерпретатору и к практике уже знающих людей.
Использование || вместо or, в некоторых случаях является серьезной ошибкой. Например, когда в качестве сравнения вызывается функция, которая оставляет за собою не обратимый след, например, $a === true || die(); когда создается переменная в операторе сравнения, например, (($a = $b) === 1) || (($a = $c) === 2)) (то-есть, даже если b === 1, в переменной a будет присвоено 2. Естественно, таких очевидных ошибок никто не делает. А не очевидных? Оператор сравнения, тернарный оператор вызывается тысячи раз за один цикл скрипта. Это далеко не оптимизация регулярных выражений, на которую всем действительно наплевать.
В итоге приходиться делать миллионы баг фиксов, платить тысячи на оптимизации, покупать мощные сервера. А легче ведь писать грамотно. Не правда ли? :) О вкусах и стилях не спорят. Но нужно задуматься. Почему одни системы работают быстро, стабильно, их не взламывают, а другие работают как их опущенные конкуренты.
if((($this->article->sectionid == 9) or ($this->article->sectionid == 2)) and !empty($this->article->city_alias) and !empty($this->article->city))
Можно добавить бесконечное количество or. Главное в кавычки поместить не забудьте.
Уважаемые, не используйте приоритетные операторы || и && направо и налево. Это негативно влияет на стабильность и производительность. Вместо этого, лучше использовать or и and, в случае, если не нужно вызывать все операции сравнения.
Что-то ни на одном блоге не вышло воспроизвести даже <!–mfunc echo "ok"; –><!–/mfunc–>. Наверное, уже сам Wordpress как-то автоматическим апдейтом профиксил.
interers, а что думать-то в плане SEO? Пагинацию вообще стоит закрывать от ПС.
Adobe InDesign, Adobe Photoshop, Notepad++ использую лично.
