Допустим, адрес вашего сайта — site.com, и директория, где он находится на сервере — /var/www/site.com. По умолчанию ассеты будут складываться в директорию /var/www/site.com/_run/, которая будет доступна по URL site.com/_run/.
Но вы, к примеру, заводите специальны домен static.com и хотите, чтоб js/css брались оттуда. Тогда задаете так:
В Альто все js- и css-файлы (если они, конечно, правильно заданы) подключаются из директории /_run. Делаете маппинг этой директории на другой домен и задаете соответствующие настройки в конфиге. Вот настройки по умолчанию:
Как можно увидеть, можно задать любой путь на диске для ассетов и любой урл для подключения. Нужно только сервер правильно настроить, чтоб и маппинг верно работал, и чтоб прав хватало.
Типографика работает так, как это задано в конфиге.
В текущей версии Альто есть два типографа — Jevix и Qevix. Я рекомендую Qevix, но вообще нужный типограф включается в конфиге (app/config/config.local.php):
$config['module']['text']['parser'] = 'Qevix'; // Text parser class: Jevix or Qevix
Настройки типографов по умолчанию задаются в common/config/jevix.php и в common/config/qevix.php. Но вы можете их изменить, задав свои правила в app/config/jevix.php или в app/config/qevix.php в зависимости от используемого типографа. Если нужного файла нет в app/config/, то создайте его, скопировав из common/config/, и скорректируйте правила так, как вам нужно.
Но учтите главное правило типографа: запрещено все, что явно не разрешено. А по умолчанию разрешены заголовки только h4, h5 и h6, а тег h3 явно не разрешен, следовательно, он вырезается.
А если серьезно то ORM который реализован в альто это полный звиздец
Во-первых, уважаемый, Вы плохо читаете, ибо я в самом начале статьи сказал, что «Лайвстритовскую реализацию ORM в части задания критериев для выборки данных я считаю просто ужасной». И по этой причине ORM не используется в базовой версии движка, хотя большинство запросов к БД довольно тривиально, и, казалось бы, этот подход тут был бы вполне уместен.
Во-вторых, внедрение AR вовсе не исключает применения и прежнего подхода — использования старого доброго SQL. Если считаете, что каждый запрос в базе непременно должен руками описываться в виде SQL-выражений — Вы можете делать это и впредь, ни в чем себя не ограничивая.
А что-то меняли в настройках? С настройками по умолчанию работает все. Посмотрел по коду — есть подозрение, что теоретически такая ошибка может быть, но воспроизвести ее не могу
Тут вот какая штука: то, что хук определен, еще вовсе не означает, что существует обработчик хука. Если обработчик есть — хук выполняется, если нет — он просто игнорируется.
Но есть и второй очень важный нюанс: даже если обработчик уже определен, то это вовсе не мешает определить свой обработчик. Вы можете написать свой плагин, который будет задавать обработчик хука, и выглядеть это будет примерно так (допустим, плагин называется test и тогда файл обработчика будет такой: common/plugins/test/classes/hooks/HookTest.class.php):
class PluginTest_HookTest extends Hook {
// регистрация обработчиков хуков
public function RegisterHook() {
// для шаблонного хука добавляем префикс 'template_'
// имя метода-обработчика может быть любым
$this->AddHook('template_content_begin', 'HookTplContentBegin');
}
public function HookTplContentBegin() {
// Вывод заносим в переменную $sResult;
return $sResult;
}
}
Я бы так сказал: участвовать в разработке Альто, что-то предлагать, выдавать пуллреквесты на гитхабе могут и сейчас все желающие и вообще без всяких условий.
Но вот вписываться в крутой вираж, кардинально меняя траекторию движения, я готов только с тем, кто готов за это отвечать, кто согласен разделить не только потенциальный успех, но и возможный провал. А как же иначе-то?
Эх, как красиво все начиналось, и как банально заканчивается. :( Все ж есть очень большие сомнения, что Вы хотя бы изучили движок, прежде чем говорить о нем (ну, хотя бы для того, чтоб лучше понять для себя, как делать не надо).
...я читал ещё в первой половине нулевых в известной вам книге 94 года выпуска
Надеюсь, не станете Вы утверждать, что и в PHP это все используется аж с 94-го года? Будете смеяться, но паттерн «внедрение зависимостей» я использовал еще тогда, когда программировал на машинах СМ-14хх/СМ-13хх, оформляя интерфейсы на Pascal-2, а тело процедур программируя на ассемблере, хоть самого этого модного термина в программировании тогда еще не было (угадайте, когда это было). Но дело-то ведь не в том, что и когда было придумано, мы ведь говорим о CMS на PHP со всеми вытекающими, не правда ли? Ну, вот и давайте об этом и будем.
...до сих пор по коду щедро разбросаны include-ы?
Слегка офигел. А «щедро» — это сколько в штуках? Вот конкретно сколько инклудов в коде Альто (давайте только не будем считать директиву Смарти «include», ибо это совсем иное, и оставим за рамками сторонние библиотеки)? Вы реально считали или так, лишь бы сказать?
Про магические методы — вы ничего не путаете?
Не путаю ничего ни на грамм. И в CI, и в Yii, и в Symfony они есть. И какая разница, кого чем поливали, если «все леди делают это»? Но вот что «в том же Symfony на 30МБ зависимостей их вне тестов определяют раз десять» — это шок для меня. Десять? Правда? В Yii, если не ошибаюсь, раза два-три. В Альто, если убрать гири совместимости с ЛС — тоже. Так о чем идет речь? Да это о чем угодно, только не про Альто.
А финал ожидаем по сути, но несколько неожиданный по форме:
А вы мне предлагаете с незнакомым человеком три года тянуть вола за яйца
Во-первых, Вы, по Вашему же признанию, год уже его тянете (ага, « я уже год в отрыве от работы собираю требования и провожу эксперименты»).
Во-вторых, я предлагал-то ровно обратное: я (будучи открытым и невиртуальным) предложил совершенно незнакомому мне анониму работать вместе, рискуя своей репутацией.
Но нет, так нет, буду с нетерпением ждать через полгода из Тайги с Bear CMS :)
Нашел такой док..., но не знаю насколько он подходит
Для общего понимания — подходит, для практического применения — не очень. Развернутой документации, к сожалению, нет. Можно только рекомендовать изучать код плагинов и задавать конкретные вопросы: как сделать то-то.
Не, ну конечно, если не знать, что в Альто используются такие штуки (или как там выше было сказано — «достижения php–программирования последних лет»), как обсерверы, декораторы, автозагрузка psr0 и psr4, то да, как бы все так же. И то, что классы ядра, включая Engine и Router можно заменить — это тоже мало кто знает, в чем, не спорю, моя вина, ибо внятной документации нет до сих пор. Всего этого и духу не было в ЛС 1.0.х (за ЛС 2.0 особо не слежу). А вот _CallModule, кстати, в нынешнем коде живет исключительно как дань совместимости, но ему осталось жить не так уж и долго.
Вот с чем согласен безоговорочно, так с двумя вещами: с тем, что терминология в ЛС, перетекшая в Альто, мягко говоря, не совсем удачна, и с тем, что граф зависимостей слишком запутан.
Класс конфига, который снаружи, какбэ, выглядит так же, переписывался полностью пару раз и нонче существенно быстрее и гибче — вот тут, конечно, сильно на любителя. Мне лично эта идея с точками-разделителями страшно нравится. На мой взгляд, это чрезвычайно удобная штука. Но за это удобство приходится расплачиваться оверхедом — против этого не попрешь.
А вот насчет внезапного негатива в адрес «магических» методов удивлен. А что, есть нонче серьезные движки на PHP, где «магические» методы не используются совсем? По-моему, эта фича (при некоторых ее недостатках) сегодня одна из наиболее востребованных абсолютно везде. Не, есть, конечно, без «магических» методов, но с декларацией и автогенерацией кода, что, на мой взгляд, гораздо хуже.
Но это ладно, это все лирика. Вопрос в лоб: есть желание делать суперсовременный Альто 2.0, вбухивая в проект время и деньги, года два-три без всякой реальной отдачи? Ок, давайте обсудим концепцию, архитектуру и — вперед. Я поддержу даже такую слегка бредовую идею, как запил движка аж под PHP7. Это неплохой маркетинговый ход будет — первая CMS разработанная сразу под «семерку». Вот только под react работать на текущем этапе я не готов (возможно, в будущем, но не сейчас).
Идет? Но только одно условие — это должна быть серьезная и долгосрочная работа и без всякой анонимности. Если просремся — пусть все знают имена «героев».
День начался с замечательно комментария. Нет, правда, я нисколько не иронизирую — первый коммент мне очень понравился, хоть и а) сам не знаю почему; б) я с ним не согласен по многим тезисам.
И я, честно говоря, даже стал набрасывать текст ответа, полагая, что это такая серьезная концептуальная дискуссия намечается. Но вот второй коммент озадачил: а о чем вообще речь? Так и хочется спросить: «Вы сайтом не ошиблись, уважаемый? Это не Лайвстрит, это — Альто!»
Но вы, к примеру, заводите специальны домен static.com и хотите, чтоб js/css брались оттуда. Тогда задаете так:
ЗЫ все примеры вымышленные, реальные пути до директорий доменом на вашем сервере могут отличаться
Как можно увидеть, можно задать любой путь на диске для ассетов и любой урл для подключения. Нужно только сервер правильно настроить, чтоб и маппинг верно работал, и чтоб прав хватало.
В текущей версии Альто есть два типографа — Jevix и Qevix. Я рекомендую Qevix, но вообще нужный типограф включается в конфиге (app/config/config.local.php):
Настройки типографов по умолчанию задаются в common/config/jevix.php и в common/config/qevix.php. Но вы можете их изменить, задав свои правила в app/config/jevix.php или в app/config/qevix.php в зависимости от используемого типографа. Если нужного файла нет в app/config/, то создайте его, скопировав из common/config/, и скорректируйте правила так, как вам нужно.
Но учтите главное правило типографа: запрещено все, что явно не разрешено. А по умолчанию разрешены заголовки только h4, h5 и h6, а тег h3 явно не разрешен, следовательно, он вырезается.
Во-вторых, внедрение AR вовсе не исключает применения и прежнего подхода — использования старого доброго SQL. Если считаете, что каждый запрос в базе непременно должен руками описываться в виде SQL-выражений — Вы можете делать это и впредь, ни в чем себя не ограничивая.
Но вообще надо бы добавить лог вызовов хуков в плагин для разработчика
Но есть и второй очень важный нюанс: даже если обработчик уже определен, то это вовсе не мешает определить свой обработчик. Вы можете написать свой плагин, который будет задавать обработчик хука, и выглядеть это будет примерно так (допустим, плагин называется test и тогда файл обработчика будет такой: common/plugins/test/classes/hooks/HookTest.class.php):
Но вот вписываться в крутой вираж, кардинально меняя траекторию движения, я готов только с тем, кто готов за это отвечать, кто согласен разделить не только потенциальный успех, но и возможный провал. А как же иначе-то?
Надеюсь, не станете Вы утверждать, что и в PHP это все используется аж с 94-го года? Будете смеяться, но паттерн «внедрение зависимостей» я использовал еще тогда, когда программировал на машинах СМ-14хх/СМ-13хх, оформляя интерфейсы на Pascal-2, а тело процедур программируя на ассемблере, хоть самого этого модного термина в программировании тогда еще не было (угадайте, когда это было). Но дело-то ведь не в том, что и когда было придумано, мы ведь говорим о CMS на PHP со всеми вытекающими, не правда ли? Ну, вот и давайте об этом и будем.
Слегка офигел. А «щедро» — это сколько в штуках? Вот конкретно сколько инклудов в коде Альто (давайте только не будем считать директиву Смарти «include», ибо это совсем иное, и оставим за рамками сторонние библиотеки)? Вы реально считали или так, лишь бы сказать?
Не путаю ничего ни на грамм. И в CI, и в Yii, и в Symfony они есть. И какая разница, кого чем поливали, если «все леди делают это»? Но вот что «в том же Symfony на 30МБ зависимостей их вне тестов определяют раз десять» — это шок для меня. Десять? Правда? В Yii, если не ошибаюсь, раза два-три. В Альто, если убрать гири совместимости с ЛС — тоже. Так о чем идет речь? Да это о чем угодно, только не про Альто.
А финал ожидаем по сути, но несколько неожиданный по форме:
Во-первых, Вы, по Вашему же признанию, год уже его тянете (ага, « я уже год в отрыве от работы собираю требования и провожу эксперименты»).
Во-вторых, я предлагал-то ровно обратное: я (будучи открытым и невиртуальным) предложил совершенно незнакомому мне анониму работать вместе, рискуя своей репутацией.
Но нет, так нет, буду с нетерпением ждать через полгода из Тайги с Bear CMS :)
Вот с чем согласен безоговорочно, так с двумя вещами: с тем, что терминология в ЛС, перетекшая в Альто, мягко говоря, не совсем удачна, и с тем, что граф зависимостей слишком запутан.
Класс конфига, который снаружи, какбэ, выглядит так же, переписывался полностью пару раз и нонче существенно быстрее и гибче — вот тут, конечно, сильно на любителя. Мне лично эта идея с точками-разделителями страшно нравится. На мой взгляд, это чрезвычайно удобная штука. Но за это удобство приходится расплачиваться оверхедом — против этого не попрешь.
А вот насчет внезапного негатива в адрес «магических» методов удивлен. А что, есть нонче серьезные движки на PHP, где «магические» методы не используются совсем? По-моему, эта фича (при некоторых ее недостатках) сегодня одна из наиболее востребованных абсолютно везде. Не, есть, конечно, без «магических» методов, но с декларацией и автогенерацией кода, что, на мой взгляд, гораздо хуже.
Но это ладно, это все лирика. Вопрос в лоб: есть желание делать суперсовременный Альто 2.0, вбухивая в проект время и деньги, года два-три без всякой реальной отдачи? Ок, давайте обсудим концепцию, архитектуру и — вперед. Я поддержу даже такую слегка бредовую идею, как запил движка аж под PHP7. Это неплохой маркетинговый ход будет — первая CMS разработанная сразу под «семерку». Вот только под react работать на текущем этапе я не готов (возможно, в будущем, но не сейчас).
Идет? Но только одно условие — это должна быть серьезная и долгосрочная работа и без всякой анонимности. Если просремся — пусть все знают имена «героев».
И я, честно говоря, даже стал набрасывать текст ответа, полагая, что это такая серьезная концептуальная дискуссия намечается. Но вот второй коммент озадачил: а о чем вообще речь? Так и хочется спросить: «Вы сайтом не ошиблись, уважаемый? Это не Лайвстрит, это — Альто!»
Про MVC и сущности в Альто: http://altocms.ru/1584.html и http://altocms.ru/1585.html
Про «hello world!» как-то не очень понятно, что писать, т.к. это ж CMS, и, в отличие от фреймворка, продукт сразу готов к употреблению.