Про Drupal7: ненависти (вместо любви) псто !

lexa - 13/Фев/2012 17:25

Только я собрался написать, что впечатления про Drupal7 более-менее положительные, все такое современное, с оверлеями и прочими понтами... как вдруг, внезапно, вылезла проблема:

Если пойти на сайт под D7 по битому URL somesite.domain/node/some-garbage

То вылезает PDO Exception, дескать к числовому полю ходят с символьным ID. Ну, как минимум под PostgreSQL вылезает, возможно MySQL к этому более толерантен (и мусор превращает, скажем, в 0, что не менее прекрасно).

В Drupal6 это место сделано куда разумнее, возвращается обычная страница '404' (нема такой страницы).

Понятно, можно подпереть на фронтенде, фильтровать после /node/ (/comment/, /user/) весь нечисловой мусор, но слишком много исключений (/node/add, небось и всякие /node/что-то-еще тоже бывают).

Значит надо фильтровать уже внутри, там грузится нечто по ID (или списку), ID бывает только числовой.

Гуглую и нахожу прекрасное: PDOException:Invalid text representation when attempting to load an entity with a string ID.

Ровно эта ошибка, ну думаю внесли недавно, сейчас возьму оттуда патч, а в следующем релизе поправят.

Ни хрена! Проблема открыта 21 декабря 2010, сопли жуют уже больше года, и все ради патча на 7 строк (который тривиален и работает, я его оттуда взял, последний по списку).

Я догадываюсь, что проблема в процедуре: активная ветка жалоб приписана к Drupal8, который какбэ девелопится. А репорты про 7.x (один нашел, тоже больше года ему) - помечен как duplicate от D8, вычеркнут и в боевой версии D7 его какбэ и нету. Запихали проблему под ковер.

отчего я такой добрый и терпеливый при моей-то тяжелой жизни? Другой бы на моем месте давно всех убил, один остался...

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

Comments

dil (not verified) - 13/Фев/2012 17:42

В очередной раз подтверждается тезис о том, что на PHP не написано ни одного приличного продукта..

lexa - 13/Фев/2012 17:49

Facebook?

dil (not verified) - 13/Фев/2012 17:57

То-то его столько раз ломали..

_slw (not verified) - 13/Фев/2012 18:08

а что в нем приличного?

lexa - 13/Фев/2012 18:54

Все рукопожатные люди - уже там!

_slw (not verified) - 13/Фев/2012 19:05

я бы сказал, что это очень, очень неприлично

dil (not verified) - 13/Фев/2012 20:14

- Рабинович, говорят, вы вступили в партию?
- Где?!

dmarck (not verified) - 13/Фев/2012 17:50

Я думаю, это скорее о том, что поддержка альтернативного (PgSQL, BSD, non-apache, чёрт в ступе) заявляется, но обычно не тестируется.

LAMP вам выдан? Вот и жуйте.

lexa - 13/Фев/2012 18:00

Хотел бы я знать, во что преобразует MySQL такой запрос. Просто "нихрена не нашлось" или выкинет все буквы, или превратит в '0'?

В 6-м друпале поддержку постгреса довольно быстро довели до работающей для core system, впрочем. Хотя там тоже были косяки и я по сей день его патчу (увеличение длины полей для messages, насколько я помню, ибо MySQL тихо обрезает, а Pg - ругается и правильно делает).

dmarck (not verified) - 13/Фев/2012 18:10

implicit type conversion вроде как гуглятся почти для любой среды ;)

lexa - 13/Фев/2012 18:14

Э, там нагугливаются очевидные вещи, в примерах из строки в целое - будет нормальная строка. А если нет?

dmarck (not verified) - 13/Фев/2012 18:22

из строки в целое - будет нормальная строка

не наоборот? ;)

В частности, именно в 9 постгрессе выкосили много этих самы имплисит преобразований, ибо результат их зачастую был неожиданным.

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

lexa - 13/Фев/2012 18:48

не, не наоборот. В примере про string->int будет строка вроде "1234", а не "здравствуйжопановыйгод"

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

dil (not verified) - 13/Фев/2012 18:01

Проверка валидности урла (и любых других параметров) должна выполняться, не доходя до базы. Если там полагается только число, не надо совать в базу произвольную строку. А то так и до sql injection недалеко.

avnik (not verified) - 13/Фев/2012 18:20

Plone же. (злобно хохоча)
NoSql и никаких инъекций. (правда там свои веселости)

lexa - 13/Фев/2012 18:01

С bind variables - откуда взяться injection?

dmarck (not verified) - 13/Фев/2012 18:09

Прямого не будет, а как свежезасунутое оно потом обрабатываться...

Впрочем, всё равно остаётся только вздыхать печално.

