ugodrus

Ничего удивительного. Вы передаете переменную через ГЕТ key=1
Внутри PHP $_SERVER['REQUEST_URI'] = /login/?key=1
Далее по коду

$page = 'login/?key=1'; 
if (file_exists("all/login/?key=1.php")) 
  include "all/login/?key=1.php"; 
  else if ($_SESSION['logged_user'] and file_exists("auth/login/?key=1.php"))
  include "auth/login/?key=1.php";
  else if (!$_SESSION['logged_user'] and file_exists("guest/login/?key=1.php"))
  include "guest/login/?key=1.php";
  else
  header('Location: /404');

Не думаю что у вас в auth/login/ найдется файл ?key=1.php
Не знаю с каких времён у вас такая дремучая конструкция. Такие городулины со времени похорон 4.3 не практиковал и не встречал.
Вердикт один - либо подбирайте другую переменную с корректным значением $page. Либо чистите эту. Убирая лишнее и анализируя подходит ли значение после фильтрации.

Без примера данных тяжело сказать. Вообще Json у вас там читается? Попробуйте поиграться с опциями json_encode может быть дело в экранировании каких-нибудь символов.

/<h2[^>]*>[^<]*<\/h2>[^<]*?(?=\z)/gm
как-то так

Chm формат смотрите.

Сталкивался с такой проблемой. Сайт был под апачем. Лечил htaccess'om. К сожалению не сохранился исходник файла. Проблема решается легко если у вас управление осуществляется с фиксированного IP. Принцип правила такой:

если это POST запрос

И он обращен НЕ на типовые скрипты (типа index.php в корне и ещё в какой-то есть приёмник для AJAX запросов в публичной части)

И если запрос не с указанного IP

то перенаправляем его на заглушку, в которой записываем в лог параметры запроса, кто, куда, и с какими данными.

таким образом злоумышленник даже в админку не войдет а про запросы к чему-то ещё вообще бесполезно.
далее пока собираются логи по размещённым злоумышленником скриптам анализируем все скрипты сайта где упоминаются следующие функции: mail, eval, fsockopen и его вариации , base64_decode, exec и её аналоги.

У меня была такая особенность: Вредоносный код был в начале файла в виде <?php затем куча пробелов чтобы скрыть от глаз в редакторе, потом код и завершалось ?> соответственно если это был изначально php файл то после этого открывался <?php родного файла

Нашел кое-что на тему curl can't open Unicode filenames in Windows.

Судя по написанному ( пробежался мельком ) проблема такая есть и разработчики в курсе но решение отложено.
Возможно когда-нибудь исправят. А пока что реализовал отправку файлов через символическую ссылку: создаю символическую ссылку ( из оперы uniqid() ) на файл с кириллицей в названии, а после успешной отправки её подтираю. Всё-таки лучше чем распихивать дубликаты весом до 60мб по диску.

Проблема не зависит от ОС. На Linux тот же эффект. Проблема возникает при сборке запроса перед его отправкой. Старый вариант подключения файлов через "@filepath" тоже не подгружает данные, но хотя бы пытается отправить запрос с указанием передаваемых файлов, но пустых.

Надеюсь на то, что у кого-нибудь найдется более простое и элегантное решение проблемы.
А пока пусть мой вопрос с моим же комментарием поможет кому-нибудь не наступить на те же грабли.

Можно и самому шрифт сконвертировать. Пару раз делал. Тем более что полный шрифт мало когда требуется. Я брал готовый, убирал лишние глифы и пережимал в нужные форматы. Font forge посмотрите.

Вообще SSD + Windows = смерть. Винда не щадит жестяков. Куча служб плодит временные файлы. Множество циклов перезаписи. Соответственно жестяк убивается очень быстро.

preg_replace("/\[(.*)\]\s*\((.*)\)/", "\1 \2", $input_lines);

Это жадный пример для одной строки.

Мой совет - продолжать "быдлокодить" еще хотя бы годик.

Немного своих размышлений на тему фреймворков. Правда нелепо быть свидетелем такого диалога?:
- А вы бегать умеете?
- Конечно. Я на костылях очень быстро передвигаюсь.

