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

Sander1 · 14 ноября 2020

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. Наличие подкатегорий не сильно влияет.

Gameer · 14 ноября 2020

26 минут назад, Sander1 сказал:
Ради интереса и чистоты эксперимента, поставил свежий 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. Наличие подкатегорий не сильно влияет.

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

celsoft · 15 ноября 2020

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

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

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

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

Ради интереса и чистоты эксперимента, поставил свежий OpenServer 5.3.7. PHP 7.4, MySQL 8.0.19

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

Sander1 · 15 ноября 2020

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 - такой категории нет, но все работает быстро и правильно. Удивительно, но факт

Gameer · 15 ноября 2020

2 часа назад, Sander1 сказал:

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

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

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

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

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

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

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) JOIN (SELECT id FROM dle_post LEFT JOIN dle_post_extras e ON (id=e.news_id) INNER JOIN (SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN (2)) z ON (id=z.news_id) WHERE approve=1 ORDER BY date desc LIMIT 0,10) as l ON p.id=l.id ORDER BY date desc

Sander1 · 16 ноября 2020

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

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

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

crafic · 16 ноября 2020

у меня запрос

SELECT 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  LEFT JOIN dle_post_extras e ON (p.id=e.news_id) 
    WHERE approve=1  AND date < '2020-11-16 16:38:32' AND p.category REGEXP '[[:<:]](29|30)[[:>:]]'
    ORDER BY date DESC 
    LIMIT 20;

занял 0.003сек при 26 912 новостях. если же с INNER JOIN DISTINCT , то (0.590 s)

подставлял и по 4 категории. p.category REGEXP '[[:<:]](9|10|12|23)[[:>:]]' - (0.003 s) . с INNER JOIN DISTINCT , то (0.412 s)

версия mysql 5.7.29-log

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

SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN (9,10,12,23)

занимает (0.342 s) . не говоря уже о обьединениях с dle_post dle_post_extras

Sander1 · 16 ноября 2020

