Leaderboard

Задача скорее практически не решаемая. Такое решение оптимально подходит для систем где есть однозначный признак сортировки - например соцсети, где фактически сортирующим признаком является идешка, направление роста которой всегда направлено в сторону увеличения. Что позволяет постраничные выборки делать в виде дополнительной фильтрации "от уже показанного ид и выше" обрезая полученную выборку от начала на длинну записей на странице. В результате запросы лимитируются по виду LIMIT N, что оч хорошо. В работе с недвижкой сортирующих факторов больше чем один, а самый "удобный" - по ид - является так же и самым бесполезным. Поэтому все постарничные запросы приходят к виду LIMIT M, N. А принцип выборок по таким запросам весьма трудоемок с ростом M. Т.е. если вам нужно получить 5-ю страницу и на странице у вас 10 объектов, то по факту вам нужно выдернуть с базы 50-объектов и первые 40-к выкинуть. Естественно на 1000-й странице объемы возрастут. Так что тут дело не в количестве на страницу, а скорее в балансе между количеством на страницу и количеством страниц. Для поисковика по факту важна первая страница из постранички. Вторую и далее он вообще не должен видеть. А первая обычно ВСЕГДА загружается менее напряжно по сравнению с остальными. Так что не парьте голову и учитывайте именно удобство людей. Листать странички по 3 объекта и листать списки по 500\страницу - две крайности.

5.4 и выше. Magic_quotes_gpc = ON - лучше ОФФ Display_errors = ON - можно тоже ОФФ если проект уже продакшен. если в стадии отладки-настройки, то допустимо и ОН но если ОФФ предыдущий, то включить Logs_errors Max_execution_time = 30 сек. Memory_limit = 64 MB обе эти настройки вменяемы и могут изменяться лишь в процессе. Напр. если работает парсинг и данных много, что возможно придется поднять обе эти планки, но скорее всего не глобально, а только в конкретных модулях путем включения ini_set. Хотя в самом общем случае Memory_limit маловат. Я бы поставил 256. Max_input_vars = 1000 Должно быть выше крыши, кроме случая когда делаются переводы полей модели. Тогда этого параметра может не хватать.

5.6 параметры на продакшн? тогда Display_errors = off Post_max_size и Upload_max_filesize = 2 MB Memory_limit = 256 MB если даст хостер

Нет. в редакторе форм вы управляете размещением элементов на форме. В /template/frontend/realia/realty_view.tpl нужно управлять размещением кода явно.

Использовать стоит. Но и стоит помнить о мере. Если посещаемость не гигантская и сервер выделенный, то динамического зиппирования должно хватить и проблем не будет. До определенного предела. Если посещаемость растет и весь плюс на отдаче сжатого контента растрачивается на расходы по зиппированию на лету + начинает скрипеть хостинг, то не стоит. В последнем случае может быть логичным сделать готовые статичные гзип-копии файлов и указать в шаблоне подключение их вместо постоянного гзиппирования разжатых файлов при каждом запросе.

В список путем размещения в шаблоне списка {$grid_items.системное имя поля "студия от..."} {$grid_items.системное имя поля "двухкомнатная от.."} {$grid_items.системное имя поля "трехкомнатная от..."} в общем такой алгоритм справедлив для любого поля типа "safe_string"

Наверное проще и эффективнее будет сменить шаблон на адаптивный, т.к. уже сейчас 30-50% посетителей заходят с мобильных устройств и этих посетителей вы теряете, т.к. распальцовкой по смартфону/планшетнику никому заниматься не охота и вчитываться в неадаптированные шрифты тоже, проще перейти на сайт конкурента. Экономя 3-5 тыс. вы теряете больше.

К сожалению, это проблема скрипта prettyPhoto. Везде где я сталкивался с этим скриптом, присутствует данная проблема. Точно уже не помню, но если мне не изменяет память, то я избавлялся от этой проблемы путем добавления подобной строчки $("a[rel^=prettyPhoto]").prettyPhoto({deeplinking: false});