2 мая 2010 в 1:49
Есть ли вообще какая-то разница куда ставится модуль? Могут ли быть какие-то побочки от установки напрямую в папку modules?
Разница в установке модуля напрямую в ядерную папку или /sites/all/modules
Главные вкладки
2 мая 2010 в 1:49
Комментарии
все зависит от того будетели вы использовать мультихостинг или нет, /sites/all/modules этот вариант для мультихостинга, модули запиханые сюда будут общие
«все зависит от того будетели вы использовать мультихостинг или нет, /sites/all/modules этот вариант для мультихостинга, модули запиханые сюда будут общие»
Спасибо! Примерно так и думал, просто не хочется папки плодить
Цитата из [##176046]Directory precedence and multi-site considerations[/##]
Peritus@drupal.org, Спасибо! Прям надо наверное всё перерывать сначала, чтоб не напрягать. С формулировкой поиска на инглише у меня часто туговато в силу кудрявости запроса
Эм .. Чтобы не флудить буду тут изредка спрашивать о своих изощренных проделках
В общем маза такая... Залез в БД ===> blocks. Что будет если я снесу 3 гарландовские блока? Два в left и один в footer.
Гарланд не юзаю и юзать не собираюсь.
Могу-ли я так-же убить всё, что считаю нужным? Блоки модулей ... Всякая фиготень, которая не задействована...
Да без проблем
Уважаемый автор, будьте добры просвятить нас в ваших порывах. Зачем убивать блоки из БД, когда их можно (и это считается модным) выключить из-под админки? Гарланд - дефолтная тема в Друпале. Попробуйте запустить update.php и вы с удивлением заметите, что ваша тема вдруг сменилась на Гарланд и на ее фоне происходит обновление модулей...
Я Вам не запрещаю ломать БД, но ответы на вопросы "почему при удалении блока из БД у меня весь сайт нафиг поломался? а мне нужно было удалить эту запись" уже не задавайте.
З.Ы. Поройте форум. Недельку назад человек уже спрашивал как вернуть назад сайт после удаления блока из БД ручками...
Конечно можете. На всяких случай посоветую: Делайте это не на рабочих сайтах.
Скажите как сделать, чтоб update происходил из моей темы? Если грубо(руками) переименую блоки в свои, почикаю лишнее - всё будет Зэр-Гут?
Зачем? А вам доставляет удовольствие жить в бардаке, когда например, из шкафа надо достать носки, а там банки с компотом(клубничным, который Вы не любите и никогда не пьёте), стиральный порошок и газовый ключ, при этом пока вы найдёте любимые носки с поросятками приходится перерыть весь шкаф?
Физически в ядре, модулях и файлах уже всё почикано xD Добрался до БД
p.s.: Полёт нормальный(почти на сверхзвуковой)
Даже обновляться по хитрому приспособился.
Ну всё получиться, если делать умеючи.
sites/default/settings.php
sites/default/default.settings.php
строка 186: # 'theme_default' => 'minnelli',
AI, я понимаю Вашу логику аля «NOBODY LIKES A SMARTASS» (никто не любит хитро*опых), но уж простите...
Ваша логика — отломи за хостинг $300 или умри.
Моя логика — «нет мозгов — плати за всё».
Давайте не будем на тему программеров и так далее.. Я очень их уважаю и ценю труды, но под мои критерии кое что не вписывается
Пасиба! Щас буду взрывать ))))
Не всё зависит.
Например обновлять куда удобней, когда доп. модули вынесены в sites - можно смело грохать старый каталог modules, не боясь, что там что-то осталось.
Я сливаю старый модуль на локаль, сравниваю с новым. Отключаю модуль, удаляю в друпале и саму папку. Убиваю шлак в новом, лью назад, бросаю старые тимплэты и стили, тестирую и смотрю, что в тимлпейтах изменилось, при надобности правлю.
Нужно бы по идее еще смотреть что с БД, чтобы данные не терять, но это можно тупо без удаления, просто папку передёрнуть(не килить в друпале).
При чём здесь старый модуль и новый модуль? Я про обновление самого Drupal говорю.
Поубирать лишнее - один из синдромов начинающего друпалера. Поубивать блоки,переопределить стили,чтобы было меньше коду,хакнуть ядро...
Вы с удивлением обнаружите, что НИЧЕГО не выиграли, но приобрели головняки с поддержкой всего этого в будущем и возможные конфликты.
Говорю на основании собственного опыта, со временем всё возвращается на своё место.
Хотя нет, польза всё же есть - "опыт сын ошибок трудных"
Да нет никаких проблем, у меня по крайней мере
А где, что и как работает — да, это мне интересно 
Автору: про логику - это камень в мой огород... не хочу бросать его обратно в Ваш.
Что касается про начинающих, программеров и иже с ними... Есть у меня приятель. 22 лет от роду. "Хакает" и "чикает" все подряд. Разные сборки линукса, сам ядра перебирал. 33 иль больше CMS перепробовал. 70 компов сжег и еще 10 под разогнанным перегревом держит. Экстримал. И ничего до конца не довел. Ничего не применил по назначению. Опыт получил? Да нафиг такой опыт, если проку от него нет.
Мне же это не интересно. Я уже свое наэкспериментировал. Я Вам не запрещаю, я предупреждаю. Если у Вас есть желание каку разгребать после своих хаков - да ради бога
Только зачем? 300$ за хостинг я не плачу. Я у Гора за 100 руб в месяц кручу сайты. И не блоги. Упакованы и CCK, и Views, и Ubercart, и еще хрен знает чем. Ничего не обрезал. И летает вся эта живность ровно так же, как на моем домашнем линуксовом серванте 2,6ГГц intel / 1,5Гб озу... Конечно, если Вы хотите халявный хостинг 000webhost.com, то я пойму ваши стремления. Только там и чистый хтмл дохнет, ибо говно хостинг.
прикольно когда так коммерческий сайт делается - поддержка другими людьми будет не хилую сумму стоить (хотя обычно переписывают с нуля) )))
Немного отвлеклись от темы вопроса
А непосредственно по теме:
1. Друпал ищет модули (кстати и темы) по следующему алгоритму
/modules/..
/sites/default/modules/...
/sites/all/modules/...
/sites/{ваща зона|ваш домен| ваш сайт }/modules - причем здесь поиск осуществляется от меньшей детализации к большей
причем в регистр модулей будет записан последний найденный и именно с ним Друпал будет работать.
Это дает широкий спектр манипулирования с модулями.
Во первых: как тут уже говорили удобство обновления (когда все не ядренные модули лежат в отдельной папке)
Во вторых удобство разделения модулей по мультисайтинговому принципу (когда разные модули нужны для разных субдоменов)
В третих простор для хакинга и для проверки своих исправлений для стандартных модулей (в этом случае достаточно скопировать стандартный модуль в паку где он будет найден позже и производить исправления уже в нем, в этом случае что бы откатится на стандартны модуль достаточно будет удалить скопированную папку)
Я уже давно обратил внимание на приоритет и пользуюсь этим от и до. Сначала модинг во второстепенной директории и тесты, потом отливка в ядерную папку
Очень удобно
Вопрос к знатокам следующего характера(к тем, кто с дурпалом давненько дружит). Как часто происходят косметические изменения в *.tpl файлах модулей при выходе новых версий?
Тенденции более в сторону наращивания плагинов и доп.минимодулей или же в сторону изменения самих ядер модулей?
Уже реально задолбало приват месадж обновлять. Поскольку шаблонная сторона модуля была изменена под свою тему, и метод обновления - простая замена .modul .info и т.д.(т.е. вывод остается старым - моим, а ядро обновляется), хочется примерно прикинуть как часто происходят корректировки...
Зависит только от автора модуля, но обычно если модуль "старый" устоявшийся то тпл-ки меняют редко (если только не добавляют какой-то функционал) ...
Кстати открою вам секрет: не обязательно менять тпл прямо в папке модуля (я бы даже сказал, что это вредно), надо копировать их из папки модуля в папку своей темы и уже там над ними изгаляться
Во первых это дает простой способ отката на стандартный шаблон если что то там перемудрили, ну и упрощает само обновление модулей - не надо выбирать, что там перезаписывать а что нет.
Всё, что можно уже вынесено туда... Некоторые тимплэйты всё-же подгребаются из папки модуля.. почему так пока не понял\
olk, спасибо!
Вопрос следующего характера: хорошо ли для друпал, когда php в режиме fast CGI? Какие с этого можно выхватить траблы и в какие моменты?
Видимо нормально ... Еще вопрос
По какому принципу происходит удаление модуля на уровне базы данных? Это просто зеркальная деструкция или условия обязательно аргументируются core_modul.install ?
Хочу немного подрихтовать модуль xml sitemap на предмет ненужный, я бы даже сказал в некоторых ситуациях вредных данных. Для этого было бы кошерно сразу убрать лишнее из базы и оторвать привязки нодах, админке и при билдинге файла(уже оторвал). Так-же хочу немного освежить там список сабмитируемых сервисов.
<priority>
Блин, таку энегрию, да в мирных бы целях!
Дублируя модули, можно огрести по полной. Полгода назад реанимировал сайт, который поддерживало несколько программистов (по очереди). выяснилось, что наличие одного и того же модуля в двух папках порождает случайные глюки.
Топикстартеру - Друпал оптимизируется не хакингом. Хагингом друпал портиться. Проверено на многих поколениях новичков.
А какая разница? Сделал свой шаблон, который расположен у тебя в теме и обновляй модуль хоть каждый день.
В том и прелесть обновления друпала - сносим всё что есть в корне и заливаем новое, кроме папки sites, - обновляем ядро. Сносим всё в sites/all/modules и заливаем новое - обновляем контриб. Моск можно на эту процедуру не включать, время лишнее не затрачивается. Если есть патчи, не забываем их складывать на видное место, например sites/patches, дабы самому не забыть и другим видно было.
Сначала шаблоны ищутся в папке модуля, если их там нет - в теме. В темизации 6-ки есть баг, при котором надо некоторые шаблоны также класть в тему, иначе нужные не будут работать, например для ССК если используем content-field-some-field.tpl.php, то content-field.tpl.php тоже надо скопировавть.
Ну это нормально. Недавно друпал на классы переписывали
Ога. Как я говорил - друпал не любит шибко умных, кто умней системы
Ага. И такое было, так мы релиза и не увидели
Это куда например?
Таким образом делаем вывод, что шаблоны модуля должны быть по возможности все в одном месте, а на подстраховку их лучше не дублировать?
Нет, Виктор. Ни в коей мере я не стремлюсь её поломать и обмануть. Я просто нифига не вкуриваю, если сразу пытаюсь что-то делать под незнакомую систему. Мне как то принцип от обратного ближе- что ли. Сначала порыться во внутрях, разобрать всё по винтикам, посмотреть как у других, потом собрать обратно и уже не ломать голову а как ... Потому что нифига тут система учи апи не работает. Много времени уйдет на тычки пальцем в небо. Проще раздраконить всё к чертям собачьим на атомы и посмотреть самому... Тем более уже половина реализована, думаю ничего грешного взять из 5-6ти модулей лучшее и от него уже отталкиваться
Модуль я так понимаю удаляется по следующему прнципу: когда он отключен при клике удалить просто происходит убиение таблиц, которые он использовал. Просиходит не всегда... На подстрахоовку после выключения нужно чистить кэш и запускать крон. Затем удалять и снова повторять процедуру.
Либо просто удалять и руками сносить таблицы из базы. Вообще остается много говна
При клике на "Удалить" вызывается то что ты напишешь в хуке hook_uninstall(), а вот пропишешь ты там удаление таблиц, не пропишешь, зависит только от тебя. Помню был баг у какого-то модуля, там автор прописал в деинсталляции удаление переменных из таблицы variable через лайковый запрос, и этот запрос половину системы херил
Это всё без тебя и так запускается
На релиз 7-ки. Вот это реально польза и разбор системы. Левелы прокачаешь мама не горюй
Системе всё равно где шаблон - она один раз всё просканирует (при обновлении реестра), потом будет брать пути из кэша темы. Конкретно этот баг довольно специфичен, я на него все несколько раз наталкивался. Во время темизации сразу видно - подхватился шаблон или нет, так что на этот счёт можно особо не переживать.
В том то и дело что нихрена оно не запускется .. По крайней мере не всегда ..
Не ... я не гамаю, чтоб левелы качать
Да, тем дофига. Одну Дан уже предложил. Модуль какой интересный написать. Да хоть бы ту же массовую загрузку файлов до ума довести.
Пока не покурю как следует откуда у кого ноги растут, браться как-то нет желания
По какому принципу работает node_revisions? Не нашёл просмотра версийсори туплю .. назвали просто странно
Если человек хорошо знает архитектуру Друпала, он может смело его оптимизировать хакингом. В некоторых случаях это очень полезно.
Например, если брать регистр тем Друпала, то там все неплохо - переопределение шаблонов делается один раз, а потом берется из кеша. Но что происходит с переопределением переменных? Например, я хочу удалить в функции template_preprocess_node следующие строки:
$variables['taxonomy'] = taxonomy_link('taxonomy terms', $node);
}
else {
$variables['taxonomy'] = array();
}
$variables['terms'] = theme('links', $variables['taxonomy'], array('class' => 'links inline'));
Т.е. мне нужно удалить или переопределить переменные $variables['taxonomy'] и $variables['terms'].
По правилам Друпала делаем, например, так:
unset($variables['taxonomy']);
unset($variables['terms']);
}
Или:
$variables['taxonomy'] = {Определяем новое значение};
$variables['terms'] = {Определяем новое значение};
}
В итоге Друпал каждый раз будет проходить 2 шага в формированиии переменных: template_preprocess_node и mytheme_preprocess_node. Но первый шаг нам не нужен, он лишний, т.к. выполняются лишние функции и запросы к базе.
А если бы мы сразу удалили/переопределили эти переменные в функции template_preprocess_node, этого лишнего шага не было бы, что и стало бы оптимизацией.
Хотя это не самый удачный пример.
P.S. Странные люди. ТС изучает систему изнутри, а ему намекают, что это плохо.
чтом мешает поставить нужную preprocess функцию вначало, а ядерную удалить через hook_theme_registry_alter ?
Не туплю всё же .... почему по адресу node/#numer-of-node/revisions меня, админа, не пускают?
Где вообще для этой ботвы юзеринтерфейс находится?
Если ревизии есть - будет таб у ноды - Ревизии (после "Просмотр" и "Редактировать"), если ревизий нет - ничего и не будет.
Ревизии создаются при редактировании материала.
Если используется таксономия, то логично, что ноды подгружаются в ноду. А то что вызывается ф-ция для их отображения - ничего страшного, она кэширует результат запроса.
Если задача очень специфическая, то имеет смысл переопределить обработчик таксономии и делать всё самим, но и для этого не надо лезть в код друпала.
А ещё можно просто отключить вызов template_preprocess_node
Любопытно ... ревизии были, но табы не появилось. Я так понимаю сообщение в системный журнал - это и есть маркер ревизии?
Нет, ревизии еще должны быть включены для данного типа материала
Всё банальнее ) Спасибо
А нафига тогда сообщение в системный журнал? Это вообще зачем?
В него все действия пишутся. syslog. Если не нужно - отключи модуль Database Loging
Первым делом снёс. Разобрался с этим... Пасиба
p.s.: *дзинь* expirience: +0.3% *тру-ту-ту* level up! *congrutulations, now you maybe not a lamer!*
Такс ... следующая хрень дас трабл: имеем доктайп XHTML + RDFa, ресурс великолепно проходит валидацию за одним маленьким но ...
Это маленькое но очень бесит и обусловлено Geshi Фильтром... Вопрос такой: как отучить друпал заворачивать блоки в параграфы по умолчанию?
Не писать же теперь всё на чистом HTML от и до... Бетер форматс установил, ноду пересохранил, понту ноль.
Кто-то смог побороть данное явление?
Отключить опцию "Строки и параграфы переносятся автоматически."
Нарушение текущей параграфной вполне сносной разметки... Необходимость передрачивать все существующие материалы попутно хардкорить на фулл HTML со всеми вытекающими...
Т.е. придётся перелопатить все материалы уже имеющиеся и отрубить себе и пользователям удобство на будущее.
Думаю над таким вариантом как поправить в очередной раз ядро на предмет добавления исключения при обнаружении в коде гешиных блоков.
Ну вот и повод появился написать простенький модуль, прикручивающий фильтр. За исходный возьми друпаловский и вставь туда проверку на гешу.
Хотя можешь начать с хака - так проще, но карма в минус и экпиренса меньше
Блин, у меня честно говоря уже башню начинает раскрывать розочкой. Не поверишь, на столе уже третий лист а4 на половину исчиркан заметками о том, что надо. Самое страшное, что все они из разных предметных областей, зато на тему друпала.
О, спасибо,
hook_theme_registry_alter- хороший хук!