DataLife Engine v.11.3 Press Release

[celsoft 6 082]

Выпущен пресс релиз по предстоящим нововведениям в версии 11.3 https://dle-news.ru/pressrelease/1718-datalife-engine-v113-press-release.html#comment

[Captain 625]

Ух ты, спасибо, почитаем. 

[holistic 24]

В 01.04.2017 в 13:43, celsoft сказал:

Выпущен пресс релиз по предстоящим нововведениям в версии 11.3 https://dle-news.ru/pressrelease/1718-datalife-engine-v113-press-release.html#comment

Боюсь спросить разработчика, по поводу:

 

* 31. Добавлена типографская обработка текста для визуальных редакторов TinyMCE и Froala, а также произведены общие улучшения правил типографской обработки текстов.

 

Скажите, вы часом, снова не ввели принудительную расстановку символов неразрывных пробелов (   ) в тексте новости (на уровне кода)?

 

Снова не будет того ужаса, который был несколько лет назад, с реальным "весом" текста в связи с абсолютно ненужными сущностями в итоговом тексте, когда каждый такой пробел добавляет еще по 6 байтов?!

 

Скажите пожалуйста, что такого не будет

[celsoft 6 082]

8 часов назад, holistic сказал:

Скажите, вы часом, снова не ввели принудительную расстановку символов неразрывных пробелов (   ) в тексте новости (на уровне кода)?

Во первых типографская обработка не может быть принудительной, она всегда была и есть только если вы сами ее примените специальной кнопкой в редакторе.

 

Во вторых неразрывные пробелы это обязательная и важная часть типографской обработки. Ставятся они не везде, а только по определенным правилам. Например "не торопитесь", по правилам типографии, не может быть приставка "не" на одной строке, а "торопитесь" на другой. Поэтому в данном случае ставится неразрывный пробел.

 

В третьих в визуальных редакторах при редактировании будет показываться " " чтобы вы видели где он стоит. Однако по факту на самой странице и в БД, будет использоваться специальный символ неразрывного пробела (есть такой символ если вы не знали, а не только " ", " " это HTML сущность), и этот символ занимает один байт в кодировке windows-1251 и два байта в кодировке UTF-8

[odys 384]

Пресс релиз прям круть, столько всего нового, аж «глаза разбегаются», ждём релиза новой версии...

[SKYNET74 315]

Цитата

1. Добавлен новый модуль "Редиректы" для админпанели скрипта. В данном модуле вы можете задавать ссылки для редиректов с одних страниц на другие. Данный модуль будет особенно полезен, когда вы что-либо удалили или перенесли в другое место. Например, удалили одну категорию, и заменили ее на другую, теперь вы можете сделать редирект со старой категории на новую указав старый и новый адрес в данном модуле. При посещении старого адреса будет произведён 301 редирект на новый адрес, что позволит и пользователям попасть на нужную страницу автоматически, и поисковикам правильно склеить нужные адреса. Также данный модуль может использоваться если какие-то ссылки у вас неверно попали в индекс поисковых систем.

Никаких элементарных регулярок, хотя бы в виде *?

Цитата

2. Полностью переписана система кеширования для memcache, для данного типа кеширования введено понятие префиксов данных. Поэтому теперь при использовании данного типа кеширования, при изменении информации в БД, кэш будет очищаться только у необходимых элементов, а не полностью, как было ранее. Тем самым существенно снижена нагрузка на сервер при использовании данного типа кеширования.

На основе чего это сделано? На getAllKeys?

Цитата

5. В настройки скрипта добавлена возможность включения для визуальных редакторов WYSIWYG, режима использования ББ тегов для изображений. При включении данного режима картинки будут вставляться в виде текстовых ББ тегов. Данное нововведение будет полезно пользователям, которые хотят использовать визуальное редактирование для публикаций, но при этом оптимизировать занимаемое место в редакторе картинками. При отключении данной настройки, изображения будут вставляться в обычном визуальном режиме в виде картинок.

Разве не в настройки групп это нужно было добавить? Пользователям нужно показывать сразу как оно выглядит, а редакторам обычно удобнее BB кодами.

Цитата

23. Для тега вывода скрытого текста ([hidе] текст [/hidе]) добавлена возможность указания, каким группам разрешён просмотр указанного в тегах текста. Вы можете указать в параметрах тега каким группам разрешено просматривать содержимое. Например, вы можете написать [hidе=3] текст [/hidе], в данном случае просмотр содержимого тега будет доступен только журналистам. Группы также допускается перечислять через запятую, например, [hidе=2,3,4] текст [/hidе]. В случае если параметр группы не указан, то действуют настройки групп, указанные в панели управления, на предмет того разрешено ли пользователю просматривать текст или нет. Администраторы сайта видят скрытый текст всегда, независимо от указанных а теге параметрах.

