26 сентября 2012 в 13:26
Искал простой метод вставить "дату последнего изменения на сайте" (именно сайта, а не текущей ноды), на форуме не нашел, предлагаю решение.
в template.php добавить функцию
<?php
/**
* Дата последнего обновления.
*/
function имя_темы_last_updated() {
// Взять из кеша, если он создан
if($cache = cache_get('имя_темы_last_updated')) {
$last_updated = $cache->data;
}
else {
// Если кеша нет, перебираем все ноды с базе
$last_updated = db_select('node', 'n')
->fields('n', array('changed'))
->condition('status', 0, '>') // учитывать только опубликованные
->orderBy('changed', 'DESC')
->range(0, 1)
->execute()
->fetchField();
// если опубликованных нод нет, возвращает FALSE.
if (!$last_updated) {
return FALSE;
}
// время хранения кэша -- сутки (60х60х24).
cache_set('имя_темы_last_updated', $last_updated, 'cache', time() + 86400);
}
return format_date($last_updated, 'medium', 'd.m.Y', NULL, NULL);
}
?>
вставить дату в нужное место темы или в блок
<?php print имя_темы_last_updated(); ?>
дата отформатирована в принятом у нас стандарте -- 26.09.2012
источник: http://drupal.stackexchange.com/questions/20022/how-can-i-display-the-la...
Комментарии
Жестокий интерпрайз с кешированием.
Вот и выросло поколение верящих в кеш...
Ну и комментарии ваши немного неверные
Тоже самое можно сделать просто Views'ом.
Фильтруем только ноды, упорядочиваем по дате обновления, ставим выводить только одну, выводим поле с датой последнего обновления.
на этом сайте у меня Views,а нет... не ставить же его ради одной даты.
в принципе был у меня еще вариант использовать блок "последние материалы" и темизацией перекорежить вывод. взять node_last_changed() вехней части списка, но сначала решил погуглить...
p.s. а что неверно в комментариях? я собственно не переводил, а по смыслу...
Просто, что вы будете брать значение из кеша, что вы будете делать новый запрос - выигрыша никакого.
Тем более, что вы ставите кеш равным целому дню, а выигрывате меньше, чем ползапроса (для справки посмотрите сколько даёт devel запросов на вашей главной странице). Для сайта, на котором последнее обновление в плюс-минус день не играет значения, зачем так заморачиваться?
$date = db_select('node', 'n')
->fields('n', array('changed'))
->condition('status', 1)
->orderBy('changed', 'DESC')
->execute()
->fetchField()
return format_date($date, 'custom', 'd.m.Y');
}
1. fetchCol вместо ->range(0, 1)->execute()->fetchField() (upd. исправил на fetchField без range)
2. опубликованы статус равен 1
3. в format_date ставьте custom, чтобы брался формат, указанный дальше (null'и по умолчанию стоят, их сократить можно).
upd. пересмотел api - medium можно оставить, он подхватывает формат в отличие от short и long, но логически правильно оставить custom
Я бы с этим поспорил.
range(0,1) туда вставлено для того чтобы в запросе был LIMIT 1, это позволит меньше строк читать мускулю.
В вашем случае, будет перебор строк.
Проверил по производительности
Результат 5000 запросов:
11.783607959747 - FetchCol
11.521826982498 - FetchField c range(0,1)
11.151861190796 - FetchField без указания range
FetchField c range(0,1) больше занимает времени, чем без указания range, так как по умолчанию там и так берётся одно значение. FetchCol в проигрыше, так как создаёт выходной массив.
Как-то так )) Милисекунды наше всё!
Спасибо за комментарии, буду использовать предложенный вариант
Здесь не в миллисекундах дело, а в прочитанных строках.
На маленьких таблицах, да ещё и 5000 подряд это естественно не будет иметь разницы.
Сделайте тоже самое, только с SQL_NO_CACHE, ощутите разницу