Пожелания для новых версий DataLife Engine

[celsoft 5 986]

41 минуту назад, aleksandrhristich сказал:

думаю, никому вреда не нанесло.

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

[aleksandrhristich 106]

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

...Это же не нанесло вам вреда я надеюсь...

Да конечно же нет :) .

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

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

Полностью согласен :) .

P.S Приношу свои извинения если кому-нибудь всетаки навредил.

Даже если и перешел на другой движок,все-таки потихому слежу за развитием DLE, как ни как "первая любовь" :) ,вдруг снова решу поднять какой-нибудь проект на вашем продукте и тогда сразу куплю лицензию,тем более сейчас могу позволить себе это без проблем (если уж Red Hat Enterprise Linux + IPS+ HPE Proliant DL380 G10 купил без проблем)

Надеюсь мы пришли к взаимопониманию.

[fanera 20]

С загрузкой файлов, по крайней мере с изображениями есть проблема.

Открываем загрузчик изображений и файлов. Несколько раз добавляем один и тот же файл с тем же именем (у меня три файла):

Загружаем и получаем:

Два файла имеют одинаковое название файла, хотя должны иметь разные. А получаем, что 1704966271_kotik.jpg дублируется в загрузчик файлов два раза.

После сохранения новости один файл пропадает, в загрузчике остается только два файла:

Третий файл просто пропал. На диске его тоже нет. Проблема мистическим образом возникает через раз, а то и через несколько раз.

[celsoft 5 986]

5 часов назад, fanera сказал:

Третий файл просто пропал. На диске его тоже нет.

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

5 часов назад, fanera сказал:

Несколько раз добавляем один и тот же файл с тем же именем (у меня три файла):

Зачем одновременно загружать три раза один и тот же файл.

5 часов назад, fanera сказал:

Проблема мистическим образом возникает через раз, а то и через несколько раз.

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

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

[fanera 20]

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

Зачем одновременно загружать три раза один и тот же файл.

6 часов назад, fanera сказал:

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

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

Поняли принципы работы?

Не имеет значения, кейс проблемный и ситуация проблемная из-за использования банальной функции time() вместо GUID или иного идентификатора.

[celsoft 5 986]

15 часов назад, fanera сказал:

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

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

15 часов назад, fanera сказал:

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

 

15 часов назад, fanera сказал:

Не имеет значения, кейс проблемный и ситуация проблемная из-за использования банальной функции time() вместо GUID или иного идентификатора.

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

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

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

[fanera 20]

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

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

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

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

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

Изменено 12 января пользователем fanera

[celsoft 5 986]

33 минуты назад, fanera сказал:

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

Никто не говорит что нужно оставлять проблему. Я лишь говорю что на данный момент эта коллизия созданная искуственно, а  не существующая в реальности. Разберем данный конкретный кейс. Его можно решить например создав GUD, это не сложно для меня, это изменить несколько байт кода, и меньше минуты времени. Но это займет в 4 раза больше памяти в базе данных на запись данной информации, это займет в 10 раз больше процессорного времени. Да это миллисекунды а не часы, но это разы!!! если сравнивать два разных подхода. И все складывается именно из миллисекунд, и если бы я не придавал значения каждой из этой миллисекунды то DLE не был бы так быстр, по отношению к другим. Это я не говорю про увеличение размеров БД, размеров страниц. Да там байт, там байт а в итоге это увеличит и расход памяти и трафик в десятки и сотни мегабайт в месяц для крупного сайта.

Пара байт кода всего, а изменения для всех!!! пользователесь весьма и весьма глобальны. Зачем создавать такие изменения для всех пользователей только на основе исскуственно созданного кейса с которым никто никогда не столкнулся в реальности за 20 лет? А процессорное время и тратить место начнут все. Зачем им всем это?

33 минуты назад, fanera сказал:

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

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

33 минуты назад, fanera сказал:

Я думаю, что подобные вопросы безопасности лежат только на разработчике, т.к. пользователи платят деньги за лицензию, а не используют open source, чтобы пушить и фиксить баги. И ответы вроде "за 20 лет ничего не получали, фиксить не будем" является издевкой для клиента.

