От себя добавлю - у Phpmailer'a проблемы в заголовках писем в некоторых почтовиках. Патч брать отсюда.

Field Collection при использовании с dev версией Entity API вообще ломается - патч отсюда брать.

Только если время поджимает... А так проще внешним модулем костыли наваять

p.s Последний и единственный патч брал с drupal.org под Webform позволяюший ставить условия для отправки сообщений на емаил

"RxB" wrote:

Очень интересно как вы будете ваять костыли в случае, например, такого косяка
http://drupal.org/node/1425182#comment-5565988
http://drupal.org/node/1070102#comment-4128184[/quote]
Может он использует только проверенные модули, в которых нет таких косяков?

"emzzy" wrote:

Может он использует только проверенные модули, в которых нет таких косяков?

А можно мне список таких модулей поимённо?

"SplasH" wrote:

А можно мне список этих модулей поимённо?

Хотите сказать, что у всех модулей есть такие косяки, которые необходимо патчить? У всех модулей есть косяки, это да, но! не все модули из-за этого нужно патчить. Ибо косяки есть мелкие, есть такие, которые можно исправить в своем модуле, что-то переопределив, есть такие от которых проще отказаться и взять или альтернитиву или наваять свое.

"emzzy" wrote:

У всех модулей есть косяки, это да, но

"emzzy" wrote:

есть такие, которые можно исправить в своем модуле

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

"SplasH" wrote:

Косяки исправляются патчами. В своих модулях допиливается или отпиливается функционал.

У вас на сайте стоит 20 модулей(допустим). 5 из них вы пропатчили. 15, которые вы не патчили, разве не имеют косяков? Имеют, но вы, или просто на них не наткнулись, или нашли другое решение, или решили, что эти косяки несущественны(например некий Notice).

"SplasH" wrote:

В дополнение - патч полезен для сообщества, а костыли - индивидуальны.

Да, но заказчик платит, за то, что вы ему предоставите готовое решение, и его мало волнует как вы это сделаете. Индивидуальное решение - это просто индивидуальное решение, и если его проще и быстрее реализовать это не значит, что это костыль.

Я веду, к тому, что патчить или не патчить зависит от конкретного случая. Патчи я применяю аналогично, как и Shok211 только в крайних случаях.

"emzzy" wrote:

У вас на сайте стоит 20 модулей(допустим). 5 из них вы пропатчили. 15, которые вы не патчили, разве не имеют косяков? Имеют, но вы, или просто на них не наткнулись, или нашли другое решение, или решили, что эти косяки несущественны(например некий Notice).

Ядро Друпала тоже имеет огромное количество багов. Мне теперь и его не патчить, даже если это решит мою проблему? Я не утверждаю, что патчи надо ставить на каждый модуль, но во многих это просто необходимо для корректной работы.

"emzzy" wrote:

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

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

"SplasH" wrote:

Ядро Друпала тоже имеет огромное количество багов. Мне теперь и его не патчить, даже если это решит мою проблему? Я не утверждаю, что патчи надо ставить на каждый модуль, но во многих это просто необходимо для корректной работы.

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

"SplasH" wrote:

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

Я не вижу взаимосвязи между качеством кода и индивидуальными решениями. Вы делаете тему для заказчика - это индивидуальное решение. Вы пишите свой модуль, под конкретный сайт - это индивидуальное решение. Это ведь не означает, что вы непременно пишите говнокод? Универсальные решения требуют совсем другого подхода чем индивидуальные. Их необходимо более тщательно тестить, делать проверку на то, как они сказываются на производительности, все ли возможные случаи покрывают, проверять совместимость с другими модулями и т.д. Безусловно, такие действия нужно делать и с индивидуальными решениями, но в этом случае проверка ограничиваются только конкретным проектом.

Ну вот вам простой пример... После того как я установил на webform патч который делает n энных вещей , кстати , написанный для сообщества. Я закончил заказ и отдал заказчику, тут заказчик решил обновить модули потому что:
a) Нашли уязвимость в модуле webform
b) Нашли уязвимость в патче.
v) Разработчик который решил добавить функционал на ваш сайт вряд ли будет копаться во все модулях для того что бы узнать где вы там что патчили.
Исход ? Сайт лежит...и вы снова идете и патчите сайт который вы уже сделали, объясняете что модули обновлять нельзя и вы это сделали чтобы заказ был быстрее выполнен. И не важно что именно из за моей лени я не написал форму на FORM API, не полез в ядро модуля и не написал form_alter для формы, не дождался стабильной версии... Или вы готовы поддерживать каждое обновление модуля и ставить патч заново ? В чем экономия времени ?

"emzzy" wrote:

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

Я всё понять не могу - с каких пор баги одного модуля решаются путём создания другого?

"emzzy" wrote:

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

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

"emzzy" wrote:

Это ведь не означает, что вы непременно пишите говнокод?

