- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Всё просто, на главной делаете вывод последних 10ти, а на второй странице вывод не по дате поступления, а самые первые добавленные выводить тобиш самые старые записи, тогда их номера будут фиксированные т.е первые десять записей будут постоянно под цифрой 1 и не будут сдвигатся, а для свежих будет тольк главная страница ну и на какойнить 335й, 336й их тож можно найти будет).. Такую херню решили сделать?)))
Не уловил вашу идею.
а если пользователь пойдет на вторую (с начала) страницу читать предыдущие новости, он что там старье увидит?
Не уловил вашу идею.
а если пользователь пойдет на вторую (с начала) страницу читать предыдущие новости, он что там старье увидит?
Ну можно сделать хитрее, на второй странице у вас будет страница не под номером 1, а под номером 355 т.е самое свежее, а чел будет видеть визуально циферку 1, а вы там уже внутри при $_REQUEST['p']=355; будете конвертить в последнюю 355 страницу т.е:
страница 1 == ($_REQUEST['p']) эт 355 <a href="/?p=355">1</a> ... <a href="/?p=354">2</a>
ну а потом что-то типа:
from=(355*per_page)
to=per_page
SELECT * FROM table WHERE ... LIMIT from, to
Вывод списка номерков тож не сложно, идея думаю понятна..
Сложно, правда? ахахахаха
Специально слазил на баш посмотрел. Имеем:
1. Страница (главная) 49 элементов + блок рекламы
2. Предпоследняя страница 50 элементов без блока рекламы
3. Последняя страница (первая в нумерации) 15 элементов.
ч.т.д. Я думаю что заморачиваться с равным распределением это бред.
В качестве вариантов решения можно рассмотреть использование алгоритма поиска целого делителя. Когда исходя из количества записей система будет рассчитывать количество элементов на странице. Для снижения нагрузки на сервер пересчет данного параметра можно осуществлять лишь при входе новых элементов. И будут проблемы с кешированием. (в смысле вырастет нагрузка)
ЗЫ Да чуть не забыл и нужно обязательно на уровне частных случаев учитывать проблему простых чисел. Вводя дополнительную коррекцию либо через (опять же) плавающее количество последней страницы, либо по примеру база за счет подмены элемента рекламным блоком.
Я думаю что заморачиваться с равным распределением это бред.
Это удобно пользователям и для СЕО.
С какой стороны это бред?
С какой стороны это бред?
На данный момент есть стандартная схема формирования страниц. С неполными последними. Чем она плоха?
Тем, что содержание страниц все время меняется.
У каждой страницы должен быть свой контент. Это удобно для посетителей и для поисковиков.
У каждой страницы должен быть свой контент. Это удобно для посетителей и для поисковиков.
Тогда просто делать вывод от старших страниц к младшим и не морочить голову. Первая страница при этом будет наполняться по мере.
это плохо, когда на первой странице один элемент вместо 10.
Тогда уж первая должна иметь излишек 10-20