Comments 46
Зачем им ПХП 7.1, если они вообще не пишут ООП-код?
Но вот к примеру банальный вызов своей функции, которая лишь возвращает результат mysql_fetch_assoc, замедляет выполнение на 12%.
Может быть KPHP или HHVM умеют инлайнить такие функции, но вот сам php даёт оверхед.
Так что повторюсь, мне жаль, что php, как и многие другие современные open source продукты, не заботяться об обратной совместимости (которая в данном случае им бы вообще ничего не стоила).
Опять двадцать пять. Это не модная одежда, которая морально устаревает. C код, написанный 30 лет назад, работает до сих пор.
Всё это настолько пустые отговорки, что диву даюсь. Могли бы хоть 10 новых mysql расширений разрабатывать, но старое проверенное и работающее оставить и не трогать.
mysqli_escape_string делает абсолютно то же самое что и mysql_real_escape_string, и этими функциями и там и там можно пользовать небезопасно. И там и там должна быть своя функция-обертка, которая для не-чисел обрамляет значение в одинарные кавычки (не двойные), и там и там нельзя использовать режим NO_BACKSLASH_ESCAPES. Не все желают пользоваться prepared statements, особенно из-за снижения производительности.
Вызов команды exec тоже может быть небезопасен. И даже echo, если им вывести xss уязвимость.
Приведу пример. Вот я недавно переписывал Sypex Dumper для поддержки PHP 7 (знаете, возможно, по сути стандарт де-факто для работы с дампами), ибо поддержки PHP 7 юзеры до сих пор не дождались. Ходят слухи, что разработчик погиб в украинской войне, а какая-то свинья до сих пор делает на юзерах деньги (ибо как еще можно объяснить, что c даты релиза PHP 7 прошло больше года, но разраб, создавший такое серьезное приложение, до сих пор не может выполнить замену mysql_ на mysqli_, имя на руках исходники (версия Pro имеет закрытый код для конечного юзера)? Дак вот его код надо видеть! Я уже говорил ранее, что можно и mysql_connect () захардкодить, было бы желание, мне так и сказали, типа ну это вообще жесть, я и говорю, типа это шутка, хотя и не без доли истины. Дак вот все запросы к БД выполняются там с помощью следующего кода:
mysql_query ("запрос") or die (mysql_error ());
Понятно, я выполнил поиск и замену, все работает, однако, думаю, нет нужды говорить о том, что такого рода лапшекод — это откровенный фейл, ибо одно дело, когда мы имеем один скрипт, который можно просмотреть даже в ручную, чтобы быть уверенным в том, что заменилось все верно и все аргументы в новых функциях стоят на своих местах, другое дело — когда имеется сложный проект, и один бог знает что там где захардкожено прямо в коде без всяких обверток. Можно создать переменную с публичной областью видимости, вызывая ее из экземпляра какого-либо класса, чтобы вставлять в тот же mysql_query (), однако это уже и есть зачатки обвертки, за которую я так ратую. Поэтому виноват-то тут не PHP, который якобы не заботится об обратной зависимости. Просто код надо писать уметь.
Шутка есть хорошая: человек приехал в автосервис с кучей проблем, мастер посмотрел и говорит: «В целом все нормально, нужно только заменить прокладку между рулем и педалями».
Говорю ни в коем случае не о Вас, а в общем.
Изменение даже одной строчки стоит денег, а также множество времени на изучение очередных несовместимостей при обновлении. Даже те же хостеры, рассадники уязвимостей и кривого кода, просто в очередной раз предложат пользователям выпадающией список с версией php, и весь код просто останется на старых версиях, без поддержки security fix. Что со временем приведёт к ещё более серьёзным проблемам с безопасностью.
Просто пример — я рад что массивы теперь можно объявлять как [] а не только через Array(); И ведь молодцы ведь, оставили старый способ для обратной совместимости! А то ведь тоже могли бы выпилить его к чертям по желанию левой пятки.
Я очень люблю PHP (и не потому, что просто вынужден на нем писать, а потому-что изначально ознакомился с ним и после этого связал с ним всю свою последующую жизнь). В плане его динамической типизации я сравниваю его с автоматической коробкой передач, благодаря которой я могу наслаждаться самой поездкой, а не дергать рычаг переключения передач постоянно (особенно в пробках). Да, он позволяет из-за этого много, что другие языки просто не позволят, но это, как говорится, остается на совести программиста) Руки прямые иметь надо. Как и во всем, собссно.
Однако их политику такого рода я и сам не всегда понять не могу, честно признаюсь. Помимо mysql_* несколько странная ситуация возникла и вокруг mb_* для многобайтовых кодировок. Идеальным вариантом в этом случае была бы замена самих исходников этих функций для поддержки многобайтовых кодировок, ибо те же mb_* по сути могут работать и с однобайтовыми, и с многобайтовыми кодировками. И ничего бы при этом не развалилось бы вообще если при этом перевести все файлы проекта в другую кодировку, это совершенно безболезненно. Да и честно признаться, я уже лет 10 не видел файлов, сохраненных в какой-нибудь cp1251, а не utf-8. А так, лично у меня переезд на utf-8 был не из самых приятных, ибо тут нельзя просто было заменить substr на mb_substr (), ибо вторым аргументом в mb_* нужно всегда указывать нужную кодировку, поэтому я просто насоздавал своих функций на замену mb_*, в теле которых просто указал кодировку через константу. Однако эти функции требуются не везде. Не везде есть необходимость в дополнительной нагрузке (возможно), если данные передаются, например, на латинице.
P. S. Ничего себе Вас заминусовали :/
Мне приходится поддерживать некоторые очень старые чужие проекты, которым по 10-15 лет, хорошо защищены от sql injection, проверены sqlmap, которые даже не хочется трогать, но которые должны работать. И конечно которые хотелось бы ускорить переходом на php7, но из-за нарушений обратной совместимости придётся потратить некоторое время, которое неоплачивается.
Да, есть wrapper типа https://github.com/e-sites/php-mysql-mysqli-wrapper/blob/master/mysql.php, при его использовании задумываешься, и зачем нужны были эти странные усилия команды php.
P. S. Какая-то эта обвертка мутная, CamelCase вперемешку со snake_case, по-ходу автор еще в себе не разобрался… Надо бы уже определиться)
Там разница была в 2-15 раз в пользу kphp. Вывод типов и оптимизации C++ компилятора дают очень хорошее ускорение. Так что отказываться от него мы пока не собираемся)
У нас, по сути, сейчас нет apache, какой уж там .htaccess.
Речь была не про stat ли запросы на каждый запрос к серверу? :)
Я думаю, что у всех представления об эстетике разные. Далеко не всем нравится ООП и java-стиль, и им наоборот, возможно, понравился бы процедурный стиль вк. И зачастую "монструозные конструкции для обхода проблем с хайлоадом" и представляют из себя очень изящные и красивые решения :). Просто эту красоту можно понять, лишь работая над другими хайлоад-проектами
Вконтакте это как Visual Studio или какой-нибудь очень Long Term Support продукт. Код там в 100500 "// TODO" и "// FIXME". Главное, что укладывается в производительность и дедлайны. Иначе они ни одной фичи бы не смогли выкатить нормально.
Вам было бы удобно писать на Коболе, если бы для него сделали транслятор в С? А насчёт "неизвестно, что и как" как раз вопрос и был: изучается ли что-то и какие результаты изучения.
Но, на самом деле, я не хочу спорить на эту тему. Я надеялся услышать из первых рук что-то вроде "нет, не проводим, потому что..." или "да, проводим, и решили, что..."
Архитектура растущего проекта на примере ВКонтакте