Как оно будет взаимодействовать с настройкой просмотра hide у конкретной группы? Что если у группы запрещён просмотр hide, и в ББ теге будет указана данная группа? Будет ли показываться каким группам доступен данный текст?

Цитата

25. Для пользовательского вывода публикаций при помощи тега {custom ...} добавлена возможность использования нового параметра futureannounce="yes". Данный параметр работает совместно с параметром days="X", и указывает что публикации нужно брать из будущих дат. Например, тег {custom futureannounce="yes" days="1"} означает что необходимо вывести публикации, дата которых назначена на завтра, т.е. на +1 дней, а тег {custom futureannounce="yes" days="2"} выводит публикации дата которых назначена на завтра и послезавтра, и т.д. Данных параметр будет полезен вебмастерам, для вывода грядущих анонсов на своём сайте.

Может всё таки на условные 0 и 1 уже перейти давно пора? Тем более что внутри кода хвосты от yes и no почищены уже почти везде.

Цитата

42. Добавлены новые превентивные механизмы для защиты сайта от действий злоумышленников, использующих методы социальной инженерии.

Можно поподробнее? Что и как, и с чем это есть?
 

Цитата

43. Оптимизирована и ускорена загрузка и рендеринг страниц сайта, при использовании визуальных (WYSIWYG) редакторов на сайте. Добавлена поддержка Gzip сжатия для TinyMCE редактора. Убрана дублирующая загрузка редакторов при редактировании публикаций и комментариев, а также при ответах на комментарии.

Это исправление следующего бага?

 

[celsoft 6 082]

8 часов назад, SKYNET74 сказал:

Никаких элементарных регулярок, хотя бы в виде *?

Нет

8 часов назад, SKYNET74 сказал:

На getAllKeys?

Нет

8 часов назад, SKYNET74 сказал:

Разве не в настройки групп это нужно было добавить?

Нет. BB коды и чистый HTML в данном вопросе независимы и показываются при редактировании так, как они были добавлены. И если один добавит в виде HTML то и другой будет видеть также только HTML и наоборот.

8 часов назад, SKYNET74 сказал:

Как оно будет взаимодействовать с настройкой просмотра hide у конкретной группы? Что если у группы запрещён просмотр hide, и в ББ теге будет указана данная группа? Будет ли показываться каким группам доступен данный текст?

Помойму все очень подробно описано в описании. Там четко написано, если указаны параметры действуют параметры, если не указаны действуют настройки групп. Администраторы видят всегда.

8 часов назад, SKYNET74 сказал:

Может всё таки на условные 0 и 1 уже перейти давно пора?

Нет, это параметры для людей, а не для внутреннего кода и устройства кода. Для людей пишутся нормальные значения, а не условные.

8 часов назад, SKYNET74 сказал:

Можно поподробнее? Что и как, и с чем это есть?

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

8 часов назад, SKYNET74 сказал:

Это исправление следующего бага?

И да и нет. Это более расширенные механизмы. Это не кеширование, а вообще не будет повторных загрузок и попыток обращения.

[holistic 24]

18 часов назад, celsoft сказал:

Во первых типографская обработка не может быть принудительной, она всегда была и есть только если вы сами ее примените специальной кнопкой в редакторе.

Короче говоря, принудительно в новой версии ДЛЕ, эти неразрывные пробелы не будут ни в каком виде ПРИНУДИТЕЛЬНО расставляться?

Только по воле редактора, только нажав на какую-то кнопку?

[celsoft 6 082]

8 часов назад, holistic сказал:

Короче говоря, принудительно в новой версии ДЛЕ, эти неразрывные пробелы не будут ни в каком виде ПРИНУДИТЕЛЬНО расставляться?

Только по воле редактора, только нажав на какую-то кнопку?

Да верно. Что и всегда было

[SKYNET74 315]

22 часа назад, celsoft сказал:

Нет

т.е. модуль редиректы будет по сути ничем иным как "аналог" .htaccess и никакого более продвинутого функционала иметь не будет?
т.е. никаких подобных правил мы не увидим?
/news/page/*/ -> /old_news/page/*/

23 часа назад, celsoft сказал:

Нет

А как тогда? Неужели был написан очень сложный алгоритм по "тегированию" тела кеша и система обработки данных тегов?

23 часа назад, celsoft сказал:

Нет. BB коды и чистый HTML в данном вопросе независимы и показываются при редактировании так, как они были добавлены. И если один добавит в виде HTML то и другой будет видеть также только HTML и наоборот.

