LiveStreet CMS

изначально версия 1.0.3 была под PHP 5.2

В сети есть версия 1.0.4 под PHP 7.0

Я доделывал под свой проект под PHP 7.2

Нет. Здесь ресурс, посвященный эксплуатации движка livestreet.

Вы стараетесь перед чужой, равнодушной к вашим проблемам, аудиторией. Здесь это оффтоп.

У меня есть перепиленная на PHP 7.2 версия, но, боюсь, я не готов с вами ею поделиться. Потому что код во множестве мест перепилен под наш проект и с базовым он может не заработать.

Вам очень-очень нужно или вы сможете на PHP 7.0 пожить?

Разумеется, дело в PHP 7.2

Потому что each и create_function в PHP 7.2 уже deprecated.

Сразу поясню, «зачем так сложно».

Мне несложно изменить конфиг конкретно шаблона Synio.

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

В общем, единственное решение, которое хоть как-то работает:

/engine/modules/viewer/Viewer.class.php

public function Init($bLocal = false)
    {
        $this->Hook_Run('viewer_init_start', compact('bLocal'));
        /**
         * Load template config
         */
        if (!$bLocal) {
            if (file_exists($sFile = Config::Get('path.smarty.template') . '/settings/config/config.php')) {
                Config::LoadFromFile($sFile, false);
            }

            $skin = Config::Get('view.skin');
            if (file_exists($sFile = Config::Get('path.root.server') . "/config/skins/{$skin}.config.php")) {
                Config::LoadFromFile($sFile, false);
            }
        }
...

И, к слову, зачем такая сложная функция слияния массивов?

чем не угодил
php.net/manual/ru/function.array-replace-recursive.php
?

Причем я не понимаю другого.

/config/config.php

Тут max_tree определен, допустим, как 7.
Этот конфиг загуржается с перезаписью (true) (перезаписываем пустой конфиг)

/config/config.local.php
При его загрузке стоит «НЕ ПЕРЕЗАПИСЫВАТЬ»

Тут max_tree определен как 10
… и значение успешно меняется на 10.

/templates/skin/synio/settings/config/config.php
При загрузке стоит опять «НЕ ПЕРЕЗАПИСЫВАТЬ»

Тут max_tree определен как 5
… значение в конфиге меняется на 5.

Что за бред вообще в логике ядра???

/engine/modules/viewer/Viewer.class.php

if (!$bLocal) {
            if (file_exists($sFile = Config::Get('path.smarty.template') . '/settings/config/config.php')) {
                Config::LoadFromFile($sFile, false);
            }
        }

Загружаем конфиг, говорим НЕ ПЕРЕЗАПИСЫВАТЬ имеющийся конфиг полученным.
Все верно? Верно.
Идем дальше по цепочке вызовов…

… и приходим к
engine/lib/internal/ConfigSimple/Config.class.php

public function SetConfig($aConfig = array(), $bRewrite = true)
    {
        if (is_array($aConfig)) {
            if ($bRewrite) {
                $this->aConfig = $aConfig;
            } else {
                $this->aConfig = $this->ArrayEmerge($this->aConfig, $aConfig);
            }
            return true;
        }
        $this->aConfig = array();
        return false;
    }

Идем в код ArrayEmerge (точнее в func_array_merge_assoc()

… и обнаружием удивительную вещь:

Массив arr1 перезаписывается ключами массива arr2, хотя это поведение НЕ ОЖИДАЕТСЯ.

Ясно же сказано — не перезаписывать конфиги? Ясно.

А данные херятся.

Где логика?

Что-то, единственно похожее на правду нашел тут:

/engine/modules/viewer/Viewer.class.php

/**
     * Получает локальную копию модуля
     *
     * @return ModuleViewer
     */
    public function GetLocalViewer()
    {
        $sClass = $this->Plugin_GetDelegate('module', __CLASS__);

        $oViewerLocal = new $sClass(Engine::getInstance());
        $oViewerLocal->Init(true);
        $oViewerLocal->VarAssign();
        $oViewerLocal->Assign('aLang', $this->Lang_GetLangMsg());
        return $oViewerLocal;
    }

Оно?

попробуем поковырять. но почему так странно сделано?

А я просто в начале каждого плагина написал вот так:

    const ConfigKey = 'expwall';
    const HooksArray = [
        'template_main_menu_item'       =>  'MenuMain',
        'template_profile_whois_end'    =>  'ProfileWhois'
    ];

    public function RegisterHook()
    {
        $plugin_config_key = $this::ConfigKey;
        foreach ($this::HooksArray as $hook => $callback) {
            $this->AddHook(
                $hook,
                $callback,
                __CLASS__,
                Config::Get("plugin.{$plugin_config_key}.hook_priority.{$hook}") ?? 1
            );
        }
    }

Да, это не решает проблему полностью, но я могу в локальном конфиге прописать:

$config['plugin']['page']['hook_priority']['template_main_menu_item'] = 2;
$config['plugin']['expwall']['hook_priority']['template_main_menu_item'] = -10;

Теперь плагин page отработает раньше, чем ExpWall

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

Идеал недостижим. Пришлось писать свой. Заодно вмешиваться в ядро. :(

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

В идеале — консольный.

Удивительно, что разработчики большинства плагинов (всех?) не считают нужным хранить этот приоритет в конфиге плагина — это очень многое бы упростило «искаропки».

Если уж разработчик в теме — не могу не задать еще один вопрос :)

Как изменить какой-то из параметров темы, не внося изменения в /template/skin//settings/config/config.php?

Сделал после загрузки конфигов dump конфига, но настройки темы в него не подгрузились.

Спасибо.

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

Заменить
/engine/lib/external/jquery/jquery.scrollto.js
на
github.com/flesler/jquery.scrollTo/blob/1.4.14/jquery.scrollTo.js

И в коде scrollTo:

```

return /webkit/i.test(navigator.userAgent) || doc.compatMode == 'BackCompat' ?
					doc.body :
					doc.documentElement;

```
на
```

return document.scrollingElement || document.documentElement;

```

это вам на форум промальпов. У вас же есть свой форум?

SQL Error: Got ...

ответ здесь, imho.
Какой-то запрос к БД делаете, который сервер БД выполнить не может.

Нужно больше информации.