Есть предложения?

Так я и предложил: мессенджер, который в виде плагина ставится на любой сайт на базе Альто (и работает прямо на сайте типа вконтактовского или фейсбучного), и плюс к нему — мобильный клиент.

Честно говоря, не понял до конца идею — что это будет за мессенджер и зачем ему CMS. Если движок нужен просто для создания официального сайта — тогда понятно. Если же для того, чтоб организовать централизованное хранилище сообщений и взаимодействие с клиентами — то тут не нужна CMS, это надо писать что-то свое сугубо специфическое.

И, конечно, не очень понятно, почему именно ваш мессенджер люди будут выбирать среди кучи прочих.

Другое дело — написать мессенджер в виде плагина для CMS. И к нему — мобильного клиента. Вот это может быть уже интересней. Тот же Pring, например, будет тогда юзеров своих сажать не за мейл-агента, а за этот мессенджер. Ведь получится, что его юзеры, даже не выходя (как бы!) на его сайт все равно общаются на ЕГО ресурсе, а не в стороннем чатике. И на клиенте можно не хранить историю чата (что его упрощает), вся история хранится на сайте и доступна юзеру в своем профиле.

Но для такого рода мессенджера десктопный клиент не нужен — если я сижу за компом и у меня есть доступ в инет, то что мешает мне выйти на сайт и чатиться там? А вот мобильный — другое дело, это реальная тема.

Есть предложение — написать краткую инструкцию, как начать (да-да, знаю, что я сам сапожник без сапог, но все ж). Вот установил юзер движок, накатил сверху плагин. И что дальше? Сначала структуру каталога определить (где? как?)? Или сразу товар вбивать?

На шаблонах из коробки Альто, есть проблемки…

Проблемки на уровне верстки и CSS-классов, но программных ошибок нет, верно?

Ну и что-то Компании не хотят нормально работать

А с ними что? Сыплются ошибки или тоже просто отображаются криво?

Немного замороченно, но можно. Если не программировать и не писать никаких плагинов, то можно чуть-чуть «накостылить» прямо в шаблонах.

Для начала надо узнать ID полей. К сожалению, увидеть их без того, чтоб лезть в базу, можно только обновившись с гитхаба, в админке там при просмотре типа контента теперь выводятся ID кастомных полей. Либо, если не обновляться, то можно увидеть их в таблице ?_content_field, поле field_id.

Дальше немного проще.

В шаблоне /common/templates/skin/_skin_name_/tpls/fields/customs/field.custom.textarea-show.tpl убирается этот самый кусок кода, который приведен выше.

В нужных местах шаблона, где нужно выводить кастомные поля, вставляете такой код:

{if $oContentType}
   {foreach from=$oContentType->getFields() item=oField}
      {if $oField->getFieldId() == N}
      {include file="fields/customs/field.custom.`$oField->getFieldType()`-show.tpl" oField=$oField}
      {/if}
   {/foreach}
{/if}

Здесь N — это как раз ID поля, которое нам надо вывести в конкретном месте.

Ну мы же уже это обсуждали. Я ведь даже не поленился, и зарегистрировался на этом ресурсе. И вот что вижу:

При создании топика есть обычная панель редактирования текста, где есть кнопка Изображение для вставки в текст. И внизу — отдельная кнопка Прикрепить файл. И инструкция: если надо вставить изображение, то надо кликать не по кнопке Изображение, а по кнопке Прикрепить файл, а потом уже… (далее по тексту).

Вам такое решение кажется элегантным. Мне — нет. Если Вы скажете, что лично Вам и пользователям Вашего ресурса нужно именно так, и никак иначе — охотно поверю. Но то, что так должно быть прямо из коробки — не соглашусь.

Предложение делать «врезку» это костыль...

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

Но вы же можете учесть все эти нюансы и сделать по-настоящему удобно

