Проверка isset($stars) бессмысленна, ибо значение вы получаете через variable_get, у variable_get второй аргумент - значение по умолчанию, в вашем случае - 5. То есть $stars всегда будет или значением variable, или 5.
Как влияет на производительность - лучше проверить. Это раз.
Поля, которые не используются действительно лучше удалять, дабы не было путаницы. Это два.
Зачатую во вьюхе лучше выводить не поля, а отрендеренную ноду в определенном вьюмоде, ибо если надо будет добавить вывод во вьюху это надо будет сделать только во вьюмоде, а не во всех вьюхах.
Смысл - давать доступ к файлам только при соблюдении определенных условий, например - только собственные файлы пользователя, скачивание файла только после оплаты доступа или заполнения формы, ещё что-то. Как-то так.
Тут вообще весь код непонятно как должен работать. Переменная $city_result не используется и затирается новым значением сразу после создания, а в settings каждый проход значение перезаписывается.
Аналогия:
Я использую на проекте гайки с левой резьбой. Везде всегда правая, а мне вот удобнее с левой. Часто ли вы встречаете, что на проект приходят люди, у которых все инструменты и документация на гайки с правой?
Правильный ответ - нечасто, но достаточно одного раза, чтобы перестать так делать.
Конкретно у меня - не скажу, что часто, но бывает. Вообще говоря ситуация реально не такая редкая. Разработку заказали в одном месте, а дальнейшую поддержку отдали на аутсорс. И можно оказаться с любой стороны.
Предполагается, что на сайте разработчики русско-понимающие.
В любой момент предположение может оказаться неверным. Из практики - доработка одного сайта, который делали поляки, которые предполагали, что на сайте разработчики польско-говорящие.
С кэшем дружить скорее всего не будет. Как вариант - наколдовать на js тупую проверку по ширине вьюпорта, если шире какого-то значения - забираем блок аяксом, если нет - ничего не делаем.
Правильно ли я понял, что при появлении поста в инстаграме нужно создавать ноду на сайте? Тогда скорее всего понадобится самописный модулёк, который тупо по крону будет дёргать API инстаграма и создавать ноду, если появились новые посты.
Чтобы пользователь сайта мог узнать об изменении правил ему всего-то надо, что зайти на гитхаб, найти открытый issue про Тёмную материю, в котором пункт 7 гласит, что "В правила «Модерация и ответственность» вносим соответствующие корректировки (будет отдельный issue)." С галочкой. И непонятно, когда эта галочка появилась.
Ммм. ИМХО, не совсем корректно уведомлять об изменениях в правилах на стороннем сайте. К тому же не помню я там упоминаний о внесении изменений в правила.
По дефолту, в хлебных крошках отображаются только те участки, которые есть в меню. Можно попробовать menu_trail_by_path, в простых случаях вполне достаточно.
У хука form_alter есть второй аргумент - $form_state. В данной переменной в $form_state['term'] лежит заглушка под термин, если форма для добавления, или же существующий термин, если форма для редактирования. В $form['#term'] какие-то значения лежат только в случае формы для редактирования.
Короче - проверяйте $form_state['term'], а не $form['#term']
Fivestar - проверка на наличие голосов
Проверка isset($stars) бессмысленна, ибо значение вы получаете через variable_get, у variable_get второй аргумент - значение по умолчанию, в вашем случае - 5. То есть $stars всегда будет или значением variable, или 5.
Как закешировать блок, внутри которого код php?
А вы залогиненым проверяете? Под админом кэша почти нет.
Предотвращение преобразования в html сущности CDATA (views rss)
У вас точно Drupal 8?
По идее, вам нужен hook_views_rss_feed_alter(&$rss_feed), в котором приблизительно
Классы транслитом. Почему нельзя?
На башкирском!
Вопрос по запросам к БД views
Во сколько раз быстрее? С кэшем или без? С entitycache или без? На 7-ке или 8-ке? Быстрее только запрос или весь рендеринг вьюхи?
Вопрос по запросам к БД views
Вопрос по запросам к БД views
Как влияет на производительность - лучше проверить. Это раз.
Поля, которые не используются действительно лучше удалять, дабы не было путаницы. Это два.
Зачатую во вьюхе лучше выводить не поля, а отрендеренную ноду в определенном вьюмоде, ибо если надо будет добавить вывод во вьюху это надо будет сделать только во вьюмоде, а не во всех вьюхах.
Не удается скрыть файлы в приватной директории
Смысл - давать доступ к файлам только при соблюдении определенных условий, например - только собственные файлы пользователя, скачивание файла только после оплаты доступа или заполнения формы, ещё что-то. Как-то так.
Не удается скрыть файлы в приватной директории
Надо запретить прямой доступ к папке на уровне веб-сервера.
Fivestar - проверка на наличие голосов
<?php
$votes = fivestar_get_votes('node',$node->nid);
Fivestar - проверка на наличие голосов
Приведенный вами фрагмент кода тоже не решает проблемы с ошибками. Зачем там два define?
Изменить адрес ноды при обращении к ней с определенной страницы
А можно сделать роут events/{year}/{month}/{day}/{title} для всех мероприятий и вообще ничего с урлом не делать.
Классы транслитом. Почему нельзя?
В таком случае, особым родом персонального ада должны быть бэм-классы кириллицей. =)))
Вывод массива
<?php
$city_titles = array();
foreach ($cities as $city) {
Вывод массива
Тут вообще весь код непонятно как должен работать. Переменная $city_result не используется и затирается новым значением сразу после создания, а в settings каждый проход значение перезаписывается.
Классы транслитом. Почему нельзя?
Аналогия:
Я использую на проекте гайки с левой резьбой. Везде всегда правая, а мне вот удобнее с левой. Часто ли вы встречаете, что на проект приходят люди, у которых все инструменты и документация на гайки с правой?
Правильный ответ - нечасто, но достаточно одного раза, чтобы перестать так делать.
Классы транслитом. Почему нельзя?
Конкретно у меня - не скажу, что часто, но бывает. Вообще говоря ситуация реально не такая редкая. Разработку заказали в одном месте, а дальнейшую поддержку отдали на аутсорс. И можно оказаться с любой стороны.
Классы транслитом. Почему нельзя?
В любой момент предположение может оказаться неверным. Из практики - доработка одного сайта, который делали поляки, которые предполагали, что на сайте разработчики польско-говорящие.
Вывод блока по условию
С кэшем дружить скорее всего не будет. Как вариант - наколдовать на js тупую проверку по ширине вьюпорта, если шире какого-то значения - забираем блок аяксом, если нет - ничего не делаем.
Drupal и Instagram
Правильно ли я понял, что при появлении поста в инстаграме нужно создавать ноду на сайте? Тогда скорее всего понадобится самописный модулёк, который тупо по крону будет дёргать API инстаграма и создавать ноду, если появились новые посты.
Обновление drupal.ru 07.08.2018: Внешний вид списков материалов и комментариев
Очень удобно.
Чтобы пользователь сайта мог узнать об изменении правил ему всего-то надо, что зайти на гитхаб, найти открытый issue про Тёмную материю, в котором пункт 7 гласит, что "В правила «Модерация и ответственность» вносим соответствующие корректировки (будет отдельный issue)." С галочкой. И непонятно, когда эта галочка появилась.
Обновление drupal.ru 07.08.2018: Внешний вид списков материалов и комментариев
Ммм. ИМХО, не совсем корректно уведомлять об изменениях в правилах на стороннем сайте. К тому же не помню я там упоминаний о внесении изменений в правила.
Обновление drupal.ru 07.08.2018: Внешний вид списков материалов и комментариев
Внезапно. И давно? Честно говоря не припомню, чтобы были какие-то уведомления об изменениях в правилах.
Хлебные крошки документов drupal 7
По дефолту, в хлебных крошках отображаются только те участки, которые есть в меню. Можно попробовать menu_trail_by_path, в простых случаях вполне достаточно.
Вывод терминов таксономии.
У хука form_alter есть второй аргумент - $form_state. В данной переменной в $form_state['term'] лежит заглушка под термин, если форма для добавления, или же существующий термин, если форма для редактирования. В $form['#term'] какие-то значения лежат только в случае формы для редактирования.
Короче - проверяйте $form_state['term'], а не $form['#term']