Путь до файла /core/components/jevix/vendor/agelxnash/jevix/src/functions.php.

Исправленный вариант кода:

<?php
/**
 * Функция ord() для мультибайтовы строк
 *
 * @param string $c символ utf-8
 * @return int код символа
 */
function uniord($c)
{
    $h = ord($c[0]);
    if ($h <= 0x7F) {
        return $h;
    } else {
        if ($h < 0xC2) {
            return false;
        } else {
            if ($h <= 0xDF) {
                return ($h & 0x1F) << 6 | (ord($c[1]) & 0x3F);
            } else {
                if ($h <= 0xEF) {
                    return ($h & 0x0F) << 12 | (ord($c[1]) & 0x3F) << 6
                        | (ord($c[2]) & 0x3F);
                } else {
                    if ($h <= 0xF4) {
                        return ($h & 0x0F) << 18 | (ord($c[1]) & 0x3F) << 12
                            | (ord($c[2]) & 0x3F) << 6
                            | (ord($c[3]) & 0x3F);
                    } else {
                        return false;
                    }
                }
            }
        }
    }
}

/**
 * Функция chr() для мультибайтовы строк
 *
 * @param int $c код символа
 * @return string символ utf-8
 */
function unichr($c)
{
    if ($c <= 0x7F) {
        return chr($c);
    } else {
        if ($c <= 0x7FF) {
            return chr(0xC0 | $c >> 6) . chr(0x80 | $c & 0x3F);
        } else {
            if ($c <= 0xFFFF) {
                return chr(0xE0 | $c >> 12) . chr(0x80 | $c >> 6 & 0x3F)
                    . chr(0x80 | $c & 0x3F);
            } else {
                if ($c <= 0x10FFFF) {
                    return chr(0xF0 | $c >> 18) . chr(0x80 | $c >> 12 & 0x3F)
                        . chr(0x80 | $c >> 6 & 0x3F)
                        . chr(0x80 | $c & 0x3F);
                } else {
                    return false;
                }
            }
        }
    }
}

/public_html/core/components/jevix/vendor/agelxnash/jevix/src/functions.php
поменял фигурные кавычки на квадратные и заработало
Илья, где именно поменяли? Файл выложите, пожалуйста

Теперь понятно.
Я думал там есть такая возможность.

Тогда вопрос отпал.

Куда именно вы хотите добавить текстовое поле? в таблицу или просто на панель в меню?

Разрешено добавлять только таблицы, ведь простые поля не будут сохраняться, там нет этого функционала.

Спасибо за ответы!

Хранит то modx чанки и шаблоны и т.п. в базе да, но с ними как раз нет проблем — сталь галочку Статичный, указываешь папку и файл е лежит код — и вот уже код хранится не в базе данных, а в файле, и можно версионировать его через git. Пишу это не для тебя ;) а скорее для читателей, которые все ещё верят в миф про то, что в modx есть какие-то проблемы есть с git-ом.

Проблем с git нет вообще! Разве что, для упрощения быстрого старта по умолчанию сохранение кода в файлы в системных настройках не включено, пожилому он и знания в БД пока не поставишь галочку или не включишь сис. настройки (staticelements что-то там такое в префиксе)…

Я использую так уже почти 10 лет. А слабое звено тут получается контент, хранящийся в базе, и вот тут будет удобно использовать что то вроде ChangePack, для автоматической генерации файла с «миграцией» изменений в БД.

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

Уже ничего не помню. Там не минутка нужна.

И 2й вопрос: могу ли использовать часть кода компонента в каком-то новом решении? С сохранением копирайтов твоих само собой.

Без проблем. И даже копирайты не обязательно.

Есть идея сделать некий githelper или gitmanager, ещё один, ага)

Проблема в том, что MODX хранит чанки, сниппеты и т.д. в базе. К базе просто так гит не подключишь и сделать синхронизацию сложно. Сейчас я пишу компоненты в которых все до установки в файлах и использую обычный гит. И версии изменений есть и обновить боевой сайт не проблема. И githelper не нужен.

Вопрос, а как сделать для категории товара?

Сниппеты исключают страницу, если нет перевода, даже если показываем 404 страницу.

Поэтому у меня работает так:

• redirect — если мы переходим на страницу без перевода, то срабатывает редирект на главную, и такие страницы исключаются из всех сниппетов.
• 404 — то же самое, что и redirect, но показываем 404 страницу вместо главной
• default — страницы без перевода учитываются в сниппетах, (pbLang, pbMenu), но не в pbSitemap. При переходе на такую страницу показываем страницу без перевода.

За это будет отвечать системная настройка pageblocks_context_fallback

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

Если страница не переведена, то она должна быть исключена из локализации — для поисковых систем это не релевантная страница в данной локализации, а для посетителя — не user friendly.

В сниппетах Polylang для этого применяется параметр onlyWithLocalization:

Исключение из результатов сниппетов ресурсов без локализации
Если необходимо исключить из результатов работы сниппетов ресурсы которые не содержат для текущего языка локализаций, то добавьте в вызов сниппета параметр onlyWithLocalization с значением 1.

Важно решить как управлять страницами при мультиязычности:
— если нет перевода, то не отображать страницу

А что значит не отображать страницу? Показываем главную?

Сейчас расскажу прикол из ряда вон выходящий, поставил на тестовом сайте, всё хорошо. Перенёс этот сайт на этом же хостинге (переименовал папки и поправил конфиги) всё, не открываются пользователи для редактирования, скопировал сайт, скопировал базу, положил рядом на этом же хостинге переименовал в dev.hostname.ru, на тестовом работает, на проде нет

Привет. Вывод интерфейса админки минишопа в web контекст никто не делал. Я делаю потихоньку интерфейс своей ERP на getTables и PVTables в web контексте. Не охота писать в админке и пускать в нее. Но пока разработка в процессе. В принципе, аналогично можно интерфейс минишопа переписать.
И даже у меня пока есть время и мне интересно взяться за такую задачу. Если вам интересен интерфейс минишопа на PVTables напишите мне. Посмотрим как вы видете задачу. Может возможно сделать, а может еще рано. Например, файлового менеджера в PVTables еще нет.

Важно решить как управлять страницами при мультиязычности:

Сейчас, если перевода нет — показывается страница в основной локали.
Остальные варианты пока не реализованы.

pbLang — есть
pbSitemap — есть
pbCanonical — будет

Желающие «переехать» на ваш компонент также столкнуться с еще одной проблемой — у многих сайты на субдоменах или того хуже — на разных доменах.

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

Важно решить как управлять страницами при мультиязычности:
— если нет перевода, то не отображать страницу

- если нет перевода, то показывать 404

- если нет перевода, то показывать «основную» локализацию



Как правило, клиенты просят исключить (не отображать) не переведенные страницы. Эта логика должна учитываться, в том числе и при формировании sitemap.

Также для мультиязычности необходим сниппет Canonical — sitemap, сanonical и переключатель языков (pbLang) базовые снипеты для мультиязычного сайта

Желающие «переехать» на ваш компонент также столкнуться с еще одной проблемой — у многих сайты на субдоменах или того хуже — на разных доменах.

PS Посмотрите в сторону Polylang, отличный компонент, но не поддерживает MODX 3.