Блок "Новости" и постраничная навигация с категориями

pavlodaranet

Новичок
Блок "Новости" и постраничная навигация с категориями

В общем тружусь над созданием раздела "новости".

Главная страница должна быть на странице ../news/index.php
На ней выводить 5 новостей из 5 разделов (по одной самой новой с каждого)
картинка

В итоге разобрался с постраничной навигацией с помощью гугла - в результате сделал постраничный вывод из таблицы news, теперь необходим вывод главной страницы раздела, с имеющимися ссылками на разделы вроде
http://test.ua/news/?cat=1&page=1

имеется следующий код:

PHP:
// Если $page отрицательно то, переходим на первую страницу 
if(empty($page) or $page < 0) $page = 1;   
if($page > $total) $page = $total;
а в данном случае надо чтобы при обращении ../news/ открывалась главная страница раздела.

Вот весь код:

PHP:
<?
// соединение с базой данных
$db = mysql_connect ("localhost","php","12345");
mysql_query("SET NAMES 'cp1251'"); 
mysql_select_db("pnet",$db);
  
// Кол-во на страницы 
$num = 2;   
// Текущая страница 
$page=$_GET['page']; 

// Общее число сообщений 
$result = mysql_query("SELECT  * FROM news ");   
$posts = mysql_num_rows($result);   

// Общее число страниц   
$total = intval(($posts - 1) / $num) + 1;   
// Начальная позиция отсчета 
$page = intval($page);   
// Если $page отрицательно то, переходим на первую страницу 
if(empty($page) or $page < 0) $page = 1;   
  if($page > $total) $page = $total;   
// С какого номера начать выводить сообщения 
$start = $page * $num - $num; 

// Вывод с $start 
$result = mysql_query("SELECT * FROM news LIMIT $start, $num");
while ( $postrow[] = mysql_fetch_array($result)) ;
 
for($i = 0; $i < $num; $i++)   
{   
 echo "<table>
                <tr>
                <td ><p><a href='view_news.php?id=".$postrow[$i]["id"]."'>".$postrow[$i]["title"]."</a></p>
               </td>
                 </tr>
          </table>";
}   
 
// Нужны ли стрелки назад   
if ($page != 1) $pervpage = '<a href= ./?page=1><<</a>   
                               <a href= ./?page='. ($page - 1) .'><</a> ';   
// Нужны ли стрелки вперед   
if ($page != $total) $nextpage = ' <a href= ./?page='. ($page + 1) .'>></a>   
                                   <a href= ./?page=' .$total. '>>></a>';   

// Стр. с обоих краев 
if($page - 2 > 0) $page2left = ' <a href= ./?page='. ($page - 2) .'>'. ($page - 2) .'</a> | ';   
if($page - 1 > 0) $page1left = '<a href= ./?page='. ($page - 1) .'>'. ($page - 1) .'</a> | ';   
if($page + 2 <= $total) $page2right = ' | <a href= ./?page='. ($page + 2) .'>'. ($page + 2) .'</a>';   
if($page + 1 <= $total) $page1right = ' | <a href= ./?page='. ($page + 1) .'>'. ($page + 1) .'</a>'; 

// Вывод 
echo $pervpage.$page2left.$page1left.'<b>'.$page.'</b>'.$page1right.$page2right.$nextpage;
?>
 

nalim

Новичок
Re: Блок "Новости" и постраничная навигация с категориями

а в данном случае надо чтобы при обращении ../news/ открывалась главная страница раздела.
Тоесть вы просите код который это делает?)
Или вам интересно как это сделать?))
Если второе - вом нужно сделать при отрицательной странице редирект на главную)
 

findnext

Новичок
где то я уже видел этот код :D

-~{}~ 23.12.08 14:11:

../news/

хорошо, вариант ->
1) редирект всех запросов на index.php с помощью мод реврайт
2) обработка урл
 

pavlodaranet

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

prolis

Новичок
Трудись ещё:
// Общее число сообщений
$result = mysql_query("SELECT * FROM news ");
// Вывод с $start
$result = mysql_query("SELECT * FROM news LIMIT $start, $num");

а по теме: если страница=0 или не установлена (../news/index.php), зная общее количество записей $post и количество их на странице $num, выводишь в цикле округлённое до большего значения страниц от $post/$num в виде ссылок
 

pavlodaranet