Я, к сожалению, не проектировщик интерфейсов и не дизайнер. А выше я уже писал, что все изменения в плане интерфейса должны начинаться именно с этой части работ. Когда речь идет об интерфейсах, то тут мало сказать: «нужно чтоб вот примерно как там, только лучше, круче и удобней». Это все еще надо изобразить в реальных скриншотах. А потом уже думать, как реализовать программно. Почти все, что Вы просите, решается на уровне шаблона, плюс небольшие доработки фронтенда (небольшой модуль javascript). И если найдется дизайнер, который все это отрисует, и верстальщик, который сверстает, создав, в итоге, шаблон Вашей мечты, то я поддержу и того, и другого всем, чем только смогу.

Да, вполне себе рабочее решение без разработки дополнительного функционала. Тем более, что:

а) есть возможность переписать любые текстовки сайта, сделав их не просто более дружелюбными по отношению к пользователю, но и учитывая специфику конкретного сайта

б) для конкретного типа топика можно создать свой шаблон как для вывода в ленте, так и для полного отображения статьи

Вот: altocms.ru/793.html
По-моему, на все вопросы ответил, но если что-то упустил — жду дополнительных вопросов

Я так понимаю, проблема со смайликами периодически (не только в этом случае) возникает из-за того, что во время вывода публикации они для браузера — просто картинки. Точно такие же, как и вставляемые фото в текст. И на них ложатся предопределенные CSS-стили.

Думаю решить эту проблему раз и на всегда можно так: добавлять ко всем смайликам свой CSS-класс, в котором описать все необходимые свойства (напр., инлайн-вставку, а не блок, ширину/высоту и пр.).

Правда, не придумал еще, как сделать, чтоб смайлики как превью не цеплялись. Но что-нибудь придумаем.

Подход примерно такой:

Если требуется изменить внешний вид, и этого можно достичь правкой CSS, то лучше создать в папке скина новую тему и там все, что нужно, править.

Если потребовалось добавить какой-то новый визуальный блок, которого нет, то это — создание виджета. Причем, виджет может быть как шаблонный, так и исполняемый. Шаблонный виджет — это tpl-файл (т.е. фактически, кусок шаблона). Исполняемый — это уже php класс.

Если первых двух вариантов не хватает для реализации своих идей, то уже имеет смысл создавать свой скин.

Что касается ионкуба и платности.

Во-первых, идея попробовать ионкуб в некоторых плагинах и сборках появилась с моей подачи. Приживется эта идея или нет — будет видно, но попробовать хочу. Разумеется, делать это нужно с умом и очень акккурантно, чтобы у разработчиков сайтов была возможность, при необходимости, развивать, наращивать, дополнять. Например, если взять нынешний движок, как есть, и закодировать класс Loader (engine/classes/core/Loader.class.php), а все остальное оставить открытым, то как это скажется на возможности развивать сайт на таком движке? Да никак! Этот класс не замещается и не переопределяется ни плагинами, ни чем иным, это часть ядра, куда сторонним разработчикам лезть крайне не рекомендуется.

Вот примерно такой подход и планируется попробовать.

Что касается платно/бесплатно — тут я вообще не очень понимаю, о чем речь и спор. Какие-то плагины — платные, какие-то — бесплатные. Так и тут может быть — какие-то сборки будут бесплатными, какие-то платными. Более того, вполне возможно, что будут сборки в двух вариантах — простой (базовый) вариант бесплатный, а более продвинутый — платный. Например, есть NovaBuild — совершенно бесплатно бери и пользуйся. Но ведь можно на базе этой бесплатной версии создать более навороченную сборку — с прикрученной оплатой, с импортом/экспортом в ЯндексМаркет и 1С, с еще какими-то наворотами — и, думаю, вряд ли кто будет удивлен, что такая расширенная и укомплектованная сборка уже будет стоит денег.

Т.к. двумя предложениями тут явно не отделаешься, то напишу отдельной статьей

