sitemap

[MSK 289]

В админской части создания карты не верно считается к-во новостей.

	$row = $db->super_query( "SELECT COUNT(*) as count FROM " . PREFIX . "_post" );

т.е. учитываются все новости, хотя надо только опубликованные.

А в самом классе выборка верная.

[celsoft 6 072]

MSK,

Так нужно, у вас же в карте нет неопубликованных новостей. В чем тогда проблема и ошибка?

[MSK 289]

Как в чем???

в дальнейшем постоении карты..

	if ( !$map->limit ) $map->limit = $row['count'];

	if ( $map->limit > 45000 ) {

и тут строится карта из нескольких файлов. хотя нужен реально один общий.

[celsoft 6 072]

MSK,

если вы внимательно посмотрите то оставляется специальный запас в 5000 новостей от максимального лимита google, и роли это не играет в данном запросе, а ресурсы сервера экономит, немного но экономит. Плюс экономия по расходу памяти

У google лимит на максимум ссылок в файле, а не на минимум. Если в нем будет меньше это даже лучше, а не хуже

[MSK 289]

Да я не говорю о том, что на 5к меньше, я о том, что если новостей 40001 и из них 5 на модерации, мы имеем:

$pages_count = @ceil( $row['count'] / 40000 );

2 страницы, и карта новостей будет составляться из 2 частей.

Т.е. будет

sitemap индексный

sitemap1 статические

sitemap2 с новостями

sitemap3 будет пустой и на него ссылка будет в индексном.

Или я что-то упустил?

[celsoft 6 072]

Или я что-то упустил?

да упустили, строчку выше.

	if ( $map->limit > 45000 ) {

и строчка

$pages_count = @ceil( $row['count'] / 40000 );

может быть выполнена только при наличии не менее 45 000 новостей, и никак она не может быть выполнена при наличии 40001 новости

[MSK 289]

И еще заметил такой баг, если было создано несколько файлов sitemap, а затем, например, часть новостей была удалена, то sitemap1,2,3... остаются на сервере.

[celsoft 6 072]

И еще заметил такой баг, если было создано несколько файлов sitemap, а затем, например, часть новостей была удалена, то sitemap1,2,3... остаются на сервере.

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

[MSK 289]

Хорошо, с 1 новостью я привел не совсем показательный вариант.

Пусть на модерации их будет 5001 (при нынешнем обилии автопостеров абсолютно реальная картина), тогда все идет по описаномы выше сценарию.

Зачем закладывать 5к, если можно просто исключить новости на модерации?

их наличие или отсутствие на сервере никакой роли не играют

Ну да, я ожидал именно такой ответ...

[celsoft 6 072]

Пусть на модерации их будет 5001 (при нынешнем обилии автопостеров абсолютно реальная картина), тогда все идет по описаномы выше сценарию.

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

Зачем закладывать 5к, если можно просто исключить новости на модерации?

я ответил уже выше. Экономия нагрузки на MySQL и экономия расходов по памяти, именно по этому в файле находится максимум 40 000 новостей, а не 50 000 как может быть по максимальным лимитам. Доболнительным 10 000 ссылкам требуется много памяти чтобы сформировать и потом записать список в файл

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

[MSK 289]

Так я же НЕ прошу выдавать все 50к!!!

Я говорю о том, что

"В админской части создания карты не верно считается к-во новостей."

что мешает

	$row = $db->super_query( "SELECT COUNT(*) as count FROM " . PREFIX . "_post" );

заменить на

	$row = $db->super_query( "SELECT COUNT(*) as count FROM " . PREFIX . "_post WHERE approve=1" );

?

[celsoft 6 072]

MSK,

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

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

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

[MSK 289]

Позиция ясна.