Новичок
а такой вариант?
PHP:
if(!isset($_GET[$cat])) // грузим главную
  {
}
else { категорию
 

Иван 76

Новичок
Re: Блок "Новости" и постраничная навигация с категориями

Автор оригинала: pavlodaranet

PHP:
// Если $page отрицательно то, переходим на первую страницу 
if(empty($page) or $page < 0) $page = 1;   
if($page > $total) $page = $total;
Это - упущение по отношению к поисковым системам. Несуществующий урл должен отдавать 404. Иначе индекс будет забит Бог весть чем.
 

pavlodaranet

Новичок
да не будет забит, т.к. ссылок для бота на несуществующие страницы небудет
 

x-yuri

Новичок
а такой вариант?

PHP:
if(!isset($_GET[$cat])) // грузим главную 
  { 
} 
else { категорию
если нет категории по умолчанию, то можно, не подумал. Но я бы без else обощелся: если грузим главную - redirect

Это - упущение по отношению к поисковым системам. Несуществующий урл должен отдавать 404. Иначе индекс будет забит Бог весть чем.
а откуда может взятся $page < 0?
 

Иван 76

Новичок
>да не будет забит, т.к. ссылок для бота на несуществующие страницы небудет

О! это только говорит про Ваш слабый опыт в работе с действующими проектами. Будет, еще и как.

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

Во вторых, - бывают случаи, когда Вы удаляете больше информации, чем добавляете (например, на новый год). Образуются "мертвые", но уже давно проиндексированные идентификаторы страниц.

И наконец - рефакторинг рубрикатора. Когда часть статей с одной рубрики резко уходит в другую рубрику. Опять же - образуются мертвые страницы в пагинаторе.

Да много еще случаев может быть. Кто-то изкал уязвимость на сайте, и ввел &page=+5 или &page=5'. Страшно то, что системы публичной статистики этот вызов зафиксировали, и поставили ссылку на нее, благополучно прописав ее для вовремя зашедшего поискового бота. Я уже молчу за хакерские боты, которые просто обстреливают сайты запросами типа &page=http://xxx.xxx.xxx.xxx/hack.php

За год работы проекта таких мусорных ссылок может скопиться - море.

А потом люди недоумевают. 500 уник. в день, а сайт грузит хостинг как монстр с 20К. При этом никто не удосужится посмотреть логи, посмотреть поисковый индекс.
 

x-yuri

Новичок
Кто-то изкал уязвимость на сайте, и ввел &page=+5 или &page=5'. Страшно то, что системы публичной статистики этот вызов зафиксировали, и поставили ссылку на нее, благополучно прописав ее для вовремя зашедшего поискового бота.
а можно подробнее? как бот полчит эту ссылку?

p.s. речь шла о $page < 0, а не о случаях, когда страницы уже нету
 

Иван 76

Новичок
x-yuri
>а откуда может взятся $page < 0?
Может взяться. Такое бывает, например, при просчетах в разработке пагинатора. Когда текущая страница больше чем количество записей в БД поделенных на лимит (например удалили сразу половину всех новостей, а бот по старинке зашел на мертвую страницу). Тогда генерятся отрицательные номера страниц, если невнимательно делать пагинатор.

>а можно подробнее? как бот полчит эту ссылку?
Через счетчики публичной статистики, которые генерируют в открытый доступ список посещенных страниц в виде ссылок на эти страницы
 

x-yuri

Новичок
по поводу ошибок: нельзя написать программу, которая защищает себя от своих же ошибок - это бесконечная рекурсия

по поводу засорения индекса: это имхо проблема поисковиков. Если ссылка на страничку исчезла, зачем ее хранить (страничку).
Кроме того, ситуация: пользователь щелкает на последнюю страничку, а в этот момент как раз страничка исчезает ))))
 

Иван 76

Новичок
>по поводу засорения индекса: это имхо проблема поисковиков. Если ссылка на страничку исчезла, зачем ее хранить (страничку).

Это, в первую очередь проблема владельца сайта (с точки зрения поисковой оптимизации) и проблема ресурсов сервера на паразитное обслуживание ботов. У ботов проблем нет. У них есть лимиты на количество ваших страниц в индексе, исходя из ряда параметров. Так что - это вдвойне проблема сайтовладельца.

Для бота страница исчезла тогда и только тогда, когда она перестала выдавать статус 200.

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

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

>по поводу ошибок: нельзя написать программу, которая защищает себя от своих же ошибок - это бесконечная рекурсия
Проще простого сделать примитивную валидацию входных параметров и выдавать 404 в случае неудачи.
 

x-yuri

Новичок
Это, в первую очередь проблема владельца сайта (с точки зрения поисковой оптимизации) и проблема ресурсов сервера на паразитное обслуживание ботов. У ботов проблем нет. У них есть лимиты на количество ваших страниц в индексе, исходя из ряда параметров. Так что - это вдвойне проблема сайтовладельца.
но поисковики ведь хотят избежать дублирования

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

