Если более конкретно отвечать на вопрос, то непосредственно с базой данных работает соответствующий компонент Mapper, и в случае с юзером это ModuleUser_MapperUser. И именно там есть методы для сохранения, обновления, получения и удаления данных юзера.
Но править код непосредственно движка — плохая практика. Для расширения функциональности надо использовать либо хуки, либо плагины.
Я наивно полагал, что бесплатный ресурс, заточненный под разработчиков (а не разработчикам там вообще непонятно, о чем речь) — это вполне себе тема для Хабра. Ан нет! Тут же прилетело НЛО: «Реклама это. Извольте на месяц в баню»
Можно пойти проторенным путем — делается site.com с основным скином и, напр., m.site.com с мобильным. Оба сайта работают с одной базой, но скины у них разные. И это можно хоть сейчас сделать, без всяких доработок. Либо можно плагин написать, который будет УРЛ вида site.com/m/... обрабатывать, подставляя мобильный скин.
Это все как раз совсем несложно по сравнению с созданием самого мобильного скина. Вот здесь, например, говорится, что «нельзя использовать другие js-скрипты, кроме самой AMP и ее расширений», а это уже очень серьезное ограничение. Если это так, то мало того, что придется выкинуть jquery и все jq-плагины, так еще и весь фронтенд-функционал переписать в виде AMP-расширений. В общем, задача прямо-таки героическая
Да, получается, что у каждой страницы должно быть 2 шаблона, обычный и AMP
Немного не так: это должен быть отдельный мобильный скин. И движок, определяя тип устройства у юзера, отдает сайт либо в заданном скине, либо в AMP. Как раньше делали обычную версию сайта и мобильную, так вот и здесь придется делать.
Это все, безусловно, хорошо, и юзерам удобно. Вопрос только в том, какой ценой это все достигается.
Поддержка AMP — это, фактически, создание нового шаблона с нуля. И приходим к тому, от чего, казалось бы, уже ушли — создание специализированного мобильного шаблона
Крик души хорошо понимаю. Более того, когда-то похожий крик души послужил одним из побудительных мотивов к созданию Альто :)
Что касается сути вопроса — совместимости Альто и ДАО, — то задача эта, на мой взгляд очень даже решаема. А уж совместимость на уровне шаблонов — это не просто, а очень просто, было б желание. Вот только решить ее полностью в одиночку я не могу, увы.
Дело в том, что на этом сайте используется несколько устаревшая версия ДАО, она не обновляется (да и необходимости особой в этом нет). Плюс те, кто в теме, знают, что ДАО — это не один плагин, а семейство плагинов. И у меня в пользовании далеко не полный комплект. К тому же ДАО штука довольно навороченная и вариантов использования может быть великое множество, а потому протестировать все кейсы на одном сайте представляется маловероятным.
В общем, все, что можно было сделать для совместимости со стороны движка (и плагина совместимости) — давно сделано, все (известные мне) баги несовместимости исправлены. Хотя, нет, если быть более точным — было одно обращение относительно совместимости Альто 1.1.х и ДАО, но речь шла о версии ДАО-плагина, для меня недоступной, а с автором плагина владелец сайта, видимо, так ни до чего и не договорился. Либо автор плагина решил эту проблему на своей стороне без моей помощи. Во всяком случае, ко мне больше никто не обращался.
Итого: суть обращения понятна, но оно должно быть чуть-чуть по другому адресу
Что касается будущего. Ветка LS 1.0.x, став родителем Альто, умерла. Как умирает мать при родах. Пытаться развивать новый движок и одновременно обеспечивать совместимость с мертвой веткой другого (пусть и родственного) движка становится все сложнее и напряжнее. Поэтому постепенно, но уверенно близится тот день, когда придется «резать к чертовой матери, не дожидаясь перитонитов». И я посчитал правильным заранее предупредить об этом тех, для кого это может быть важно.
AR не привносят нового функционала или новых возможностей по получению и/или обработке данных. Они лишь значительно уменьшают трудозатраты на кодирование, позволяя не углубляться в написание SQL-запросов. Достаточно будет описать модель и связи. Плюс этот подход значительно упрощает абстрагирование от конкретного движка БД.
При этом возможность написания SQL руками, конечно же, остается. Но ORM легко может покрыть львиную долю операция с БД, оставив за «чистым» SQL особо сложные случаи
Есть две причины, из-за которых работа (теоретически) может замедлиться:
1) Затраты ресурсов, связанные с инициализацией объектов
2) Неоптимальные итоговые SQL-запросы
По п.1 надо будет, конечно, внимательно смотреть и анализировать, и постараться по максимуму задействовать кеширование. Но пока я смотрю на это со сдержанным оптимизмом, и у меня нет оснований считать, что производительность просядет.
А по п.2 вообще все получается интересно — я думаю, что общее число запросов к базе может даже уменьшиться, т.к. будет использован механизм «ленивых связанных коллекций», благодаря которому дополнительные связанные данные могут подгружаться только тогда, когда они действительно нужны.
Сударь, ежели сим утверждением Вы хотите констатировать, что данное творение есть творение умов скудных и жалких, а посему не желаете Вы знаться с нами, то, Бог с Вами, не стану я Вам возражать. И уж тем более мне нечего Вам предложить в Ваш рацион из экзотических колючих растений. А потому предлагаю воздержаться от дальнейших словопрений, и разойтись с миром. И не нужно колдовать над клонами бестелесными — пустая это трата времени и Вашего и моего.
Сударь, позвольте выразить Вам крайнее неудовлетворение сим непотребным текстом. Каким бы не было Ваше негодование и душевное возмущение, но соизвольте-таки использовать выражения, более приличествующие собранию сему. Ибо не на извозную площадь изволили Вы явиться, но в место, где крайне не поощряется столь непотребное поведение. И дамы, опять же, имеют обыкновение сюда захаживать. И по оным резонам, сударь, сдается мне, что придется посетить Вам банные помещения денька, эдак на три, дабы пораздумать над словами своими и выводы сделать, какие следует
В разделе Модули переходите в «Мои лицензии», там скачиваете лицензию для этого плагина и кладете ее вместо той, что идет с плагином по умолчанию. Эта информация есть в письме, которое вам было отправлено
Данные, задаваемые через админку пишутся в базу. И в файловый кеш они попадают уже из базы. Поэтому, в данном случае, бесполезно удалять кеш, нужно решить проблему первоисточника.
Вариант 1: Можно просто сбросить все исправления, которые вносились через админку. Это в админке Инструменты — Сброс данных — Сброс конфигурации. Но надо иметь ввиду — будут сброшены ВСЕ исправления через админку.
Вариант 2: Он посложнее — это прямо в базе данных в таблице prefix_storage удалить отдельные записи.
Но для начала рекомендовал бы обновиться до 1.1.19, возможно, имеет место баг, который был исправлен в релизе.
Если более конкретно отвечать на вопрос, то непосредственно с базой данных работает соответствующий компонент Mapper, и в случае с юзером это ModuleUser_MapperUser. И именно там есть методы для сохранения, обновления, получения и удаления данных юзера.
Но править код непосредственно движка — плохая практика. Для расширения функциональности надо использовать либо хуки, либо плагины.
Это все как раз совсем несложно по сравнению с созданием самого мобильного скина. Вот здесь, например, говорится, что «нельзя использовать другие js-скрипты, кроме самой AMP и ее расширений», а это уже очень серьезное ограничение. Если это так, то мало того, что придется выкинуть jquery и все jq-плагины, так еще и весь фронтенд-функционал переписать в виде AMP-расширений. В общем, задача прямо-таки героическая
Это все, безусловно, хорошо, и юзерам удобно. Вопрос только в том, какой ценой это все достигается.
Что касается сути вопроса — совместимости Альто и ДАО, — то задача эта, на мой взгляд очень даже решаема. А уж совместимость на уровне шаблонов — это не просто, а очень просто, было б желание. Вот только решить ее полностью в одиночку я не могу, увы.
Дело в том, что на этом сайте используется несколько устаревшая версия ДАО, она не обновляется (да и необходимости особой в этом нет). Плюс те, кто в теме, знают, что ДАО — это не один плагин, а семейство плагинов. И у меня в пользовании далеко не полный комплект. К тому же ДАО штука довольно навороченная и вариантов использования может быть великое множество, а потому протестировать все кейсы на одном сайте представляется маловероятным.
В общем, все, что можно было сделать для совместимости со стороны движка (и плагина совместимости) — давно сделано, все (известные мне) баги несовместимости исправлены. Хотя, нет, если быть более точным — было одно обращение относительно совместимости Альто 1.1.х и ДАО, но речь шла о версии ДАО-плагина, для меня недоступной, а с автором плагина владелец сайта, видимо, так ни до чего и не договорился. Либо автор плагина решил эту проблему на своей стороне без моей помощи. Во всяком случае, ко мне больше никто не обращался.
Итого: суть обращения понятна, но оно должно быть чуть-чуть по другому адресу
Что касается будущего. Ветка LS 1.0.x, став родителем Альто, умерла. Как умирает мать при родах. Пытаться развивать новый движок и одновременно обеспечивать совместимость с мертвой веткой другого (пусть и родственного) движка становится все сложнее и напряжнее. Поэтому постепенно, но уверенно близится тот день, когда придется «резать к чертовой матери, не дожидаясь перитонитов». И я посчитал правильным заранее предупредить об этом тех, для кого это может быть важно.
AR не привносят нового функционала или новых возможностей по получению и/или обработке данных. Они лишь значительно уменьшают трудозатраты на кодирование, позволяя не углубляться в написание SQL-запросов. Достаточно будет описать модель и связи. Плюс этот подход значительно упрощает абстрагирование от конкретного движка БД.
При этом возможность написания SQL руками, конечно же, остается. Но ORM легко может покрыть львиную долю операция с БД, оставив за «чистым» SQL особо сложные случаи
1) Затраты ресурсов, связанные с инициализацией объектов
2) Неоптимальные итоговые SQL-запросы
По п.1 надо будет, конечно, внимательно смотреть и анализировать, и постараться по максимуму задействовать кеширование. Но пока я смотрю на это со сдержанным оптимизмом, и у меня нет оснований считать, что производительность просядет.
А по п.2 вообще все получается интересно — я думаю, что общее число запросов к базе может даже уменьшиться, т.к. будет использован механизм «ленивых связанных коллекций», благодаря которому дополнительные связанные данные могут подгружаться только тогда, когда они действительно нужны.
А по процедуре обновления все то же: http://altocms.ru/689.html
Единственный нюанс: если вы использовали Jevix, как-то особо его настраивали и хотите дальше его использовать — об этом здесь в самом начале сказано.
Вариант 1: Можно просто сбросить все исправления, которые вносились через админку. Это в админке Инструменты — Сброс данных — Сброс конфигурации. Но надо иметь ввиду — будут сброшены ВСЕ исправления через админку.
Вариант 2: Он посложнее — это прямо в базе данных в таблице prefix_storage удалить отдельные записи.
Но для начала рекомендовал бы обновиться до 1.1.19, возможно, имеет место баг, который был исправлен в релизе.