То же относится к фреймворкам. Как костыли вызывают атрофию мышц, фреймфорки вызывают атрофию креативного мышления. Фреймворк какой бы он ни был хорошим и удобным ставит вас в определенные рамки мышления и реализации кода. И чем меньше ваш кругозор в том или ином языке (чистом), тем более узким будет ваше видение ваших реализаций внутри фреймворка. И в конечном итоге в один прекрасный момент, столкнувшись с чем-то неординарным в работе, вы скорее всего будете судорожно искать в нете что-то готовое подходящее под ваши задачи, нежели делать это самому, т.к. нить связи с чистым языком у вас уже практически утрачена.

Я, например, занимаюсь php уже более 10 лет. При мне он развивался и крепчал. Даже без фреймфорков могу написать практически любое приложение. И только в начале этого года я принялся за Laravel. И решение такое было вызвано огромной необходимостью, т.к. занимаюсь разработкой в одиночку (без команды), и в последнее время ко мне стали часто обращаться с достаточно крупными проектами, требующими особого подхода в реализации, и вариант с готовой CMS там не прокатит, а уж тем более с системой свёрстанной "на коленке".

Вообще, на мой взгляд, фреймворк - это больше зло чем добро. Очень много минусов в сторону производительности. Но есть два огромных плюса которые сильно компенсируют эти недостатки - это удобство коллективной разработки за счёт структуры приложения и стандартизации кода, и второй плюс - достаточно быстрый старт любого проекта, благодаря наличию в нем огромного количества готовых плюшек. Ваша задача при разработке лишь собрать ваш велосипед из уже готовых деталей и дописать лишь недостающие связующие элементы.

Фреймворк - последняя инстанция хорошего программера. Пока не научитесь бегать самостоятельно -не советую браться за костыли.

Вообще тема нужная как раз для этих "макак". Но это уже не тема хабра и тостера, поскольку тема была уже сотни раз приготовлена, съедена и переварена.

Сейчас развелось много phpшников, которые только начали заниматься и соответственно ляпают хрен знает что и хрен знает как. Достаточно почитать некоторый вопросы здесь, да и на многих форумах чтобы в этом убедиться.

В нете куда больше всяких трюков по оптимизации кода, а данный пример действительно ни о чём. Если действительно хотите помочь новичкам - не занимайтесь трюками на минимальном левеле php с циклами и операторами. Примеров оптимизации в этой теме больше чем достаточно. Копайте в сторону ООП. Там гораздо больше чудес кроется. По многим примерам в нете тяжело что-то найти.
Кое-какие эксперименты и сам делал. И соответственно делал выводы что лучше использовать а что категорически нельзя.

Хотя всё относительно. Можно столкнуться с такой задачей, что твое нельзя превратится в нужно. В конечном счёте, оптимизация относится в большей степени ко всему приложению, а не к маленьким его кусочкам. Можно оптимизировать циклы и использование операторов или функций, но сложить в целом приложение которое будет нещадно жрать память из-за утечек. И потому такой оптимизации цена будет 0.

А по циклам вообще. Максимальные циклы за мою практику for и foreach до 300, while до 50 000.

Во-первых, так ли необходимо хранить именно Json?
Во-вторых, что предполагается делать с этим набором данных.
Ну и соответственно Json - машинно читаемый формат данных и соответственно лучше пихать его в BLOB (бинарное хранилище).

Сам одно время пробовал парсить результат выдачи яндекса. Поверьте моему опыту - парсить живой (не xml) результат поиска - сломанный костыль. Часто меняются элементы разметки и бан идёт регулярный, хотя я пользовался сокетами и имитировал браузер на 100%. После 2х месяцев геморроя сам прикрыл лавочку.
Мой совет - ковыряйте XML выдачу.

Карамзин "История государства Российского" в исполнении Шевчука. тут
А вообще вцелом наверное ничего подобного нет. Только собирать по крупицам.

Впринципе это возможно. Но врятли средствами API в чистом виде. Я бы сделал с помощью радиальных зон.
Допустим есть три точки (отправные пункты). Для каждой указан радиус обслуживаемой территории. Получаете данные о пункте доставки и сверяете своими силами какой зоне принадлежит эта точка. Если их несколько, то можете определить ближайший центр, или ещё какой-нибудь принцип. В конечном счете все сведётся к элементарной геометрии.