Я согласен, что это проблема. Мне только не нравится идея на откуп автору топика способ вывода комментов отдавать. По-моему, это может юзеров дизориентировать — тут такой вывод, здесь эдакий.
Но, повторюсь, проблема существует, будем думать, как решать ее
1-2. Группы, конечно, нужны, но на начальном этапе можно объединить п.1 и 2. Т.е. продумать права админов и модераторов блогов, и расширить их. А то сейчас они действительно какие-то кастрированные.
3. Никогда не понимал, почему надо сначала вступить в блог, чтоб написать в него, имхо, юзер должен иметь возможность писать в любой блог, который ему доступен, без всяких лишних телодвижений. Насчет специальной кнопки не уверен, возможно, просто при создании топика текущий блог должен по умолчанию подставляться.
5. Есть сомнения, что это хорошая идея — разные топики с разным способом структурирования комментов
Я сказал уже, что мусолить эту тему дальше не вижу смысла. Функционал, отключающий получение информации с сервера Alto CMS, как архиважный, уже реализован в девелоперской версии.
Короткую ссылку получилось добавить быстрее, чем я предполагал. Сейчас в девелоперской версии в режиме редактирования топика добавилась кнопка «Получить короткую ссылку».
Для каждого топика действует ссылка вида: site.com/t/123/
Второй вариант, раз уж свои админы, свои страницы, свой дизайн — это скорее уже мультисайтовая система, когда один экземпляр движка используется на нескольких поддоменах.
Да вот в том и дело, что у разных людей разное представление, чего выносить в поддомены. Поэтому и хотелось бы понять, кому чего нужно. Мне лично кажется странным выносить на поддомен чисто пользовательский профайл, но, возможно, кому-то это действительно нужно, я не знаю.
Я сейчас больше склоняюсь к тому, что нужен функционал, который позволит вешать на поддомен что угодно. Т.е. прописываешь что-то типа:
%text%.site.com => site.com/profile/%text%
или
%text%.site.com => site.com/blog/%text%
… и радуешься жизни :) Если какого-то специфичного функционала не нужно, а достаточно отображения на поддомен стандартных экшенов, то это самое оптимальное решение будет.
Но в любом случае, это нужно плагином делать, функционал довольно специфичен, явно большинству он не пригодится, поэтому не стоит движок перегружать
Только есть один вопрос, где находиться файл обрабатывающий текст для ЧПУ?
Вообще, в движке есть описания используемых языков и локалей, они лежат здесь: engine/lib/external/UserLocale/i18n/
И там же для любого языка можно задать правила транслитерации. Сейчас эти правила заданы для языков ru (русский), uk (украинский), be (белорусский), bg (болгарский). Я постарался составить эти правила так, чтоб они подходили если не для всех, то для большинства языков, основанных на кириллице. В PHP нормально работает транслитерация для многих языков на основе латиницы (напр., умляуты в немецком), а вот кириллические тексты не умеет переводить в транслитерацию, поэтому приходится использовать правила транслитерации, где кириллическим символам ставится в соответствие латиница.
Кстати, будем премного благодарны, если кто-то решит добавить описания новых языков, или дополнит имеющиеся.
Насчет перевода символа S в символ Z — это была ошибка в правиле транслитерации, сейчас исправили
Вообще-то, любое предложение, оканчивающееся знаком вопроса — это вопрос. И тут в коментах они не риторические, а вполне конкретные. И ты не ответил ни на один мой вопрос. Но сейчас это уже неважно, ниже объясню, почему.
есть понятие «политика конфиденциальности», некоторые сайты даже про установку куков уведомляют пользователей. хотя это вполне нормальная и обыденная вещь. важно открыто предоставить такую информацию.
Очень хорошо понимаю, что такое «политика конфиденциальности» в отношении сайта/сервиса. А что это применительно к движку — не знаю. Что-то не припомню такого применительно к движку (не к сайту!!!) Wordpress, Joomla, Drupal. Все они (во всяком случае WP и Joomla точно, насчет Друпала не помню наверняка) подгружают в админке инфу с официальных сайтов и проверяют установленную версию, чтобы предложить обновиться. И это без всякого согласия с какой-либо «политикой». И, согласись, опираться на опыт работы этих CMS больше оснований, чем на опыт LS. Более того, было 100500 просьб от самих юзеров, чтоб сам движок проверял актуальность версии как ядра, так и плагинов, и позволял бы в один клик (условно говоря) ставить обновления. Мы в этом направлении и работаем. Но как я уже сказал выше — обязательно сделаем эту опцию отключаемой.
Почему такая бурная реакция на нормальный вопрос?
Могу легко это объяснить:
1) Вопрос был опубликован не в блоге «Вопросы», что было бы логичным, а в блоге с максимальным рейтингом.
2) Текст подан подан так, что у людей, не анализирующих внимательно код, может сложиться ложное представление, будто на сервер отправляется какая-то статистика об их сайтах, и проводится явная аналогия с ЛС, что является в корне неверным.
3) В вопросе речь идет об идентификации сайта, что опять же есть неправда.
4) Сама формулировка вопроса «почему нельзя...?» выглядит несколько странной — любому более-менее вменяемому разработчику ясно, что можно.
5) Наконец, мы оба знаем о некоих «экспериментах по социальной инженерии»
Любой из этих факторов в отдельности не вызвал бы у меня никакой особой реакции (максимум — удивление). Но все вместе в одной точке они как бы навевают на некоторые нехорошие мысли.
Но мусолить дальше эту тему я смысла не вижу. Поэтому предлагаю считать все это лишь недоразумением. Я готов согласиться с тем, что ты был просто неточен в формулировках, а я не вполне верно тебя понял. А на самом деле ты предположил, что каким-то админам сайтов на Альто совсем неважно знать, актуальны ли у них версии самого движка и плагинов, а посему нужно сделать эту опцию отключаемой. Ок, я тебя услышал — сделаем.
Если будут еще какие-то предложения — пожалуйста, высказывай, нам очень важен фидбек, но, желательно делать это более корректно, чтоб это не вызывало двусмысленного толкования.
Во-первых, если у нас диалог, то предлагаю отвечать на задаваемые вопросы. Думаю, это будет честно. Если нет желания отвечать на вопросы — давай закроем дискуссию.
Во-вторых, идентификатор — это признак, который позволяет однозначно идентифицировать объект. Каким образом можно идентифицировать сайт по уникальному ключу?
Наконец, раз возник такой разговор вообще, то для особо параноидальных юзеров сделаем опцию отключения всех информеров — это ни разу не проблема (хотя я, например, не увидел, где такое отключается в WP, как, впрочем, не видел и рассуждений на тему «WP следит за нами!»)
Вы же видели реакцию окружающих на внедрение похожего ф-ла в ЛС
Извини, Сергей, но это уже откровенная туфта. Я не знаю, как это иначе назвать и искренне не понимаю, зачем тебе это нужно.
Давай сравним «похожий» (как ты утверждаешь) функционал.
Что имеем в ЛС:
— внедрение счетчика, который фиксирует URL всех страниц сайта, сделанного на ЛС, по которым бродят юзеры
— отправка на сервер ЛС явной информации о реальном домене и используемом скине сайта
Что имеем в Альто:
— для сайта генерируется уникальный код с многократным вложением md5 и sha1, да еще с «солью» (которая, как правило, отличается на разных сайтах), т.е. информация о сайте (о его домене/адресе) в принципе не может быть получена никаким способом!
Т.е. в одном случае — вполне конкретная информация, однозначно идентифицирующая не только сайт, но и отслеживающая поведение юзеров на нем, в другом — некий абстрактный код, который вооще никак ни разу не указывает на что-то конкретное.
И давай теперь покажи, где тут «похожесть»?
На вопрос «зачем» отвечу: задача стоит лишь в кешировании данных. У нас весьма амбициозные планы, и я не вижу смысла дергать сервак буквально по каждому запросу.
Я доступно излагаю?
Для чего еще можно юзать ключ, который абсолютно никак нельзя увязать с каким-либо конкретным сайтом — я лично не могу представить. Если есть соображения, что как-то может быть раскрыта информация о сайте — поделись, как. И тогда вместе подумаем, как этого избежать.
Юзером pixellife был задан вопрос именно относительно «курл-не-курл» (см. его топик по ссылке выше), и я конкретно на него ответил. Что тут неожиданного?
Суть вопроса я понял. И согласен, что это нужно, и это один из вопросов, зачем нужен нормальный механизм редиректа, о котором выше написал. Обязательно посмотрю, как это в WP сделано
Вопрос — при редактировании статьи можно будет получить короткую ссылку — которая всегда будет вести на статью, даже если ее ЧПУ ссылка изменится?
Пока такого нет. Хотя, нет, если быть более точным — есть такое, но не рекомендуется к использованию. Потому что это источник дублей страниц для поисковиков, что не очень хорошо.
В движке планируется реализовать механизм редиректа, когда скажем, есть у страницы полный URL, который будет индексироваться, и короткий, который будет не внутри движка «шаманить» и выдавать страницу, а формировать нормальный редирект на постоянный адрес с кодом 301. Тогда и людям будет просто оперировать короткими адресами, и поисковики не будут индексировать ничего лишнего
Весь код движка открыт. Все CURL-функции начинаются с префикса curl_ (см. www.php.net/manual/ru/book.curl.php). Поэтому подозрения решаются элементарно: выполняется поиск по всему проекту на наличие CURL-функций. Пожалуйста, найдите время, сделайте такое дело, и, если не трудно, сообщите о результатах
Сергей, а для чего нужно постить топик в заведомо неверный блог и при это формулировать вопрос в духе «желтой прессы», формируя у людей заведомо ложное представление? Я бы понял, если б такой вопрос исходил от нуба, который не может разобраться в коде движка, но не ожидал этого от профи, вроде тебя. Или это очередное твое мероприятие в духе социальной инженерии?
Еще раз повторю, на всякий случай, чтоб не было неясностей и инсинуаций:
1) в Альто не втыкается свой счетчик на все страницы, как в это делается в ЛС
2) в Альто не отправляется куда-то никакая статистика по сайту, ни название сайта, ни используемый скин, как в ЛС
3) в Альто не используются никакие «секретные» запросы с использованием CURL-функций (у нас вообще нет кода, где бы эти функции вызывались, и ни в одной из сторонних библиотек, используемых в проекте, я подобных функций не обнаружил).
И, как выше уже было сказано, в Альто есть подгрузка новостей в админке, как это сделано, например, в Wordpress.
Если звезды удачно сойдутся, то следующий релиз выйдет в третьей декаде мая. Многое из того, что планировалось реализовать в базовой версии, либо уже сделано, либо скоро будет сделано. Но могут быть, конечно, и «нежданчики», которые немного оттянут релиз на более поздний срок. Но вряд ли задержка будет существенной.
Что касается обновлений — если у Вас сайт только в стадии разработки, то можно обновляться и с гитхаба. Во всяком случае, будете в курсе всех нововведений и добавляемых фич и сможете учесть это в процессе работы над сайтом. Понятно, что могут быть в девелоперской версии какие-то баги и недочеты, но сама по себе версия вполне рабочая. Если же сайт уже рабочий, и им активно пользуются юзеры, то не стоит их травмировать частыми обновлениями, и лучше подождать официального релиза.
Я писал уже, что бывают разные варианты, и у разных сайтостроителей могут быть разные потребности. Например, для кого-то достаточно смены языка интерфейса, а вот фильтрация контента по языку может быть нежелательной. А кто-то создает, фактически, разные версии сайта под разные языки. Встречался мне вариант, когда владелец сайта хотел статические страницы делать под разные языки и выдавать соответствующую языковую версию страницы в зависимости от языка, выбранного юзером, а вот топики разноязычные по его замыслу должны были одной лентой идти, с указанием языка, и юзер сам мог доп.фильтр включать/выключать.
Поэтому и решено было в самом движке лишь базовый функционал реализовать, а навороты оставить для плагинов
Но, повторюсь, проблема существует, будем думать, как решать ее
3. Никогда не понимал, почему надо сначала вступить в блог, чтоб написать в него, имхо, юзер должен иметь возможность писать в любой блог, который ему доступен, без всяких лишних телодвижений. Насчет специальной кнопки не уверен, возможно, просто при создании топика текущий блог должен по умолчанию подставляться.
5. Есть сомнения, что это хорошая идея — разные топики с разным способом структурирования комментов
Насчет остального — надо подумать
Тему закрываю.
Для каждого топика действует ссылка вида: site.com/t/123/
Я сейчас больше склоняюсь к тому, что нужен функционал, который позволит вешать на поддомен что угодно. Т.е. прописываешь что-то типа:
%text%.site.com => site.com/profile/%text%
или
%text%.site.com => site.com/blog/%text%
… и радуешься жизни :) Если какого-то специфичного функционала не нужно, а достаточно отображения на поддомен стандартных экшенов, то это самое оптимальное решение будет.
Но в любом случае, это нужно плагином делать, функционал довольно специфичен, явно большинству он не пригодится, поэтому не стоит движок перегружать
engine/lib/external/UserLocale/i18n/
И там же для любого языка можно задать правила транслитерации. Сейчас эти правила заданы для языков ru (русский), uk (украинский), be (белорусский), bg (болгарский). Я постарался составить эти правила так, чтоб они подходили если не для всех, то для большинства языков, основанных на кириллице. В PHP нормально работает транслитерация для многих языков на основе латиницы (напр., умляуты в немецком), а вот кириллические тексты не умеет переводить в транслитерацию, поэтому приходится использовать правила транслитерации, где кириллическим символам ставится в соответствие латиница.
Кстати, будем премного благодарны, если кто-то решит добавить описания новых языков, или дополнит имеющиеся.
Насчет перевода символа S в символ Z — это была ошибка в правиле транслитерации, сейчас исправили
Вообще-то, любое предложение, оканчивающееся знаком вопроса — это вопрос. И тут в коментах они не риторические, а вполне конкретные. И ты не ответил ни на один мой вопрос. Но сейчас это уже неважно, ниже объясню, почему.
Очень хорошо понимаю, что такое «политика конфиденциальности» в отношении сайта/сервиса. А что это применительно к движку — не знаю. Что-то не припомню такого применительно к движку (не к сайту!!!) Wordpress, Joomla, Drupal. Все они (во всяком случае WP и Joomla точно, насчет Друпала не помню наверняка) подгружают в админке инфу с официальных сайтов и проверяют установленную версию, чтобы предложить обновиться. И это без всякого согласия с какой-либо «политикой». И, согласись, опираться на опыт работы этих CMS больше оснований, чем на опыт LS. Более того, было 100500 просьб от самих юзеров, чтоб сам движок проверял актуальность версии как ядра, так и плагинов, и позволял бы в один клик (условно говоря) ставить обновления. Мы в этом направлении и работаем. Но как я уже сказал выше — обязательно сделаем эту опцию отключаемой.
Могу легко это объяснить:
1) Вопрос был опубликован не в блоге «Вопросы», что было бы логичным, а в блоге с максимальным рейтингом.
2) Текст подан подан так, что у людей, не анализирующих внимательно код, может сложиться ложное представление, будто на сервер отправляется какая-то статистика об их сайтах, и проводится явная аналогия с ЛС, что является в корне неверным.
3) В вопросе речь идет об идентификации сайта, что опять же есть неправда.
4) Сама формулировка вопроса «почему нельзя...?» выглядит несколько странной — любому более-менее вменяемому разработчику ясно, что можно.
5) Наконец, мы оба знаем о некоих «экспериментах по социальной инженерии»
Любой из этих факторов в отдельности не вызвал бы у меня никакой особой реакции (максимум — удивление). Но все вместе в одной точке они как бы навевают на некоторые нехорошие мысли.
Но мусолить дальше эту тему я смысла не вижу. Поэтому предлагаю считать все это лишь недоразумением. Я готов согласиться с тем, что ты был просто неточен в формулировках, а я не вполне верно тебя понял. А на самом деле ты предположил, что каким-то админам сайтов на Альто совсем неважно знать, актуальны ли у них версии самого движка и плагинов, а посему нужно сделать эту опцию отключаемой. Ок, я тебя услышал — сделаем.
Если будут еще какие-то предложения — пожалуйста, высказывай, нам очень важен фидбек, но, желательно делать это более корректно, чтоб это не вызывало двусмысленного толкования.
Во-вторых, идентификатор — это признак, который позволяет однозначно идентифицировать объект. Каким образом можно идентифицировать сайт по уникальному ключу?
Наконец, раз возник такой разговор вообще, то для особо параноидальных юзеров сделаем опцию отключения всех информеров — это ни разу не проблема (хотя я, например, не увидел, где такое отключается в WP, как, впрочем, не видел и рассуждений на тему «WP следит за нами!»)
Давай сравним «похожий» (как ты утверждаешь) функционал.
Что имеем в ЛС:
— внедрение счетчика, который фиксирует URL всех страниц сайта, сделанного на ЛС, по которым бродят юзеры
— отправка на сервер ЛС явной информации о реальном домене и используемом скине сайта
Что имеем в Альто:
— для сайта генерируется уникальный код с многократным вложением md5 и sha1, да еще с «солью» (которая, как правило, отличается на разных сайтах), т.е. информация о сайте (о его домене/адресе) в принципе не может быть получена никаким способом!
Т.е. в одном случае — вполне конкретная информация, однозначно идентифицирующая не только сайт, но и отслеживающая поведение юзеров на нем, в другом — некий абстрактный код, который вооще никак ни разу не указывает на что-то конкретное.
И давай теперь покажи, где тут «похожесть»?
На вопрос «зачем» отвечу: задача стоит лишь в кешировании данных. У нас весьма амбициозные планы, и я не вижу смысла дергать сервак буквально по каждому запросу.
Я доступно излагаю?
Для чего еще можно юзать ключ, который абсолютно никак нельзя увязать с каким-либо конкретным сайтом — я лично не могу представить. Если есть соображения, что как-то может быть раскрыта информация о сайте — поделись, как. И тогда вместе подумаем, как этого избежать.
В движке планируется реализовать механизм редиректа, когда скажем, есть у страницы полный URL, который будет индексироваться, и короткий, который будет не внутри движка «шаманить» и выдавать страницу, а формировать нормальный редирект на постоянный адрес с кодом 301. Тогда и людям будет просто оперировать короткими адресами, и поисковики не будут индексировать ничего лишнего
Еще раз повторю, на всякий случай, чтоб не было неясностей и инсинуаций:
1) в Альто не втыкается свой счетчик на все страницы, как в это делается в ЛС
2) в Альто не отправляется куда-то никакая статистика по сайту, ни название сайта, ни используемый скин, как в ЛС
3) в Альто не используются никакие «секретные» запросы с использованием CURL-функций (у нас вообще нет кода, где бы эти функции вызывались, и ни в одной из сторонних библиотек, используемых в проекте, я подобных функций не обнаружил).
И, как выше уже было сказано, в Альто есть подгрузка новостей в админке, как это сделано, например, в Wordpress.
Что касается обновлений — если у Вас сайт только в стадии разработки, то можно обновляться и с гитхаба. Во всяком случае, будете в курсе всех нововведений и добавляемых фич и сможете учесть это в процессе работы над сайтом. Понятно, что могут быть в девелоперской версии какие-то баги и недочеты, но сама по себе версия вполне рабочая. Если же сайт уже рабочий, и им активно пользуются юзеры, то не стоит их травмировать частыми обновлениями, и лучше подождать официального релиза.
Поэтому и решено было в самом движке лишь базовый функционал реализовать, а навороты оставить для плагинов