Было бы удобнее, если бы DLE сам парсил и приводил это к нужному виду исходя из данной настройки, которая находилась бы в настройках групп, ибо:
1. Обычные пользователи как правило смотрят на ББ коды как на нечто страшное и не понятное.
2. Объяснить "деревянным" пользователям как с ними работать это ещё та задачка, а что бы они там не творили всяких ошибок ещё сложнее, по этому и используется визуальный редактор.
3. Редакторам это всё не нужно, им бы всё не растягивать на огромную простыню текста, т.е. картинки в виде BB кодов, администраторам тоже самое как правило.
PS: Есть такой замечательный редактор как WysiBB (wysibb.com), дак у него сам подход к данному вопросу как правило решает все эти проблемы без их возникновения.

23 часа назад, celsoft сказал:

Помойму все очень подробно описано в описании. Там четко написано, если указаны параметры действуют параметры, если не указаны действуют настройки групп. Администраторы видят всегда.

т.е. настройки групп на новый BB код никак не будут действовать?
А как видеть в самом тексте кому доступен данный текст, а кому нет?
Пример: пользователь выложил с доступом для определённых групп, другой его процитировал/скопипастил чуть ниже, и не в курсе был что данный контент нужно было закрывать от таких то групп, администратор тоже только видеть видимо будет, а для того что бы понять кому видно, а кому нет, он должен лезть в редактирование новости/комментария/и т.д.?

23 часа назад, celsoft сказал:

Нет, это параметры для людей, а не для внутреннего кода и устройства кода. Для людей пишутся нормальные значения, а не условные.

Это бы давно уже позволило элементарно задавать больше условий для одного тега, а не просто yes и no. Тоже время кеширования конкретного блока контента выводимого через {custom}, а это в свою очередь сделает этот тег гораздо более гибким и динамичным, нежели сейчас. Либо кеш, либо не кеш.

23 часа назад, celsoft сказал:

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

Ну не настолько же умным как гугл или яндекс он стал, и явно же не машинное обучение там будет...
Рандомные дополнительные хеши в POST запросах будут или что то подобное?
Смотреть реферер откуда пришёл POST запрос, и есть ли в данном месте подобная функция? Например создание нового пользователя делается только из админ панели с соответствующей страницы, а не с /engine/go.php.
Спрашиваю, т.к. с этими "новшествами" может перестать работать очень много уже написанного кода.

23 часа назад, celsoft сказал:

И да и нет. Это более расширенные механизмы. Это не кеширование, а вообще не будет повторных загрузок и попыток обращения.

т.е. если где то на странице используется визуальный редактор, его скрипты и стили будут подгружены в head DLE переменной {jsfiles} и эти скрипты будут использоваться в том числе и в JQ UI окошках?

[celsoft 6 082]

1 час назад, SKYNET74 сказал:

т.е. модуль редиректы будет по сути ничем иным как "аналог" .htaccess и никакого более продвинутого функционала иметь не будет?
т.е. никаких подобных правил мы не увидим?
/news/page/*/ -> /old_news/page/*/

на текущем этапе пока нет.

 

1 час назад, SKYNET74 сказал:

А как тогда? Неужели был написан очень сложный алгоритм по "тегированию" тела кеша и система обработки данных тегов?

Да на основании префиксов, как у файлового кеширования. Что сложного в тегировании? Пять строк кода.

1 час назад, SKYNET74 сказал:

т.е. настройки групп на новый BB код никак не будут действовать?
А как видеть в самом тексте кому доступен данный текст, а кому нет?
Пример: пользователь выложил с доступом для определённых групп, другой его процитировал/скопипастил чуть ниже, и не в курсе был что данный контент нужно было закрывать от таких то групп, администратор тоже только видеть видимо будет, а для того что бы понять кому видно, а кому нет, он должен лезть в редактирование новости/комментария/и т.д.?

А как вы сейчас это видите? Вы когда нибудь пробовали цитировать комментарии содержащие тег hide? Попробуйте. Его контент не идет в цитату. А от копипаста со страницы напрямую вам уже ни один скрипт и ни одна проверка не поможет.

1 час назад, SKYNET74 сказал:

т.е. если где то на странице используется визуальный редактор, его скрипты и стили будут подгружены в head DLE переменной {jsfiles} и эти скрипты будут использоваться в том числе и в JQ UI окошках?

Да если на этом сайте у пользователя есть определенные права и задействуется редактор.

 

1 час назад, SKYNET74 сказал:

Спрашиваю, т.к. с этими "новшествами" может перестать работать очень много уже написанного кода.

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

 

1 час назад, SKYNET74 сказал:

Смотреть реферер откуда пришёл POST запрос, и есть ли в данном месте подобная функция? Например создание нового пользователя делается только из админ панели с соответствующей страницы, а не с /engine/go.php.

