celsoft

Тогда просто в настройках укажите минимальное количество букв в слове.

На нагрузку это не влияет. Вам нужно решать лишь в плане личного удобства.

Кеш браузера очищали? есть ли у вас серверное кеширование статики?

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

Нужно в этом случае использовать не HTML, а именно символы кодировки UTF8 https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts

Вообще неверное предположение. Проверяйте наличие прав на запись на файл uploads/sitemap.xml на него должен стоять CHMOD 666

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

Своих конкурентов я знаю. Да ладно, а что это у нас вдруг news_id = 1 нарисовался? У нас что доп. поля только в полной новости показываются. А теперь достаньте их на 10 кратких новостях, и в пяти блоках custom, и все это в пределах одной страницы. Я посмотрю у кого решение производительнее, при 500 000 запросах в сутки к примеру. И записей в базе под миллион. Думаете таких сайтов на DLE нет? Так я вас разочарую. Многие решения пришли при анализе работы именно таких сайтов. Вот это мне вообще без разницы. Я вообще никого не осуждал, это вы пришли навязывать свои нормы и правила, не имея ничего за плечами. Ну в вашем же понимании конвертеры за счет воздуха работают, и ресурсов не потребляют. Так мне то что сомневаться. Вы сначала создайте, а потом указывайте. Пока что за 15 лет, те кто создал уже не указывает, а тот кто не создавал любит раздавать указания. Это опыт накопленный годами, а не теория. Так что когда создадите, поймете кто прав и перестанете указывать, либо так ничего не создадите, но будете любить раздавать указания. Для меня нет сложности удалить. Нагрузки не от удалений, а от записи и чтения. В основном конечно от чтения. И вы крайне не внимательны, я вам вообще писал о другом, а именно о том, почему в некоторых случаях записан логин пользователя, а не связка по id. На этот вопрос я вам не отвечал, но отвечу. Потому что существенно замедляется скорость записи и обновления. А на крупных сайтах, с большим количеством одновременных посетителей, это критично. В том то и дело, что вы свою "библию" тянете другим как "идеальную". А правда в том, и что подтверждает мой опыт, что понятия "идеальности" просто не существует. Любой другой программист назовет вашу "идеальную" структуру идиотской, и будет по своему прав, потому как он пишет по другому. Удобство понятие индивидуальное и у каждого свое. Хотя мне лично, главное не удобство как писать код и сколькими запросами удалять, а самое главное сделать так, чтобы код работал максимально быстро и потреблял как можно меньше ресурсов сервера. Это философия DLE, к которой я стремлюсь. И принимаю только пожелания как улучшить и оптимизировать именно это. А не то сколькими запросами выполнять действие которые либо не делается никогда, либо делается раз в месяц. Я про удаление новостей сейчас. Ваша проблема, что вы забываете самого главного. Писать код нужно не ради кода. И не важно сложный он или простой. А важно что пишите не код а продукт, которым будут пользоваться люди. Писать код нужно ради продукта, а не ради кода. И именно продукт должен работать быстро, качественно и на благо пользователя, а пользователю глубоко "по барабану" одна строка в коде или десять, но при этом далеко не по барабану, когда ради десяти посетителей нужно брать отдельный сервер, а для тысячи уже кластер (это я просто условные цифры привел, для примера) Это вообще вызывает улыбку, потому что пришел господин MaHarder и говорит, ну ка быстро выкинули больше 15 000 своих клиентов. Потому что мне на них все равно, и все равно что у них на сервере стоят старые версии MySQL, в которых InnoDB не поддерживает полнотекстовых индексов. Поэтому DLE автоматически определяет установленное ПО и может работать как на старом ПО, так и на новом используя как MyISAM так и InnoDB. Хостеры крайне консервативны, и редко обновляют работающее ПО. Хотя есть и такие кто использует всегда актуальное. И это не повод выбрасывать нам за борт своих клиентов, и ставить их в положение.

Давайте вы не будете давать советы, понятия при этом не имея почему что то именно так и не иначе. Договорились? Нет никакой определенности. И нет никакой идентификации пользователя то по имени то по id. Именно идентификация по одному параметру. А в некоторых таблицах есть имя пользователя, чтобы не тянуть эти данные связками и тем самым снизить нагрузку, когда это возможно. А когда нужно более расширенная информация, то используются уже связки по ID. Поэтому она и не создавала CMS, которые еще никто не обогнал по самой низкой нагрузке на сервер, при имеющихся в ней функциях. При всех своих знаниях нормативов и пятерок в школе )) Лично DLE и нам удобно. А DLE как известно готовый коробочный продукт, а не фрейворк. Понимаете разницу? Так создайте свою CMS, потом похвастаетесь, и мы посмотрим на ее производительность. Нет такого понятия, как правильно или неправильно. Есть продукт, который должен выполнять заявленные функции, и при этом делать это должен быстро и качественно. И именно к этому мы стремимся, и более того реализовали. А ваше обучение нормам, не делает продукт более быстрым и менее ресурсоемким, а наоборот. Вы увидели различия в типах, и все, начали думать о своих каких то нормативах, а вот почему именно так и не иначе, что это дает и какие преимущества в производительности, вы никогда не думали. Я при этом не говорю, что DLE абсолютно идеален в плане производительности и в нем наверняка можно что то улучшить и поменять, и такие предложения я с удовольствием готов слушать и реализовывать. Но говорить о непонятно кем установленных нормативах ... суть которых лишь замедлить DLE и увеличить нагрузку, зато чтобы было как в школе учили? Нет уж увольте ... И это правильно. Потому как иногда нужно оперировать выборками дат, например по месяцам, и тогда datetime оптимален, потому как в разные месяцы разное количество дней, иногда когда в этом нет необходимости выборка просто по числу намного быстрее потому как integer, а иногда вообще нет выборки по этому параметру и чистый unix формат оптимален, чтобы потом нативно работать с ним в PHP, а как следствие на этом сэкономить ресурсы. Жаль что ваша учительница учила только вас каким то придуманным своим персональным нормам, а не тому в чем разница между казалось бы одними и теми же данными, и тому что нужно знать разницу между скоростью выборок и работой с тем или иным форматом.

Такая функция есть в DLE И такая тоже давно есть.

Нет конечно. Ни на бесплатном тарифе ни за 20$, только на тарифе за 200$ Может попасться запросто, причем на любом тарифе в том числе и за 200$. Вы не решаете какой IP вы получите а они меняются постоянно у сайта. Все нравилось кроме цены. Мы пользуемся теперь услугами другой компании, а именно услугами дата центра по защите от DDOS. Мы и не в селектел поэтому 😀

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

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

Потому что шаблон мобильной версии у вас "кривой".

Блин, ну вот почему сразу нельзя написать суть проблемы четко и понятно. Посмотрите на свой первый пост и что вы там написали. Вы написали что код исковеркался и в качестве на что исковеркался, не дописали целую кучу второй строки. Я думал она у вас пропадает и на это смотрел при проверки и видел что конца кода строки не пропадает, а у вас суть совсем в другом, а в том что тег {THEME} обработался и заменился на путь к шаблону. Я даже на это внимание не обратил. Писать всегда нужно нормально и максимально подробно. Выражение "краткость сестра таланта" не работает когда нужна помощь технический поддержки. Нужно писать суть проблемы четко и ясно чтобы было понятно, и не приходилось выискивать в чем собственно состоит суть проблемы. Проблема принята. Данная проблема будет исправлена в следующей версии.