Если не задумываясь все файлы копировать, то да. И так всегда было. Если меняете тексты в папке templates/language, то берегите эти файлики при обновлении
Но вряд ли через админку. Невозможно заранее предусмотреть, что кому-то потребуются «бухтелки, терки, чтиво». Поэтому все больше склоняюсь к языковым «патчам» (или «заплаткам»), которые будут работать так же, как сейчас работает файл конфигурации config.local.php. Этот файл переопределяет лишь часть значений общего конфига. Точно так же языковой патч — отдельный файл, который админ сайта может создать и положить в определенное место — будет перекрывать часть общих текстовок.
Захотели вместо блогов писать «терки», а вместо топиков — «предъявы» — создаете небольшой файл, где переписываете лишь отдельные тексты. Тогда и при обновлении движка не возникнет проблем
Вопрос не так прост, как это могло бы показаться. Особенно, если абстрагироваться от ЛС.
Людей, ведущих в инете активную жизнь, мне кажется, особо не смущает ни «топик», ни «пост». Термин «топик» чаще используется на форумах (и в ЛС-сообществе). А «пост» — более блоговый термин. Но если вы создаете ресурс для людей, как один мой знакомый выражается, «не очень интернетных», то оба эти термина их сбивают с толку. Поэтому и был принят термин «статья» (хотя в обсуждениях очень часто по инерции говорим о «топиках»).
И еще одно важно замечание: Альто — НЕ блоговый движок. Это многофункциональный движок общего назначения. И «блоги» — это механизм структурирования контента. Например, в одном из проектов, который я делал, нет никаких персональных блогов, а блоги коллективные переименованы в «разделы», топики — в «статьи». Т.е. есть сайт, на нем есть разделы, в которых публикуются статьи. И юзеры легко и просто эту терминологию приняли.
Но тут вряд ли можно придумать какой-то универсальный рецепт. Допускаю, что может быть даже несколько локализаций (наборов текстов) на одном языке, даже на русском. Либо стоит подумать о том, чтоб можно было подгружать «языковые патчи» — небольшие наборы фраз, которые частично перекрывают общий набор текстовок.
1. Отключение персональных блогов — да, востребованная вещь. И есть еще мысль сделать опциональным автосоздание персонального блога. Т.е. он создается только тогда, когда юзер в него пишет. В одном из проектов реализовывал это. Или, как выше писалось, сделать создание персональных блогов явным, как и все блоги. Создай, а потом пиши.
2. Есть в планах
3. А это, наверное, только админам надо? Вряд ли рядовой юзер будет заполнять метатеги
4. Это обязательно. С виджетами вообще самая главная сложность — как все возможности, доступные через конфиг, запихнуть в простой и интуитивно понятный интерфейс.
Сдается мне, дельное замечание. Достаточно оставить лишь число читателей для информации, и там все равно есть ссылка Все читатели блога — вот ее и оставить, убрав перечень. Кому надо — посмотрят полный список. И нагрузка на базу чуть-чуть сократиться, наверное
Поделюсь планами по развитию плагина, думаю, это снимет все вопросы:
* настройка, какие графики вынести на главную админки, а все доступные графики показывать на отдельной странице админки
* настройка, какие графики показывать внешним юзерам, а в перспективе — создание виджетов, которые можно включать, куда угодно — страницы, топики и т.д.
* вставку счетчика Метрики совместить с настройкой плагина, т.е. получил код счетчика Яндекса и в настройках плагина его сразу и добавил, не залезая в исходники
Альто за собой тянет, в первую очередь, совместимость с ЛС с программной точки зрения и возможность легкого переезда. На это реально тратится много ресурсов.
Что касается юзабилити и интерфейсов вообще, то мы открыты к предложениям. Только тут очень важны конкретные предложения, которые можно рассматривать и, если они удачны, внедрять. Предложения Алены здесь — интересны и заслуживают внимания. В параллельной ветке идет обсуждение концепта — altocms.ru/29.html И за ним внимательно смотрим.
И чем больше подобных предложений и обсуждений будет — тем лучше, у команды проекта, разумеется, полно своих идей, но мы не хотим вариться в собственном соку. Поэтому рассуждения об ущербности наследия ЛС в этом не очень конструктивны, гораздо эффективней будут конкретные предложения о том, как и куда двигаться.
С одной стороны, поддомен для каждого города не самое выгодное решение, но, с другой стороны, как пользователю при посещении сайта сразу показать исключительно те афиши, которые касаются мероприятий в его городе
А тут, на мой взгляд, с технической точки зрения не играет принципиальной роли, показывать ему афишу на gorodok.site.ru или на site.ru/city/gorodok/. Первый вариант, возможно, чуть-чуть удобнее для набирания адреса руками. Но так ли часто адрес руками будет набираться?
И не совсем понятно, что значит без «гео-фильтрации»? Без нее можно только в одном случае — если у Вас по каждому городу отдельная база (или на каждый город свои наборы таблиц со своими префиксами). Тогда да, наверное, проще вешать города на отдельные домены и там цеплять свои базы и с ними работать.
Но если все в одной базе и все события в одной таблице, то фильтровать все равно ведь придется. И тогда правильнее, думаю, другой вариант будет — спрашивать юзера, где он живет и для авторизованных включать какие-то глобальные фильтры, по которым все отфильтровывать, с возможностью эти фильтры отключать/переключать. И при таком подходе вообще не нужно город указывать в URL, ни в поддомене, ни в папке
Во-первых, с префиксом таблиц есть баг, это верно. В SQL-выражениях должно быть «alto_», а не «prefix_», упустил я этот момент при генерации sphix.conf. Сейчас исправил в плагине, но у Вас правильно уже стоит.
Теперь давайте дальше разбираться. Префикс данных Сфинкса, как я вижу у Вас в sphix.conf в третьей секции стоит «ptzmedia», и индексируемая хрень складывается в /var/lib/data. Значит, в /plugins/sphinx/config/config.php должно быть так:
И если всю папку engine обновили, то ошибки Сфинкса должны логгироваться. Если поиск не заработает — смотрите в админке в разделе «Ошибки системы», там Сфинкс должен ошибки отложить, которые натолкнут на мысль, куда копать
Первый раз с такой просьбой встречаюсь. Но мало сделать заголовок необязательным, нужно придумать, что же будет взамен. Ведь заголовок топика — это еще и прямая ссылка на топик, и текст ссылки не может быть пустым. И место, где сейчас заголовок, не может быть пустым — т.е. надо еще шаблоны править
Если файл config/config.php не трогали, то достаточно оставить config/config.local.php. Если какие-то плагины ставили и настраивали, то их файлы конфигурации тоже стоит сохранить
Напр., если в шаблоне задать {router page='page'}about/, то получим ссылку site.com/page/about/, а если так: {router page='page'}/about/, то получим ссылку с двойным слешем: site.com/page//about/.
Или если в шаблоне будет {cfg name='path.root.url'}/dir/, то опять получим двойной слеш: site.com//dir/
В общем, смотреть нужно. Впрочем, не исключаю, что и в движке где-то еще может остаться не совсем корректное формирование URL, приводящее к двойным слешам
Слеш в конце путей был добавлен по моей инициативе. И я сейчас объясню, почему.
Нет времени искать ссылку на первоисточник, но, согласно правилам формирования URL, ссылки на папки/директории должны оканчиваться слешем. Если слеша нет, но считается что URL указывает на файл: site.com/abc/ — ссылка на папку /abc/ site.com/abc.txt/ — ссылка на папку /abc.txt/ site.com/abc — ссылка на файл /abc site.com/abc.txt — ссылка на файл /abct.xt
Конечно, это правило соблюдается далеко не всеми и далеко не всегда, поэтому современные веб-сервера учитывают это разгильдяйство сайтописателей, и если получают запрос на URL без слеша на конце, то сначала сервер смотрит — есть ли такой файл. Если есть — отдает его, если нет, то редиректит запрос на точно такой же URL, но со слешем на конце.
Более того, где-то встречал рассуждения, что если используются ссылки без слеша на конце, то по факту браузер шлет два запроса на сайт, сначала оригинальный, а потом — со слешем, и сервер, соответственно, в итоге обрабатывает два запроса вместо одного.
Итого — мое глубокое убеждение, что ссылки на папки (или «псевдопапки», как в LS, в Alto и других MVC-движках) должны заканчиваться слешем.
Двойной слеш, который иногда наблюдается, это побочный эффект от «наследства» LiveStreet'а. От него, разумеется, нужно избавляться (и мы избавляемся), но не удалением слеша в путях, а правкой шаблонов.
Захотели вместо блогов писать «терки», а вместо топиков — «предъявы» — создаете небольшой файл, где переписываете лишь отдельные тексты. Тогда и при обновлении движка не возникнет проблем
Людей, ведущих в инете активную жизнь, мне кажется, особо не смущает ни «топик», ни «пост». Термин «топик» чаще используется на форумах (и в ЛС-сообществе). А «пост» — более блоговый термин. Но если вы создаете ресурс для людей, как один мой знакомый выражается, «не очень интернетных», то оба эти термина их сбивают с толку. Поэтому и был принят термин «статья» (хотя в обсуждениях очень часто по инерции говорим о «топиках»).
И еще одно важно замечание: Альто — НЕ блоговый движок. Это многофункциональный движок общего назначения. И «блоги» — это механизм структурирования контента. Например, в одном из проектов, который я делал, нет никаких персональных блогов, а блоги коллективные переименованы в «разделы», топики — в «статьи». Т.е. есть сайт, на нем есть разделы, в которых публикуются статьи. И юзеры легко и просто эту терминологию приняли.
Но тут вряд ли можно придумать какой-то универсальный рецепт. Допускаю, что может быть даже несколько локализаций (наборов текстов) на одном языке, даже на русском. Либо стоит подумать о том, чтоб можно было подгружать «языковые патчи» — небольшие наборы фраз, которые частично перекрывают общий набор текстовок.
2. Есть в планах
3. А это, наверное, только админам надо? Вряд ли рядовой юзер будет заполнять метатеги
4. Это обязательно. С виджетами вообще самая главная сложность — как все возможности, доступные через конфиг, запихнуть в простой и интуитивно понятный интерфейс.
Все же блог с топиками/статьями — это не твитер, это несколько иная среда. Если нужно что-то более твитерообразное, то это — стена
* настройка, какие графики вынести на главную админки, а все доступные графики показывать на отдельной странице админки
* настройка, какие графики показывать внешним юзерам, а в перспективе — создание виджетов, которые можно включать, куда угодно — страницы, топики и т.д.
* вставку счетчика Метрики совместить с настройкой плагина, т.е. получил код счетчика Яндекса и в настройках плагина его сразу и добавил, не залезая в исходники
Что касается юзабилити и интерфейсов вообще, то мы открыты к предложениям. Только тут очень важны конкретные предложения, которые можно рассматривать и, если они удачны, внедрять. Предложения Алены здесь — интересны и заслуживают внимания. В параллельной ветке идет обсуждение концепта — altocms.ru/29.html И за ним внимательно смотрим.
И чем больше подобных предложений и обсуждений будет — тем лучше, у команды проекта, разумеется, полно своих идей, но мы не хотим вариться в собственном соку. Поэтому рассуждения об ущербности наследия ЛС в этом не очень конструктивны, гораздо эффективней будут конкретные предложения о том, как и куда двигаться.
И не совсем понятно, что значит без «гео-фильтрации»? Без нее можно только в одном случае — если у Вас по каждому городу отдельная база (или на каждый город свои наборы таблиц со своими префиксами). Тогда да, наверное, проще вешать города на отдельные домены и там цеплять свои базы и с ними работать.
Но если все в одной базе и все события в одной таблице, то фильтровать все равно ведь придется. И тогда правильнее, думаю, другой вариант будет — спрашивать юзера, где он живет и для авторизованных включать какие-то глобальные фильтры, по которым все отфильтровывать, с возможностью эти фильтры отключать/переключать. И при таком подходе вообще не нужно город указывать в URL, ни в поддомене, ни в папке
Теперь давайте дальше разбираться. Префикс данных Сфинкса, как я вижу у Вас в sphix.conf в третьей секции стоит «ptzmedia», и индексируемая хрень складывается в /var/lib/data. Значит, в /plugins/sphinx/config/config.php должно быть так:
И если всю папку engine обновили, то ошибки Сфинкса должны логгироваться. Если поиск не заработает — смотрите в админке в разделе «Ошибки системы», там Сфинкс должен ошибки отложить, которые натолкнут на мысль, куда копать
Напр., если в шаблоне задать {router page='page'}about/, то получим ссылку site.com/page/about/, а если так: {router page='page'}/about/, то получим ссылку с двойным слешем: site.com/page//about/.
Или если в шаблоне будет {cfg name='path.root.url'}/dir/, то опять получим двойной слеш: site.com//dir/
В общем, смотреть нужно. Впрочем, не исключаю, что и в движке где-то еще может остаться не совсем корректное формирование URL, приводящее к двойным слешам
Нет времени искать ссылку на первоисточник, но, согласно правилам формирования URL, ссылки на папки/директории должны оканчиваться слешем. Если слеша нет, но считается что URL указывает на файл:
site.com/abc/ — ссылка на папку /abc/
site.com/abc.txt/ — ссылка на папку /abc.txt/
site.com/abc — ссылка на файл /abc
site.com/abc.txt — ссылка на файл /abct.xt
Конечно, это правило соблюдается далеко не всеми и далеко не всегда, поэтому современные веб-сервера учитывают это разгильдяйство сайтописателей, и если получают запрос на URL без слеша на конце, то сначала сервер смотрит — есть ли такой файл. Если есть — отдает его, если нет, то редиректит запрос на точно такой же URL, но со слешем на конце.
Более того, где-то встречал рассуждения, что если используются ссылки без слеша на конце, то по факту браузер шлет два запроса на сайт, сначала оригинальный, а потом — со слешем, и сервер, соответственно, в итоге обрабатывает два запроса вместо одного.
Итого — мое глубокое убеждение, что ссылки на папки (или «псевдопапки», как в LS, в Alto и других MVC-движках) должны заканчиваться слешем.
Двойной слеш, который иногда наблюдается, это побочный эффект от «наследства» LiveStreet'а. От него, разумеется, нужно избавляться (и мы избавляемся), но не удалением слеша в путях, а правкой шаблонов.