Такие предложения лучше, конечно, отдельной темой оформлять, чтобы можно было предметно обсуждать, т.к. текущий топик все ж немного об ином. Не первый раз возникает тема мобильного приложения. Но проблема в том, что каждый раз это звучит как идея ради идеи.
Попробуйте написать отдельный топик, где ответите развернуто на вопросы: в чем принципиальное отличие мобильного приложения от мобильной версии сайта? В чем ценность такого мобильного приложения для юзера (иначе говоря: почему он будет его скачивать и устанавливать)? Что необходимо сделать, чтоб «каждый на базе своего ls-проекта мог выкатить контентное мобильное приложение»?
Идеально было б это на конкретных примерах объяснить — взять какой-то конкретный сайт и на его примере дать ответы на вопросы.
Если вы задавали шаблон через админку, то эта настройка сохраняется в базе и в кеше конфига. И эти настройки имеют более высокий приоритет, чем заданные в конфиг-файле.
Чтобы после этого иметь возможность задавать шаблон через конфиг, нужно сделать следующее:
1) В базе в таблице ?_storage найти и удалить строку с ключом 'custom.config.router.view.skin'
2) Удалить файл /_tmp/cache/data/custom.cfg
После этого движок будет использовать шаблон, заданный в конфиге
Вообще-то, такая возможность есть и сейчас. Если мы хотим, чтобы по адресу profile/user показывались топики юзера, то достаточно в конфиг-файл app/config/config.local.php добавить такую настройку:
Трудно, конечно, въехать сразу, где тайтл — это тайтл, а где тайтл — это просто тайтл. Но повторю то, что уже есть в статье:
1) В конфиге можно задавать правила формирования тега <title>, как хотите. В т.ч. можете задать обязательную часть, а можете и не задавать.
2) С помощью плагина Seopack можно задавать абсолютно произвольные значения <title> без всяких правил, как левая нога захотела, на любых страницах сайта.
3) В дополнение к уже сказанному — есть еще конфиг-параметр view.name:
$config['view']['name'] = 'Your Site Name'; // название сайта
Он, как правило, выводится в шапке сайта, и он же обычно используется как часть тега <title>. Но это вовсе не обязательно и Вы можете на своем сайте настроить это, как угодно.
Давайте просто вместе доведем все до ума
Давайте. Только, желательно, делать свои предложения без эмоций, системно, и хоть как-то обосновывать.
1) В нынешней версии только с картинками, текста нет. Возможно, добавим в будущих версиях, если востребовано.
2) А «стопицот» это сколько? На невнятный вопрос трудно дать внятный ответ
3) Курсор на картинках появляется, видимо, потому, что картинка оборачивается в тег <a>. Согласен, что включение такой опции по умолчанию без возможности легко ее отключить было не вполне продуманным.
Суть такая: допустим, есть адреса «site.ru/a.html» и «site.ru/b.html», которые отображают один и тот же контент, но мы считаем, что «a.html» — это каноническая страница. Если мы ставим редирект с «a.html» на «b.html», то страницу «b.html» робот даже и не загружает, а сразу идет, куда нужно.
Если использовать rel=canonical на «b.html», то робот ее загрузит, распрасит, увидит директиву и на индексацию отдавать не станет. Но при этом Гугл оговаривает, что, теоретически, возможны какие-то баги, глюки и прочие обстоятельства, при которых страница «b.html» все же может случайно оказаться в индексе.
Поэтому редирект, конечно, более предпочтителен (т.к. исключает всякие случайности), но с точки зрения логики (как должна работать индексация) использование rel=canonical вполне достаточно.
Мда, что-то я все время упускаю этот момент. С nginx я как-то не очень дружу, но есть уверенность, что подобные же правила и там можно сформулировать. Причем, с одной стороны, чисто на nginx сидят те, кто юзает VPS/VDS (на шаред-хостинге не встречал я такого), значит, им доступны любые файлы конфигурации. С другой — они могут быть такими же чайниками, как и шаред-юзеры, и что-то править в конфигах (а не просто .htacces в корне сайта) для них может быть опасно.
При правильной верстке на самом сайте ссылок без слеша быть не должно, это верно. Но Алена права в том, что рано или поздно поисковик может узнать о вариантах и без слеша. Как решать эту проблему — на уровне .htaccess, на уровне конфига или аж на уровне экшенов — у меня нет пока хорошего рецепта.
И интересно — кто-нибудь изучал, как подобные проблемы решаются в других CMS?
Промаявшись полдня ощущением дежавю, таки восстановил картину мира, и вспомнил, что когда-то сам озадачивался уже такой темой, но так и не пришел ни к какому решению и вот почему.
Вот есть, например, это страница, где сейчас комментарии пишем. Какое значение ставить у last-modified? Учитывая, что есть сам топик, и к нему могут быть (а могут и не быть) комменты, то это либо дата создания топика, либо дата его редактирования, либо дата последнего комментария, либо дата редактирования комментария. В общем, одна из четырех дат (самая последняя существующая из них). Но есть еще и прямой эфир в сайдбаре — надо и оттуда дату проверять. Но есть еще и список блогов, есть виджет со списком плагинов. На других сайтах могут быть свои виджеты, и мы не можем наверняка знать, когда в последний раз обновились данные, которые в них отображаются.
В общем, получается, что сделать-то можно, но надо понимать, что тогда часть элементов на странице у юзеров будут обновляться с задержкой по времени. Для нагруженных проектов это может быть и допустимо, но вряд ли все владельцы сайтов этого захотят.
Попробуйте написать отдельный топик, где ответите развернуто на вопросы: в чем принципиальное отличие мобильного приложения от мобильной версии сайта? В чем ценность такого мобильного приложения для юзера (иначе говоря: почему он будет его скачивать и устанавливать)? Что необходимо сделать, чтоб «каждый на базе своего ls-проекта мог выкатить контентное мобильное приложение»?
Идеально было б это на конкретных примерах объяснить — взять какой-то конкретный сайт и на его примере дать ответы на вопросы.
Чтобы после этого иметь возможность задавать шаблон через конфиг, нужно сделать следующее:
1) В базе в таблице ?_storage найти и удалить строку с ключом 'custom.config.router.view.skin'
2) Удалить файл /_tmp/cache/data/custom.cfg
После этого движок будет использовать шаблон, заданный в конфиге
Аналогично можно на странице профиля по умолчанию показывать стену:
Это называется «внутренний редирект».
1) В конфиге можно задавать правила формирования тега <title>, как хотите. В т.ч. можете задать обязательную часть, а можете и не задавать.
2) С помощью плагина Seopack можно задавать абсолютно произвольные значения <title> без всяких правил, как левая нога захотела, на любых страницах сайта.
3) В дополнение к уже сказанному — есть еще конфиг-параметр view.name:
Он, как правило, выводится в шапке сайта, и он же обычно используется как часть тега <title>. Но это вовсе не обязательно и Вы можете на своем сайте настроить это, как угодно.
Давайте. Только, желательно, делать свои предложения без эмоций, системно, и хоть как-то обосновывать.
2) А «стопицот» это сколько? На невнятный вопрос трудно дать внятный ответ
3) Курсор на картинках появляется, видимо, потому, что картинка оборачивается в тег <a>. Согласен, что включение такой опции по умолчанию без возможности легко ее отключить было не вполне продуманным.
Если использовать rel=canonical на «b.html», то робот ее загрузит, распрасит, увидит директиву и на индексацию отдавать не станет. Но при этом Гугл оговаривает, что, теоретически, возможны какие-то баги, глюки и прочие обстоятельства, при которых страница «b.html» все же может случайно оказаться в индексе.
Поэтому редирект, конечно, более предпочтителен (т.к. исключает всякие случайности), но с точки зрения логики (как должна работать индексация) использование rel=canonical вполне достаточно.
Надо думать…
Только его нужно его добавить ДО переадресации на index.php
Почему-то мне кажется, что это более верный подход
И интересно — кто-нибудь изучал, как подобные проблемы решаются в других CMS?
Вот есть, например, это страница, где сейчас комментарии пишем. Какое значение ставить у last-modified? Учитывая, что есть сам топик, и к нему могут быть (а могут и не быть) комменты, то это либо дата создания топика, либо дата его редактирования, либо дата последнего комментария, либо дата редактирования комментария. В общем, одна из четырех дат (самая последняя существующая из них). Но есть еще и прямой эфир в сайдбаре — надо и оттуда дату проверять. Но есть еще и список блогов, есть виджет со списком плагинов. На других сайтах могут быть свои виджеты, и мы не можем наверняка знать, когда в последний раз обновились данные, которые в них отображаются.
В общем, получается, что сделать-то можно, но надо понимать, что тогда часть элементов на странице у юзеров будут обновляться с задержкой по времени. Для нагруженных проектов это может быть и допустимо, но вряд ли все владельцы сайтов этого захотят.