Ага, я так и написал: надо id набора полей сохранять в массиве-описании соответствующей кнопки. $item->fcid из приведенного кода, вероятно, подойдет.
Но, кстати, у использования hook_forms() и генерации множества одинаковых форм есть свои плюсы. Например, легко потом повесить аякс на сабмит каждой формы. Ну и движку не нужно будет тащить в form_state значения всех групп полей при сабмите только одной группы.
form_state['clicked_button']
A full copy of the button element that was clicked to submit the form. This is more reliable than the old $form_values['op'] name, and also carries any additional information that was placed in the button element's form definition.
Это с той же страницы, что Nikit в начале привел. По-моему так оно и делается. После обеда проверю.
Да не, он же вроде одну форму генерирует, а не несколько форм с одним набором обработчиков.
Там не нужны никакие дополнительные поля, селекты и баттоны, надо id набора полей сохранять в массиве-описании соответствующей кнопки, он будет передан в форм-стейт, надо только вспомнить, куда именно
Решал аналогичную задачу. Надо в кнопке сохранять какой-нибудь id, а потом при сабмите проверять. Точно не помню где он будет доступен, что-то вроде $form_state['submit'].
На орге об этом есть информация, поищите. Если не найдете, могу примерно после 15:00 посмотреть свой код.
НО! Можно поставить таймаут в 300 секунд (сейчас 60), включить рекламу для взрослых (ещё +десяток попапов) и можно отключить бесплатный вариант, оставив только СМС, минимальная цена 30р
Опять по новой. При чем сдесь «правильные» или «не правильные»? Ты с помощью виевс создаешь сниппет и вид тех данных, что он тебе выдаст. Так если ты возьмешь этот же, сформированный Виевсом код и просто переделаешь, его убрав зависимость от АПИ виевса. Что бы его можно было использовать потом «напряму», путем вставки в блок или код страницы, не суть. Что будет в результате более производительным?
Аргументов выше было предостаточно, кстати. Основной - здравый смысл, которы вы же сами и обозначили словами об очевидных преимуществах нативных решений.
теги в документах
*недоуменно*
Вы пользовались таксономией-то когда-нибудь? Создавали словари? Подключали их к типам содержимого?
теги в документах
Да похоже что это просто таксономия. Нет?
[РЕШЕНО] Первые эксперементы c видами. Нужна поддержка.
Не, если я правильно понял, не надо блок и страницу из блоков. Надо представление типа grid.
Не отображается сайт
??? С телефона что ли сайт делаешь?
Да, из-за этого. В сообщении даже сказано, где надо не забыть прописать пароль.
Проблема с пунктом таксономии
Собственно, что может быть проще, чем посмотреть, как оно сделано в движке? Из функции taxonomy_del_term():
[Решено]Скрыть отображение терминов
Через hook_nodeapi можно скрыть что угодно
CCK или Таксономия
Вообще то, что вы описали - это таксономия. Я бы в ней и делал.
Перевод меню, таксономии и прочих элементов
Internationalization
проблема создание ноды через модуль
Да, в hook_load() надо подгружать.
На drupal.org в handbooks есть руководство по программному созданию своего типа содержимого. Прочитайте - подобных вопросов больше не будет.
Москва-2010: регистрация на Drupalcamp
А есть какие-нибудь новости по проживанию? Когда деньги сдавать?
[РЕШЕНО] Таксономия: как сделать чтобы термин родитель отображал подтермины?
Легко решается. Поискали бы чуть-чуть по сайту, регулярно спрашивают.
А, ответ: taxonomy/term/1/all
Возможно ли создать ссылку из профиля на конкретный коммент?
Сделайте через views. Если не знаете, как - поставьте APK+Panels+Views, там это есть. Посмотрите, скопируйте.
Ну или оставьте даже APK, в нем прикольно профили сделаны.
Forms API - несколько кнопок submit.
Тут вроде речь про случаи с неизвестным/переменным числом кнопок.
Forms API - несколько кнопок submit.
Ага, я так и написал: надо id набора полей сохранять в массиве-описании соответствующей кнопки. $item->fcid из приведенного кода, вероятно, подойдет.
Но, кстати, у использования hook_forms() и генерации множества одинаковых форм есть свои плюсы. Например, легко потом повесить аякс на сабмит каждой формы. Ну и движку не нужно будет тащить в form_state значения всех групп полей при сабмите только одной группы.
Forms API - несколько кнопок submit.
Во, нашел.
Это с той же страницы, что Nikit в начале привел. По-моему так оно и делается. После обеда проверю.
Forms API - несколько кнопок submit.
Да не, он же вроде одну форму генерирует, а не несколько форм с одним набором обработчиков.
Там не нужны никакие дополнительные поля, селекты и баттоны, надо id набора полей сохранять в массиве-описании соответствующей кнопки, он будет передан в форм-стейт, надо только вспомнить, куда именно
Forms API - несколько кнопок submit.
Решал аналогичную задачу. Надо в кнопке сохранять какой-нибудь id, а потом при сабмите проверять. Точно не помню где он будет доступен, что-то вроде $form_state['submit'].
На орге об этом есть информация, поищите. Если не найдете, могу примерно после 15:00 посмотреть свой код.
Категорию из hook_user - в панель
APK крутой, но запрограммированную категорию не нашел. А author pane уже стоял, он не про это.
Как изменить запрос views
А почему без использования фильтров, напомните?
Как изменить запрос views
Да! ДА!!!
Как изменить запрос views
Как изменить запрос views
Как изменить запрос views
Это же друпал.ру. Считаю, что тут должен быть срач "Views vs. Сниппеты", а не про украинский язык или баны мдинка!
Где взять демо данные?
В смысле, сгенерировать тестовые ноды и пользователей? Модуль Devel.
Как изменить запрос views