Согласно вашей логике то что одна картинка может замениться другой это проблема в безопасности, а значит может использоваться для атаки. А если это убрать, то атакующему потребуется в пять раз меньше ресурсов для вывода сервера из строя, например для DDOS атаки это уже не угроза в безопасности? Так что ли?  В таком случае если эта угроза безопасности, то вы предлагаете одну угрозу поменять на другую угрозу. Так какая в таком случае лучше? Мне кажется что первая все таки лучше, т.к. менее опасна.

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

[fanera 20]

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

Никто не говорит что нужно оставлять проблему. Я лишь говорю что на данный момент эта коллизия созданная искуственно, а  не существующая в реальности. Разберем данный конкретный кейс. Его можно решить например создав GUD, это не сложно для меня, это изменить несколько байт кода, и меньше минуты времени. Но это займет в 4 раза больше памяти в базе данных на запись данной информации, это займет в 10 раз больше процессорного времени. Да это миллисекунды а не часы, но это разы!!! если сравнивать два разных подхода. И все складывается именно из миллисекунд, и если бы я не придавал значения каждой из этой миллисекунды то DLE не был бы так быстр, по отношению к другим. Это я не говорю про увеличение размеров БД, размеров страниц. Да там байт, там байт а в итоге это увеличит и расход памяти и трафик в десятки и сотни мегабайт в месяц для крупного сайта.

Пара байт кода всего, а изменения для всех!!! пользователесь весьма и весьма глобальны. Зачем создавать такие изменения для всех пользователей только на основе исскуственно созданного кейса с которым никто никогда не столкнулся в реальности за 20 лет? А процессорное время и тратить место начнут все. Зачем им всем это?

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

Согласно вашей логике то что одна картинка может замениться другой это проблема в безопасности, а значит может использоваться для атаки. А если это убрать, то атакующему потребуется в пять раз меньше ресурсов для вывода сервера из строя, например для DDOS атаки это уже не угроза в безопасности? Так что ли?  В таком случае если эта угроза безопасности, то вы предлагаете одну угрозу поменять на другую угрозу. Так какая в таком случае лучше? Мне кажется что первая все таки лучше, т.к. менее опасна.

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

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

И все это решается просто генерацией уникального префикса по uniqid, не окончательно, но уже в большинстве случаев, чем с time(). Понимаете о чем я? Если нет, то я тоже уже не знаю как вам объяснить, что безопасность и продуманная логика превыше вашей макросекунды.

Изменено 12 января пользователем fanera

[aleksandrhristich 106]

@celsoft @fanera

[celsoft 5 986]

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

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

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

И все это решается просто генерацией уникального префикса по uniqid, не окончательно, но уже в большинстве случаев, чем с time(). Понимаете о чем я? Если нет, то я тоже уже не знаю как вам объяснить, что безопасность и продуманная логика превыше вашей макросекунды.

Это совсем уже другая история. Не имеющая никакого отношения к этому. Раньше DLE вообще всегда и для всех картинок генерировал префикс к картинкам и оригинальное имя не оставалось никогда и всегда у картинок был уникальный префикс. Но потом большое количество людей начали возмущаться, что префикс им не нужен, что это плохо для SEO, что это вообще не нужная и лишняя информация в имени. Причем просило много людей и весьма продолжительное время. После чего префикс по этим просьбам был убран и если такого имени нет на сервере, то остается оригинал. Так что это даже не мое желание или мнение, это реализация пожеланий большого количества людей, которое было реализовано. Так что все вопросы относительно этого не ко мне ))) это к другим пользователям DLE, они так решили что так лучше. Это реализация пожеланий клиентов DLE, а не мое желание чтобы так было. Я бы лично тоже оставил бы префикс всегда )))

34 минуты назад, aleksandrhristich сказал:

@celsoft @fanera

🤣👍

[kamensk 83]

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

пожеланий клиентов DLE, а не мое желание чтобы так было. Я бы лично тоже оставил бы префикс всегда

