Как я люблю, когда человека отправляют заниматься хернёй, вместо одной строчки кода в template.php. Ну когда же до людей дойдёт, что правильные склонения - это важно?!
Пока курил тему, придумал два варианта: первый - сохранять в таблице history дату просмотра каждой страницы ноды отдельно - но это значит, что надо сохранять жёсткую привязку к количеству комментариев на страницу; второй - сохранять в таблице history записи для каждого комментария. Думаю дальше.
Ого, сколько понаписали. Прошу прощения у всех, кому не ответил в 2010 году - в армии был. А после было не до друпала - идёт много новых проектов. Если у кого есть вопросы по OG и прочему для Drupal 6 - обращайтесь, подскажу.
Ну я пока тоже красиво не оформлял. Это на себя должна темизация брать, по идее. Вот кусок кода из моего helper-модуля, используется на http://rupor.sampo.ru/ :
Ооок... я просто от этого модуля отказался недавно, но работало. В настройках пункта меню роль указали верно? Не работает оно как - если для рута, то всё в порядке.
Более чем. Я больше скажу - есть такая штука, как hook_schema_alter. Я могу навскидку привести некоторое количество модулей которые, если бы использовали этот хук, в разы меньшё дёргали бы базу и гоняли данных.
Честное пионерское, я так и на понял мотивы использования вордпресса. Ну фиг с ним. Но мотивы совместного использования и вордпресса, и друпала я вообще не понял. Спасибо.
Спасибо за ребёнка. С каких это пор желание ПОНЯТЬ принцип работы системы, ПОЧЕМУ оно так работает и ЧЕМ руководствовался создатель - это глупость и ребячество? Мне нравится настолько высокий уровень абстрации у друпала, но мне хочется понять чутка больше.
Не аргумент. Что мешает хранить тот же линк на ноду или термин непосредственно рядом с нодой/термином в базе? Или с пользователем, или со словарём. Есть кеш на фильтры, но нет кеша на объекты пользователей и пути. Только-только появился. Кеш на файлах реализуется вообще сторонними средствами. Апи файлов не расширяемо, только свой контриб на полный цикл, но при этом sessions.inc - можно вынести в отдельный файл. Таких мелочей много. Интересно же.
Views, помимо всего прочего, предлагают тонну хуков, генерируют кучу лишних данных в объекте, которые вы может и не будете использовать, и вообще весьма активно используют как процессор, так и память. В своём коде будет в разы меньше данных гоняться. В связи с этим мне просто непонятно, зачем некоторые модули требуют Views для работы, хотя он им в принципе по факту не нужен... например OG User Roles...
Темы уже разные, за ними, естественно, и блоки. Как доделаю полностью разделение и настрою правильно редиректы - обязательно расскажу, что и как получилось.
Спасибо за доклад, для классического мультисайтинга очень и очень. Но меня мучает вот такой вопрос:
У меня общее - всё. Вплоть до поведения (сайт построен на OG). Просто необходимо некоторые части сайта определить как отдельный домен. Что я для этого делаю: определяю новый settings.php, в нём указываю тему для нового сайта, главную страницу и строки перевода, после чего переписываю все URL'ы при помощи hook_url_alter_outbound, определяя, к какому из сайтов принадлежит та или иная нода.
В свой модуль. Ну или смотрите аттач. Я правда на орге еще не выкладывал, надо причесывать.
Как я люблю, когда человека отправляют заниматься хернёй, вместо одной строчки кода в template.php. Ну когда же до людей дойдёт, что правильные склонения - это важно?!
Пока курил тему, придумал два варианта: первый - сохранять в таблице history дату просмотра каждой страницы ноды отдельно - но это значит, что надо сохранять жёсткую привязку к количеству комментариев на страницу; второй - сохранять в таблице history записи для каждого комментария. Думаю дальше.
Неужели больше никто не сталкивался с проблемой? Это же глупо - при открытии темы все комментарии на всех страницах помечаются как прочитанные!
Ого, сколько понаписали. Прошу прощения у всех, кому не ответил в 2010 году - в армии был. А после было не до друпала - идёт много новых проектов. Если у кого есть вопросы по OG и прочему для Drupal 6 - обращайтесь, подскажу.
А понаписали интересно, стоит и самому покурить.
Например, из template.php и поместить в $vars
Вызвать там, где надо, эту функцию. Она отдаст код ссылки для присоединения. лучше способа я не придумал.
Ну я пока тоже красиво не оформлял. Это на себя должна темизация брать, по идее. Вот кусок кода из моего helper-модуля, используется на http://rupor.sampo.ru/ :
Ооок... я просто от этого модуля отказался недавно, но работало. В настройках пункта меню роль указали верно? Не работает оно как - если для рута, то всё в порядке.
Отвечу так же, как был задан вопрос: всё работает. Перечитайте README.
Ну вопрос был про работу с базой напрямую Я просто добавил ещё один вариант.
Более чем. Я больше скажу - есть такая штука, как hook_schema_alter. Я могу навскидку привести некоторое количество модулей которые, если бы использовали этот хук, в разы меньшё дёргали бы базу и гоняли данных.
Я спросил, есть ли материалы или ещё какая-нибудь информация. А вы как-то странно рефлексируете. Кстати, не Крис, а Дрис.
Судя по тому, что я вообще знаю о вордпрессе - он не совсем рогатка. Далеко не рогатка. Он вилы. Рогатка - это друпал без излишков.
Честное пионерское, я так и на понял мотивы использования вордпресса. Ну фиг с ним. Но мотивы совместного использования и вордпресса, и друпала я вообще не понял. Спасибо.
Спасибо за ребёнка. С каких это пор желание ПОНЯТЬ принцип работы системы, ПОЧЕМУ оно так работает и ЧЕМ руководствовался создатель - это глупость и ребячество? Мне нравится настолько высокий уровень абстрации у друпала, но мне хочется понять чутка больше.
В функции темизации, выводящей блок. Или в функции hook_block в части, непосредственно описывающей массив для блока.
Не аргумент. Что мешает хранить тот же линк на ноду или термин непосредственно рядом с нодой/термином в базе? Или с пользователем, или со словарём. Есть кеш на фильтры, но нет кеша на объекты пользователей и пути. Только-только появился. Кеш на файлах реализуется вообще сторонними средствами. Апи файлов не расширяемо, только свой контриб на полный цикл, но при этом sessions.inc - можно вынести в отдельный файл. Таких мелочей много. Интересно же.
Views, помимо всего прочего, предлагают тонну хуков, генерируют кучу лишних данных в объекте, которые вы может и не будете использовать, и вообще весьма активно используют как процессор, так и память. В своём коде будет в разы меньше данных гоняться. В связи с этим мне просто непонятно, зачем некоторые модули требуют Views для работы, хотя он им в принципе по факту не нужен... например OG User Roles...
Content Profile + Imagefield + Imagefield Crop. Но честно скажу - лучше взять модуль Avatar Crop и довести его до ума.
В свой модуль же.
<?php
function helper_module_form_alter(&$form, $form_state, $form_id) {
Да, получается так. Спасибо.
Темы уже разные, за ними, естественно, и блоки. Как доделаю полностью разделение и настрою правильно редиректы - обязательно расскажу, что и как получилось.
Спасибо за доклад, для классического мультисайтинга очень и очень. Но меня мучает вот такой вопрос:
У меня общее - всё. Вплоть до поведения (сайт построен на OG). Просто необходимо некоторые части сайта определить как отдельный домен. Что я для этого делаю: определяю новый settings.php, в нём указываю тему для нового сайта, главную страницу и строки перевода, после чего переписываю все URL'ы при помощи hook_url_alter_outbound, определяя, к какому из сайтов принадлежит та или иная нода.
Вот уж подписки мне точно жалко не будет Можно было и опционально.
Ключевое слово - может. В общем, жертвуем всем ради гибкости, я понимаю конечно... Но вот всё подряд пихать в пользователя тоже не стоит, по-моему.