Доброго времени!

В связке LS 1.0.3 + плагин Компании (от gran-а) столкнулся с невозможностью редактирования данных у некоторых компаний (брендирование, виджеты и т.п.).
Также на станице редактирования компании появлялась ошибка: Warning: Illegal string offset in...

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

В файле /plugins/company/classes/modules/company/entity/Company.entity.class.php находим функцию protected function extractPrefs и меняем её содержимое на:

protected function extractPrefs () {
    if (is_null($this->aPrefs)) {
        $aFixPrefs = preg_replace_callback ( '!s:(\d+):"(.*?)";!s', function ($match) {
            return ($match[1] == strlen($match[2])) ? $match[0] : 's:' . strlen($match[2]) . ':"' . $match[2] . '";';
        }, $this->getPrefs() );
        $aPrefs = unserialize($aFixPrefs);
        $this->aPrefs = is_array($aPrefs) ? $aPrefs : array();
    }
}

P.S.: для решения воспользовался этой информацией

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

Чтобы избежать этого, мы можем выводить предупреждение по событию beforeunload, т.е. перед тем как пользователь покидает страницу. Только перед этим проверим были ли изменения в полях ввода.

Как реализовать?

Необходимо на страницах добавления и редактирования топика добавить скрипт. На мой взгляд проще всего это сделать через php-хук движка:
Читать дальше →

Друзья, товарисчи!

Уже недели 3-4 на этот сайт практически невозможно залогиниться.
Сейчас каким-то чудом залогинился через Yandex браузер. Пользуясь случаем, пишу этот топик.

Большая просьба ко всем — у кого есть проблемы с логином, отпишитесь pls в этом тикете

Upd (23.06.2021)

В Chrome v91 убрали флаг same-site-by-default-cookies
Но можно запустить Chrome с командной строки.
Для Win10:
"C:\Program Files\Google\Chrome\Application\chrome.exe" --disable-features=SameSiteByDefaultCookies
Для OSX:
/Applications/Google Chrome.app/Contents/MacOS/Google Chrome --disable-features=SameSiteByDefaultCookies

Upd (25.02.2021)
Вобщем выяснил наконец причину!

Дело в том, что начиная с 80-й версии chrome-based браузеров появилась защита от межсайстовой передачи куков (межсайтовых POST-запросов). А на LS сейчас именно такая система используется: passport.livestreetcms.com редиректит на livestreet.ru, передавая куки

«Вылечить» можно так:
1. Заходим по адресу chrome://flags/#same-site-by-default-cookies
2. Устанавливаем для свойства SameSite by default cookies значение Disabled
3. Перезапускаем браузер и все работает

Иными славами для файлов (в т.ч. куков) добавлено новое свойство: SameSite. У которого возможно 3 значения:
— SameSite=Strict — куки передаются только в пределах одного сайта
— SameSite=Lax (именно такое значение задается кукам по дефолту, если оно не задано явно) — куки передаются между сайтами только в пределах одного домена
— SameSite=None — ограничения на передачу куков отсутствуют

Подробнее здесь и здесь.

Глобально решить проблему можно, задав для куков авторизации свойство SameSite со значением None (SameSite=None; Secure). И при этом необходимо чтобы и livestreet.ru также был на https.

Сделать это можно примерно так:
Для php < 7.3 (через установку заголовков):
header('Set-Cookie: cross-site-cookie=name; SameSite=None; Secure');
Для php ≥ 7.3:
setcookie('cross-site-cookie', 'name', ['samesite' => 'None', 'secure' => true]);

Или поставить примерно такую либу.

Но это может сделать только Макс, если захочет ;)

Решение — кросс-пост с тикета на github

В браузере Chrome начиная с v56 появилась т.н. функция Scroll Anchoring, которая включена по умолчанию.

В результате на всех Chrome-based браузерах на странице с подгрузкой контента (например в Активности) после подгрузки скролл уходит вниз страницы. и подгружаемый контент «уходит» вверх, а не появляется внизу как положено. В итоге теряется смысл этой фичи и чтобы увидеть подгруженный контент, нужно скроллить вверх вручную.

Этот баг воспроизводится и на этом сайте (см. страницу Активность). В Firefox все работает как надо.

Решение:
Читать дальше →

На сайте подключена библиотека для ленивой загрузки изображений (Lazy Loading).
Таких js-библиотек достаточное количество на github-е. Вот одна из популярных.
Как правило, для задействования либы требуется:
a) — наличие у тега img определенного класса
b) — наличие у тега img атрибута data-original (или data-src) c указанием ссылки на изображения.
Примерно так:

<img data-original="site.com/uploads/.../img.jpg"/>

Атрибут src может быть не задан вовсе, либо в нем должна быть ссылка на «заглушку».
Чтобы не «ковырять» редактор и/или текстовый парсер было решено сделать в js так:

$('#content .topic-type-topic img').each(function () {
    $(this).addClass('lazy');
    $(this).attr('data-original', $(this).attr('src'));
    $(this).removeAttr('src');
});

