Artem
короче, я понял
Sergey
Из плюсов то, что штатное и что подсветка прямо в редакторе включается. Это прикольно.
Artem
суть вопроса вот в чём Этот функционал, судя по интернету, нахер никому не упал. Заграница вообще любит JCE и не пользуется тини Информации на Stack Overflow, github, буржуйском джумла форуме вопросы об этом "примере кода" в тини поднимались аж раза 3, за последние 10 лет и всё сводилось к рекомендации "пользуйся JCE" А мне это не нравится! Я хочу чтоб всё по дефолту меня радовало!
Vladimir
@rkazhet не подскажешь ссылки?
Artem
А в чем твой вопрос?
хочу SQL! Хочу bash!
Artem
и чтобы это в редакторе выбиралось
Artem
Решение я нашёл. Но есть подозрение, что за столько лет жизни джумлы кто-то то должен был сделать хотьт что-то?
Vladimir
да делал николас вон ринат скинет ссылки
Eugene
это интересно, но.. по таким сервисам вопросы: - что будет, если картинка увеличена больше? там будет проверка или просто часть изображения на печать уйдет? юзеру нужно понимать, где края. - как быть с качеством изображений? человек может загрузить картинку с веб и получит кашу при печати. перевод расходников, возврат средств, убыток
Vladimir
а еще есть цветопередача
Vladimir
там всегда куча вопросов
Sergey
Да, есть
RINAT
@rkazhet не подскажешь ссылки?
https://github.com/nikosdion/plg_system_tinymod этот?
Vladimir
там потом ты еще кидал ссылки интересные
Artem
Да
Artem
примерно, то что нужно
Artem
только один недостаток. Нужно писать тупо весь объект, т.к. он подсовывает default из плагина вместо того, который тини поставил. А там опцый дофига.
Artem
ну это уже херня
RINAT
https://github.com/nikosdion/plg_system_tinymod этот?
Есть еще такое https://github.com/dgrammatiko/wysiwyg-tinymce-j4.1
Artem
Есть еще такое https://github.com/dgrammatiko/wysiwyg-tinymce-j4.1
Это немного не то. Это подтягивает стили для тини с активного шаблона фронтенда Но я вчера в потрохах editor ковырялся и там уже это реализовано
Artem
А вот плагин николоса - просто огонь
Artem
Он закрывает больную тему по многим пунктам настройки тини
Eugene
Партнёрами ispmanager в рамках программы по поиску ошибок была обнаружена уязвимость в ispmanager 6, позволяющая получить root-доступ к серверу.
Vladimir
⚡️Важно! Партнёрами ispmanager в рамках программы по поиску ошибок была обнаружена уязвимость в ispmanager 6, позволяющая получить root-доступ к серверу. Проблема уже решена, но для её устранения необходимо обновить панель до последней версии — stable 6.88.1 или beta 6.90.1. Для обновления панели до последней версии зайдите в раздел «Помощь» → «Читать о программе», выберите «Обновить продукт». Уязвимость также коснулась и ispmanager 5. На следующей неделе компания ispmanager подготовит решение по исправлению этой ситуации для 5 версии панели. Задержка обусловлена тем, что обновления для 5 версии и устаревших ОС больше не выходят и репозиторий отключен. На данный момент устранить уязвимость можно только с помощью обновления до последней версии ispmanager 6, вы можете обновиться самостоятельно или обратиться за помощью в нашу поддержку.
Vladimir
смешнее всего судьба владельцев isp 5 🙂
Vladislav
Купил себе logitech mx master 3s для удобства работы... Так у этой фигни из коробки колесико глючит. Сделал, блин, себе подарок, улучшил рабочие условия
Vladimir
лучше брать PRO
Vladimir
у мастер низкое разрешение
Vladimir
я купил недавно pro x lightspeed 2
Vladimir
безупречно все
Vladislav
Модели всего 1.5 года
Vladimir
Vladimir
Vladimir
32000 против 8000
Vladimir
Модели всего 1.5 года
но у них же есть гарантия
Vladislav
Судя по реддиту это поголовная проблема... Кстати в отзывах на pro тоже жалуются на скролл. Если у меня он периодически не работает, на pro он случайно срабатывает (самый популярный минус в отзывах)
Vladimir
вторая версия вышла несколько месяцев назад в октябре
Vladimir
и там решили этот вопрос кардинально
Vladimir
https://club.dns-shop.ru/digest/103761-predstavlena-topovaya-igrovaya-myishka-logitech-g-pro-x-superlight-2/
Vladislav
23к за мышку чет дороговато
Eugene
лучше брать PRO
заметил, что при скроллинге колесиком вниз, иногда открывается в новой вкладке что-то, что система посчитала ссылкой. хз как правильно объяснить. скроллишь текст вниз и 3-4 вкладки открыться может по ссылкам внутри пролистанного контента. это тюнится?
Eugene
ок
Eugene
да, точно
Eugene
а можно это отключить? не нужно просто
Vladislav
14 😉
Это где такие цены?
Igor
Это где такие цены?
https://www.dns-shop.ru/product/d42d1e7ae3f9ed20/mys-besprovodnaa-logitech-g502-x-plus-910-006167-cernyj/ Ну вот 502 x с RGB
Igor
либо PRO возми тут надо смотреть на весь и форму еще
Igor
502 высокая и тяжлее pro на 60г
Vladimir
Это где такие цены?
https://fragstore.ru/devaysy-ili-geymerskaya-perefiriya/igrovye-myshi/logitech/logitech-g-pro-x-superlight-2-wireless-white/
Vladimir
вот
Vladimir
у них можно получить скидку в 5%
Vladimir
то есть реальная цена 15к
Artem
Хотите маленький кейс из боли админа high-load проекта? Я никогда ранее не админил тяжело нагруженные сервисы. Понятия "масштабирование" для меня было чем-то далёким. И вот я столкнулся лицом-к-лицу с проектом, который обслуживает огромное кол-во пользователей. Для понимания, php-fpm работает в режиме 250 активных процессов и простаивают из них одновременно не больше 40. Nginx проксирует на php по 150-200 запросов в секунду, а заказы в админке появляются по 2-3 штуки в минуту. И вот я встрял на проблеме сессий. Где их хранить? В базе? Так с таким кол-вом обращений база тупо ляжет, т.к. каждый запрос к php - это операция update для базы. Плюс, сессий, в среднем, на 6-10 ГБ выходит На файлах? Тоже отпадает, т.к. диски ложатся от постоянного поиска по файловой системе Остаются не реляционные базы ключ—значение. В web'е принято использовать для этого memcached или redis (любая уважающая себя CMS имеет эти 2 драйвера в своей коробке) Что сказать про memcached? Он классный, быстрый, но не стабильный. Он хранит все данные в оперативной памяти и никуда их не бэкапит. Упала служба? Перезапустили сервис? Прощайте все пользовательские сессии! (прощайте корзины анонимных пользователей). Ещё и memcached не умеет в распределение на ноды, срепликацией (с кастылями это можно сделать, но будет крайне не стабильно) Остаётся redis! Он точно так же хранит все оперативные данные в RAM, но, в отличии от memcached, данные можно реплицировать, а так же он имеет инструменты восстановления данных после падения. Redis представляет 2 варианта: дамп в файл или ведение журнала. Дамп в файл позволяет быстро перезагружаться, но, в случае падения, это приводит к потери части данных. Файлы журналов позволяют сохранять оперативные данные каждую секунду, но приводят к очень медленному перезапуску. Я настроил комбинированный вариант, когда раз в час база дампится в файл, а промежуток между дампами логгируется в журнал. Таким образом, максимальный промежуток потерянных данных может составлять ~1сек Жил проект так долго и здорово. Но сейчас клиент решил запустить новую маркетинговую кампанию, от чего всплески набегов покупателей стали колоссальными. От этого кол-во сессий выросло, пришлось докинуть редису ещё 2гб ОЗУ, но теперь столкнулся с тем, что раз в час на системный диск (мой косяк) дампится база в 10гигов и просто укладывает диск и процессор. А в моменты маркетинговых рассылокпики посещаимости иду такие, что журнал redis начинает дёргать диск и опять вешается процессор на iowait. Вернулись опять к тормозам 😢 Какой вывод? Не нужно упарываться в монолиты! Распределяйте сервера. Думайте о горизонтальном масштабированиии проекта, т.к. бесконечное подкидываение ресурсов в сервера перестают оказывать хоть какой-то эффект в геометрической прогрессии.
Igor
Хотите маленький кейс из боли админа high-load проекта? Я никогда ранее не админил тяжело нагруженные сервисы. Понятия "масштабирование" для меня было чем-то далёким. И вот я столкнулся лицом-к-лицу с проектом, который обслуживает огромное кол-во пользователей. Для понимания, php-fpm работает в режиме 250 активных процессов и простаивают из них одновременно не больше 40. Nginx проксирует на php по 150-200 запросов в секунду, а заказы в админке появляются по 2-3 штуки в минуту. И вот я встрял на проблеме сессий. Где их хранить? В базе? Так с таким кол-вом обращений база тупо ляжет, т.к. каждый запрос к php - это операция update для базы. Плюс, сессий, в среднем, на 6-10 ГБ выходит На файлах? Тоже отпадает, т.к. диски ложатся от постоянного поиска по файловой системе Остаются не реляционные базы ключ—значение. В web'е принято использовать для этого memcached или redis (любая уважающая себя CMS имеет эти 2 драйвера в своей коробке) Что сказать про memcached? Он классный, быстрый, но не стабильный. Он хранит все данные в оперативной памяти и никуда их не бэкапит. Упала служба? Перезапустили сервис? Прощайте все пользовательские сессии! (прощайте корзины анонимных пользователей). Ещё и memcached не умеет в распределение на ноды, срепликацией (с кастылями это можно сделать, но будет крайне не стабильно) Остаётся redis! Он точно так же хранит все оперативные данные в RAM, но, в отличии от memcached, данные можно реплицировать, а так же он имеет инструменты восстановления данных после падения. Redis представляет 2 варианта: дамп в файл или ведение журнала. Дамп в файл позволяет быстро перезагружаться, но, в случае падения, это приводит к потери части данных. Файлы журналов позволяют сохранять оперативные данные каждую секунду, но приводят к очень медленному перезапуску. Я настроил комбинированный вариант, когда раз в час база дампится в файл, а промежуток между дампами логгируется в журнал. Таким образом, максимальный промежуток потерянных данных может составлять ~1сек Жил проект так долго и здорово. Но сейчас клиент решил запустить новую маркетинговую кампанию, от чего всплески набегов покупателей стали колоссальными. От этого кол-во сессий выросло, пришлось докинуть редису ещё 2гб ОЗУ, но теперь столкнулся с тем, что раз в час на системный диск (мой косяк) дампится база в 10гигов и просто укладывает диск и процессор. А в моменты маркетинговых рассылокпики посещаимости иду такие, что журнал redis начинает дёргать диск и опять вешается процессор на iowait. Вернулись опять к тормозам 😢 Какой вывод? Не нужно упарываться в монолиты! Распределяйте сервера. Думайте о горизонтальном масштабированиии проекта, т.к. бесконечное подкидываение ресурсов в сервера перестают оказывать хоть какой-то эффект в геометрической прогрессии.
2-3 фигня. Мы вон 36 выдержали без проблем. Rama же вообще штука опасная.
Igor
Держать базу в и резульатыты выполнения в RAM вообще можно разве что в статичных сайтах. Иначе постоянно будет что-то случаться.
Vladimir
Да. 😀 36 заказов в минуту у нас было
Vladimir
кстати хотел тебе рассказать про этот жуткий опыт
Igor
Это именно созданых. Так то наверное под 100 одновременно было. Просто лимит был на 36 товаров по 1 одному в заказе
Дмитрий
Всем привет. Посоветуйте профессиональный монитор 24-27 дюймов
Vladimir
@kernusr вот так было
Vladimir
Vladimir
Igor
Проблема же описанного текса скорее в маналите бд. Когда у тебя слишком много обращений в одной таблице
Дмитрий
какое разрешение надо
Разрешения не важно, главное чтоб монитор хороший был