Я может быть к счастью, может к сожалению не являюсь активным пользователем git. Сама ситуация конечно настолько нелепая что вызывает ступор.
Вообще нынешние законотворцы мне напоминают один бородатый анекдот, в котором некая женщина долгие годы копила деньги на круиз и наконец купила билет на огромный шикарный пароход, причем в каюте низшего класса, и когда в ходе плавания корабль начинает тонуть, она обращается к богу, мол «за что? а так трудилась во всем себе отказывала и т.д.». А бог отвечает «я вас козлов, тоже 20 лет по всей земле собирал».
Складывается такое ощущение что и в их ряды собирали самых «недалёких» со времён перестройки. Их законотворческие абсурды порой приводят в такой же ступор как и ситуация с git.
А вообще есть способ отыграться за подобные ляпы некомпетентных людей. Можно обратиться в суд с иском о возмещении вреда причиненного органом власти, коим является роскомнадзор. Если ваша работа напрямую связана с github, и вследствие блокировки вы понесли убытки из-за вынужденного простоя, то все вполне реально. Не факт что всё получится, но основания для ваших претензий вполне законные. Если придет в суд 10 000 исков — это уже заставит призадуматься тех, кто принимает такие решения.
Вопрос по реализации. Как реализовано хранение товаров через ресурсы или в сторонних таблицах?
Я сам тоже реализовывал магазин на MODX. Моя реализация на сторонних таблицах. Но в моем случае без этого было никак, т.к. магазин работает под 1С (через обмен данными) и категоризация товаров там двойная: по структуре номенклатуры из 1С и по свойствам товара. Отображение во фронтенде по свойствам. Пришлось изрядно попотеть и конструкцию со стороны БД пришлось укреплять процедурами. А для управления всем этим чудом использовал MIGX.
В том то и дело что спор на пустом месте. Ведь и ваш пример можно посадить на те же салазки. И поверьте, сервер не будет мешать а только помогать. По первому примеру и с таким вот регулярником например.
Главное скрипт получит запрос только если есть с чем ему работать. А если поставить ограничение на сам скрипт и проверять на редирект и реферер то он вообще лишний раз не запустится.
Речь то не о PHP. Если не обратили внимание, речь идет о распределении нагрузки. Работа любого интерпретатора изначально более дорогая (создание окружения, подгрузка кода и т.д.) чем минимальная логика на уровне HTTP сервера. А для несчастных владельцев CGI особенно, поскольку интерпретатор при использовании того же PHP в качестве модуля или FCGI уже запущен и ждёт команды, а при CGI для начала работы приложения требуется больше времени. При этом у нас всегда есть сам сервер. И если есть возможность за счёт его способностей снять лишнюю нагрузку с интерпретатора — грех этим не воспользоваться. В данном случае приводится лишь пример как не запускать скрипт впустую благодаря mod_rewrite.
И вообще я сталкивался столько с перенаправлениями типа:
RewriteCond %{REQUEST_URI} thumb
RewriteRule ^(.*)$ thumb.php [L]
или
<FILES thumb>
# давай работай что-нибудь
</FILES>
что аж страшно… А потом владельцы сайтов начинают верещать «Ой мне письмо пришло от хостера, что у меня превышение процессорного времени и меня отключат». А что удивляться? Времена меняются. Если лет 6-7 назад подсчёт процессорного времени был в диковинку, то сейчас почти на каждом шагу. На одном сайте даже слайдер починял — изображения 1200х450 генерировались при каждом заходе на страницу.
1.
А зачем класть сам скрипт? Достаточно разместить там сам .htaccess с соответствующими изменениями. Скрипт может лежать в любом месте в пределах публичной папки чтобы Apache мог туда перенаправить. Если разместить вне DOCUMENT_ROOT или в директории с ограничением доступа доступа к скрипту не будет.
2.
Так суть как раз в том чтобы не дёргать скрипт по поводу и без. Apache согласно набору правил сам определяет целесообразность запуска скрипта проверяя наличие исходника для преобразования. А сохранять можно хоть в pdf. Если конечно очень хочется. И будет лежать 1.jpg 1.png 1.gif и т.д. в папке /images/thumb/a.
И еще… даже проверять на редирект в скрипте не обязательно. Кидаем в QUERY_STRING ключик и добавляем проверочку.
А при хранении шаблонов преобразований в файлах, можно даже застраховаться от вызова миниатюризатора с неверным шаблоном. И все это без запуска скрипта.
Смотря что и как склеивать. Сомневаюсь что у кого-нибудь найдется пара тысяч css или js файлов для регулярного сжатия или склеивания… если это конечно не репозиторий сборных библиотек. А вот даже в том же магазине уже более 30 000 изображений только в каталоге товаров. И вопрос оптимизации и удобства в управлении — №1.
Рад за вас. Метод простой, но действенный. И уж 100% я не первый. Просто я перерыл google в поисках чего-то подобного но не нашел (возможно потому, что с google общаюсь исключительно на английском). На самом деле у меня есть и чуть более сложный вариант с использованием setenv но я не стал его сюда публиковать, т.к. данный модуль не везде включён. В нем интерпретатору передаются оба маршрута и шаблон преобразования через окружение. А одна из задач поста немного переосмыслить такую элементарную штуку как htaccess и mod_rewrite. Ведь представленные на просторах интернета рецепты напоминают фрагмент монолога Р. Карцева «Отец»: "… Папаня, на уникальных японских электронных микроскопах пальто висят. — Ну вам наша вешалка?.."
Вообще нынешние законотворцы мне напоминают один бородатый анекдот, в котором некая женщина долгие годы копила деньги на круиз и наконец купила билет на огромный шикарный пароход, причем в каюте низшего класса, и когда в ходе плавания корабль начинает тонуть, она обращается к богу, мол «за что? а так трудилась во всем себе отказывала и т.д.». А бог отвечает «я вас козлов, тоже 20 лет по всей земле собирал».
Складывается такое ощущение что и в их ряды собирали самых «недалёких» со времён перестройки. Их законотворческие абсурды порой приводят в такой же ступор как и ситуация с git.
А вообще есть способ отыграться за подобные ляпы некомпетентных людей. Можно обратиться в суд с иском о возмещении вреда причиненного органом власти, коим является роскомнадзор. Если ваша работа напрямую связана с github, и вследствие блокировки вы понесли убытки из-за вынужденного простоя, то все вполне реально. Не факт что всё получится, но основания для ваших претензий вполне законные. Если придет в суд 10 000 исков — это уже заставит призадуматься тех, кто принимает такие решения.
Я сам тоже реализовывал магазин на MODX. Моя реализация на сторонних таблицах. Но в моем случае без этого было никак, т.к. магазин работает под 1С (через обмен данными) и категоризация товаров там двойная: по структуре номенклатуры из 1С и по свойствам товара. Отображение во фронтенде по свойствам. Пришлось изрядно попотеть и конструкцию со стороны БД пришлось укреплять процедурами. А для управления всем этим чудом использовал MIGX.
Главное скрипт получит запрос только если есть с чем ему работать. А если поставить ограничение на сам скрипт и проверять на редирект и реферер то он вообще лишний раз не запустится.
И вообще я сталкивался столько с перенаправлениями типа:
или
что аж страшно… А потом владельцы сайтов начинают верещать «Ой мне письмо пришло от хостера, что у меня превышение процессорного времени и меня отключат». А что удивляться? Времена меняются. Если лет 6-7 назад подсчёт процессорного времени был в диковинку, то сейчас почти на каждом шагу. На одном сайте даже слайдер починял — изображения 1200х450 генерировались при каждом заходе на страницу.
А зачем класть сам скрипт? Достаточно разместить там сам .htaccess с соответствующими изменениями. Скрипт может лежать в любом месте в пределах публичной папки чтобы Apache мог туда перенаправить. Если разместить вне DOCUMENT_ROOT или в директории с ограничением доступа доступа к скрипту не будет.
2.
Так суть как раз в том чтобы не дёргать скрипт по поводу и без. Apache согласно набору правил сам определяет целесообразность запуска скрипта проверяя наличие исходника для преобразования. А сохранять можно хоть в pdf. Если конечно очень хочется. И будет лежать 1.jpg 1.png 1.gif и т.д. в папке /images/thumb/a.
И еще… даже проверять на редирект в скрипте не обязательно. Кидаем в QUERY_STRING ключик и добавляем проверочку.
А при хранении шаблонов преобразований в файлах, можно даже застраховаться от вызова миниатюризатора с неверным шаблоном. И все это без запуска скрипта.