Іван Клімчук

Как выше Василий подметил, это уже текущие расходы бизнеса, к стоимости разработки сайта отношения не имеют.

DO в любом случае дороже. Я за свой сервер в РБ (из-за требований законодательства) плачу вообще около 15$. Так что даже 3 евро с плавающим курсом мне было бы выгоднее. Тут конечно нужно смотреть по ситуации, согласен, но ресурсов у scaleway больше в 4 раза, чем у DO + это физический сервер. Можно при желании заменить несколько DO на один :)

Не за рубли, но ценник больно дешевый — 3 евро всего за 2 гига памяти и 4 ядра. www.scaleway.com/pricing/
Они продают железные настоящие ARM-серверы. У меня есть для рабочих нужд один такой, работает ок. Но под реальные нагрузки не проверял. Если под dev/pet проекты, то в самый раз.

Я их кстати делаю, дабы расшарить контент на англоязычную аудиторию. Но не все сразу. Ютуб русский хоть и распознает, но коряво. Так что буду рад помощи, так как времени отнимает много на самом деле. Час ушел на 15 минут видео про Gitify. Во всех видео включена настройка, которая позволяет присылать свои субтитры.

Не было необходимости, но нужную для вас информацию через API вытянуть можно. Т.е. логика по ее обработке все равно понадобится, но не нужно будет все эти данные хранить у себя. Если я не ошибаюсь, то вроде Лев Вербицкий что-то подобное хотел писать, можно у него спросить или предложить такое сделать.

Ну окей, tech.yandex.ru/metrika/?ncrnd=285 — вот апи. Весь учет поведения (настроить тоже можно как угодно, включая цели и тд) берет на себя метрика, через апи на сайте делается логика.

Я не вижу смысла в вашем случае такие объемы данных генерировать и хранить у себя. Что вы будете делать через год, когда база вашего трекинга разрастется до несколькоих десятков гигабайт? А по вашей логике код должен эту базу каждый раз шерстить и выдавать то, что показать пользователю.

А не проще ли поставить яндекс.метрику?

Какой мобильник? У меня на андроиде можно. Не так удобно как на десктопе, но уведомления приходят и можно пользоваться.

Василий там почти всегда (ну только если не спит в это время), я тоже всегда онлайн. Пишите, спрашивайте. Там все англочзычные разработчики и фанаты MODX. Кто-то более активен, кто-то менее, все же люди работают, а не по чатам шастают и только и ждут, чтобы всем без устали отвечать :) Ну и про часывые пояса забывать не стоит, Джейсон ночью тоже спит, просыпается в 14:00 по MSK.

Да, есть. rtfm.modx.com/revolution/2.x/getting-started/installation/git-installation

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

За помощь спасибо, правда из-за особенностей ЯД пока не могу ими воспользоваться, жду подтверждения идентификации.
В ближайшие недели будет, вместе с небольшим обновленим Gitify, которое я анонсировал на минском митапе. Ну и видео с него тоже будет, вернее оно уже есть, но я жду, когда ребята отдатут все смонтированные доклады, чтобы выложить все разом.

Таки да, спасибо. Все же мечта сделать сайт на чистом femon близка к правде. А то из-за особенности pdoPage пришлось отказаться в свое время. Теперь пора вернуть как было :)

В таком случае да, одного плагина будет недостаточно. Нужно инджектить в страницу админки ExtJS плагин, который будет слушать события на кнопке save и или даже следить за отправкой запроса и получением ответа и после этого делать какой-то рефреш полей. Задачка интересная, но слегка бесполезная, мне кажется.

Я выше написал как можно сделать, Джейсон другое решение предложил.

В реализации это не статический метод, на то есть причины. Достаточно посмотреть в исходники.

public function cleanAlias($alias, array $options = array()) {
    return $this->xpdo->call($this->_class, 'filterPathSegment', array(&$this->xpdo, $alias, $options));
}

Как видно, вызывается функция filterPathSegment в то же классе, которая уже отвечает за обработку непосредственно. Вот она уже статическая и при желании ее можно использовать напрямую.

modResource::filterPathSegment($modx, $alias);

Так они и так же без перезагрузки страницы сохраняются, за исключением моментов, когда создается полностью новый ресурс. В таком случае сохраненного ресурса еще нет, потому и требуется перезагрузка страницы. Так же перезагрузка случается, если сменить шаблон, так как нужно загрузить новые TV, привязанные к новому шаблону.
Опишите, что вам нужно сделать, а не как вы хотите и собираетесь сделать. Т.е. саму прикладную задачу или проблему. Возможно уже есть решение, но мы пока не поняли до конца суть задачи.

Ок, понятно, что данные будут считаться и тд. Но вот такой вопрос, есть допустим товар и у него какой-то параметр (например просмотры) равен 20 153. За 5 минут эта цифра увеличится на 113 единиц и станет 20 266. Мне как посетителю не критично знать сколько там конкретно просмотров у этой страницы, примерно 20 тыс и ладно. Поэтому ничего не мешает эту информацию кешировать на N минут. И я уверен, что таких параметров будет большинство. Реальные данные для одного-двух параметров можно оставить и то, если это критически важно, остальное все можно и нужно кешировать, ибо без кеширования это будет создавать бесполезную нагрузку.

Плюс есть такое понятие как отложенные вычисления. Если нужно что-то посчитать, то нет смысла это делать прямо сейчас. Пускай система записывает данные в master, к мастеру можно настроить slave, доступный только для чтения, оптимизированный под выборки, не обремененный блокировками записи. Расчетные показатели могут обсчитываться в фоне крон-скриптами или ругим ПО, например не на PHP, а на Go (что быстрее в разы) и добавляться в базу по мере обработки.

В hiload принято кешировать все и вся и настоящие realtime системы – это очень узкая ниша, поэтому не нужно думать, что пользователю понадобится непременно вся актуальная иформация в данный момент, особенно на простом сайте или интернет-магазине.

Ох, докупать мощности сервера только из-за просадки на паре запросов? Это пушкой по воробьям, достаточно поставить любой кеширующий слой и настроить его. Если выборка не критичная для получения realtime данных (на большинстве сайтов так и есть), то ничего не мешает ее кешировать в тот же редис на 10-20-30 минут и драматически снизить нагрузку в случае большой посещаемости. Поиск тоже делать через специаильный поисковые движки, которые позволяют построить оптимальный индекс, адаптированный именно для поиска по ключевым словам/фразам. Подводя небольшой итог: возможностей для оптимизации – вагон, увеличивать мощности последняя задача, которую следует рассматривать только в комлексе оптимизации архитектуры, а не просто увеличить памяти и ресурсов процессора.

Отличное решение! Планируется ли возможность создания собственных шаблонов квитанции и счета? Ибо сейчас только для РФ это актуально, насколько я понял.