тут лучше использовать хранилище(localStorage), для хранения данных пользователя, иначе при перезагрузке устройства им каждый раз придется авторизироваться

Сейчас браузер юзера при авторизации получает куку, а потом при каждом заходе на сайт происходит автоматическая авторизация по этой куке. Тут ведь так же можно устроить. Или хотите в локальном хранилище прямо пару логин/пароль хранить?

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

Я так понимаю, что разработка делается с помощью PhoneGap? А как это хозяйство с внешним сайтом общается, как обычный браузер? Такие вещи, как сессии и куки, работают как у обыкновенного браузера?

Нет, в Альто нет такого функционала, чтоб прямо при редактировании статей расставлять блоки с рекламой.

Самый простой вариант — это втыкать рекламу с помощью шаблонных виджетов. Т.е. создаете шаблонный виджет (фактически — tpl-файл), включаете его в список используемых виджетов, а потом втыкаете в шаблонах, где нужно с помощью {widget name="..."}

а если это страница тега?

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

ну это наверное без дополнительного плагина не обойтись?

Да. Причем, тут мало количество символов считать, надо более детально анализировать текст, чтоб не разбивать его посреди предложения. Но этого мало — желательно отматывать до тега перевода строки или конца параграфа. В общем, много мелочей нужно продумать

Оберните вывод рекламы в условие:

{if $oTopic AND !$bTopicList}
Тут вывод рекламы
{/if}

Тогда реклама будет выводиться только при просмотре самого топика (ведь такая задача стоит, я верно понял?)

в середине текста, задавая местоположение блока вручную

Не очень понял этот момент. Как определяется сам шорткод — это ясно. А как он потом вставляется? В шаблон? Или прямо в редакторе при редактировании текста?

Кстати, в вашем случае можно было не плагин отключать, а отключить только проверку IP на предмет блокировки. Т.е. в конфиге плагина прописать:

$config['block_ip'] = array(
    'enable' => false,
    // дальше можно ничего не менять
);

Тогда проверка на блокировку IP на этапе запуска движка отключается. И проверка работает только при постинге форм

Выложил новую версию плагина, где можно задавать «белые» списки IP-адресов. В конфиге плагина это задается так:

$config['white_ip'] = array(
    'enable' => true,
    'list' => array(
        '195.112.117.2',
        '195.112.117.25-195.112.117.30',
    ),
);

Т.е., во-первых, можно задать любое число адресов, а, во вторых, задавать можно как одиночный адрес (в примере '195.112.117.2'), так и диапазон. Если задан диапазон, то, разумеется, все IP этого диапазона будут «белыми». В примере это все адреса от 195.112.117.25 до 195.112.117.30 включительно.

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

Важно: сначала идет проверка «белых» адресов, поэтому если какой-то IP в этих списках, то проверяться этот IP больше не будет (даже если он одновременно был внесен и в «черные» списки, это будет проигнорировано)

Это была ошибка плагина Категории. Залил в каталог исправленную версию

Хорошее минималистичное решение, мне нравится

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

Если исходим из того, что нам не нужно будет выполнять поиск по контенту, хранимому в истории (т.е. кто, когда и что менял — это да, а вот прямо по самому контенту — нет), то заводим таблицу для хранения историй изменения сущностей примерно такой структуры:
* history_id
* target_type
* target_id
* history_user_id
* history_date
* history_data
И пишем метод, которой будем вызывать перед обновлением каждой сущности, примерно так:

$this->PluginHistory_History_Insert('topic', $iTopicId);

А в методе дергаем нужную сущность и сохраняем ее сериализованные данные в этой таблице.

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

Вот, как-то так, наверное

Я правильно понимаю: у тебя любой видео УРЛ преобразуется в медиа-ообъект? Т.е. вставить просто ссылку на Ютуб без преобразования нельзя?

То, что парсить лучше на стороне сервера, а не в js — это вообще даже не обсуждается, это как само собой разумеющееся. Но кроме чисто парсинга иногда нужно еще и API сервиса дергать. У того же Rutube, например, есть несколько форматов (старые и новые), и без API невозможно обраьотать все форматы их УРЛов.

Но здравое зерно в твоих рассуждениях есть. Может, и приду, в итоге, к универсальной кнопочке «Вставить Медиа»

Все так. За все время работы с ЛС и с Альто я только одного человека встречал, который считал, что история редактирования должна быть в CMS прямо из коробки. Я же лично не вижу в этом потребности. Поэтому, как и обычно в подобных случаях, склонен отдать это на откуп плагинам.

Думаю, можно базу спроектировать так, чтобы ведение такой истории не отразилось на быстродействии. Но по объему раздуваться база, конечно, будет. И чем активнее юзеры на сайте, тем быстрее она будет раздуваться.

Был такой баг. Исправлено в версии 1.0.8

Какими бы не пользовались в каждом конкретном месте, включать поддержку вставки объектов надо максимально возможную

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

вставка медиа-объекта

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

Используя код для вставки, как на скриншоте выше — вообще никаких проблем. Посмотрю, можно ли будет короткую (прямую) ссылку так же использовать

Сейчас есть варианты отработки разных ссылок с Youtube, Vimeo, Rutube. Добавить другие — не проблема, но хочется понять потребность и сначала наиболее востребованные добавить

А у ВК есть возможность встраивать видео на сторонний ресурс, как у Ютуба? Или это только ссылка с переходом туда?

Хм, кстати, да, в теории это возможно — попадание собственного IP в черный список. Надо будет добавить к плагину еще и «белый список», задаваемый в конфиге