Реферал это http данные. Его легко подделает curl в одну строку. Базироваться на нем нет никакого смысла, равно как и использовать его в проверках направленных на безопасность, значение которому нет никакого доверия. Он может задействоваться только если нужно сделать какую то функциональность без упора на безопасность.

1 час назад, SKYNET74 сказал:

Рандомные дополнительные хеши в POST запросах будут или что то подобное?

Тоже бесполезная штука. Парсить HTML форму и выбирать из нее любые данные, дело одной строчки кода.

1 час назад, SKYNET74 сказал:

Ну не настолько же умным как гугл или яндекс он стал, и явно же не машинное обучение там будет...

Можно было бы и машинное обучение сделать, но это убьет ваш сервер по производительности  Тоже нет. Иногда эффективные вещи делаются очень просто. Не всегда просто они сразу в голову приходят, поэтому и появляются не сразу а позднее по прошествии времени.

[SKYNET74 315]

6 минут назад, celsoft сказал:

Да на основании префиксов, как у файлового кеширования. Что сложного в тегировании? Пять строк кода.

И как вы будете выборочно очищать записи в memcache по этому префиксу? Нужно же их всех очистить, а не только последние 100 записей с префиксом "news_".

Я этот вопрос прорабатывал от и до, и нашёл только два варианта, это тегирование, и второй мой собственный более с более продвинутым функционалом.

11 минуту назад, celsoft сказал:

А как вы сейчас это видите? Вы когда нибудь пробовали цитировать комментарии содержащие тег hide? Попробуйте. Его контент не идет в цитату. А от копипаста со страницы напрямую вам уже ни один скрипт и ни одна проверка не поможет.

Дело не в тупости пользователей копипастящих текст, а дело в том что даже если там умный пользователь, он не видит кому доступен этот текст, а кому нет.
Можно сделать по аналогии с цитатой (Данный текст доступен только группам: {groups}), и обильно сдобрить все элементы классами, тогда кому не нужно смогут скрыть этот текст, либо вообще в языковом пакете затереть строчку эту и всё. Но врятли от такой функциональности будут отказываться, ведь это удобно.

1 час назад, celsoft сказал:

Реферал это http данные. Его легко подделает curl в одну строку. Базироваться на нем нет никакого смысла, равно как и использовать его в проверках направленных на безопасность, значение которому нет никакого доверия. Он может задействоваться только если нужно сделать какую то функциональность без упора на безопасность.

cURL не может выдавать себя за пользователя сайта, не утянув куки или пароли однако...

2 часа назад, celsoft сказал:

Можно было бы и машинное обучение сделать, но это убьет ваш сервер по производительности  Тоже нет. Иногда эффективные вещи делаются очень просто. Не всегда просто они сразу в голову приходят, поэтому и появляются не сразу а позднее по прошествии времени.

Надеюсь админов подозрительных оно банить не будет по подсети?  И захватывать контроль на сервере...

[celsoft 6 082]

3 часа назад, SKYNET74 сказал:

И как вы будете выборочно очищать записи в memcache по этому префиксу? Нужно же их всех очистить, а не только последние 100 записей с префиксом "news_".

Конечно все. И не просто все, а только от этого сайта, т.к. на одном сервере может быть много сайтов.

3 часа назад, SKYNET74 сказал:

Я этот вопрос прорабатывал от и до, и нашёл только два варианта, это тегирование, и второй мой собственный более с более продвинутым функционалом.

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

3 часа назад, SKYNET74 сказал:

cURL не может выдавать себя за пользователя сайта, не утянув куки или пароли однако...

