1. Главная
  2. gun_dose

gun_dose: Комментарии

Главные вкладки

19 июля 2016 в 10:20

О! Кажись придумал. Делаем изначально плоский словарь чисто по брендам, а потом на hook_node_save вешаем обработку, которая смотрит на ветку классификации каталога и к термину бренда пристаканивает всю эту ветку, как дочернюю (ну в смысле создаётся новая ветка, где термины с теми же названиями, что и в словаре каталога) , попутно навешивая эти термины на товар. А если ветка уже есть, то просто выбирает эту ветку как термины товара. И через Hierarchical Select ограничиваем выбор бренда только корневым термином, чтобы не захламлять форму создания ноды. Т.е.

19 июля 2016 в 0:46

Тоже думал о таком, выглядит просто и функционально. Надо подумать, может изначально словари неправильно построены. Например кому в здравом уме понадобится фильтрация только по бренду? Типа "А куплю-ка я что-нибудь от самсунга, батарейку или телевизор". Но тогда неудобно товары заполнять - нужно указывать сразу два поля из разветвлённых словарей. Может надо какие-то зависимые поля типа field_collection?

18 июля 2016 в 16:08

Пробовал, но он тогда упорно в начало адреса пишет "taxonomy/term", и слайдер цены с ним почему-то ломается и выдаёт "Страница не найдена".

Но если у вас есть опыт настройки facetapi_pretty_paths, с благодарностью выслушаю.

18 июля 2016 в 16:06

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

15 июля 2016 в 11:52

Зависит от того, чем является страница. Нода, таксономия, вьюс и т.д. Для большинства сущностей есть подмодули метатега, которые отвечают за "локальные" тэги.

13 июля 2016 в 0:31

Есть же drush up. А что касается критики, то к ней тут вполне нормально относятся, просто её обсуждают, что вполне обоснованно, ведь для того и придумали форумы.

12 июля 2016 в 23:40

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

11 июля 2016 в 15:53

OldWarrior wrote:

Имеет ли это значение, если речь чаще всего идёт о костылях

Давайте ещё мануал напишем, как правильно к друпалу костыли прикручивать))))))))))))))))))) И вместо джуниоров-мидлов-сеньоров будем делить на трость-девелопер, костыль-девелопер и инвалидная-коляска-девелопер. А самые гуру будут гордо зваться "Ока-с-педалями-на-руле-девелопер".

11 июля 2016 в 14:59

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

10 июля 2016 в 16:01

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