Добрый!

Кто-нибудь удалял таблицы field_revision_* в D7 или это совсем не вариант для стабильной работы?

Насколько я понял, модули в духе Field SQL norevisions просто чистят таблицы.

На drupal.org есть ветки, но достаточно старые и без конкретных ответов на сабж.

p.s. Не надо, пожалуйста, спрашивать и делиться мыслями зачем их вообще удалять. Лучше промолчать.

Добрый день!

Работаю с Views 3.11 (Drupal 7), нужно в шаблоне использовать кастомное поле, допустим, field_address.
Когда это поле добавляю в fields.

В шаблоне
print_r($row) выглядит:
...
[field_data_field_address_node_entity_type] => node
...
[_field_data] => Array
(
[nid] => Array
(
[entity_type] => node
[entity] => stdClass Object
(
и начинаются данные ноды по всем полям.
}

Как бы не колдовал с выводом, пробовал с разными полями, всегда грузится _field_data.
Можно этого избежать и грузить в $row или в $fields чисто мое поле?

В модуле используется hook_menu, есть item

$items['mobile'] = array(
'title' => 'my test',
'access arguments' => TRUE,
'page callback' => 'my_page_callback',
'type' => MENU_CALLBACK,
);

страница /mobile доступна - все ок.
Только она же будет открываться по урлам /mobile/fgdfgfdg /mobile/eegfgd/dfgdfg и.т.д.

Кто-нибудь стандартный способ этого избежать?
У некоторых стандартных модулей поведение точно такое же с внутренними страницами.

В интерфейсе есть необходимость получать в коде английский оригинал фразы по русскому переводу.

Например:

print t('Район');

-> District

Использовать везде английские фразы, вариант понятный, но не подходящий по задаче.

В документации t() есть игра с параметром языка, но непонятно как он работает.
t('Район',array(),'en') то что нужно не возвращает.

В интернетах ответа не нашел.

Спасибо!