Иван 76

Новичок
>но поисковики ведь хотят избежать дублирования
Проблема нечеткого распознавания дубликатов - слишком сложная тема, и выходит за рамки этого топика. Она тем более выходит за рамки PHP.

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

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


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

Т.е. если допустить, что, в заданный промежуток времени, содержимое БД не изменяется, - то многократный вызов одной и той же "мертвой" страницы будет показывать одно и то же уникальное содержимое (а именно - самые последние записи, ведь $page = $total), к которому можно вычислить уникальный идентифицирующий хеш.

Таким образом, можно было бы распознавать четкие дубликаты, но только при условии, что содержимое БД не меняется (что невозможно на живом сайте).
В противном случае, количество новостей на последней странице будет равно как остаток от деления количества строк в БД на лимит, и будет находиться в интервале от одного до $limit.
Т.е., при добавлении одной новости, - количество новостей на последней странице увеличивается на одну единицу.
При удалении любой новости - уменьшится на единицу.
А поскольку, удаляют как правило только последние новости (причем автоматически), - то изменится не только количество новостей на последней странице, но и ее содержимое (уже другие заголовки новостей).

А поскольку, поисковый робот посещает мертвые страницы в различные временные интервалы, то остается очень низкая вероятность, что он сможет увидеть на мертвых страницах один и тот же уникальный контент (ведь БД постоянно меняется.).

Контент мертвой страницы с прописанным $page = $total будет изменяться как при каждом добавлении новости, так и при каждом удалении новости.
Причем уникальным он НЕ БУДЕТ (в практических условиях) ПРАКТИЧЕСКИ НИКОГДА!
Вернуться в уникальное состояние он сможет только в том случае, если мы удалим ту новость, которая была добавлена самой последней (т.е. удалим самую свежую новость), что с практической стороны никогда не бывает.

Другая ситуация, когда контент мертвой страницы будет "максимально" но не "точно" совпадать с тем контентом, который у нее уже когда-то был, - это когда мы добавили ровно столько новостей, сколько их выводится на одну страницу ($limit), и при этом, не удалили ни одной новости! За одним маленьким исключением, - в пагинаторе стало на одну страницу больше! А это значит, что изменился порядковый номер последней страницы, и ссылка на последнюю страницу.


А значит содержимое мертвой страницы с $page = $total будет меняться при каждом изменении БД, и ее содержимое ВЕРОЯТНО НИКОГДА НЕ ПОВТОРИТСЯ!

Поэтому, поисковые системы, даже с очень сильными алгоритмами распознавания нечетких дубликатов, не в состоянии определять "мертвые страницы", что приводит к захламлению поискового индекса, снижению его качества (ведь индекс лимитирован, чем больше мусора - тем меньше качественных страниц), и повышенному потреблению трафика и ресурсов сервера

>Но компонент не должен защищать себя от своих же ошибок
Да не надо никого ни от кого защищать. Следуйте протоколу http и всего делов. Поисковая система через панель вебмастера вам сама скажет, какие страницы ссылаются на мертвые страницы.
 

x-yuri

Новичок
Во первых, не исключены ошибки в работе генераторов ссылок.
>Но компонент не должен защищать себя от своих же ошибок
Да не надо никого ни от кого защищать. Следуйте протоколу http и всего делов. Поисковая система через панель вебмастера вам сама скажет, какие страницы ссылаются на мертвые страницы.
я и говорю, что если цель избежать засорения индекса - это может быть оправдано, но обработка своих же ошибок - тупиковый путь

Проблема нечеткого распознавания дубликатов
тогда лучше редирект делать, а не 404 (чтобы пользователь не натыкался на такие штуки)
 

Иван 76

Новичок
>тогда лучше редирект делать, а не 404 (чтобы пользователь не натыкался на такие штуки)

При грамотном оформлении страницы 404 - в редиректе нет необходимости.
К тому же, если делать редирект, - то 301, т.к. 302 (в РНР по умолчанию) хранится в стеке и периодически "простукивается".
Но технически, с точки зрения протокола http, редирект здесь не уместен.
 

x-yuri

Новичок
на самом деле не знаю:
404 поможет пользователю понять, что то, что он ищет уже не существует (если он пришел через поиск).
Но списки (с постраничной навигацией) меняются, и если он попал на какую-то страницу, то интересующая его запись может на данный момент быть на другой странице. Так что полноценно решить проблему все равно нельзя
 
Сверху