Блоги по умолчанию и гуманитарная помощь
Уже поднималась тема подписания юзеров по умолчанию на какие-то блоги. Столкнулся с тем, что и мне сейчас это нужно. Думаю, периодически на разных ресурсах такая необходимость будет возникать (например, блоги «О проекте», «Новости» и т.д.).
Собственно предложение: при создании корп. блога админом (именно админом!) должна быть возможность пометить его «Подписка пользователей по умолчанию». И всех новых юзеров на него подписывать.
Собственно предложение: при создании корп. блога админом (именно админом!) должна быть возможность пометить его «Подписка пользователей по умолчанию». И всех новых юзеров на него подписывать.
7 комментариев
1. Создание нового типа блога
2. Добавление дополнительного свойства для блога
Когда стал разбираться с кодом, то увидел, что тип блога «open» вшит прямо в код, и в комментах указано, что список будет дополняться. И решил, что этот путь однозначно создаст проблемы при будущих апгрейдах.
Путь второй менее проблемный, хотя и понятно, что совсем без них и тут не обойдется. Но решил идти в этом направлении.
В результате потребовалось:
1. Добавить поле в таблицу БД — это фигня и безпроблемно
2. Доработать несколько шаблонов Смарти и файл руссификации — это тоже естественно
3. Но еще пришлось внести изменения в следующие файлы: ActionBlog.class.php (отработка значения доп.поля «по умолчанию», Blog.entity.class.php (получение/присвоение значения соотвествующему свойству), Blog.mapper.class.php (запись/чтение значения в БД), ActionRegistration.class.php (чтобы отработать подключение к дефолтным блогам на этапе регистрации).
На этом я остановился, так до конца задачу еще не реализовав, т.к. оказалось, что готового метода подключения юзера к блогу нет, в текущей версии это сделано через вызов аяксом внешнего пхп-скрипта. В принципе, сделать-то это не сложно, т.к. код есть. Но я остановился и задумлася: а вот выйдет завтра версия 0.4, и что делать? Заливать накатом обновления — убить все нафиг. Руками править код в стандартных модулях? И делать это каждый раз при выходе новой версии? Думаю, мне будет влом это делать. Сидеть на старой версии? Или вообще свою ветку развития ЛС открывать?
И что-то ощутил я легкое расстройство. Вроде и хорошая вещь — ЛС, и открытая, и с точки зрения современных тенденций проектирования, вроде, грамотное, и все такое. Но при всем при этом получается вещь в себе, где доработка напильником может основательно выйти боком. Народ, а как вы планируете поддерживать в рабочем состоянии свои хаки, а?
Или, может, я глобально где-то ступил, не заметил какого-то «изюма» и совсем не в том направлении рыть начал? Тогда вправьте мне мозги на место, плиз, в качестве гуманитарной помощи.
так же покопай в сторону merge
1. если файл с последней использованной ревизии не менялся в svn, то merge сольёт два файла без проблем
2. если файл в svn менялся, но не в тех строках, где внёс изменения ты — merge опять без проблем отработает
3. если файл менялся именно там, где ты его менял, то merge укажет на конфликт. Останется только его разрешить.
О сюда делаю вывод, что вероятность удачного апдейта гораздо выше.
Может, я параноик или ваще технофоб, но это свыше моих сил!