celsoft

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

Я вас понял. Проблема подтверждается. Будет исправлена в следующей версии скрипта.

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

если скачиваение идет через тег [attachment=...] то конечно нагружается, т.к. скачивание идет через скрипт DLE. Если при загрузке указано было что файл публичный и скачивание по прямой ссылке, то нет не нагружается.

Он их считает в любом случае. Если не править файлы скрипта. Вы убрали сортировку, а значит порядок вывода будет не предсказуемым. Результаты будут меняться. Тут уж как MySQL решит и как ему удобней.

Обе эти ссылки абсолютные а не относительные. И вам в данном случае нужно убрать имя домена, а не сделать относительными. Но не суть. В админпанели есть раздел поиск и замена, и там делаете замену "http:/site.ru/" на "/". Не забудьте сделать бекап на случай если что то пойдет не так, прежде чем делать замену.

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

Я не удивлен, при том что вы указали 10 млн. новостей и данные своего сервера: Видимо вы память под свои данные, служебные ключи и прочее и прочее собираетесь брать из воздуха. 4 ГБ памяти это на все !!!! на работу OS, сотен процессов различного серверного ПО и т.д. Куда все все помещать будете? плюс два ядра на обработку данных, при условии что соседи ничего не выгребают с процессора. Ничего не берется из ниоткуда и не пропадают в никуда. Для 10 млн публикаций не то что о мощном отдельном тщательно оттюнингованном в плане серверных настроек нужно задумываться нужно, а возможно да

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

У меня нет готового плагина или кода на данный момент

Это ошибка в скрипте, она будет исправлена в следующей версии

Все она ставится, не вижу никаких проблем ее поставить такую ссылку. Что именно вы делаете некорреткно, я уже не знаю.

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

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

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