lexa - 13/Фев/2012 18:19

В bind variables? было бы странно там ожидать чего-то кроме преобразования типов.

dil (not verified) - 13/Фев/2012 18:23

А там точно везде и всегда binding используется? Сам по себе PDO этого не гарантирует.

lexa - 13/Фев/2012 18:50

Там где видел - там да.

Авторы модулей, конечно, способны на всякие выверты.

lexa - 13/Фев/2012 18:53

Ну вот пошел на plone.org, вбил там в поисковую строку Facebook login и обломался. Simple Social - это, как я за 5 минут понял, только like и подобное.
Аналогично с кросспостом в ЖЖ.

Не, Drupal - тот еще подарок, конечно. Но новый сайт, с шахматами и монашками, запускается ну за пару часов. С дизайном (и огромным выбором из готовых, что для меня важно).

avnik (not verified) - 13/Фев/2012 20:22

Модули плона свалены в "общий" с всеми питономодулями pypi, и/или svn/github коллектива (collective.*). Но увы -- это из тех вещей, о которых надо знать из каких-то тайных знаний ;)

Вот google:plone+facebook+auth показало plonesocial.facebook.rpx вот так сходу второй ссылкой. Но мне грозит через неделю делать сайтег с авторизацией по фейсбуку -- могу если интересно потом написать, что оказалось более менее рабочим из коробки.

lexa - 13/Фев/2012 20:31

Да, немножко интересно. Но есть небольшая разница между логином в существующий аккаунт и логином с одновременным его (аккаунта) созданием. Второе гораздо нужнее.

renat (not verified) - 14/Фев/2012 06:41

Последний патч по списку таки появился за четыре дня до написания поста, странно было бы ожидать его присутствия в ядре. А предыдущие версие красненькие почти все почему-то ;) Это при том, что в треде и ведущие разработчики ядра отметились. Понятно, что вы бы быстро написали патч, фиксящий проблему у вас же - да вот только на других инсталляциях что-нибудь могло бы и поломаться.

А процедура правильная, кровью писана. Иначе не избежать огромного количества деградаций в новой версии, что неприемлемо. К тому же особой проблемы она не создает - основная часть багов фиксится после выхода мажорной версии, когда новая ветка от нее еще ничем не отличается. D8 и D7 начали расходиться только осенью, сколь я помню, и до сих пор значительная часть фундаментальных изменений - в отдельных ветках GITа. Так что до недавнего времени "портирование" изменений было простой формальностью, да и сейчас оно не сложно.

lexa - 14/Фев/2012 15:10

Ну да, последний патч по списку - 4 дня назад. Но патчи похожие по смыслу - почти год назад, в марте 2011.

Я про то и говорю
1) год жуются сопли.
2) А бабушки в это время падают и падают - семерку зарелизили 5 января 11 года.
3) Зеленые патчи включают в себя и патчи тестов.

И процедура - неверная, даже если написана кровью. Она привела к тому, что в D7 (который боевой и все дела) бага какбэ нет. А в D8 - ну, имеет право быть.
Во всяком случае, в open issues для семерки я по словам PDO Exception/PDOException ничего похожего не нашел.

Верная процедура не должна приводит к ситуации, когда патч на 7 строчек с достаточно противной багой в боевой версии пишется год.

Бага противна тем, что по части неверных URL вместо errorpage 404 вылезает вовсе даже 500, отловить которую штатными средствами нельзя. Если бы была какая-то затычка - ну я бы залепил ею и тоже бы расслабился.
Т.е. это не critical, наверное, не падает с грохотом все, но достаточно недалеко от таковой.

renat (not verified) - 14/Фев/2012 20:43

Алексей, баг может существовать против "боевой" версии только в том случае, если в следующем мажорном релизе его просто нет (содержащий сбойный код компонент полностью переписан, например). Во всех же остальных случаях он приписывается к разрабатываемой версии, однако обязательно помечается тегом "needs backport to D7". Разумеется, все активные контрибъюторы знают об этой особенности и проверяют багтрекер с учетом этого тега, а остальные все равно находят нужный тред в Гугле.

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

Поймите правильно, я перешел на семрку в прошлом феврале, причем речь шла в том числе о сложных проектах с активным использованием такой новой фичи, как мультиязычные поля. Она и сейчас не не сказать чтобы Rock solid, а тогда вообще создавалась только - в ядре были для нее "закладки", но недостаточные, при том что сама фича абсолютно "ядерная". Соответственно пришлось по полной программе принять участие в борьбе с багами, и я со всей ответственностью могу сказть - нормально процесс работы выстроен. Хотя несложно представить количество проблем, с которыми тогда пришлось столкнуться - ну а что делать?

lexa - 14/Фев/2012 21:24

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

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