$("img.lazy").lazyload({
    effect: "fadeIn"
});

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

Недавно заглянул в консоль и увидел, что картинки при загрузке страницы все равно загружаются все разом, а эффект ленивой подгрузки лишь визуальный, т.к. никакой экономии трафика не происходит. Причина загрузки всех изображений в том, что обработка атрибутов тега img происходит ПОСЛЕ загрузки дерева DOM, в частности после загрузки всех картинок и jQuery.

В идеале конечно обработать img в самом движке — добавить правила Jevix, подправить редактор и/или текстовый парсер, затем все имеющиеся топики прогнать через все это.
Можно ли обработать тег img на лету до загрузки страницы? (через модуль Viewer?)

Гугл предложил еще вариант — заменить js-обработку тега img с jQuery на чистый JavaScript и вставить её в head. Кто знает как это сделать — прошу помочь, а я протестирую этот вариант.

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

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

1. Конфиг.
Наличие протокола https можно «забирать» прямо в php ($_SERVER['HTTPS']). Поэтому в конфиге прописал вот такую строку (переопределяем в config.local.php эту строку):

if (isset($_SERVER['HTTP_HOST'])) {
    if (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] != 'off') {
        $config['path']['root']['web'] = 'https://'.$_SERVER['HTTP_HOST'];
    } else {
        $config['path']['root']['web'] = 'http://'.$_SERVER['HTTP_HOST'];
    }
} else {
    // for CLI scripts. or you can append "HTTP_HOST=http://yoursite.url" before script run command
    $config['path']['root']['web']        = null;
}

или одной строкой:

$config['path']['root']['web'] = isset($_SERVER['HTTP_HOST']) ? ((isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] != 'off') ? 'https://' : 'http://') . $_SERVER['HTTP_HOST'] : null;

Выглядит непрезентабельно, и возможно неоптимально, но вроде работает. В зависимости от протокола по которому зашли, меняется конфиг {Config::Get('path.root.web')}

2. Ссылки на изображения.
На github-е уже предлагалось при загрузке изображений в редактор подставлять относительные ссылки.
src="http://site.com/uploads/images/.../img.jpg" -> src="/uploads/images/.../img.jpg"
Это дает универсальность и независимость от протокола. Но возникает проблема с RSS, т.к. в RSS потоке относительные ссылки не работают. По всей видимости, если переходить на относительные ссылки, то необходимо в ActionRSS делать replace для относительных ссылок и добавлять к ним {Config::Get('path.root.web')}

3. Внутренние ссылки в контенте.
Для внутренних ссылок существует универсальный способ href="http://site.com/..." -> href="//site.com/...". В данном случае протокол у ссылки будет задействован тот, в котором открыта страница со ссылкой. Решение универсальное, но распространяется только на внутренние ссылки. Вероятно, возможно применить это, делая replace в контенте при условии что это внутренняя ссылка.

Случайно подпортил базу на проекте. Благо есть недавний backup.
Есть база ls103 -> в ней таблица prefix_topic_content -> в ней поле topic_text_source
Вот это поле и «подпортилось».
Помогите, кто знает каким запросом заменить данные в этом поле из базы ls103_backup?

Т.е. нужно заменить все данные в поле topic_text_source, в том случае если в этой строке совпадает значение поля topic_id

Имеется плагин, который выводит блок через свой конфиг:

Config::Set('block.rule_somerule', array (
    'action'  => array (
        'index',
        'feed'
    ),
    'blocks' => array (
        'right' => array (
            'block_someblock.tpl'=> array (
                'params' => array ( 'plugin' => 'someplugin' ),
                'priority' => 101,
            )
        )
    ),
));

Помогите указать в шаблоне условие, что текущий action ($sAction) соответствует action из настроек вывода блока.

К примеру, такая конструкция не работает:

{if in_array($sAction, Config::Get('plugin.someplugin.block.rule_somerule.action')}
    ...
{/if}

После редактирования конфига Jevix новые правила обработки текста применяются если войти в режим редактирования топика и сохранить его.

Существует ли способ «прогнать» через новые правила все топики одним разом?

При публикации топика когда мы между между участками текста оставляем пустую строку (чтобы выглядело как параграфы) -> на выходе мы вместо одной пустой строки получаем один тег br. И в опубликованном топике это выглядит как один перенос строки. Соответственно, параграфов, как при редактировании, не получается.

Именно поэтому Jevix автоматически добавляет еще один тег br, потому что именно два тега br выглядят как пустая строка и дает нам вид параграфа. Есть конечно теги-исключения, которые задаются в конфиге Jevix-а.

К примеру наш параграф — это код ( в теге code):

Some Code

Не могу понять, почему два тега br над кодом имеют меньшую высоту, чем два тега br под ним. Собственно доказательство этого представлено выше. Причем это касается только только кода.



Кто-нибудь знает, почему так происходит?