Владимир Чернышев

Версии клиента и сервера совпадают?

if(RESULTS_COUNT<$results_per_page || RESULTS_COUNT==$results_per_page)

O_o

Есть оператор сравнения <=

Второе предложение — взять фреймворк, нормально поддерживающий мультиязычность, и написать самому. Могу порекомендовать symfony 1.4 (> PHP 5.2.4, давно стабилен, много доков и гайдов, в т. ч. русскоязычные доки) и symfony2 (> PHP 5.3.2, в активной разработке, интенсивное использование фич 5.3, стабильное API только начало формироваться, доков мало, по-русски только несколько обзоров видел, большей частью на хабре) — скучно точно не будет :)

MaxSite max-3000.com/ посмотрите

Помню на phpforum.ru/ были бесплатные онлайн курсы PHP, хотя лично мне многие моменты казались спорными…

А вообще постановка вопроса «препод по php» мне кажется неверной — для изучения большинства (на всякий случай не «всех») императивных ЯП нужно несколько дней максимум, годы может занимать приобретение опыта, изучение «best practices», получение навыков проектирования архитектуры и реализации приложения с учётом архитектуры, особенностей и стандартных/популярных библиотек/фреймворков, «подводных камней» и т. п…

Приводить в одну «нормальную» форму: отбросить мусор (знаки препинания, например), преобразовать в один регистр, развернуть сокращения (или наоборот, свернуть в них)отсортировать слова по алфавиту

Хороший шаблонизатор, идеально интегрирующийся с PHP называется… PHP :) В шаблонах удобно использование альтернативного синтаксиса.

Можно. Назначить расширению jpg обработчиком php например (тогда в jpg надо хранить текст скрипта :) ).

Или, как выше сказано, rewrite/redirect: из запроса GET /upload/articles/58fa0825907dc76e67e8cb1150a7ac36.jpg?w=100&h=100&strict делать запрос GET /superscript.php?path=/upload/articles/58fa0825907dc76e67e8cb1150a7ac36.jpg&w=100&h=100&strict

Хотя, если стоит задача масштабирования, я бы пошёл другим путём:
— при запросе nginx проверяет есть ли файл /upload/articles/58fa0825907dc76e67e8cb1150a7ac36_100х100_strict.jpg
— если нет, то вызывает php для генерации
— отдаёт файл (он уже есть обязательно, если не было фатальных ошибок)

Плюсы: php вызывается только один раз, при первом обращении
Минусы: требуется больше места на диске; при изменении оригинального файла нужно удалять сгенерированные

По моему опыту, при тонкой настройке библиотек, реализующих ORM (прежде всего настройка lazy load чуть ли не для кждого запроса) оверхид при выполнении от них небольшой (по сравнению с собственно выполнением запроса) и полностью компенсируется упрощением разработки и поддержки, если не требуется использовать «экзотику» типа хранимых процедур или триггеров.

Имхо, хранить 200 000 файлов в папке не самая лучшая идея. я бы сделал структуру папок вроде 12/34/56/78/90/*.jpg, где 1234567890 — obj_id. Хотя, конечно, сильно зависит от ФС и свободной памяти на сервере

То есть дублировать данные в БД, реализовав собственный механзим сохранения сессионных данных? Имхо, не стоит, если нет каких-то очень специфических требований — или дёргайте БД при каждом запросе или дёргайте её только при аутентификации и пользуйтесь стандартными средствами сессий для сохранения полученных из БД данных для дальнейшего использования

Обработчик поиска формирует результативный набор записей, сохраняет их (целиком или только id) в сессии с ключом (там же сохранить и параметры запроса можно, например md5 от строки поиска и редиректит на что-то вроде /search?key=hash — по хистори можно ходить какое-то время да и на бд нагрузка меньше