Вот это сейчас очень смешно прозвучало. cURL это не какой то протокол для обмена данными, это обертка для HTTP протокола для ленивых, чтобы не писать каждый раз десятки строк кода, при формировании HTTP запроса. Выполнить HTTP запрос может и браузер а сформировать его может простейший JS скрипт, в котором будет все и любой реферал, и вообще абсолютно любые заголовки HTTP. И браузер пошлет все ваши куки уже сам, потому как был сгенерирован уже HTTP запрос и к нему он пошлет все остальное. Все что начинается с HTTP_ в глобальной переменной $_SERVER является данными полученными от HTTP протокола, которые сформированы вручную клиентом из вне. И ни в коем случае нельзя им доверять, потому как они априори заполнены злоумышленником. Именно по этому любая XSS на сайте куда можно завести администратора, является ошибкой с самым высоким уровнем опасности, и именно поэтому мы в течении получаса выпускаем патчи, как только нам становится об этом известно. Чего к сожалению редко делают другие разработчики, наивно полагая что если куки по http only и JS они недоступны, то ими и воспользоваться нельзя, а это большое заблуждение. И считают XSS уязвимости несерьезной проблемой, и исправления выпускают потом планово. И именно поэтому когда слезно просят брать тот же IP из HTTP_ префиксов из за криво настроенного прокси у хостинга, мы категорически в этом отказываем, и требуем чтобы настройки сервера исправлял хостинг. Потому как любое "тихое" изменение настроек хостинга, и в эти данные полетят вручную заполненные данные. Две последние уязвимости DLE https://dle-news.ru/bags/ это атаки с использованием именно социальной инженерии на админов. Без админа и его обмана, они не стоят и выведенного яйца, хотя в DLE уже 100 лет как куки недоступны из JS, атаки направлены на то чтобы заставить админа самого сделать все необходимое на сайте.  Никакие проверки реферала и отправка рандомных данных из форм не помогли бы в данный случаях, т.к. все это легко получить и подделать. Поэтому и были разработаны новые превентивные меры защиты от таких действий. И новые превентивные меры защиты направлены на то, чтобы администратора не возможно было завести куда не следует. Ни уговорами, ни обманом. Превентивные меры защищают от неизвестных угроз, а не конкретные угрозы.

[SKYNET74 315]

2 часа назад, celsoft сказал:

Конечно все. И не просто все, а только от этого сайта, т.к. на одном сервере может быть много сайтов.

 

2 часа назад, celsoft сказал:

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

т.е. как минимум у каждого кеша два тега? (сайт+тип кеша) А то и больше.
Я то умею работать с массивами, если бы там было всё так просто, то уже все бы использовали memcached под любые задачи, однако там далеко не в массивах спасение... Посмотрим собственно говоря как сделали, но чувствуются мне там "подводные камни" будут ещё какие...
И естественно раз говорю про тегирование, то я в курсе как оно делается
 

4 часа назад, celsoft сказал:

Вот это сейчас очень смешно прозвучало. cURL это не какой то протокол для обмена данными, это обертка для HTTP протокола для ленивых, чтобы не писать каждый раз десятки строк кода, при формировании HTTP запроса. Выполнить HTTP запрос может и браузер а сформировать его может простейший JS скрипт, в котором будет все и любой реферал, и вообще абсолютно любые заголовки HTTP. И браузер пошлет все ваши куки уже сам, потому как был сгенерирован уже HTTP запрос и к нему он пошлет все остальное. Все что начинается с HTTP_ в глобальной переменной $_SERVER является данными полученными от HTTP протокола, которые сформированы вручную клиентом из вне. И ни в коем случае нельзя им доверять, потому как они априори заполнены злоумышленником. Именно по этому любая XSS на сайте куда можно завести администратора, является ошибкой с самым высоким уровнем опасности, и именно поэтому мы в течении получаса выпускаем патчи, как только нам становится об этом известно. Чего к сожалению редко делают другие разработчики, наивно полагая что если куки по http only и JS они недоступны, то ими и воспользоваться нельзя, а это большое заблуждение. И считают XSS уязвимости несерьезной проблемой, и исправления выпускают потом планово. И именно поэтому когда слезно просят брать тот же IP из HTTP_ префиксов из за криво настроенного прокси у хостинга, мы категорически в этом отказываем, и требуем чтобы настройки сервера исправлял хостинг. Потому как любое "тихое" изменение настроек хостинга, и в эти данные полетят вручную заполненные данные. Две последние уязвимости DLE https://dle-news.ru/bags/ это атаки с использованием именно социальной инженерии на админов. Без админа и его обмана, они не стоят и выведенного яйца, хотя в DLE уже 100 лет как куки недоступны из JS, атаки направлены на то чтобы заставить админа самого сделать все необходимое на сайте.  Никакие проверки реферала и отправка рандомных данных из форм не помогли бы в данный случаях, т.к. все это легко получить и подделать. Поэтому и были разработаны новые превентивные меры защиты от таких действий. И новые превентивные меры защиты направлены на то, чтобы администратора не возможно было завести куда не следует. Ни уговорами, ни обманом. Превентивные меры защищают от неизвестных угроз, а не конкретные угрозы.

Реферер как одна из проверок, а не как панацея имелась ввиду.
Вы так всё расписали, что теперь хочется пощупать, как оно там сделано, что "дешево" и сердито...

[celsoft 6 082]

10 часов назад, SKYNET74 сказал:

т.е. как минимум у каждого кеша два тега? (сайт+тип кеша) А то и больше.

Нет конечно. Зачем это? Количество ключей в кеше это сумма записей в кеше + 1 служебный. Т.е. если в кеш запишется 10 значений, то ключей 11. Служебный ключ хранит массив служебной информации о других 10 ключах, и по служебной информации может производить операции над другими ключами где хранятся данные.