Следующая тема о которой я так же хотел бы поговорить - тег {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

Изменено 16 ноября 2020 пользователем Sander1

crafic · 16 ноября 2020

на счет полей я тут тему создавал https://searchengines.guru/ru/forum/1021845

если по рейтингу сортируем то беда.

celsoft · 16 ноября 2020

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

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

А на запись она какой станет? Не проверили. А вот существенно увеличится. Во время просмотра не только чтение происходит, но и запись. Ваше тестирование в данном случае по одному запросу не совсем корректно.

Gameer · 16 ноября 2020

4 часа назад, Sander1 сказал:

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

Очень странно.

Тот что я предложил.

Стандартный

В базе 54000 записей.

PHP 7.3, MariaDB 10.3

Sander1 · 16 ноября 2020

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 или категории по умолчанию включена сортировка по просмотрам.

celsoft · 17 ноября 2020

16.11.2020 в 18:18, Sander1 сказал:

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

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

Sander1 · 17 ноября 2020

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.

Хоббит · 17 ноября 2020

15 минут назад, Sander1 сказал:
Мне нет смысла выдумывать.

Операционная система: 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.

Если надо могу дать доступ к бд с 300к+ новостями, чисто контентый сайт, бд весит ~6 гб

Изменено 17 ноября 2020 пользователем Хоббит

Sander1 · 17 ноября 2020

Локалка:

Версия 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. У меня банально закончилось место на винте под эту временную таблицу.

crafic · 18 ноября 2020

SELECT COUNT в MyISAM тоже в разы быстрее чем на Innodb

skd · 21 ноября 2020

Здравствуйте! Мегаважно сделать выбор основной категории новости, категории, которая будет отражаться в url новости. Это крайне не удобно, когда назначается категория, которая просто выше в списке. Например, пусть основной категорией первая, выбранная пользователем, или сделать поле выбора основной категории. Спасибо за движок!

crafic · 23 ноября 2020

если для ред публ на сайте выбран bbcode то невозможно загрузить изображение пока не будет фокус в textarea

аналогично кнопочка возле нее

alex32 · 23 ноября 2020

22.11.2020 в 04:58, skd сказал:

Здравствуйте! Мегаважно сделать выбор основной категории новости, категории, которая будет отражаться в url новости. Это крайне не удобно, когда назначается категория, которая просто выше в списке.

Поддерживаю, потому что сейчас с этой принудительной сортировкой сильно снижается функционал тегов [category] и [catlist]

dimitron · 23 ноября 2020

Дополнительно поле СПИСОК. Нужно расшыть его что бы можно было выбрать несколько пунктов из списка. Такое же поля как мы выбираем категории (несколько категорий).

Mr. Bot · 25 ноября 2020

21.11.2020 в 23:58, skd сказал:

Здравствуйте! Мегаважно сделать выбор основной категории новости, категории, которая будет отражаться в url новости. Это крайне не удобно, когда назначается категория, которая просто выше в списке. Например, пусть основной категорией первая, выбранная пользователем, или сделать поле выбора основной категории. Спасибо за движок!

Этому багу уже 100 лет в обед, но судя по всему @celsoft не видит ничего зазорного в том что второстепенные категории могут заменять основную, в зависимости от того чей ID категории меньше.

23.11.2020 в 23:46, alex32 сказал:

Поддерживаю, потому что сейчас с этой принудительной сортировкой сильно снижается функционал тегов [category] и [catlist]

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

@celsoft, почему доп. поле дата и время не использует unixtime?
Элементарно же можно было сделать много интересных вещей (вроде привязки к времени сайта, сортировке, различные кастомные выборки), а так это сугубо текст в БД.

alex32 · 25 ноября 2020

5 минут назад, Mr. Bot сказал:

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

так то если категории не вложенные, то этот тег игнорируется, потому что у полной новости всего одна категория, которая стоит первой

Crashlabs · 26 ноября 2020

Просьба добавить тег [inform_имя] текст [/inform_имя] для проверки информера по аналогии с [banner_имя] текст [/banner_имя].

Crashlabs · 30 ноября 2020

Также, не хватает аналогичных тегов [page-description] текст [/page-description], [not-page-title] текст [/not-page-title] только для {category-title} и {category-description}

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

Рекомендованные сообщения

Sander1 62

Ссылка на сообщение

Поделиться на других сайтах

Gameer 321

Ссылка на сообщение

Поделиться на других сайтах

celsoft 6221

Ссылка на сообщение

Поделиться на других сайтах

Sander1 62

Ссылка на сообщение

Поделиться на других сайтах

Gameer 321

Ссылка на сообщение

Поделиться на других сайтах

Sander1 62

Ссылка на сообщение

Поделиться на других сайтах

crafic 35

Ссылка на сообщение

Поделиться на других сайтах

Sander1 62

Ссылка на сообщение

Поделиться на других сайтах

crafic 35

Ссылка на сообщение

Поделиться на других сайтах

celsoft 6221

Ссылка на сообщение

Поделиться на других сайтах

Gameer 321

Ссылка на сообщение

Поделиться на других сайтах

Sander1 62

Ссылка на сообщение

Поделиться на других сайтах

celsoft 6221

Ссылка на сообщение

Поделиться на других сайтах

Sander1 62

Ссылка на сообщение

Поделиться на других сайтах

Хоббит 36

Ссылка на сообщение

Поделиться на других сайтах

Sander1 62

Ссылка на сообщение

Поделиться на других сайтах

crafic 35

Ссылка на сообщение

Поделиться на других сайтах

skd 5

Ссылка на сообщение

Поделиться на других сайтах

crafic 35

Ссылка на сообщение

Поделиться на других сайтах

alex32 943

Ссылка на сообщение

Поделиться на других сайтах

dimitron 34

Ссылка на сообщение

Поделиться на других сайтах

Mr. Bot 26

Ссылка на сообщение

Поделиться на других сайтах

alex32 943

Ссылка на сообщение

Поделиться на других сайтах

Crashlabs 81

Ссылка на сообщение

Поделиться на других сайтах

Crashlabs 81

Ссылка на сообщение

Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Создать аккаунт

Войти