Тождественно это не равно конечно, но незнание правильных подходов к решению задач обычно обусловлено отсутствием понимания архитектуры системы. И в этом случае простые вещи делаются очень сложно, что приводит к захламлению проекта.

"Shok211" wrote:

a) Нашли уязвимость в модуле webform
b) Нашли уязвимость в патче.

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

Я ведь говорил про то что если ваш патч отличается от патча вышедшего для модуля логикой работы то модуль работать не будет. Уже второй раз спотыкаюсь об эти грабли. Первый раз я писал патч который позволяет в views файлы оборачивать ссылками на их thumbnails. Дак с обновлением на 3 views. Перестала работать галерея, и я 2 дня искал куда что опять надо патчить. Хотя самым удобным решение было написать эту галерею без views. 2 Брал сайт готовый и обновлял все модули

"SplasH" wrote:

Я всё понять не могу - с каких пор баги одного модуля решаются путём создания другого?

Читайте выше пример от Shok211. Еще примеры:

1. Не прописаны правила доступ к странице у какого-то модуля, к которой по логике может иметь доступ только админ, а имеют все. Прописываем свой hook_menu_alter в своем модуле
2. Вьюшка криво создает хандлер - создаю свой хандлер в своем модуле и его использую.
3. Taxonomy menu большим количеством терминов выжирает всю память. Делаю свою выборку, или делаю менюшку через Views и кеширую ее.

"SplasH" wrote:

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

Вспомните историю, как Дрис создавал свой Drupal. http://ru.wikipedia.org/wiki/Drupal Он не хотел создать универсальное решение, он создавал индивидуальное решение для себя.

"SplasH" wrote:

Тождественно это не равно конечно, но незнание правильных подходов к решению задач обычно обусловлено отсутствием понимания архитектуры системы. И в этом случае простые вещи делаются очень сложно, что приводит к захламлению проекта.

Если вы понимаете архитектуру Drupal, вы одинаково качественно сделаете, как индивидуально, так и универсальное решение. Но, как было указано мной выше, универсальное решение требует напорядок больше времени и усилий.

"emzzy" wrote:

Не прописаны правила доступ к странице у какого-то модуля, к которой по логике может иметь доступ только админ, а имеют все. Прописываем свой hook_menu_alter в своем модуле

Это не баг. Это функционал. По-хорошему это должно быть в модуле, но разработчик имеет право не реализовывать эту фичу.

"emzzy" wrote:

Вьюшка криво создает хандлер - создаю свой хандлер в своем модуле и его использую.

"emzzy" wrote:

Taxonomy menu большим количеством терминов выжирает всю память. Делаю свою выборку, или делаю менюшку через Views и кеширую ее.

Я пытаюсь донести одно - если бы каждый делал только для себя, то сообщества не было бы. Каждый мой проект обязательно сопровождается статьями в блог, модулями на д.орг, и кучей патчей. Поэтому я принципиально против решений "для себя" - без активной работы "для людей" комьюнити потухнет. Если вы сделали свою выборку в taxonomy menu - запостите ишью на д.орг со своим решением. Это займёт 5-10, зато поможет сотням людей.

"<a href="mailto:andypost@drupal.org">andypost@drupal.org</a>" wrote:

Хорошо бы еще научить людей писать ревью на эти патчи

Стараюсь всегда ревьюировать патчи - правда, чаще всего приходится отрицательно.

Другое дело, когда разработчики не спешат включать их в ядро новых версий - яркие тому примеры views, flag и global redirect - хотя, вероятно, есть на то причины.

Мы вроде обсуждали не про сообщество и как ему помочь, а про решения конкретных проблем за короткие сроки без фатального исхода через неделю. Хотя я абсолютно согласен что сделал модуль поделись со всеми.

p.s Раз уж можно пофлудить. Уже 3 неделю хочу выложить модуль для удобного управления alias. Написал введение xD. У кого есть желание может подхватить. Модуль позволяет добавлять новые пути на уже существующие.

"Shok211" wrote:

Уже 3 неделю хочу выложить модуль для удобного управления alias. Написал введение xD. У кого есть желание может подхватить. Модуль позволяет добавлять новые пути на уже существующие.

Создавай отдельную ветку и покажи наработки.

"SplasH" wrote:

Я пытаюсь донести одно - если бы каждый делал только для себя, то сообщества не было бы. Каждый мой проект обязательно сопровождается статьями в блог, модулями на д.орг, и кучей патчей. Поэтому я принципиально против решений "для себя" - без активной работы "для людей" комьюнити потухнет. Если вы сделали свою выборку в taxonomy menu - запостите ишью на д.орг со своим решением. Это займёт 5-10, зато поможет сотням людей.

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

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

Ниже прикреплен патч ну или фикс, как вам виднее... Темы я так и не нашел.

Опыт работы с 16 до 18 лет (Вроде у меня 1 тема в блоге была о просьбе платных консультаций полтора года назад) действительно не большой.

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