9 декабря 2016 в 17:19
Всем привет!
Озадачился вопросом - как сделать всю строку таблицы ссылкой на материал?
Организована страница с материалами через views, где анонсы материалов расположены в виде таблицы. Нужно сделать так, чтобы при нажатии в любое место строки открывался материал.
Нашел такую тему с решением, но я не силен в javascript b посему не знаю, как применять данный код.
Могу предположить, что его нужно сохранить в файле .js и этот скрипт подключить в .info файле темы.
Комментарии
javascript тоже правильно.
Но можно:
1. переобределить вывод
2. Переопределить шаблон
Не понимаю, что значит "переопределить". И как это делается?
js не хочется использовать, чтобы сайт лишний раз не тормозить.
Оба пункта касаются настроек views, в настроках полей есть настройки вывода.
шаблоны переопределяются в правом нижним углу views (расширенные настройки)
там где Тема оформления: Информация
js не хочется использовать, чтобы сайт лишний раз не тормозить.
там понимаешь ли переписать все эти ссылки после загрузки - ну что то около 0,001 секунды
далее - обернуть ссылкой строку таблицы - нельзя.
делать надо так - есть таблица - один столбец. В каждой ячейке надо нарисовать
<tr>
<td><a href=""><div>
<table> ....... </table>
</div></a></td
</tr>
</table>
неплохо да?
в тоже время ты можешь спокойно сделать
так что javascript быстрее справится, чем браузер отрисует эти художества
Сейчас буду копать. В любом случае большое спасибо! И, пожалуйста, не отключайтесь - думаю, вопросы еще будут!
Я правильно понимаю, что нужно в корне темы создать файл типа views--[название_представления].tpl.php и в нем прописывать скрипт?
Если идете по пути javascipt не надо менять темплэйты.
У вас есть view, в центральной колонке присутствуют настройки "шапка" и "подвал". Туда можно вписать Глобальный: PHP
и сделать в нем вывод:
...
$(document).ready(function(){
});
</script>
с каких пор для обработки js нужно включать формат php? плюс, скрипт пример не будет работать
С кодом не поможете? Конкретно этот код вставить? Я js не знаю, увы.
Об этом я тоже сейчас думаю - нужно ли включать php?
Что из этого нужно выбрать, чтобы скрипт писать?
какой фильтр позволит не резать скрипт - такой и ставьте, какая разница? php позволяет также и кое что другое сделать.
Нужна помощь, да помогу. Пишите в личку сообщение, хотя бы о том, а что нужно то в итоге?
Подключайте js-скрипт правильно - https://www.drupal.org/docs/7/api/javascript-api/adding-javascript-to-yo..., https://www.drupal.org/docs/7/api/javascript-api/managing-javascript-in-... либо через attached (http://drupal.stackexchange.com/questions/29210/how-do-i-add-javascript-...) и не слушайте горе-советы, особенно про использование php-фильтра.
Очень умный пост.
Типа если у вас нет своей темы и своего модуля - то и вообще не подходите к компу.
потому что там - о ужас - есть php-фильтр.
Он был написан исключительно для страшилок.
я - пользуюсь, давно и долго.
Это первое.
Второе - указанные вами (ну мужики то не знали) способы подключения - ими тоже нужно знать как пользоваться.
Иначе будет так что у вас на всех страницах сайта колбасит jQuery по несуществующим элементам.
Зато подключили в theme.info! Правильно, типа.
Само по себе включение пхп-фильтра - огромная дыра в безопасности. Даже если им не пользоваться и запретить его использовать всем. А для вставки скриптов можно просто сделать свой текстовый формат без обработок. Кликается мышкой за минуту, зато спать можно спокойно.
"Хранить исполняющий код в бд как минимум не безопасно."
Общие фразы. Общие вычитки.
Не о чем говорить. А что вы будете делать если вам надо построить вывод views в зависимости от системной переменной или от реферера или от текущего языка или от текущей темы? без php фильтра у вас не получится. Так может и от views откажемся ради "великих" постулатов?
фигня
Хахаха, а вот это уже просто смешно. У меня в любом проекте есть какая-либо альтерация вьюсов. Делается совершенно безо всяких пхп-фильтров. Не верите, попробуйте это
да, ладно! Ради global $langusge;
return $language;
Альтерацию лепить?
А i18nviews для кого придумали?
и это еще надо ставить?
На каждый чих по модулю, когда все и так лежит в memcache?
Ну каждый делает по своему!
А потом Друпал ругают за то что тормозит. Ну а как тут не тормозить если по 1000 модулей активны на проекте, который в MODx например весит всего ничего...
Вообщем так. Юзал, юзаю и буду юзать.
И за много лет работы ни разу никто мне ничего не сломал (хотя пытались и пытаются)
А как иначе? Вы умеете через пхп-фильтр перевести все текстовые лэйблы, раскрытые фильтры, пейджер, подвал, шапку и заголовок вьюса? О_о
какой безопаснстью тут жертвуется????
Конкретно что?
остальные вопросы - просто делаю вид что не видел.
Ну пока ты там мамочке жалуешься - напишу для остальных.
Доступ к БД - это полный провал. Никто не будет себя обнаруживать выполнением кода. Просто будут тырить данные.
Но не все так страшно.
Правильная настройка прав доступа в апаче, права на файлы и каталоги на уровне Linux, пароль длиннее чем 6 символов - ну хотя бы 20, настройки доступа к самой базе, через сокет, а не по сети, и никто никогда доступ к вашей базе не получит. Скорее будет найдена очередная брешь в ядре. Это происходит примерно 1 раз в месяц.
Кстати, да. Вот сейчас перетягиваю древний сайт с MODX на Друпал, там активно используется split(), который нынче deprecated. Очень много кода хранится в сниппетах, которые находятся в БД (и не только они, есть еще чанки, плагины). Доступа к базе нет, пришлось патчить ядро MODx и перед eval() делать автозамену старых функций на актуальные. А вот на модекс-форуме обсуждение - http://modx.im/blog/questions/1685.html . ))
Там можно хранить код не в базе, но сам движок и (фреймворк для Revo) настолько убоги, что нет слов. И не удивительно - пусть дизайнеры рисуют, а программисты придумывают архитектуру.
Создатель его дизайнер/верстальщик, которому было не удобно натягивать дизайн на обычных CMS и потребовался свой велосипед. верстать для него темы в принципе действительно удобно...
У меня нет говнокода, в этом дело. Вы пишете про что то свое, близкое, родное. Мне не знакомое. ПОэтому не о чем говорить.
зато у вас есть говнобаза)))))))))))))))))))))))))))))))))))))))))))))))))))))))))
для веб-приложения куски исполняемого кода в базе данных - это как раз то, что именуют "говнокод",
именуют грубо, чтоб баловать ГК не хотелось даже начинающему.
База данных - для хранения данных.
Views не ранит код в базе, он там хранит правила по которым строится выборка. Это действительно разные вещи.
еще чего
Если вы будете использовать пхп-фильтр вместо написания модулей, вы никогда не дорастёте до того, чтобы делать сайты, на которых в БД могут быть ценные данные, которые не видно с морды анониму.
На практике же более 99% взломов не ломают функционал сайта, не уничтожают содержимое и не воруют данные, а просто срут в код страницы невидимыми спам-ссылками, либо рассылают с сервера почту со спамом, либо ддосят какие-то третьи ресурсы. И зачастую проходят годы, прежде чем владелец сайта обнаружит взлом.
И прописывали это условие в своих акках.
приведите мне пример. Вот конкретный пример, каким образом вы собираетесь внедрить свой код в "Output code"
глобального PHP в настройках views.
Тогда это будет полезным постом
а конкретный пример, где есть необходимость в views_php имеется?
А зачем это делать?
gun_dose написал:
на которых в БД могут быть ценные данные, которые не видно с морды анониму.
Ну вот новости Яндекса про Аудитории - достаточно получить список пользователей, чтобы задешево использовать его не для рассылки всякой всячины, а грамотно отработать в РСЯ
Хотя бы это - а ведь есть еще IP, логи... могут быть. Вообщем доступ к базе - это катастрофа
Новости яндекса - согласен. А сколько проектов подобного масштаба вы сделали?
http://drupal.stackexchange.com/a/2512
Вкратце на русском.
1. Код в базе - удачи с контролем версий и деплоем.
2. Код из базы выполняется через тормозной eval. От себя - удачи с opcache
3. Удачи с отладкой.
4. БОЛЬШОЙ удачи при апах мажорной версии. Но проблема скорее всего будет с промежуточными security-fix'ами, так как именно они на моей памяти добавляли обратной несовместимости.
5. Всегда можно продолбать момент, и случайно дать юзерам возможность заполнить это поле.
6. Всегда есть вероятность существования возможности внедрения sql-инъекции. А если ещё и код можно будет при этом в базу вставлять...
https://youtu.be/xhpb0DB70Cw?t=1m37s Мимо крокодил.
Ахаха, деплой, отладка, контроль версий)))) такие люди кликают, что как-то работало, а потом по фтп файлы заливают на хостинг))
Уверен, что postgre есть, что нам рассказать об использовании гита))
1. Контроль версии чего? global $language?
да нет, никакого такого супер кода в php фильтр ставить не требуется
2. eval ну да, и что? на php fpm не заметил ничего, memcache тоже не возражал, а ему и тем более все равно
3. отладка - заходите в админку во view, и нажимаете внизу кнопку - вывести результат - выводите - смотрите
4 5 6 - вообще то изначально речь шла о конкретном php filter, кажется это было упущено. Мысль ушла далеко вбок.
поэтому пункты 4 5 6, они не об php filter
Контроль версий кода конечно же. И конфигурации. Надеюсь, вы не ставите эксперименты на продакшене. Так вот, когда на локальной копии проводятся изменения, то если они в коде, то всё решается через гит пуш/гит пулл. Если же они в базе данных, то за время работы контент-менеджер может насоздавать котент, а юзеры напишут комментов. И при заливке базы это всё похерится. А кликать всё повторно вручную - это лишние движения и путь к ошибкам. Именно поэтому при разработке нужно изначально максимально перенести конфигурацию в код.
За первый пункт пояснили выше.
За второй - я вам про тёплое, а вы мне про мягкое. Код в eval выполняется медленнее. И не оптимизируется opcache хоть тресни.
За третий пункт - вы не понимаете, что значит отладка.
Четвертый пункт - поясняю по хардкору. Вышел security fix у модуля, который ломает обратную совместимость. Если у вас используется php filter хрен вы найдёте, где и что сломалось.
Пятый пункт - реально очевиден. PHP filter повышает критичность ошибки в настройке прав на сайте.
Шестой - как бы тоже. Если можно исполнять код из базы - это не дырень, а дырища.
а в чем собственно говоря проблема?5 строчек кода и все под рукой..
зато потом не приходится мучительно перкликивать весь интерфейс, проклиная дебила который куда то запихнул php код..
Был забанен на три дня за цитирование классика современности, поэтому молчал.
To gun_dose -
ну я вообще сотрудничаю с Яндексом, переписал например для себя их модуль Яндекс.Пингер, для своих нужд, их модуль слишком активно пингует, может и забанить, да и вообще всячески стараюсь пользоваться их API, и всем рекомендую, потому что Интернет - это их бизнес, увы, не наш. Их и гугла.
Я думаю ребята очень жалеют что проморгали facebook, надо же, кто то начинает серфинг в инере мимо их поисковиков...
обидно наверное.
По количеству - у меня есть работодатель, поэтому все решения - в одном экземпляре.
Рад за вас! Работа есть, значит и опыт и ум не за горами)))
Ну вот опять вас тянет на личности перейти.
то есть сейчас по вашему мнению я глуп? Ну хорошо. Но собственно вы ставите точку в дискуссии, вы ведь не станете общаться с глупым человеком?
Подождете ведь пока поумнею? Ок, я тоже подожду
Ну и подождём)) я тоже когда-то был глуп, я и сейчас в некоторых вещах не шарю. Главное - критику и альтернативные мнения записывать на кору больших полушарий. Ну не самых больших, а тех, что в голове))
To dga_studio:
проблема - в разграничении прав доступа и зон ответственности. Компании которые взяли себе друпал как SMC так или иначе выстраивают следующую организационную структуру:
1. Редактор материалов - свой сотрудник - имеет права доступа на добавление и редактирование материалов. Задача - обновлять сайт новостями, обзорами, прочее. Квалификация не предполагает никаких знаний в программировании.
Стоимость работы - учтена в зарплате.
2. Продвинутый пользователь, возможно даже - Администратор сайта. Как правило это еще свой сотрудник, продвинувший идею Друпал, увлекающийся человек. Стоимость работ - учтена в зарплате. Квалификация - все умеет через админку, кроме программирования и администрирования хостинга сайта.
3. программист - разработчик. Как правило приглашается со стороны, стоимость работ - договорная, дорого.
Теперь задача - все товары поступившие в последний месяц пометить плашкой новинка. А потом через месяц - все убрать.
Во первых кому поручить? За бесплатно и через два часа - своему продвинутому? или
один день искать фрилансера, торговаться, давать доступ чужому человеку к своему серверу, менять потом пароли, платить ему деньги...
а ведь вопрос то решается очень просто. Нет, вот сейчас точно модуль не нужен, и переопределение шаблонов - тоже.
Сейчас нужно простое решение своими силами.
И через php-filter задача решается оптимально, бесплатно, качественно.
Что касается боязни php в базе - соблюдайте меры безопаснсти и никто к вам никогда не пролезет.
Допустим вы хоститесь на таймвэбе. Супер. Через час максимум я буду знать технический домен вашего сайта.
А значит - имя пользователя БД, А значит я могу побутфорсить вас, если вы любитель паролей типа: логин drupal, пароль dupral
Так вот - не в php проблема - а в этом.
https://www.drupal.org/node/2315661
Это мнение не только мое
ну а если по существу ответить: в конкретно данных условиях, описанных выше, бесплатное решение задачи, за 2 часа (это сверхмаксимум), лучше чем за непонятные деньги и более чем за сутки, с необходимостью при этом давать доступ к своему серверу сторонним лицам.
Это очень некоректно писать пр другого человека гадости "за глаза". Про меня пишите, я то здесь.
Давате вернемся к началу дискуссии - вот ваш первый пост:
- Хранить исполняющий код в бд как минимум не безопасно. Где Вы начитались, что это правильно?
Вообще то еще раз, речь идет о конкретном php filter, который является частью core Drupal 7.
Из документации конечно я узнал как его использовать.
Автор views знал что писал, зачем и для кого.
https://www.drupal.org/u/merlinofchaos
Адмнистратор, который не владеет навыками программирования тем не менее в состоянии сформулировать вопрос:
ребятя напишите плиз на php условие что дата создания ноды больше чем месяц.
И конечно он сможет понять этот код поскольку он самоописываемый:
<?phpif ($node->created > date() - (30 * 24 * 60 *60){}
?>
и конечно сможет применить.
Самое важное и ценное здесь то, что сделать это можно через админку, активирвать через админку, убрать, изменить строки, верстку и все оставное. А для кода - вам ведь понадобиться еще и форму конфига писать, не так ли? чтобы срок менять, чтобы вкл-выкл...
И ваши 5 строк кода медленно превращаются, медленно превращаются (25 $ в час) в 5 т.р.
> нажать "Сохранить" и молиться, чтоб не белый экран)
Вы хоть раз пробовали положить в белый экран views? Нет?
Так вот:
1. Обращение к несуществующему методу
2. Обращение к несуществующему элементу массива
3. ОБращение к несуществующему свойству
4. Деление на ноль
Не приводят к белому экрану, единственное последствие - отсутствие вывода. То есть срабатывает Try catch блок.
5. Синтаксические ошибки - приводят к появлению диагностического сообщения во всплываыющем ajax-окне views
скриншот прилагаю (второй)
Попробуйте сами, и не придется выдумывать.
>Вести разработку сразу на продакшене - удел далеко не умных людей.
Согласен. Надеюсь вы так не делаете. Рекомендую VirtualBox.
Ну и напоминаю, что даже если на продакшене, по каким то уж очень неотложным причинам, все изменения во вьювс вступают в силу только после сохранения, а до сохранения запрос можно тестировать сколько угодно, в админке.
>Я понимаю, Вы никогда ещё в своей жизни не работали с крупными проектами с большой посещалкой,
Откуда у вас такое понимание?
Вернемся к вопросу:
Была поставлена маленькая жизненная задача.
Вот мое решение:
<?php
if ($row->created > date() - (30*24*60*60)) {
print '<img width="100" height="25" class="plashka" src="/sites/default/files/plashka.jpg" alt="Новый товар в последнем месяце">';
}
?>
и в скриншоте - как это сделать.
Жду вашего решения задачи. Потом обсудим результаты.
Я бы в данном случае, вместо поля Глобальный:PHP сделал поле Глобальный:Пользовательский с пустым выводом. Вывод бы переопределил во вьюшном шаблоне этого поля, написав ваш PHP-код.
Писать логику в шаблонах - это тоже костыль. Хотя я вот прямо сейчас сижу и делаю такое)))
Вот, о чем я и говорю,
переносить логику в шаблон - это взорвать мозг следующему админу.
Но допустим -а дальше?
Маркетолог говорит - срочно за пять минут изменить сроки новинок - 20 дней и 5 часов, все остальное отрезаем.
Views - он сам по себе уже админка, причем с тестовым выводом.
А темплэйт - это уже иной уровень ответственности и компетенции.
В 8-м Друпале php filter убрали из ядра, это говорит о росте популярности Друпала, и следовательно, о повышенных мерах защиты от "неумелого" применения.
ТО есть если понимаешь риски - подключай и пользуйся и бери те блага, которые естесственным образом за этим следуют.
Мне проще искать код в шаблонах в папке темы, чем открывать вьювы и искать там нужное поле. Описанное решение - временное, но это первый шаг. Я бы дальше сделал функцию is_novinka() и логику бы вынес в кастомный модуль, сделал бы админку для этого. Тогда бы менеджер сам мог менять сроки новинок.
Не канонично, согласен. Но тут речь идет о быстром решении. Я бы так сделал, а потом разбирался.
Это на каком языке?)))
Рашн-америкашн ))
1. напоминаю, что результат отработки view - он кэшируется. И с точки зрения поле или шаблон - разницы нет никакой, вообще. Это вопрос проектирования.
2. Вопросы производительности являются таким же элементом разработки, как и алгоритмизация и прочее и прочее и почти всегда индивидуальны.
3. Я не вижу связи между существованием в Drupa php filter и тем, над какими проектами я работал и какая у них посещаемость.
MODX Revo.
Весь пользовательский php - в базе.
Более миллиона скачиваний.
Вот интересный вопрос - хамские посты этого типа - Мyли25$/часГана - они здесь узаконены?
Господа!
Убедительная (читать "последняя") просьба завершить флуд!
Хотите дискутировать на эту тему - создавайте отдельный ТОП.
Дальнейшие проявления неуважения к собеседникам будут приравнены к
измене родиненарушению, с возможным баном.В целом, друпал довольно продуманная и цельная система, и качество кода весьма неплохое в целом, причём не только в ядре, но и в большинстве модулей, не только самых популярных, причём. Тут, как говорится, всё познаётся в сравнении.
Можно, конечно, ругать друпал за не использование ООП подхода, до недавних пор, но это не более чем холивар будет на самом деле - ООП отнюдь не "серебряная пуля".
Для того чтобы подумать о миграциях, надо бы сказать - "мы решили стать фреймворком, и пошли бы все эти пользователи, желающие самостоятельно понатыкать себе сайт - нам куда важнее разработчики!"
Понятно, что это я утрирую, но думаю, мысль понятна. Выбран простой и работоспособный метод с полями - этого вполне достаточно. И не будет лишних несовместимостей заодно, если очередной модуль-поле решит сделать миграцию ломающую другой модуль, сущности хорошо изолированы...
А что касается ООП, то зачем этим хвастать? OOП не какое-то офигенное достижение враз решающее все проблемы.
По мешанине - думаю постепенно её станет меньше в 9, например и далее.