Anonymous
Кокоин уже не модно, но все привыкли.
Кокаин, это не стареющая классика. Или Вы не про наркотик?
Alexander
Dark
А модификаторы его это полный ахтунг , в ядре они не нужны
Позволю с вами не согласиться. Штука удобная, позволяет заменить кучу сниппетов, ускорить работу страниц и снизить количество запросов к БД (если вместо модификаторов использовать самописные сниппеты). Плюс из ядра они более шустро работают. Дайте человеку просто допилить их нормально.
Глебка
А кто сможет сделать мне фильтр Чекбоксами по 2м тв?
Dmytro
Могу но за $ )
Глебка
Ну естно
Глебка
Ну давай я те в скайп писану)
Dark
@zvyagingk, вот зачем вы человека отвлекаете, ему CMS доделывать нужно :)
alexx
зарабатывать тоже нужно
Evgeny
Блин жаль, нужна была помощь по рево, эво я думал загнулась совсем
Dmytro
ДА по рево тоже можем подсказать )
Dmytro
Чего это Ево загибаться 🙂?
Раньше Здесь Был Мат_
Это система, чьё имя не называют)
Раньше Здесь Был Мат_
Я про 1с
Evgeny
Хорошо. Я не особо дружу модкс, в основном битрикс. Стойте не спешите закрывать телеграмм... Стоит задача сделать небольшой сайтик на модкс рево. Суть в том, что я дошел до интеграции новостей, использую компонент ТИКЕТС, у меня не получается вывести в анонсе (в списке новостей), фотографию, которая бралась бы из детальной новости
Evgeny
да)))
Evgeny
потому что у рево нет чата
Evgeny
может приютите?
Andrews
Хитро
Женечка
есть
Andrews
может приютите?
Конечно, стоит всего лишь выучить Evolution
Женечка
https://t.me/ru_modx
Dark
Bitrix - это, конечно, треш еще тот. Это переплетение php и html это нечто. Занимаюсь иногда мелкими правками на этой системе.
Evgeny
все там норм
Evgeny
в плане доков и апи
Evgeny
ненужно учить непонятный синтаксис в модкс
Evgeny
Все спасибо всем пока....
Раньше Здесь Был Мат_
Dark
А в плане доков и API это вообще триндец - попытка найти там что-то в этой горе документации то еще издевательство
Dark
Это я про битрикс
Раньше Здесь Был Мат_
Ну контрол+ф всегда выручает)))
Andrey
Или "ок Гугл"
Сергей
Позволю с вами не согласиться. Штука удобная, позволяет заменить кучу сниппетов, ускорить работу страниц и снизить количество запросов к БД (если вместо модификаторов использовать самописные сниппеты). Плюс из ядра они более шустро работают. Дайте человеку просто допилить их нормально.
это где это эта штука ужасно удобная? [!Breadcrumbs[*template:is(`7`):or:is(`17`):then=`?&showCurrentCrumb=0`*]!] это в каком это месте заменяет кучу сниппетов и ускоряет работу страниц и снижает количество запросов в БД ? вы в курсе что если попадается хоть один модификатор, то сразу подгружается огромный класс, чуть ли не больше самого парсера с кучей модификаторов. Хорошо что ещё с боем удалось сделать возможность отключения и модификаторов и тегов Яма <@> Тот же плагин Twig, экономит не только кучу времени, но и заменяет все однострочные сниппеты, либо IF на раз и кэшер свой с анлимом доков. И в разы быстрее всех этих модификаторов. Плюс, так же поддерживается Доклистером.
Dmytro
А как оно визуально красиво и читабельно это вообще огонь
Dmytro
подскажите что я делаю не так что собирая сайты у меня штук 5-10 чанков и 1-2 самописных снипета?
Dmytro
о каких тучах самописных снипетов идет речь не пойму:(
Сергей
там еще это все надо обернуть в теги с @ что б совсем все было круто 🙂
это обязательно нужно сделать. ибо планирую модуль с кнопкой - "Сделать чтобы было всё быстро" ну и в коде модуля обычная регулярка, которая нахрен вырезает все яматеги из парсера, и заменяет кривые функции исправленные Ямой на те что работали годами ))
Dark
Ну значит, что я не прав, утверждая, что скорость сайта становится выше. Это были сугубо мои предвзятые заключения, основанные на недостаточно репрезентативной выборке, без должной теоретической базы. Сугубо на эмпирических полученных данных.
Alexander
Dark
Ну а по поводу сниппетов, у меня на отдельных сайтах до 20 сниппетов и чанков под сотню. А на других как у Дмитрия
Сергей
Ну а по поводу сниппетов, у меня на отдельных сайтах до 20 сниппетов и чанков под сотню. А на других как у Дмитрия
до версии 1.3.3 можно было делать как угодно, но на последних версиях, модификаторы уже стали раковой опухолью парсера
Сергей
ладно бы косяки то были в новых решениях, но он губит старые
Dark
На 1.3.6 у меня норм, существенного падения скорости не заметил. А вот удобство есть, только злоупотреблять не нужно. То что в примере выше, это уже перебор
Alexander
ладно бы косяки то были в новых решениях, но он губит старые
Они меня не слушают(( Они еще просто не встревали в ямовские косяки
Сергей
теперь надо писать мануал по настройке... если хотите ускорить сайт в 10 раз, отключите теги <@>, не забудьте что кэш не очищается как прежде при сохранении документови других элементов в админ панели.
Сергей
На 1.3.6 у меня норм, существенного падения скорости не заметил. А вот удобство есть, только злоупотреблять не нужно. То что в примере выше, это уже перебор
с тегами <@> и модификаторами загрузка страницы - 0,1, без них было 0,04, а теперь стало 0,009. а на глаз это не заметно
Dark
ну вот я сегодня встрял
Видно, меня это просто еще не задело то, за что все ругают косяки Ямы. Плюс я вижу результаты исследований коллег относительно влияния модификаторов, которые полностью противоположны моим результатам. Вывод, я немного не прав, проблемы явно не на пустом месте возникли.
No
всссссссссссссссссс
No
кошка :)
Dark
Пока оптимальный вариант, это пусть Яма допиливает ядро, а пока мелкие правки проводить на базе текущей версии 1.3.* , которая относительно стабильна.
Dmytro
я 1.3 оставил на случай багов или критических изменений а так остальное уже в 1,4 просто пилить мелочи отдельно а потом переносить в 1.4 более трудоемко
Dark
Полностью согласен. Но судя по льющемуся негативу в сторону Ямы, версия 1.4 сильно далека от стабильности. Поэтому я и написал выше о возможном варианте
Dark
всё верно) много времени уходит чтобы найти ошибки, которых просто не должно было быть
Ну если делать рефакторинг (читай переписать заново), то нет ничего удивительного, что такие проблемы возникают. От нас зависит только, чтоб их было меньше за счет поиска багов.
Dmytro
О вспомнил пароль от клиентского сайта 🙂 http://take.ms/L2YVQ
Dmytro
это для тех кто думает что в EVO есть ограничения в 5000 документов 🙂
Dmytro
не много ни мало 1 лям )
Сергей
Ну если делать рефакторинг (читай переписать заново), то нет ничего удивительного, что такие проблемы возникают. От нас зависит только, чтоб их было меньше за счет поиска багов.
повторю чуть громче. теперь кэш не чистится при сохранении доков. то есть при выходе версии 1.4 на нас выльется куча недоумения. Ибо то что всегда работало, теперь не будет работать
Dmytro
Надо яме писать все баги. Выполнять роль тестеров
Сергей
не много ни мало 1 лям )
вот отличный хомячок для теста))
Dmytro
Могу сделать копию 🙂
Сергей
Могу сделать копию 🙂
да, надо бы, на хостинг потом закинуть и версии сравнить, пару тройку установок сделать, 1.1RC, релиз и бету
Dark
Вопрос, а с чем связано то, что решили отказаться от очистки Кеша после сохранения документов?
Dmytro
это баг
Anonymous
не баг, а фича
Сергей
Вопрос, а с чем связано то, что решили отказаться от очистки Кеша после сохранения документов?
это Яма так решил, аргументируя, чтобы не было нагрузки на больших сайтах
Dark
А его нельзя обойти костылем в виде плагина на событие сохранения документа и вызовом API очистки кэша?
Сергей
можно) но не проще ли было сделать плагин, который при количестве к примеру 5000 тыс доков отключает автоочистку кэша, либо вынести количество в конфигурацию
Сергей
а веселее всего узнать это методом тыка, а не в теме - "Что нового в бете".
Dark
а веселее всего узнать это методом тыка, а не в теме - "Что нового в бете".
Полностью согласен, это нехорошо. Но тут Дима пишет, что это баг, значит или эту правку отменят или введут ограничения, например предложенные вами
Dmytro
ну да правильно нельзя менять логику того что в базе
Dmytro
все новое тольок через настройку или допом