10 часов назад, SKYNET74 сказал:

Реферер как одна из проверок, а не как панацея имелась ввиду.

Проверка которая никак не защищает, является бессмысленной. Проверять нужно не количеством, а качеством.

 

 

[Datagor 31]

Привет! Спасибо, мне новости понравились. Настораживает только дата публикации.

 

Тут шутники с З-Д-НЬЮЗ на весь Рунет прогремели о возобновлении полной поддержки MS Win XP до 2022 года со стороны Майкрософта.

И пр. утки на 1 апреля

[SKYNET74 315]

11 час назад, celsoft сказал:

Нет конечно. Зачем это? Количество ключей в кеше это сумма записей в кеше + 1 служебный. Т.е. если в кеш запишется 10 значений, то ключей 11. Служебный ключ хранит массив служебной информации о других 10 ключах, и по служебной информации может производить операции над другими ключами где хранятся данные.

Да это понятно, как вы будете сбрасывать те же страницы с краткими новостями, и {custom} блоки из кеша?
Записывать таймштамп в каждый кеш в служебный ключ (например подключ "timestamp"), и как только появляется новая новость, в источнике (какой-нибудь /engine/cache/system/memcached_news.php) он меняется на актуальный, и алгоритм считает кеши просроченными, где таймштамп не соответствует свежеустановленному в конфиге?

[celsoft 6 082]

12 часа назад, SKYNET74 сказал:

Да это понятно, как вы будете сбрасывать те же страницы с краткими новостями, и {custom} блоки из кеша?

Все точно также как и работает файловое кеширование. Разницы в работе между файловым кешированием и кешированием memcache больше нет.

 

Записывать таймштамп в каждый кеш в служебный ключ (например подключ "timestamp"), и как только появляется новая новость, в источнике (какой-нибудь /engine/cache/system/memcached_news.php) он меняется на актуальный, и алгоритм считает кеши просроченными, где таймштамп не соответствует свежеустановленному в конфиге?

Зачем? Memcache имеет стандартную встроенную возможность, которая позволяет указать время жизни кеша. Если кеш просрочен по времени, memcache сервер его сам "убьет" как просроченный, причем сделает это для каждого ключа в разное время, в зависимости от того когда они были созданы.

[SKYNET74 315]

3 часа назад, celsoft сказал:

Все точно также как и работает файловое кеширование. Разницы в работе между файловым кешированием и кешированием memcache больше нет.

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

 

3 часа назад, celsoft сказал:

Зачем? Memcache имеет стандартную встроенную возможность, которая позволяет указать время жизни кеша. Если кеш просрочен по времени, memcache сервер его сам "убьет" как просроченный, причем сделает это для каждого ключа в разное время, в зависимости от того когда они были созданы.

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

То что я описал постом выше является классической схемой тегирования ключей, а у вас всё таки что будет?

Изменено 6 апреля 2017 пользователем SKYNET74

[celsoft 6 082]

2 часа назад, SKYNET74 сказал:

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

Я этого не говорил и не писал. Какие то непонятные выводы непонятно на чем сделанные.

2 часа назад, SKYNET74 сказал:

То что я описал постом выше является классической схемой тегирования ключей, а у вас всё таки что будет?

Мне известно понятие "Классическая музыка", а вот понятие "классическое тегирование" мне неизвестно. В скромности вам не отказать  Вам нужно сначала что то создать, умереть, а потом лет через 100 если что то созданное вами в программировании останется, тогда потомки будут говорить об этом как о классике. Если вы называете это классическим тегированием, то я в DLE это называю "классическим  префиксированием", т.к. DLE работает с кешем не на основе тегов, а на основе префиксов.

 

2 часа назад, SKYNET74 сказал:

чьи имена заранее не известны.

 

2 часа назад, SKYNET74 сказал:

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

Специально для тех кто спрашивает, и кто не умеет читать ответы, дублирую еще раз ссылку https://forum.dle-news.ru/topic/71136-datalife-engine-v113-press-release/?do=findComment&comment=355730 с ответом. Имена известны и храняться в служебном ключе.

2 часа назад, SKYNET74 сказал:

а у вас всё таки что будет?

Будет релиз и увидите. 

[Ser Antony 2]

Цитата

 

6. Добавлена возможность отправлять в обратной связи прикреплённые к письмам файлы.

8. Добавлена возможность использования нескольких форм обратной связи на сайте.

11. Для модуля "Перекрёстные ссылки", добавлено игнорирование тегов заголовков h1...h5

20. Добавлена поддержка написания микроразметки

 

 

