Cyrax_02

«Обычно» панели на VPS создают следующую структуру папок:

домашняя директория пользователя = /var/www/user/data/
корневая директория сайта = ~/www/site.ru = /var/www/user/data/www/site.ru
логи сайтов = /var/www/httpd-logs/...
сертификаты = /var/www/httpd-cert/user/...
fcgi-враппер = var/www/php-bin/user/php + php.ini

Интересует, какую структуру папок выдерживают разработчики/админы в случае, когда:
— на VPS работают только свои (или одного заказчика) сайты и все сайты (скрипты) запускаются от одного пользователя?
— панели для управления сервером не используются и не будут использоваться

По стандарту FHS для сайтов должна использоваться папка /srv. Но на практике этот «стандарт», как правило, не соблюдают и в большинстве случае размещают сайты в /var/www/.

MinifyX/munee 1.4.2 — сжимает в 1.3-1.5 раз слабее, чем это возможно.

Сравнил библиотеки jquery, jquery-ui и flexslider. Готовые min-файлы весят в 1.3-1.5 раз меньше, чем те, которые получаем после MinifyX/munee. Вначале думал, что алгоритмы сжатия используются примитивные, но оказалось, что такая степень сжатия достигается за счёт минимизации имён локальных переменных и прочих объектов языка (вплоть до 1 символа). Логично.

Судя по всему, munee не умеет «сжимать» локальные имена. Или всё-таки умеет?
Кто что думает по этому поводу? Если не умеет, не планирует ли кто реализовать эту минимизацию на уровне компонентов, например, того же самого MinifyX/munee?

P.S. Сходу это дело реализовать не получится, поскольку регулярками здесь не обойтись (регулярки не учитывают уровень вложенности). Нужен полноценный парсер JS-кода. Ну а коли использовать (или писать) такой парсер, то и munee может уже и не понадобиться…

Пользовательская таблица, имеет xPDO-схему без связей с другими таблицами:

<?xml version="1.0" encoding="UTF-8"?>
<model package="s" baseClass="xPDOObject" platform="mysql" defaultEngine="MyISAM" version="1.1">
        <object class="sRelations" table="sRelations" extends="xPDOSimpleObject">
                <field key="id1" dbtype="int" precision="10" attributes="unsigned" phptype="integer" null="false" index="index" />
                <field key="id2" dbtype="int" precision="10" attributes="unsigned" phptype="integer" null="false" index="index" />                
        </object>
</model>

Как видно по схеме, все поля имеют целочисленный тип.

Если пользовательскую таблицу join'ить к «modResource»:

$query = $modx->newQuery('modResource');
$query->select(array('modResource.id AS resourceId'));
$query->innerJoin('sRelations', 'sRelations', array('sRelations.id1:=' => 5));

то число 5 парсится как строка:

SELECT modResource.id AS resourceId
FROM `modx_site_content` AS `modResource`
JOIN `sRelations` `sRelations` ON `sRelations`.`id1` = '5'

Каковы минусы реализации системы баннеров не на собственных таблицах, а на стандартных ресурсах + TV?

В качестве плюсов можно назвать:
1) Почти все поля-характеристики баннеров и позиций уже имеются у ресурсов. Связь баннеров и позиций реализуется с помощью TV с множественным выбором
2) Число переходов (кликов) будет считать стандартный счётчик просмотров ресурсов.
(Если же нужно будет фиксировать каждый клик и строить график, то достаточно будет в системе учёта просмотров ресурсов реализовать фиксацию каждого просмотра)
3) Каждый пользователь-непрограммист сможет добавлять новые характеристики баннерам и позициям и использовать их стандартным способом (тем самым, расширяя функционал баннерной системы)
4) При изменении в новых версиях особенностей реализации архитектуры modx баннерная система не «поломается»

Удивительно, но это факт. При открытии окна редактирования ресурса вывожу сообщение в логи с текстом ($modx->event->name). Сначала получаем OnDocFormRender, затем OnDocFormPrerender.

После обновления modx 2.2.14 => 2.3.0 => 2.3.2 обнаружил, что все uri ресурсов оказались перегенерированы стандартным генератором modx. Так и должно быть?

uri для всех ресурсов я генерирую плагином на OnDocFormSave и OnResourceDuplicate (по собственному алгоритму). Но после обновления modx все uri оказались идентичны псевдонимам. Никто не обратил внимание?

Если это не глюк, а запрограммированное поведение, то нужно что-то предпринимать. Например, использовать заморозку (но при следующем обновлении снова нужно будет проверить, может и замороженные uri modx перегенерирует).

modx revo 2.3.2, Ace 1.5.0
Заметил такой артефакт. Если переименовать папку assets, а в /core/config/config.inc.php оставить без изменений, то при загрузке админки (например, загрузка страницы для какого-нибудь сниппета) правая часть окна останется пустой. При этом:
а) никаких ошибок в логах php/apache (уровень логирования — максимальный)
б) никаких ошибок в логах modx (уровень логирования «warnings»)
в) ручная очистка кэша modx ничего не меняет

Понятно, что причина здесь в Ace (хотя, кто его знает, может, modx виноват). Но таких ситуаций в корректной программной системе быть не должно. Либо нужно отказываться от компонентов, приводящих к таким ситуациям, либо найти быстрый способ выявления причины без трассировки кода.

При выполнении скриптов (сниппетов и плагинов) modx создаёт в папке cache/include/elements/ include-файлы в виде функций, содержащих код этих скриптов. Далее подключает эти файлы и вызывает содержащуюся в них функцию. Всё логично.
При включении в настройках modx кэширования скриптов (cache_scripts) modx дополнительно к include-файлам создаёт в папке cache/script/elements/ кэш-файлы с содержимым будущих include-файлов (т.е. содержимое кэш-файлов дублирует содержимое будущих include-файлов).

Логика работы modx при обработке скрипта (плагина или снипппета) при включенном кэшировании скриптов следующая (modscript.class.php):

1) Проверяется наличие include-файла
2) Если include-файл существует и актуален (при хранении скрипта во внешнем файле), то этот файл подключается и выполняется содержащаяся в нём функция
3) Если include-файл отсутствует или неактуален (при хранении скрипта во внешнем файле):
а) проверяется наличие кэш файла скрипта
б) если кэш-файл существует, modx получает его содержимое и помещает в include-файл (далее с созданным include-файлом выполняется п.2)
в) если кэш-файл отсутствует, он создаётся + это же содержимое помещается в include-файл (далее с созданным include-файлом выполняется п.2)

В этой логике непонятна роль кэш-файла скрипта, поскольку:

В целях ускорения метода invokeEvent() возникла задача перегрузить класс modx.
Собственно, перегрузить класс и написать свой invokeEvent(), как оказалось, самая простая часть задачи. Сложнее выполнить подмену стандартного класса modX своим.

В исходных кодах объект modX создаётся в 4 местах:
1) При инициализации контекста «web»: в index.php
2) При инициализации контекста «mgr»: в connectors/index.php, manager/index.php и manager/min/index.php

Со временем в modx полностью никак не разберусь.
1. Если в настройках modx задать [server_offset_time = 1], то modx должен считать, что локальное время, отображаемое в админке, должно на час превышать локальное время сервера. В частности, время изменения файла, отображаемое на странице редактирования файла в modx, должно на (server_offset_time) часов превышать серверное время изменения файла. Что получаем на практике (всё наоборот):