Перейти к публикации

SKYNET74

изгнанные
  • Публикации

    651
  • Зарегистрирован

  • Посещение

  • Дней в лидерах

    50

Сообщения, опубликованные пользователем SKYNET74

  1. 3 часа назад, panovgor сказал:

    Да вы гений :D Меня как бы интересовала более конкретная информация. В частности, я хотел бы знать нужно ли для создания этой задумки править файлы движка или можно обойтись коррективами шаблона. Мне кажется что нужно вносить изменения в show.full.php

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

    • Поддерживаю 1
  2. В 04.11.2016 в 14:28, germanydletest сказал:
    
    TRUNCATE TABLE `dle_post`

    и

    
    TRUNCATE TABLE `dle_post_extras`

    Выполняем эти два sql запроса, при этом не забываем менять префикс таблиц если меняли его при установке 

    ВАЖНО: Все новости будут удалены!

    Это не всё что нужно сбрасывать, могут быть потом подводные камни.

    • Поддерживаю 1
  3. Хотелось бы видеть продвинутую систему логирования, что бы каждый чих на сайте можно было логировать, отредактировал новость пользователь, ушло в лог, отправил ПМ или коммент, ушло в лог и т.д. и т.п., а не как сейчас, что только административные действия хоть как то логируются, и то далеко не все действия.
    К тому же нужно бы писать в БД IP регистрации пользователя и IP с которого была добавлена и отредактирована новость, IP с которого было написано ПМ.
    В свете законодательства это просто необходимо сейчас, да и во внутренних "разборах полётов" часто пригождается (сейчас сделано в виде модификации кода).

    • Поддерживаю 2
  4. 1 час назад, celsoft сказал:

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

    Я понимаю что чуть чуть образно было (хотя SQL запросы там простые же будут), но если сайт имеет десятки тысяч новостей, он явно хостится не на хостинге за пол бакса, более менее стоящие проекты уже как бы и дедиками обзаводятся, так что разовая нагрузка ночью не особо такая проблема.

    • Поддерживаю 1
  5. 30 минут назад, celsoft сказал:

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

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

    • Поддерживаю 1
  6. 27 минут назад, celsoft сказал:

    И при этом как то навредить сайту? Нет нельзя. Поисковик примет за основную страницу ту которая стоит на самом сайте, т.е. /news/ а страницу /news/page/1/ отбросит как дубликат, на ранжировании основной страницы это никак не скажется.

     

    Алгоритмы ранжирования неизвестны, а вот алгоритмы приоритетов ими прекрасно опубликованы и описаны.

     

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

    Может быть потому что все популярные сайты активно используют каноничные ссылки и редиректы? А так же роботс.txt.

     

     

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

    Почему, если например на каком то внешнем сайте умышленно например поставить ссылку на ваш сайт /news/page/1/, то робот ее найдет, в панели вебмастера у вас отсветится что такую страницу нашел робот. Эти уведомления специально сделаны для вебмастеров, чтобы если они допустили где ошибку и не заметили исправили ее. Но вреда от этой ссылке на внешнем сайте, для самого сайта не будет никакого.

     

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

     

    Давайте мне ссылки на сайты, которые используют ваши SEO CMS, я вам на них продемонстрирую как прикручу им параметры, которые они никак не уберут. Если вам так не нравится банальный пример на яндексе. 

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

    • Поддерживаю 1
  7. 11 минуту назад, celsoft сказал:

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

     

    Какие старые? DLE таких ссылок никогда не формировал.

    т.е. по вашему нельзя скормить ПС дубликат страницы /news/ по адресу /news/page/1/?
    Их внутренние алгоритмы нам не ведомы, и вместо надежды на вменяемость ПС может стоит сделать просто переадресацию, как у всех других SEO направленных CMS?
    Для других рандомных GET параметров есть вообще как бы каноническая ссылка, которая тоже не везде используется.

    PS: Приводить в пример яндекс и сравнивать его со свежим сайтом, это как сравнивать мягкое с солёным...

    • Поддерживаю 1
  8. 41 минуту назад, Cartmont сказал:

    Пусть себе чихают, но новость не будет разбиваться на страницы вида:

    dle-news.ru/release/1687-datalife-engine-v111-final-release.html

    dle-news.ru/release/page,1,2,1687-datalife-engine-v111-final-release.html

     

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

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

    Если на то уж пошло, то ставим лимит 1К комментов на страницу и делаем кеширование, сердито конечно, но зато не выкидываем контент из индекса.

    • Поддерживаю 1
  9. 1 час назад, Cartmont сказал:

    /page/1/ и /page/1 видны, только если ручками писать в строку, кнопок и ссылок ведущих на них не нашел

    Однако это не значит что это не позволяет нагадить нужному сайту...
    Да и старые ссылки никуда не делись, канонической ссылки тоже нет, так что однозначно выпилить редиректом и начинать со страницы №2.

    • Поддерживаю 1
  10. 8 минут назад, celsoft сказал:

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

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

    И потом вы будете объяснять куче ваших клиентов что это они дураки, а не скрипт не проверяющий и пишущий копии ID категорий в category, из-за чего их mysql серверу всё плохее и плохее становится будет?



    Помнится при фиксе бага с не удалением подписок пользователя, в апдейте тоже не была реализована чистка ненужных строк в таблице _subscribe, и они у многих до сих пор мёртвым грузом висят (и грузят бедную БД), а некоторым даже проблемы в виде багов доставляют.

    • Поддерживаю 1
  11. 2 часа назад, Cartmont сказал:

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

    Ничего что паукам чихать на ajax по большей части (кроме гугла, он там что то чешится по этому поводу)?

    • Поддерживаю 1
  12. 6 часов назад, Captain сказал:

    ТС, да, просто слеш или адрес с ним.

    Исходя из вашего .htaccess ничего кроме "с www на без", как бы и не нужно, остальное "устаревшая годами хрень";), достаточно после RewriteEngine On:

    
    RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
    RewriteRule ^(.*)$ http://%1/$1 [L,R=301]

    Пункты 3 и 4 вашего вопроса поддерживаются скриптом по умолчанию уже давно (или я возможно чего-то не понял, приведите тогда конкретный пример, вернее ссылку на сайт), тем более в 11-ой версии, если не накосячили с правкой файлов DLE.

    Да там как обычно начали делать, да не доделали, я выше описал проведённые тесты...
    Нужно доделывать и выпиливать /page/1/ и /page/1 вообще, что бы был сразу редирект на /category_name/ и всё, а на остальных страницах проверялся слешь на конце, сейчас он только у категорий проверяется.

    • Поддерживаю 1
  13. В 19.07.2016 в 01:16, celsoft сказал:

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

    Однако почему то таймштамп-префикс у изображений идёт не по порядку, например у третьего по счёту изображения префикс может быть меньше чем у первого и второго, т.е. якобы третье изображение грузилось раньше чем первое и второе.
    Не совсем понятно почему скрипт так делает.
    Давно заметил эту проблему, особого дискомфорта не вызывает, т.к. в БД ссылки на изображения идут по порядку, но вот эстетически, в том же FTP изображения перемешаны, а не идут по порядку загрузки на сервер.

    • Поддерживаю 1
  14. Доделать уже средние копии изображений для доп.полей типа изображение и галерея, т.к. в коде функционал этот заложен, но его почему то не доделали.
    И расширить количество переменных для вывода полного пути к маленькому, среднему и оригинальному изображению, а так же переменные-условия, для составления сложных условий в шаблоне (если есть маленькая, выводим маленькую, если нет смотрим среднюю, если и её нет выводим оригинал).

    Сделать так же отдельные переменные для каждого отдельного изображения для доп.поля типа галерея по аналогии:
    {upload_images_N1_image_thumb_N2}
    {upload_images_N1_image_medium_N2}
    {upload_images_N1_image_full_N2}
    где N1 это название доп.поля галереи, а N2 это порядковый номер изображения из этого доп.поля, а так же переменные-условия для составления сложных вложенных блоков-условий.
    Например:
    [upload_images_N1_image_thumb_N2]{upload_images_N1_image_thumb_N2}[/upload_images_N1_image_thumb_N2]
    [not_upload_images_N1_image_thumb_N2][upload_images_N1_image_medium_N2]{upload_images_N1_image_medium_N2}[/upload_images_N1_image_medium_N2][/not_upload_images_N1_image_thumb_N2]
    [not_upload_images_N1_image_medium_N2]{upload_images_N1_image_full_N2}[/not_upload_images_N1_image_medium_N2]
    [not_upload_images_N1_image_full_N2]

    Ссылка на изображение-заглушку
    [/not_upload_images_N1_image_full_N2]

    • Поддерживаю 1
  15. В файле /engine/inc/xfields.php примерно на 77-78 строках:
     header("Location: http://" . $_SERVER["HTTP_HOST"] . $_SERVER["PHP_SELF"] .
    "?mod=xfields&xfieldsaction=configure");
    нужно бы заменить на:
    header("Location: ".$_SERVER["PHP_SELF"]."?mod=xfields&xfieldsaction=configure");

    т.к.:
    1. Может использоваться HTTPS.
    2. Всё таки лучше отправлять по относительной ссылке.
    3. В совокупности некоторых специфических факторов и настроек, редирект может отправлять на другой алиас сайта.

    • Поддерживаю 1
  16. В 13.10.2016 в 18:50, celsoft сказал:

    Тег {custom} это тег вспомогательного пользовательского вывода новостей по тем критериям которые указаны в параметрах тега. Никакие общие настройки на него не действуют. Для этого он и создан. Для вывода по настройкам, используется тег {content}. Никаких изменений в данном вопросе в скрипте не будет.

    Может быть просто в {custom добавить переменную main которая равняется 1 или 0? Если её нет то вообще ничего не добавлять в SQL запрос.
    У себя конечно уже давно сделано, но хочется из коробки, а не каждый раз перелопачивать код.

    • Поддерживаю 1
  17. В списке новостей в админ-панели сайта, при массовом добавлении категорий новостям, которые уже могут присутствовать в этих категориях, в БД в колонку category повторно заносится ID категории.
    Например может получится следующее: 11,1,1,11

    • Поддерживаю 1
  18. Логика скрипта действительно не делает редирект с /category_name/page/3 на /category_name/page/3, а отправляет сразу на /category_name/ что как бы не правильно.
    И с /category_name/page/1/ на /category_name/ так же редиректа нет, т.е. дубликат получается.

    Если уж начал разработчик делать нормальные адреса, то нужно было бы все ситуации отработать, а не только с /category_name на /category_name/.

    • Поддерживаю 1
  19. Проще всего будет добавить новый параметр в {custom, для этого нужно править функцию custom_print.
    Целсофту уже неоднократно предлагали расширить набор переменных для {custom (сделать элементарно для всех переменных антонимы), но воз и ныне там.
    Причём нагрузка будет лишь там, где действительно обилие переменных используется, а там где они не указаны, будет просто пропускаться данный кусок SQL запроса.

    • Поддерживаю 1
  20. Единственный вариант, это перебрать все новости, и путём встроенных функций DLE пересохранить все дополнительные поля новости+изменённое доп.поле, за один запрос это не сделать.
    Ну и не забыть сбросить файлы кеша, если он используется.
    Лучше написать отдельный модуль под это дело.

    • Поддерживаю 1
×
×
  • Создать...