Комментарии 41
"[[Wayfinder?startId=`0`]]"! Ну конечно! Как логично! Как я сразу не догадался, всего-то написать "[[Wayfinder?startId=`0`]]" и появится меню!
Судя по всему это сарказм…
Да, в MODX можно написать [[Wayfinder?startId=`0`]] и появится меню (если на сайте вообще страницы заведены).
Это стандартный MODX-компонент: modx.com/extras/package/wayfinder
Это знаете ли, как выполнить jQuery(element).hide(), и элемент магическим образом скроется с глаз. Надо только jQuery знать и подключить ее на страницу.
Да, в MODX можно написать [[Wayfinder?startId=`0`]] и появится меню (если на сайте вообще страницы заведены).
Это стандартный MODX-компонент: modx.com/extras/package/wayfinder
Это знаете ли, как выполнить jQuery(element).hide(), и элемент магическим образом скроется с глаз. Надо только jQuery знать и подключить ее на страницу.
Как будет при этом выглядеть вызов того же Wayfinder?
Я делал на modx (evo) несколько сайтов и для меня первой проблемой было как раз вот это — выяснить какие у сниппета параметры, как они точно называются и за что конкретно отвечают.
Вторая проблема была — вспомогательные по отношению к текущему шаблону вещи (чанки), которых для большого вызова сниппета (Ditto, в частности) требовалось изрядное количество. Они тоже уйдут куда-то во внешний код?
Я делал на modx (evo) несколько сайтов и для меня первой проблемой было как раз вот это — выяснить какие у сниппета параметры, как они точно называются и за что конкретно отвечают.
Вторая проблема была — вспомогательные по отношению к текущему шаблону вещи (чанки), которых для большого вызова сниппета (Ditto, в частности) требовалось изрядное количество. Они тоже уйдут куда-то во внешний код?
Хороший вопрос.
Элементы MODX можно вызывать двумя способами:
1. Используя синтаксис MODX. Тот же [[Wayfinder?startId=`0`&level=`1`&limit=`10`]]
Сначала идет имя объекта, а после знака вопроса можно перечислить передаваемые параметры.
2. Вызвать этот объект через API MODX. К примеру мы получим тоже самое, написав на PHP:
То есть отказываясь от парсера, мы не теряем возможности работать ни с каким из MODX-пакетов. Так или иначе пока я оставил MODX-парсинг внутри компонента, пока не будет до конца все оттестировано. Но в любом случае, даже если парсер будет отключен полностью, на уровне своих пользовательских скриптов всегда можно будет получить MODX-парсер и обработать код. Это конечно сложнее, чем использовать MODX в базовой комплектации, но при правильном подходе можно получить выигрыш по скорости в разы. Пруфф: community.modx-cms.ru/blog/documentation/9193.html
Так что мой компонент не меняет MODX-механизма в целом. Он просто дает новые возможности.
Элементы MODX можно вызывать двумя способами:
1. Используя синтаксис MODX. Тот же [[Wayfinder?startId=`0`&level=`1`&limit=`10`]]
Сначала идет имя объекта, а после знака вопроса можно перечислить передаваемые параметры.
2. Вызвать этот объект через API MODX. К примеру мы получим тоже самое, написав на PHP:
$output = $modx->runSnippet('Wayfinder', array(
'startId' => 0,
'level' => 1,
'limit' => 10,
));
То есть отказываясь от парсера, мы не теряем возможности работать ни с каким из MODX-пакетов. Так или иначе пока я оставил MODX-парсинг внутри компонента, пока не будет до конца все оттестировано. Но в любом случае, даже если парсер будет отключен полностью, на уровне своих пользовательских скриптов всегда можно будет получить MODX-парсер и обработать код. Это конечно сложнее, чем использовать MODX в базовой комплектации, но при правильном подходе можно получить выигрыш по скорости в разы. Пруфф: community.modx-cms.ru/blog/documentation/9193.html
Так что мой компонент не меняет MODX-механизма в целом. Он просто дает новые возможности.
К примеру для того, чтобы получить на своей странице меню, достаточно прописать [[Wayfinder?startId=`0`]]А зачем изобретать какие-то «теги», что мешает реализовать это в виде <?= new MenuView($startId = 0) ?> с правильным образом реализованным MenuView::__toString()? Понятно и новичкам и всем прочим, что MenuView это определённый класс с определёнными аргументами в конструкторе, и никакие доки не нужны, IDE всё сама подскажет.
Вообще, мне немножко непонятна необходимость этого (кроме, разве что, для выигрыша лишних 10-20 мс производительности). Чем плохи теги, особенно если их грамотно кешировать?
Есть основной шаблон, в него тегами вставляются блоки. У каждого блока своя логика. Зачем использовать т.н. «шаблонизаторы»?
Наоборот существующая структура по-моему позволяет горахдо эффективней отделить собственно шаблон от функциональных блоков с контентом. При этом у каждого блока тоже может быть своё оформление, если вставлять не сниппеты напрямую в шаблон, а чанки, и уже из чанков вызывать сниппеты.
Тут главное о кешировании не забывать, конечно, иначе конечно оверхед будет действительно сильным. Но всё же — можете пояснить идею?
Есть основной шаблон, в него тегами вставляются блоки. У каждого блока своя логика. Зачем использовать т.н. «шаблонизаторы»?
Наоборот существующая структура по-моему позволяет горахдо эффективней отделить собственно шаблон от функциональных блоков с контентом. При этом у каждого блока тоже может быть своё оформление, если вставлять не сниппеты напрямую в шаблон, а чанки, и уже из чанков вызывать сниппеты.
Тут главное о кешировании не забывать, конечно, иначе конечно оверхед будет действительно сильным. Но всё же — можете пояснить идею?
кроме, разве что, для выигрыша лишних 10-20 мс производительностиРечь не о 10-20мс, а о выигрыше порой в разы. Покажите свой самый шустрый сайт на MODX Revolution. Если он будет код отдавать менее чем за 150 мс., я уже буду удивлен. Даже для сайтов-визиток 0.2-0.3 сек. — нормальная практика. А вот парень жалуется, что страница грузится 20+ сек.
Сайт, с которым я сейчас веду эксперименты, отдает код за 90-120 мс. Само собой и на хостинг нагрузка снижена.
Обычными методами кеширования этого не добиться, тем более с обильным использованием чанков. Я систему кеширования MODX очень хорошо знаю. И могу сказать точно: она не идеальна. Хороша и довольно универсальна для новичков, но не идеальна из-за универсальности.
Но всё же — можете пояснить идею?Но еще очень важный момент: не мало любителей есть шаблонизаторов типа Smarty и т.п. (и я не против Смарти). Так вот, то, как сейчас работает MODX, не позволяет просто так воткнуть Smarty. Да, админка на Смарти работает, но в админке и все запросы обрабатывает не modRequest и modResponse, а modManagerRequest и modManagerResponse. Для того же, чтобы использовать во фронтенде Смарти, придется писать замену modRequest. А иначе фигня полная получится. С моим модулем можно без всяких костылей подключать Смарти и т.п.
Ок, с производительностью, хоть и немного спорно, но пожалуй не буду спорить с вашим опытом. Хотя, ИМХО, если корректно прослеживать, где что кешируется, всё вполне реально (например, выводы из той вашей статьи вполне логичны для меня, ничего необычного и сложного не увидел — так и думал, что так всё и обрабатывается).
А вот причину использовать Smarty в MODX не вижу никакой — MODX создан сам по себе как шаблонизатор. На крайний случай, для этого можно использовать те же сниппеты — вызов из шаблона одного единственного сниппета, который и будет являться Smarty парсером. А сам шаблон Smarty хранить, например, в чанке. Или вообще в отдельном файле.
А вот причину использовать Smarty в MODX не вижу никакой — MODX создан сам по себе как шаблонизатор. На крайний случай, для этого можно использовать те же сниппеты — вызов из шаблона одного единственного сниппета, который и будет являться Smarty парсером. А сам шаблон Smarty хранить, например, в чанке. Или вообще в отдельном файле.
Вот как раз по этому поводу мы холивары точно не будем устраивать. Каждый использует для себя то, что хочет. Тем более если это просто сайт-визитка, так там вообще нечего заморачиваться.
Но пакет не накладывает ограничений. Это ведь отдельный тип ресурсов. То есть используйте базовый modResource, и все будет работать как и работало. Но если по каким-либо причинам нужен вызов сразу php-файла, то просто тип документа меняете на phpTemplateResource и все. Ничего более делать не нужно.
Но пакет не накладывает ограничений. Это ведь отдельный тип ресурсов. То есть используйте базовый modResource, и все будет работать как и работало. Но если по каким-либо причинам нужен вызов сразу php-файла, то просто тип документа меняете на phpTemplateResource и все. Ничего более делать не нужно.
Меня больше волнует факт о том, что «идею поддержали на самом верху», и опасение, что развитие MODX пойдёт по этому пути…
«На верху» не пустят развитие MODX по плохому пути. И никто не говорит, что MODX-парсер надо убирать. Речь только идет о том, чтобы дать возможность выбора. Скорее всего это выльется в нативную возможность выбора парсера/шаблонизатора, чтобы каждый разработчик смог выбирать именно тот инструмент, который ему привычней и интересней.
Я не первый год плотно с MODX работаю, и это не первое мое решение, которое как-то расширяет базовый MODX. Тот же сайт MODX-сообщества modx-cms.ru работает на моем пакете modLivestreet, обеспечивающим связку MODX+LivestreetCMS, что тоже не стандартное решение.
Так что не могу сказать, что это решение не подпитано большим опытом.
Я не первый год плотно с MODX работаю, и это не первое мое решение, которое как-то расширяет базовый MODX. Тот же сайт MODX-сообщества modx-cms.ru работает на моем пакете modLivestreet, обеспечивающим связку MODX+LivestreetCMS, что тоже не стандартное решение.
Так что не могу сказать, что это решение не подпитано большим опытом.
Я не первый год плотно с MODX работаю, и это не первое мое решение, которое как-то расширяет базовый MODX. Тот же сайт MODX-сообщества modx-cms.ru работает на моем пакете modLivestreet, обеспечивающим связку MODX+LivestreetCMS, что тоже не стандартное решение.
Так что не могу сказать, что это решение не подпитано большим опытом.
С чем с чем, а с вашим большим опытом разваливать 5 летнее сообщество за 1 месяц сложно поспорить.
Хорошее у вас решение modLivestreet
Особенно радует совместимость с REVO
Правда я так и не понял что куда интегрировали но судя по вот этому:
Это не связка MODX+LS
а совсем наоборот
Особенно радует совместимость с REVO
Правда я так и не понял что куда интегрировали но судя по вот этому:
Это не связка MODX+LS
а совсем наоборот
Еще один плюс: только что получил результаты.
За счет этого решения сумел сократить кеш документа с почти 100 кило до 1,5 килобайт. Если документ не кешируемый, то в MODX это совсем плохо. Если же он кешируемый, то хоть документ и нормально грузится, кеш у него просто ппц, из-за того, что все элементы внутри него кешируеются в ассоциативный массив для поддержания управления кешем отдельных вложенных объектов. У меня есть сайт на 60 000 страниц, так вот за недельку у него собирается несколько гигабайт кеша (кеш одной странички там 120-200 кило). Если у меня закешируются все страницы, это будет под 10 гигов.
За счет этого решения сумел сократить кеш документа с почти 100 кило до 1,5 килобайт. Если документ не кешируемый, то в MODX это совсем плохо. Если же он кешируемый, то хоть документ и нормально грузится, кеш у него просто ппц, из-за того, что все элементы внутри него кешируеются в ассоциативный массив для поддержания управления кешем отдельных вложенных объектов. У меня есть сайт на 60 000 страниц, так вот за недельку у него собирается несколько гигабайт кеша (кеш одной странички там 120-200 кило). Если у меня закешируются все страницы, это будет под 10 гигов.
Вот это действительно плюс, согласен. Но данное решение, ИМХО, полумера…
Тут надо ещё смотреть, как именно работает парсер MODX, возможно его сам по себе можно оптимизировать, тогда бОльшая часть проблем с производительностью исчезнет и не придётся хранить такие большие массивы данных.
Тут надо ещё смотреть, как именно работает парсер MODX, возможно его сам по себе можно оптимизировать, тогда бОльшая часть проблем с производительностью исчезнет и не придётся хранить такие большие массивы данных.
Это вряд ли получится. Так как MODX-элементы в рамках одного ресурса могут быть и как правило вложенные, плюс какие-то кешируемые, какие-то нет, то и приходится где-то кешировать. В разных файлах — еще хуже получится. Потому они и набиваются в один кеш.
Ну почему же. Всё равно кешируемость определяется на самом высоком возможном уровне. Условно говоря, надо просто при первом кеширующем проходе развернуть все кешируемые сниппеты и сохранить только их значения — останутся в итоге только некешируемые. Собственно, если сейчас мы имеем (беру из Вашей статьи, 3 пример):
и
То получится просто:
И вообще без elementCache. Единственное, можно, возможно, прописать, какой нибудь массив со всеми элементами, которые там закешированы:
При инвалидации кеша любого из элементов перечисленных в cachedElements мы просто полностью пересобираем кеш странички. Why not?
<?php return array (
'resourceClass' => 'modDocument',
'resource' =>
array (
'id' => 1,
'type' => 'document',
....................
'content' => '[[snippet1]]
[[snippet2]]
[[snippet3]]',
и
'elementCache' =>
array (
'[[*pagetitle]]' => 'Home',
'[[snippet1]]' => '<br />1352835306',
'[[snippet2]]' => '<br />1352835306',
'[[snippet3]]' => '[[!snippet2]]',
),
То получится просто:
<?php return array (
'resourceClass' => 'modDocument',
'resource' =>
array (
'id' => 1,
'type' => 'document',
....................
'content' => '<br />1352835306
<br />1352835306
[[!snippet2]]',
И вообще без elementCache. Единственное, можно, возможно, прописать, какой нибудь массив со всеми элементами, которые там закешированы:
"cachedElements" => array( "snippets" => array("snippet1", "snippet2", "snippet3")),
При инвалидации кеша любого из элементов перечисленных в cachedElements мы просто полностью пересобираем кеш странички. Why not?
1. Закешированный элемент может встретиться несколько раз, потому разумно держать кеш этого элемента именно в ассоциативном массиве elementCache, чтобы можно было вызывать в любом месте.
2. Вся эта фигня происходит из-за того, что одни и те же элементы могут быть вызваны в нескольких местах, при чем как кешируемые, так и тут же не кешируемые. Такой безобразный массив к сожалению является лучшим решением.
Кеш-манагером занимаются не один год, и не думаю, что можно вот так вот сесть, и придумать что-то получше. Конечно вы можете напрограммировать свой парсер и кеш-манагер, MODX позволяет подключать сторонние решения. А вось и будет лучше работать.
2. Вся эта фигня происходит из-за того, что одни и те же элементы могут быть вызваны в нескольких местах, при чем как кешируемые, так и тут же не кешируемые. Такой безобразный массив к сожалению является лучшим решением.
Кеш-манагером занимаются не один год, и не думаю, что можно вот так вот сесть, и придумать что-то получше. Конечно вы можете напрограммировать свой парсер и кеш-манагер, MODX позволяет подключать сторонние решения. А вось и будет лучше работать.
Поговорю с разрабами MODX на эту тему, заинтриговали.
Между тем, немного не понимаю, что вы имеете ввиду под «Закешированный элемент может встретиться несколько раз».
Респарсинг вот такого вот:
Мне кажется что будет гораздо менее производительно, чем просто:
В первом случае нам надо кешированные теги каждый раз перепарсить, во втором — нет. По количеству хранимой информации тоже меньше выходит.
Ведь перегенерация кеша всё равно будет осуществляться на основании оригинального документа из БД, нам нет необходимости хранить всю информацию об уже закешированных тегах.
Между тем, немного не понимаю, что вы имеете ввиду под «Закешированный элемент может встретиться несколько раз».
Респарсинг вот такого вот:
"content" => "[[snippet1]]/[[snippet1]]/[[snippet1]]/[[snippet1]]/[[snippet1]]",
"elementCache" => array(
"snippet1" => "sometext",
)
Мне кажется что будет гораздо менее производительно, чем просто:
"content" => "sometext/sometext/sometext/sometext/sometext",
"cachedElements" => array( "snippets" => array("snippet1")),
В первом случае нам надо кешированные теги каждый раз перепарсить, во втором — нет. По количеству хранимой информации тоже меньше выходит.
Ведь перегенерация кеша всё равно будет осуществляться на основании оригинального документа из БД, нам нет необходимости хранить всю информацию об уже закешированных тегах.
А теперь представьте, что snippet1 содержит под мегабайт кода. А прописан он 5 раз. Это так, на вскидку. Плюс надо ковырять досконально парсер. К примеру не до конца ясно, он все пять сниппетов будет поочередно перебирать, или только один обработает, и пять раз заменит его в content. В таком случае парсеру легче будет пробезаться по нескольким байтам кода в content, и обработать один сниппет, чем пройтись по коду, в пять раз превышающему код одного элемента.
Лучше пусть хранится «чистый контент» на 5 мегабайт по 5 раз, чем будет оверхед на добавление в строку всё тех же 5 мегабайт по 5 раз (копирование, да ещё и с заменой. Ведь тут нужно:
1. Расширить строку на эти 5 мегабайт
2. Сдвинуть текст который уже есть чтоб расчистить место по середине строки
3. Собственно скопировать
4. Повторить ещё 4 раза). В конце концов, те же 5 раз по 5 мегабайт отправятся клиенту. В данном случае экономия на месте — экономия на спичках. ИМХО.
1. Расширить строку на эти 5 мегабайт
2. Сдвинуть текст который уже есть чтоб расчистить место по середине строки
3. Собственно скопировать
4. Повторить ещё 4 раза). В конце концов, те же 5 раз по 5 мегабайт отправятся клиенту. В данном случае экономия на месте — экономия на спичках. ИМХО.
По логике да, но вы видимо не совсем понимаете как MODX-парсер работает. Кеширование документа не означает, что этот кеш не будет обрабатываться, и будет выплевываться как есть. Нет. После того, как весь этот кеш будет получен объектом modResponse, этот объект прежде чем выплюнуть все это дело, тщательно все это дело опять пропарсит, и только потом конечный код уже отдаст браузеру. И парсить он будет как раз вот этот _content (конечно правильней сказать _content, потому что content — это контент самого документа, а _content — это весь код вместе с шаблоном). И вот именно его парсер и будет парсить каждый раз, при чем дважды.
И вот считайте, что мы и докопались до сути проблемы. Этим своим решением я максимально сокращаю парсинг-код. Плюс, имея возможность выполнять php-код сразу в шаблоне, а не дожидаясь того, когда MODX-соберет в кучу все мои элементы, и начнет все это дружно парсить, я могу прервать процесс, принтнув уже конечный HTML-код и выполнив exit();
То, как это работает сейчас, считайте что просто почти невозможно.
/* collect any uncached element tags in the content and process them */
$this->modx->getParser();
$maxIterations= intval($this->modx->getOption('parser_max_iterations', $options, 10));
$this->modx->parser->processElementTags('', $this->modx->resource->_output, true, false, '[[', ']]', array(), $maxIterations);
$this->modx->parser->processElementTags('', $this->modx->resource->_output, true, true, '[[', ']]', array(), $maxIterations);И вот считайте, что мы и докопались до сути проблемы. Этим своим решением я максимально сокращаю парсинг-код. Плюс, имея возможность выполнять php-код сразу в шаблоне, а не дожидаясь того, когда MODX-соберет в кучу все мои элементы, и начнет все это дружно парсить, я могу прервать процесс, принтнув уже конечный HTML-код и выполнив exit();
То, как это работает сейчас, считайте что просто почти невозможно.
Ну так я о том и говорю. Мы избавимся при помощи моего способа от лишних (уже закешированных) тегов в _content, и парсеру не придётся каждый раз их заново распарсить.
Я прекрасно понимаю, что вы пытались найти обход всё той же проблеме, но ваше решение этой проблемы — лишь обход самой проблемы, о чём я и говорю с начала этой ветки. Говорю, тут надо с разрабами MODX обсудить, почему было выбранно именно такое решение, с необходимостью повторного репарса уже закешированных тегов. Незакешированные — с ними всё понятно, проход при отдаче контента необходим, но вот если можно «пропустить» уже закешированные — почему не сделать это?
Я прекрасно понимаю, что вы пытались найти обход всё той же проблеме, но ваше решение этой проблемы — лишь обход самой проблемы, о чём я и говорю с начала этой ветки. Говорю, тут надо с разрабами MODX обсудить, почему было выбранно именно такое решение, с необходимостью повторного репарса уже закешированных тегов. Незакешированные — с ними всё понятно, проход при отдаче контента необходим, но вот если можно «пропустить» уже закешированные — почему не сделать это?
Говорю, тут надо с разрабами MODX обсудитьКого именно вы имеете ввиду? Rayn Thrash и Jay Gilmore поддержали мое решение. И они не сказали, что мое решение половинчатое.
Вы всерьез думаете, что вот так вот на раз-два придумали, как улучшить парсер? Думаете, ребята там несколько лет ерундой страдают, а все на самом деле очень просто?
Вы лучше не обсуждайте тогда, а попробуйте сделать новый парсер на замену, вот тогда будет о чем разговаривать предметней.
Я хочу обсудить с ними, почему было выбрано именно это решение для парсера. Тогда будет просто понятней, вот и всё. Возможно, я что-то упускаю, а они же смогут подсказать.
В частности, по Core делам надо говорить с Jason Coward (opengeek) и Shaun McCormick (splittingred), больше с Jason как главным архитектором. Ryan — больше идейный вдохновитель.
Вариант с Custom Resource довзоляющим использовать php код — это одно, а реализация парсера — это другое.
И да, когда я пойму эти причины, если не буду с ними согласен — я действительно собираюсь попробовать написать другой парсер.
PS: ни в коей мере не хотел вас как-то обидеть, извините, если ненароком так вышло.
В частности, по Core делам надо говорить с Jason Coward (opengeek) и Shaun McCormick (splittingred), больше с Jason как главным архитектором. Ryan — больше идейный вдохновитель.
Вариант с Custom Resource довзоляющим использовать php код — это одно, а реализация парсера — это другое.
И да, когда я пойму эти причины, если не буду с ними согласен — я действительно собираюсь попробовать написать другой парсер.
PS: ни в коей мере не хотел вас как-то обидеть, извините, если ненароком так вышло.
Николай, твои эксперименты по разрушению MODX уже нисколько не забавляют. Я не знаю, что именно ты делаешь, но положительных результатов пока и близко нет.
Вот мой сайт, на чистом, 100% MODX. 0.5 — 1 сек.!
Вот сайт сообщества, с твоей связкой. 2 — 6 сек..
Чем объяснишь такую разницу в скорости? Плохим сервером, моей низкой нагрузкой, пятнами на солнце? Или 2 CMS — в два раза тормознее? Из другой точки и вовсе 20 — 30 сек., это вообще за гранью.
Если ты не можешь построить быстрый сайт на MODX — не надо отрезать от него лучшие куски. Ну или иди сразу в чистый php и не сверли мозг окружающим. MODX очень крут именно разделением оформления и логики, засовывание php в шаблоны — это худшее что может случиться с системой.
Я работаю уже очень давно, и квалификация моя не вызывает сомнений у сообщества, однако таких идей даже мельком не приходило в голову. MODX — быстрый, это доказано.
Требую демонстрации твоего скоростного сайта — после этого можно будет судить о вменяемости этих методов. Пока вижу только попытку превратить хорошую CMS в говнокод.
Вот мой сайт, на чистом, 100% MODX. 0.5 — 1 сек.!
Вот сайт сообщества, с твоей связкой. 2 — 6 сек..
Чем объяснишь такую разницу в скорости? Плохим сервером, моей низкой нагрузкой, пятнами на солнце? Или 2 CMS — в два раза тормознее? Из другой точки и вовсе 20 — 30 сек., это вообще за гранью.
Если ты не можешь построить быстрый сайт на MODX — не надо отрезать от него лучшие куски. Ну или иди сразу в чистый php и не сверли мозг окружающим. MODX очень крут именно разделением оформления и логики, засовывание php в шаблоны — это худшее что может случиться с системой.
Я работаю уже очень давно, и квалификация моя не вызывает сомнений у сообщества, однако таких идей даже мельком не приходило в голову. MODX — быстрый, это доказано.
Требую демонстрации твоего скоростного сайта — после этого можно будет судить о вменяемости этих методов. Пока вижу только попытку превратить хорошую CMS в говнокод.
Тест скорости домашнего сайта связки LiveStreet + MODX — modlivestreet.ru даёт те же дохлые результаты 3 — 8 секунд.
О чем тут говорить, кому там модыксовый парсер кажется медленным? Webpagetest.org утверждает, что о скорости автору заикаться не стоит, если он не может оптимизировать собственный сайт.
Чтобы не быть голословным — опять же, мой сайт на чистом MODX.
О чем тут говорить, кому там модыксовый парсер кажется медленным? Webpagetest.org утверждает, что о скорости автору заикаться не стоит, если он не может оптимизировать собственный сайт.
Чтобы не быть голословным — опять же, мой сайт на чистом MODX.
Всем известно, что loadimpact только канал забивает, реального результата производительности он не дает.
Сайт: www.radimax.ru
Можете с чистой совестью продолжать использовать MODX в чистом виде, это абсолютно личное дело каждого.
Сайт: www.radimax.ru
Можете с чистой совестью продолжать использовать MODX в чистом виде, это абсолютно личное дело каждого.
Вы смеетесь? и это ваша работата?
Хотя да, чего и следовало ожидать.
Уровень на высоте:
Фавикон от LS? или и тут у вас связка LS+MODX ???
Ресайз картинок на высоте:
Хотя да, чего и следовало ожидать.
Уровень на высоте:
Фавикон от LS? или и тут у вас связка LS+MODX ???
Ресайз картинок на высоте:
Да, это моя работа. И я не виноват, что менеджеры сайты заливают картинки не в соответствии с представленным ими же дизайном. Были согласованы одни пропорции, а заливаются картинки совершенно других пропорций.
Но вопрос: какое это отношение имеет к производительности? Сайт быстро работает, или нет? Судя по всему работает он быстро, но надо же было за что-то зацепиться.
Но вопрос: какое это отношение имеет к производительности? Сайт быстро работает, или нет? Судя по всему работает он быстро, но надо же было за что-то зацепиться.
И я не виноват
Вы должны предусмотреть таких менеджеров и обрабатывать картинки при загрузки изображений, ресайз никто не отменял.
какое это отношение имеет к производительности
Вы по как определяете? на глаз или на…
источник: www.webpagetest.org/result/121201_H1_15Y/
Судя по всему работает он быстро
Document Complete — 21.860s оооооооочень быстро работает, особенно если переходы делаем по Брендам.
Можете с чистой совестью продолжать использовать MODX в чистом виде, это абсолютно личное дело каждого.
Нет. не уважаемый Fi1osof, если бы вы сделали форк, и творили там свои… слово не могу подобрать, то это было бы ваше дело, а так, как вы используете Бренд MODX, своими… сново то слово, унижаете просто разработчиков — значит это дело общее.
Ответьте на вопрос.
1) Зачем вам MODX?
2) Зачем в вышеприведённом вами сайте LS+MODX, я там не вижу смысла ни первого, ни второго! У меня дочка увидела этот сайт и сказала: — Папа, дядя наверное с гор спустился, он не знает какой сейчас век?
3) Зачем вы себя пиарите и брешете в каждом посту, и самое главное, втираете свою брехню новичкам!
P.S. Вам больше нужен фрейм какой-нибудь изучить и издеваться там, а не ломать, то, что построено не вами.
Здесь то зачем?
Тест от Webpagetest.org показывает, что первый проход 25.319s, второй — 12.243s. Атас, какой быстрый!
А loadimpact говорит, что сайт без обработки картинок через phpthumb, с нулевой посещаемостью отдаётся за 4-7 сек, в начале.
Затем, мы внимательно смотрим, как график зависит от количества посещений и в итоге доходит до 35 сек!
Это не забивание канала, это тест отзывчивости сайта под нагрузкой. Подозреваю, что и тут виновата «чудосвязка» с LiveStreet, неясно зачем используемая. Причем, что LS, что MODX по отдельности отлично держат удар, а с твоей связкой — не очень.
Если ты начнешь делать сайты в соответствии со своими новыми идеями — страшно представить каких монстров мы еще увидим. Никто не запрещает этим заниматься дома, с выключенным светом. Но зачем тащить свои извращения на Хабр, где их могут увидетьдети начинающие программисты?
У тебя теперь есть своё собственное сообщество — там и надо этим заниматься. А здесь выходит только глобальный антипиар MODX.
X-Powered-By:LiveStreet CMS
Тест от Webpagetest.org показывает, что первый проход 25.319s, второй — 12.243s. Атас, какой быстрый!
А loadimpact говорит, что сайт без обработки картинок через phpthumb, с нулевой посещаемостью отдаётся за 4-7 сек, в начале.
Затем, мы внимательно смотрим, как график зависит от количества посещений и в итоге доходит до 35 сек!
Это не забивание канала, это тест отзывчивости сайта под нагрузкой. Подозреваю, что и тут виновата «чудосвязка» с LiveStreet, неясно зачем используемая. Причем, что LS, что MODX по отдельности отлично держат удар, а с твоей связкой — не очень.
Если ты начнешь делать сайты в соответствии со своими новыми идеями — страшно представить каких монстров мы еще увидим. Никто не запрещает этим заниматься дома, с выключенным светом. Но зачем тащить свои извращения на Хабр, где их могут увидеть
У тебя теперь есть своё собственное сообщество — там и надо этим заниматься. А здесь выходит только глобальный антипиар MODX.
отделение логики от шаблона это очень нужно и правильно, но не должно доходить до маразма как в модх. Собственно это основная причина почему пришлось отказать от этой системы
А можть ну его… php в смысле. Сразу на html страницы делать будем? Че мелочиться то? От парсера modx избавляться, php с html смешивать…
Мы не постеснялись получить официальный ответ от Jason Coward, главного архитектора и идеолога MODX Revolution.
Кто не силен, переведу:
Не знаю, в каком таком «верху» поддержали эту идею, но Jason явно не в курсе.
Кто не силен, переведу:
bezumkin: Jason, извини что беспокою. Можешь сказать нам пару слов по поводу чистого PHP в шаблонах MODX?
Некотjрое время назад у нас в сообществе появился «гений» с такими идеями, и он утверждает, что руководство MODX поддерживает их.
Вот ссылка на популярный российский ресурс с миллионами просмотров в сутки.
Так же он автор говносвязки modLivestreet.
Jason Coward: Я не одобряю это… Почему бы просто не использовать фреймворк на PHP
Agel_Nash: Российское сообщество не поддерживает эти идеи.
Мы можем показать ему твой ответ?
Jason Coward: И напомните ему, что основной концепт MODX это отделение представления от логики, который по своей сути будет разрушен чистым PHP
Не знаю, в каком таком «верху» поддержали эту идею, но Jason явно не в курсе.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MODX Revolution и php-шаблоны