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

Sander1

местные
  • Публикации

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

  • Посещение

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

    20

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

  1. При использовании DIRECTORY_SEPARATOR на Windows - путь к файлу получается с обратным слешем:

    \engine\modules\file.php

    В то время как в утилите управления плагинами прописан путь:

    /engine/modules/file.php

    Отчего DLEPlugins::Check() не находит файл.

    В принципе мелочь, но ведь не сложно из коробки прописать строку:

    '/' === DIRECTORY_SEPARATOR || $check_file = str_replace(DIRECTORY_SEPARATOR, '/', $check_file);

     

  2. Проблема во всех версиях до DLE 15.3 включительно.

    $custom_cache_id = "customcomments".$param_str.$config['skin'];

    Кеш проверятся с использованием значения вышеуказанной переменной.

    $content = dle_cache( "news", "customcomments".$custom_cache_id, true );

    Т.е. значение получается "customcommentscustomcomments параметры"

    А создается кеш с другим именем:

    if ( $config['allow_cache'] ) create_cache( "news", $content, "customcomments".$param_str.$config['skin'], true );

    Т.е. тут значение получается "customcomments параметры"

  3. 1617045261_logo.png

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

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

    Цитата

    Страница модуля: Highload by Sander
    Цена: $17

    На странице модуля представлена более подробная информация, а так же там его можно купить в автоматическом режиме

     

  4. Если по заданным критериям не найдено никаких комментариев и используется memcache, то кеширование не будет работать, поскольку метод:

    $content = $comments->build_customcomments( $tpl, $custom_template.'.tpl' );

    Ничего не возвращает, т.е. имеем $content = NULL
    И в мемкеш так же записывается значение NULL

     И следовательно проверка кеша уже недействительна.

    if( $content !== false ) {

     

  5. 1612540862_logo.png

    С помощью данного модуля можно организовать разделение страницы полной новости на вкладки с отдельными URL адресами.

    Для каждой вкладки создается своя отдельная URL страница со своим шаблоном.
    Панель навигации подключается автоматически, но так же можно подключить ее вручную в любом месте сайта.
    Внешний вид панели можно оформить в любом стиле. Единственное что необходимо - это наличие знаний html+css.

    1612534641_screenshot_2.png

    1612534613_screenshot_4.2.png

    1612534604_screenshot_5.png

    1612534618_screenshot_6.png


    Админка:
    1612535456_screenshot_10.png

    1612535524_screenshot_11.png
     

    Цитата

    Страница модуля: Fullpage-Tabs by Sander
    Демо: Довод / Tenet (2020)
    Цена: $8

    На странице модуля представлена более подробная информация, а так же там его можно купить в автоматическом режиме

     

    • Поддерживаю 1
  6. 1608931119_logo.png


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

    Админка:
    1608931556_screenshot_6.png

    1611579058_screenshot_7.png

    Виды навигации:
    В модуле поддерживается 5 типов навигации (и без навигации).

    1. Стандартная, цифры и кнопки Вперед-Назад.
      1608931558_screenshot_7.png
       
    2. Только цифры
      1608931507_screenshot_10.png
       

    3. Только кнопки Вперед-Назад
      1608931548_screenshot_9.png
       

    4. Показать еще
      1608931515_screenshot_8.png
       

    5. lazyLoad - автоподгрузка по мере прокрутки контента.

     

    Цитата

    Страница модуля: AJAX-Custom by Sander
    Демо: TestFilm - тестовый сайт
    Цена: $7

    На странице модуля представлена более подробная информация, а так же там его можно купить в автоматическом режиме

     

  7. 1611098557_views-top-v2.png

    Новая версия модуля - дополнения для тега custom, который позволяет организовать вывод реально популярных материалов исходя из значений текущих просмотров.
     
    Как известно, в DLE есть возможность вывод "популярных" новостей.
    Это можно сделать через тег {topnews} или посредством {custom order="reads" days="30"}
     
    Но в обоих случаях будет выведен топ популярных материалов основываясь на дате публикации.
    Т.е. если новость была опубликована более месяца назад, но по сей день пользуется популярностью, то вышеуказанные методы такую новость не будут показывать в ТОП-е.
     
    Для решения этой проблемы и создан модуль Views-Top.
    Основной его функционал - это сбор суточной статистики и предоставление возможности вывести реально популярные материалы за заданный промежуток времени.
    1611143091_screenshot_6.png
     
    Так же, помимо его основного функционала, он работает в разы быстрее чем order="reads"
    Пример его использования:
    {custom order="views_top_7"}
    где 7 - количество дней (ТОП созданный в админке модуля).
     
     
    Цитата

    Страница модуля: Views-Top v.2 by Sander
    Демо: TestFilm - тестовый сайт
    Цена: $5

    На странице модуля представлена более подробная информация, а так же там его можно купить в автоматическом режиме

     

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

    А много ли сайтов на дле - 200-300тысяч публикаций?

    Не знаю. Может и есть, не сомневаюсь в этом.

    Но про такие числа и не идет речь. Все тестирования я провожу на вполне реальных сайтах с количеством публикаций 50-100к
    Сайт кинотематики 61к новостей: 44к фильмов, 10к сериалов, 6к мультиков. 
    Сайт с играми 94к.

  9. 14 часов назад, ntrtv сказал:

    А как без отложек? У нас несколько корреспондентов на сайте. Они расставляют новости с интервалом 20-30 минут. Как без отложки это делать? А как на раннее утро ставить, на поздний вечер и т.п.?

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

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

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

    16 часов назад, crafic сказал:

    ну тогда я предлагаю и AND approve=1 убрать для ускорения запроса

    и перемещать все новости на модерации в отдельный раздел. например вот так https://skr.sh/s5PsSZX3P3X

    а если бы мне за оптимизацию платили я бы еще кое что придумал,  да такое что dle точно бы прибавил газу  ?

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

  10. 33 минуты назад, MSK сказал:

    $cache_hash = md5($sql_count);

    если я правильно понял про кеширование, то при появлении новых новостей в момент хождения по страницам - $sql_count не изменится, изменится результат его выполнения...

    Мой хак хранит кеш всех результатов запросов в одном файле с именем news_select-count.tmp. Добавление или удаление новости удаляет все файлы кеша с префиксом news_. В том числе мой файл кеша так же будет удален и создан заново с новыми, правильными значениями.

     

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

    Sander1 у тебя наверно отключена отложенная публикация. и запрос один и тот же. а так на самом деле и AND date<'...' добавляется

    "Отложенная публикация" - это как раз то, что я у себя в статье рекомендую отключать в первую очередь.
    Вот примеры запросов:

    В разделе 110к новостей
    [query] => SELECT COUNT(*) as count FROM dle_post p INNER JOIN (SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN ('2')) c ON (p.id=c.news_id) WHERE approve=1
    [time] => 1,4607090950012
    
    
    В категории 44к новостей
    [query] => SELECT COUNT(*) as count FROM dle_post p WHERE category IN ('1') AND approve=1
    [time] => 0,27791213989258
    
    
    В категории 10к новостей
    [query] => SELECT COUNT(*) as count FROM dle_post p WHERE category IN ('2') AND approve=1
    [time] => 0,083189964294434
    
    
    В разделе 5к новостей
    [query] => SELECT COUNT(*) as count FROM dle_post WHERE xfields LIKE '%2019%' AND approve=1
    [time] => 0,746661901474

     

  11. Вновь подниму вопрос касательно оптимизации.

    Как известно, на средних и больших БД, запрос вида:

    SELECT count(*) as count_all FROM dle_post WHERE {...}

    Порой занимает довольно продолжительное время. И чем больше новостей в разделе, тем дольше запрос.
    И получается, что на всех (!!) страницах где есть навигация:
    /page/2/, /page/3/, /page/4/, /page/5000

    Будет повторно выполняться один и тот же медленный запрос, который всегда будет отдавать один и тот же результат.
    Таким образом, в результате сканирования всех 5000 страниц, будет выполнено минимум 10000 запросов. Хотя могло, и следовало бы - 5001.

    Я предлагаю сделать отдельный кеш для счетчика количества новостей во всех разделах.

    PS. Для желающих использовать или попробовать это решение - выложил в виде плагина на github:
    https://github.com/San-Dev/dle-plugins/blob/master/cat-optim.xml

    • Нравится 1
    • Поддерживаю 1
  12. Локалка:

    Версия PHP: 7.3.17
    Версия MySQL: 8.0.19

    Часть 1. Пустые записи, 88к штук. InnoDB. Размер таблиц:
    dle_post = 37.7Мб
    dle_post_extras = 14.6Мб

    Результаты замеров плюс минус пол секунды, но в основном такие:

    dle_post_extras - 9.067 sec
    dle_post - 9.268 sec

    Часть 2. Новости частично заполнены, 89к записей, InnoDB.
    dle_post = 4.8 ГиБ
    dle_post_extras = 15.6 МБ

    dle_post_extras - 8.922 sec
    dle_post - 16.041 sec

    Часть 2.1 Эти же данные, но на MyISAM

    dle_post_extras - 1.361 sec
    dle_post - 1.994 sec

    Часть 3. Заполнена только короткая новость, в среднем по ~20кб текста и немного в доп.полях. Количество записей 134к, InnoDB, MariaDB-10.3
    dle_post = 7.1 ГиБ
    dle_post_extras = 21.6 Мб

    dle_post_extras - 5.292 sec
    dle_post - 8.445 sec

    Часть 3.1 Сократил short_story до 900 символов
    dle_post = 2.0 ГиБ

    dle_post_extras - 5.394 sec
    dle_post - 5.66 sec

     

    Зато запрос:

        WHERE category REGEXP '[[:<:]](1)[[:>:]]' AND approve=1
        ORDER BY e.news_read desc

    Выполняется 2,65 сек
    При том, что запрос с p.views обрабатывается за 0,0013 сек

    А все потому что Using temporary; Using filesort

    На большой таблице запрос с news_read DESC вообще выполнялся дольше минуты. Я не знаю почему так...
    А главную страницу сайта я вообще так и не смог открыть пока не выключил topnews. У меня банально закончилось место на винте под эту временную таблицу.

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

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

    Мне нет смысла выдумывать.

    Операционная система: Linux 3.10.0-1062.18.1.el7.x86_64
    Версия PHP: 7.2.29
    Версия MySQL: 5.5.5-10.0.38-MariaDB
    dle_post             60,703    MyISAM    utf8mb4_general_ci    201.5 МБ    
    dle_post_extras      60,703    MyISAM    utf8mb4_general_ci    7.6 МБ

    Обычный кино-сайтец, где-то одно предложение в short_story, где-то абзац, где-то вообще нету. Поле xfields заполнено везде, примерно по 500 символов в каждом.

    <?php
    error_reporting(E_ALL ^ E_NOTICE);
    
    define('DATALIFEENGINE', true );
    define('ROOT_DIR', __DIR__);
    define('ENGINE_DIR', ROOT_DIR . '/engine');
    
    include_once ENGINE_DIR . '/classes/plugins.class.php';
    header('Content-type: text/plain; charset=utf-8');
    
    
    echo date('Y-m-d H:i:s') . ' dle_post_extras' . PHP_EOL;
    
    $ids = range(10000, 60000);
    shuffle($ids);
    $mt = microtime(true);
    for ($i = 0; $i < 10000; $i++) {
    	$id = array_pop($ids);
    	$db->query('UPDATE dle_post_extras SET news_read = news_read + 1 WHERE news_id = ' . $id);
    }
    echo round(microtime(true) - $mt, 3) . ' sec' . PHP_EOL . PHP_EOL;
    
    
    
    echo date('Y-m-d H:i:s') . ' dle_post' . PHP_EOL;
    
    $ids = range(10000, 60000);
    shuffle($ids);
    $mt = microtime(true);
    for ($i = 0; $i < 10000; $i++) {
    	$id = array_pop($ids);
    	$db->query('UPDATE dle_post SET views = views + 1 WHERE id = ' . $id);
    }
    echo round(microtime(true) - $mt, 3) . ' sec' . PHP_EOL . PHP_EOL;

    Результаты 4 замеров:

    2020-11-17 16:01:27 dle_post_extras
    1.251 sec
    
    2020-11-17 16:01:29 dle_post
    1.168 sec
    
    ------------------------------------
    
    2020-11-17 16:06:29 dle_post_extras
    1.488 sec
    
    2020-11-17 16:06:31 dle_post
    1.38 sec
    
    ------------------------------------
    
    2020-11-17 16:06:38 dle_post_extras
    1.279 sec
    
    2020-11-17 16:06:39 dle_post
    1.271 sec
    
    ------------------------------------
    
    2020-11-17 16:06:50 dle_post_extras
    1.443 sec
    
    2020-11-17 16:06:51 dle_post
    1.394 sec

    Сейчас на локалке сделаю 80к новостей в каждой заполнив shortstory по 1 - 10кб текста
    Так же проверю заполнив и fullstory по 30-60кб текста, хотя и считаю, что full_story следует перенести в post_extras.

  14. 34 минуты назад, celsoft сказал:

    А на запись она какой станет? Не проверили. А вот существенно увеличится. 

    Вот, провел небольшой тест:

    $ids = range(10000, 60000);
    shuffle($ids);
    $mt = microtime(true);
    for ($i = 0; $i < 10000; $i++) {
    	$id = array_pop($ids);
    	//$db->query('UPDATE dle_post SET views = views + 1 WHERE id = ' . $id);
    	$db->query('UPDATE dle_post_extras SET news_read = news_read + 1 WHERE news_id = ' . $id);
    }
    echo microtime(true) - $mt;

    Для обоих таблиц - время одинаковое, ~1.2 сек на 10к запросов.
    Но ведь к тому же есть кеширование счетчика просмотров.

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

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

    Ваше тестирование в данном случае по одному запросу не совсем корректно.

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

  15. Следующая тема о которой я так же хотел бы поговорить - тег {sort}
    Я согласен с тем, что разделение таблицы dle_post на dle_post и dle_post_extras - это хорошее решение.
    Но вот с тем как выполнено это разделение - я немного не согласен.

    По моему мнению, во вторую таблицу так же следовало бы вынести второстепенные данные, которые используются преимущественно только на странице полной новости.
    К примеру это такие поля как:
    descr, keywords, allow_br и, пожалуй, full_story

    Но в свою очередь перенести обратно из dle_post_extras поля:
    news_read, allow_rate, rating, vote_num, editdate, editor, reason

    Чтобы при штатном выводе контента show.short.php - вообще не использовалась таблица dle_post_extras (за исключением rss).

    Теперь немного конкретики и зачем я изначально упомянул тег {sort}
    При использовании сортировки по популярности или посещаемости:

    SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, e.news_read, e.allow_rate, e.rating, e.vote_num, e.votes, e.view_edit, e.editdate, e.editor, e.reason 
    	FROM dle_post p
        LEFT JOIN dle_post_extras e ON (p.id=e.news_id)
        WHERE category IN ('1') AND approve=1
        ORDER BY e.news_read desc
        LIMIT 0,60

    Время запроса стабильно 1 - 1.5 сек. Количество новостей в категории 44к
    EXPLAIN: Using index condition; Using where; Using temporary; Using filesort

    Но если перенести колонку news_read в dle_post, то картина совершенно другая

    SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, e.news_read, e.allow_rate, e.rating, e.vote_num, e.votes, e.view_edit, e.editdate, e.editor, e.reason 
    	FROM dle_post p
        LEFT JOIN dle_post_extras e ON (p.id=e.news_id)
        WHERE category IN ('1') AND approve=1
        ORDER BY p.views desc
        LIMIT 0,60

    Время запроса не превышает 5мс
    EXPLAIN: Using where

    Аналогичная проблема касается сортировок в custom

    • Нравится 1
    • Поддерживаю 2
  16. 17 часов назад, Gameer сказал:

    Как на счёт такого запроса?

    С тем же успехом, 220мс.
    Даже чуть хуже. Во всех ситуациях в среднем на 15мс медленнее. Это более заметно, когда выборка идет по двум категориям, когда тайминги в районе 40мс и 55мс соответственно. 

  17. 13 часов назад, Gameer сказал:

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

    Да это просто програмно заполненная база из "Test #{n}" заголовков с рандомным распределением по заданным категориям.

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

    Если вы можете вы знаете лучшее решение, то я был бы рад это услышать.

    К сожалению, если бы оно у меня было - я бы его уже озвучил :(
    Разве что такое предложение, сделать пункт "мультикатегории" опциональным индивидуально для каждой категории.

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

    Чистый, это априори значит плохо.

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

    Но обнаружил интересный факт.
    WHERE cat_id IN (2) - обрабатывается в среднем 220мс (против 900мс раньше) при количестве 54к

    Зато когда несколько категорий, то уже совершенно другое дело.
    WHERE cat_id IN (2,3) - за 39мс. 71к записей.
    WHERE cat_id IN (2,1000) - за 28мс. 1000 - такой категории нет, но все работает быстро и правильно. Удивительно, но факт

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

    Для чего в принципе включать мультикатегории непонятно. Их проще отключить и тогда запрос будет намного проще.

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

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

    Этот запрос не будет работать например в MySQL 8.xx

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

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

    Он не должен столько выполняться при 60к публикаций. Что то некорректно настроено в MySQL, недостаточно выделено под служебные данные.

    Ради интереса и чистоты эксперимента, поставил свежий OpenServer 5.3.7. PHP 7.4, MySQL 8.0.19
    DLE 14.1, добавил 78к новостей, каждая отмечена в 3х категориях. Ситуация чуть лучше, но все равно за пределами нормы.

    SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, e.news_read, e.allow_rate, e.rating, e.vote_num, e.votes, e.view_edit, e.editdate, e.editor, e.reason FROM dle_post p INNER JOIN (SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN ('3')) c ON (p.id=c.news_id) LEFT JOIN dle_post_extras e ON (p.id=e.news_id) WHERE approve=1 ORDER BY date DESC LIMIT 10,10

    [time] => 0.94885897636414

    SELECT COUNT(*) as count FROM dle_post p INNER JOIN (SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN ('3')) c ON (p.id=c.news_id) WHERE approve=1

    [time] => 0.33806180953979

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

    Если в категории 10к новостей, то тайминги: 0.137 и 0.041. Наличие подкатегорий не сильно влияет.

  19. Хочу обсудить вопрос оптимизации и целесообразности использования таблицы dle_post_extras_cats

    Имеется тестовый сайт с 60к+ новостями. Мультикатегории включены, но каждая новость отмечена только в одной категории.

    Берем штатный, стандартный запрос для категории (в ней 44к записей) и проведем несколько замеров:

    SELECT SQL_NO_CACHE p.id, p.autor, p.date, p.short_story, full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, e.news_read, e.allow_rate, e.rating, e.vote_num, e.votes, e.view_edit, e.editdate, e.editor, e.reason 
        FROM dle_post p 
        INNER JOIN (SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN (1)) c ON (p.id=c.news_id) 
        LEFT JOIN dle_post_extras e ON (p.id=e.news_id) 
        WHERE approve=1
        ORDER BY date DESC 
        LIMIT 50,20

    Запрос занял 2.1704 сек.
    Запрос занял 1.7433 сек.
    Запрос занял 1.6352 сек.

    Но если выполнить этот запрос по старому формату, с category REGEXP '[[:<:]])(1)[[:>:]]', то числа получаются уже совершенно другие:
    Запрос занял 0.0024 сек.
    Запрос занял 0.0017 сек.
    Запрос занял 0.0020 сек.

    На другом тестовом сайте, где в категории ~100к записей - ситуация абсолютно такая же.

    И вот еще, если в запросе несколько категорий, то в первом случае время запроса всегда больше 2 сек, во втором практически не меняется, так же в районе 0,002 сек.
    EXPLAIN запроса показывает вовсе не радостную картину: Using temporary; Using filesort - т.е. используется временная таблица и сортировка выполняется без использования каких-либо индексов.

    Я не хочу сказать, что использование REGEXP - хорошая практика. Его действительно следовало заменить, но текущая реализация, как мне кажется, тоже не является лучшим решением.

  20. WHERE cat_id IN ('" . implode ( ',', $allowed_cats ) . "')

    В результате имеем:

    WHERE cat_id IN ('1,2,3,4,5')

     

    PS. В админке можно одновременно выбрать '- Все -' и другие категории, в результате в строке allow_cats будет сохранена строка: 'all,1,2,3,4,5'
    Ну и соответственно эта проверка уже работать не будет:

    if ($value['allow_cats'] != "all" AND !$value['allow_short'] )

     

    • Поддерживаю 1
  21. DLE 14.0

    Для сортировки и редактирования используется "виртуальный" ID, который по сути является просто номером строки в файле xfields.txt

    Но при перемещении поля, в HTML коде остаются прежние ID, а файл перестраивается и эти же поля уже имеют новые ID.

    Приходится каждый раз обновлять страницу.

     

×
×
  • Создать...