Хм, либо саппорт хостера тупит, либо я сильно отстал от жизни и не в курсе, что CMS, написанная на php, может в процессе своей работы самостоятельно php-модули подключать. Насколько я помню, токенайзер с довольно давних пор включен в php при компиляции по умолчанию. Возможно, где-то в настройках сервера он еще и как внешний модуль подключается — php.ini, extensions.ini или как-то еще.

По поводу «чуда» — вероятно, файл /common/templates/language/actions/admin/en.php редактировался и был неверно сохранен. Должна быть кодировка UTF-8 без BOM

А если в код глянуть?

<meta property="og:title" content="Google Glass - новые перспективы дополненной реальности">
<meta property="og:url" content="http://demo.altocms.com/experience/10.html">
<meta property="og:description" content="Осведомленность о бренде интегрирована. Целевой сегмент рынка индуктивно допускает системный анализ, отвоевывая рыночный сегмент. По мнению ведущих маркетологов, стратегическое планирование">
<meta property="og:site_name" content="EXPERIENCE">
<meta property="og:type" content="article">
<meta name="twitter:card" content="summary">
<meta name="og:image" content="http://demo.altocms.com/experience/uploads/images/00/00/10/2014/06/26/0u2a3857df-4811d437-681894e3.jpg-700x700-crop.jpg">

Скорее всего какая-то ошибка в javascript. А что за шаблон? Я б проверил

А плагин под название Ls активирован? Он в комплекте с движком идет

Понял правильно — так оно и задумано, чтоб не было жесткой зависимости между id плагина и его каталогом. Более того, при таком подходе вообще можно группировать плагины, напр., так:
/common/plugins/novabuild/core/ — это сам плагин
/common/plugins/novabuild/robokassa/ — это дополнение к нему
/common/plugins/novabuild/latte/ — еще дополнение

А id формировать так:
novabuild.core
novabuild.robokassa
novabuild.latte

Но это пока в задумке, реализации окончательной еще нет. Поэтому пока либо называть папку «a_h», либо название класса плагина — «PluginAh»

Так в том и дело, что автор исчез, у многих, кто скачивал плагин, возникали проблемы, а решить их было некому. Потому я и убрал его в черновики с глаз долой. Если автор вдруг вернется и возобновит поддержку плагина, я только рад буду.

Вы очень-очень скептически относитесь к темам SEO

Ошибочное мнение. Я в этом не очень хорошо разбираюсь (хотя общее представление, конечно, имею). Поэтому предпочитаю не диктовать юзерам, что и как надо делать, не задавать жесткие рамки, а дать возможность им самостоятельно подкрутить SEO-параметры, как они считают нужным. Именно по этой причине настройки тега Title вынесены в конфиг, а для остального есть специальный SEO-плагин, а также плагин «Похожие статьи», как выше писал.

Если Вы спец в вопросах SEO, то было бы здорово, если б Вы изучили эти возможности, и написали статью с рекомендациями для вебмастеров, как по максимуму выполнить SEO-оптимизацию Альто-сайтов, используя весь этот набор.

Тот, кто в этом особо не разбирается, тот только спасибо скажет. А если какой-то сеошник с чем-то не согласен будет, то пусть он лучше с Вами спорит, чем со мной :)

По поводу тегов Hn — услышал. Я не знаю, насколько это существенно, но если постараться соблюсти эти советы, то хуже-то точно не будет. Поэтому принято.

По поводу пингатора Яндекса — на базе Альто создаются сайты, кроме прочего, и закрытого типа, которым пингатор не нужен в принципе (у них другие методы продвижения). Плюс есть вебмастера, которым на Яндекс вообще плевать, они ориентируются на другие поисковики. Именно поэтому я не считаю верным прямо в коробку встраивать пингатор. Возможно, стоит добавить его в SEO-плагин. Но если уж и делать подобный функционал, то хотелось бы, как минимум, и для Гугла нечто подобное сделать, и дать возможность в конфиге настраивать, какие поисковики требуется пинговать.

Но плагин этот в каталоге перевел в черновик, чтобы больше никто не натыкался