Как ни приятны новости, но эти пункты реально опоздали на несколько лет(((

 

Уверен, для многих работы без этих пунктов была крайне не удобна, поэтому и используют сторонние скрипты для создания нескольких форм и для прикрепления к ним файлов. А вместо модуля перекрестные ссылки, сторонние системы перелинковки.

 

Никогда не понимал почему вот сейчас это сделано а не несколько лет назад, когда реально было нужно? И зачем вообще теперь уже сделано, когда все работают на сторонних разработках?

 

Изменено 6 апреля 2017 пользователем Ser Antony

[celsoft 6 082]

7 минут назад, Ser Antony сказал:

Никогда не понимал почему вот сейчас это сделано а не несколько лет назад, когда реально было нужно?

Несколько лет назад были сделаны другие вещи. Не может все появится мгновенно и сразу.

 

7 минут назад, Ser Antony сказал:

И зачем вообще теперь уже сделано, когда все работают на сторонних разработках?

Это хорошо что вы свой сайт сделали несколько лет назад. А вот огромное количество людей еще только начинают и начнут делать свои сайты. Для них это и сделано. А также для тех кто при желании откажется от сторонних модулей на своей сайте, и сделает при помощи стандартных возможностей.

[SKYNET74 315]

19 часов назад, celsoft сказал:

Я этого не говорил и не писал. Какие то непонятные выводы непонятно на чем сделанные.

Как бы...

В 06.04.2017 в 14:01, celsoft сказал:

Зачем? Memcache имеет стандартную встроенную возможность, которая позволяет указать время жизни кеша. Если кеш просрочен по времени, memcache сервер его сам "убьет" как просроченный, причем сделает это для каждого ключа в разное время, в зависимости от того когда они были созданы.

А такой подход не подходит для случаев выборочного "убийства" части ключей по наступлению события...

 

19 часов назад, celsoft сказал:

Мне известно понятие "Классическая музыка", а вот понятие "классическое тегирование" мне неизвестно. В скромности вам не отказать  Вам нужно сначала что то создать, умереть, а потом лет через 100 если что то созданное вами в программировании останется, тогда потомки будут говорить об этом как о классике. Если вы называете это классическим тегированием, то я в DLE это называю "классическим  префиксированием", т.к. DLE работает с кешем не на основе тегов, а на основе префиксов.

Ну как бы первые ссылки из гугла по теме датированы аж 2008 годом...
А когда вы решали использовать memcached в DLE, вы не могли не гуглить на данную тему...

https://habrahabr.ru/post/43539/
http://smira.ru/posts/20081029web-caching-memcached-5.html

 

19 часов назад, celsoft сказал:

Специально для тех кто спрашивает, и кто не умеет читать ответы, дублирую еще раз ссылку https://forum.dle-news.ru/topic/71136-datalife-engine-v113-press-release/?do=findComment&comment=355730 с ответом. Имена известны и храняться в служебном ключе.

Но из этого следует всего две вещи, либо вы не понимаете что я вам говорю, либо вы решили хранить ВСЕ записи (например категории) в одном ключе memcached, но это сомнительно ибо лимит в 1Mb для одного ключа никто не отменял (его можно повысить, но КПД будет стремится к нулю)...
Представим мемкеш обычным хранилищем файлового кеша (там можно так же создавать ключи в виде путей /site.ru/cache/news/categories/1/pages/1.tmp), как вы заранее узнаете о том сколько нужно сбросить этих:
/site.ru/cache/news/categories/1/pages/1.tmp

/site.ru/cache/news/categories/1/pages/2.tmp

/site.ru/cache/news/categories/1/pages/3.tmp

/site.ru/cache/news/categories/2/pages/1.tmp

/site.ru/cache/news/categories/2/pages/2.tmp

/site.ru/cache/news/categories/2/pages/3.tmp
Если не известно сколько их всего может быть + не известно сколько может быть вообще категорий и других источников кеш-данных + отсутствие атомарности у мемкеша (и можно получить кашу в так называемом "служебном ключе").

PS: Хотя конечно же посмотрим что получилось в итоге, главное что бы это было "юзабельным", может быть действительно какой то чудо алгоритм в пару строк кода придумали...

18 часов назад, Ser Antony сказал:

Как ни приятны новости, но эти пункты реально опоздали на несколько лет(((

 

Уверен, для многих работы без этих пунктов была крайне не удобна, поэтому и используют сторонние скрипты для создания нескольких форм и для прикрепления к ним файлов. А вместо модуля перекрестные ссылки, сторонние системы перелинковки.

 

Никогда не понимал почему вот сейчас это сделано а не несколько лет назад, когда реально было нужно? И зачем вообще теперь уже сделано, когда все работают на сторонних разработках?

Это уже классика, ~99% идей для новых версий берутся из популярных модулей для DLE, т.к. когда игнорирование требований пользователей системы уже чревато возможным их уходом на те системы, где это есть из коробки...
Собственно в большинстве случаев для разработчика это единственный довод что та или иная возможность действительно нужна.
 

18 часов назад, celsoft сказал:

А вот огромное количество людей еще только начинают и начнут делать свои сайты.

Пощадите бедный рунет и не только...

18 часов назад, celsoft сказал:

А также для тех кто при желании откажется от сторонних модулей на своей сайте, и сделает при помощи стандартных возможностей.

А потом они попутно узнают что волшебным нажатием кнопочки это не сделать, и опять придётся кого то нанимать за дорого, что бы им всё их ассорти загнали в стандартные возможности CMS...
Потребности должны удовлетворятся в разумные сроки, а не через многие года, когда это уже становится не потребностью, а де факто базовой составляющей системы...

Изменено 7 апреля 2017 пользователем SKYNET74

[Taganay 27]

Цитата

1. Добавлен новый модуль "Редиректы" для админпанели скрипта.

А редирект на другой домен возможен? Было бы полезно при переезде сайта.

[celsoft 6 082]

31 минуту назад, SKYNET74 сказал:

А такой подход не подходит для случаев выборочного "убийства" части ключей по наступлению события...

Кто вам сказал об одном и том же подходе для разных событий? Событие "устаревание кеша по времени", и событие "удаление ключа, т.к. изменилась БД", это два разных события и происходят они в разные отрезки времени, и для каждого события свой метод обработки, а не один универсальный на все событие. Если наступает событие "кеш устарел по времени", его убьет memcache сервер своими нативными средствами, DLE даже делать ничего не нужно. Если наступило событие "изменилась информация в БД", очистку произведет DLE по своим алгоритмам. Все. Очень просто.

35 минут назад, SKYNET74 сказал:

либо вы решили хранить ВСЕ записи (например категории) в одном ключе memcached, но это сомнительно ибо лимит в 1Mb для одного ключа никто не отменял

Еще раз даю ссылку https://forum.dle-news.ru/topic/71136-datalife-engine-v113-press-release/?do=findComment&comment=355730 там указан пример того сколько ключей. Откуда вывод что все будет в одном ключе????????

37 минут назад, SKYNET74 сказал:

Это уже классика, ~99% идей для новых версий берутся из популярных модулей для DLE, т.к. когда игнорирование требований пользователей системы уже чревато возможным их уходом на те системы, где это есть из коробки...
Собственно в большинстве случаев для разработчика это единственный довод что та или иная возможность действительно нужна.

Да ладно? Вы разработчик DLE? Вот я лично разработчик DLE и пишу код DLE. И все что реализуется беру из Пожелания Для Новых Версий Линейки 11.хх Там клойдак для идей, и того что нужно реализовать. Откуда вы как человек даже близко не имеющий отношения к разработке скрипта, утверждаете, что берется из каких то модулей. Последний сторонний модуль, я смотрел года три назад, и то когда попросили разобраться с проблемами в нем, очень хорошие люди. Так что ваше утверждение просто высосано из пальца, не обоснованное ничем.

42 минуты назад, SKYNET74 сказал:

Потребности должны удовлетворятся в разумные сроки, а не через многие года, когда это уже становится не потребностью, а де факто базовой составляющей системы...

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

51 минуту назад, SKYNET74 сказал:

Представим мемкеш обычным хранилищем файлового кеша (там можно так же создавать ключи в виде путей /site.ru/cache/news/categories/1/pages/1.tmp), как вы заранее узнаете о том сколько нужно сбросить этих:
/site.ru/cache/news/categories/1/pages/1.tmp

/site.ru/cache/news/categories/1/pages/2.tmp

/site.ru/cache/news/categories/1/pages/3.tmp

/site.ru/cache/news/categories/2/pages/1.tmp

/site.ru/cache/news/categories/2/pages/2.tmp

/site.ru/cache/news/categories/2/pages/3.tmp
Если не известно сколько их всего может быть + не известно сколько может быть вообще категорий и других источников кеш-данных + отсутствие атомарности у мемкеша (и можно получить кашу в так называемом "служебном ключе").

Как файловое кеширование в DLE узнает какой кеш нужно сбросить? Точно также об этом узнает DLE и в memache. Только читает не список файлов, а список им же созданных и им же запомненных ключей. Служебный ключ запоминает информацию о ключе где хранится информация. А не хранит все в одном ключе. Ваше "тегирование" работает точно так же, есть ключи с информацией, есть ключ со служебной информацией где храняться теги и привязки их ключам. DLE делает точно также, только теги не использует, он хранит имена префиксов, как в файловом кешировании.