Надо тогда предоставить выбор по чебоксу включения/отключения префикса. Для части клиентов это естественно будет востребованная функция. А кому-то префиксы вовсе не нужны.

Даже если админ один (как в моем случае) - но я не помню за шесть семь лет названия всех файлов. Можно и лажануть))

[celsoft 5 986]

8 минут назад, kamensk сказал:

Надо тогда предоставить выбор по чебоксу включения/отключения префикса. Для части клиентов это естественно будет востребованная функция. А кому-то префиксы вовсе не нужны.

Чекбоксов на все не наберешься под каждое " персональное хотение". Настроек итак уже за несколько сотен перевалило и их не знают все даже самые опытные. При загрузке тоже чекбоксами обвесится, а то вдруг передумает? Все должно быть разумно, а не чекбокс под каждый чих на каждый клик, в противном случае вся страница в чекбоксах будет. Вон полистайте тему тут таких желаний под разные "хотелки" столько что диву даешься что такие желания вообще могут быть, и при этом каждый хочет, и каждый под свое желание хочет "хотя бы чекбокс".  Если востребовано для кого то, то есть система плагинов, поставил свой персональный плагин с нужным функционалом и все. Базовые функции коробочной CMS это не про персональные желания и персональные чекбоксы это уж точно.

[NlCKRUS 48]

Можете при редактировании новости добавить дату окончания опроса?

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

Спасибо

[Uralbox 4]

Сделайте вывод показа расширения файла как-то отдельно, не в названии, тк название может быть длинным и чтобы посмотреть расширение нужно наведение на сам файл. Можно например выводить расширение вместо дизайнерской стрелки вниз (которая сильно не имеет смысловой нагрузки) ну или как-то совместить с ней.

[Captain 613]

40 минут назад, Uralbox сказал:

Сделайте вывод показа расширения файла как-то отдельно...

Если загрузка через скрипт, то тег {extension} выведет расширение:

https://dle-news.ru/extras/online/attachment.html

[MSK 287]

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

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

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

[celsoft 5 986]

29 минут назад, MSK сказал:

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

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

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

Так и происходит и всегда собственно было в DLE, или я чего то непонимаю. Но оригинальное имя сохраняется.

[MSK 287]

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

Так и происходит и всегда собственно было в DLE

Как это всегда было????

поясню.

Загрузите файл с названием, например "тестовый файл.pdf" и какое имя будет у файла после загрузки на сайт и при вставке его в новость?

Будет загружен "testovyj-fajl.pdf" и вставляться он будет как [attachment=3:testovyj-fajl.pdf] и в списке загруженных он будет такой, а не "тестовый файл.pdf".

[MSK 287]

adminpanel.css кешируется - после его изменения было бы хорошо сделать возможность добавлять параметр в путь

[celsoft 5 986]

13 часов назад, MSK сказал:

поясню.

Загрузите файл с названием, например "тестовый файл.pdf" и какое имя будет у файла после загрузки на сайт и при вставке его в новость?

Будет загружен "testovyj-fajl.pdf" и вставляться он будет как [attachment=3:testovyj-fajl.pdf] и в списке загруженных он будет такой, а не "тестовый файл.pdf".

Я вас понял, вы про транслитерацию. Я подумал что префикс добавляется.

[crafic 31]

On 1/11/2024 at 5:23 PM, celsoft said:

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

uniqid() ставьте и не будет повторов

[MSK 287]

11.01.2024 в 18:23, celsoft сказал:

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

А если загружаем файлы с одним именем, но разным содержанием?

На локалке лежат в разных паках, поэтому нет конфликта одинаковых имен, а грузятся к одной новости...

[Uralbox 4]

18.01.2024 в 13:07, Captain сказал:

Если загрузка через скрипт, то тег {extension} выведет расширение:

 

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

[celsoft 5 986]

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

А если загружаем файлы с одним именем, но разным содержанием?

На локалке лежат в разных паках, поэтому нет конфликта одинаковых имен, а грузятся к одной новости...

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