Adamos

> Я рассчитываю, что каждую секунду в окно браузера будут последовательно выводиться числа

Имхо, это дурь с самого начала. В смысле - ожидание от PHP интерактива. Хотите, чтобы на странице что-то менялось - AJAX к вашим услугам. А задача РНР - сформировать вывод как можно быстрее и закончить работу. Потому что дальше - неизвестные задержки по дороге к пользователю, неизвестно что у него в браузере и прочая неизвестность. В которую впутывать серверные скрипты совершенно незачем.

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

Вижу два положительных момента:
1. Верстка все-таки сделана, а это порядка 30% работы над сайтом.
2. Судя по всему, руководство настолько в теме, что тот пароль ему все равно не понадобится.

А вам никто еще руки не оторвал за такой код? Привыкли, что за вас компиляторы думают?
Например, проверять $a != $b внутри десяти вложенных циклов - это [к сожалению, цензурных слов не нашлось].
Кстати, РНР проверяет условия по порядку, и ставить первым самое тяжелое - это [ну, скажем, саботаж...].

За прошедшее с выхода книги время:
- Линукс для разработки стали заворачивать в Vagrant,
- Апач не только подпирают, но и полностью вытесняют Нджинксом,
- с Мускулем набили столько шишек, что напрямую работать не советуют,
- а РНР вообще сменил парадигму (для тех, кто это заметил)
Сомнительной нужности учебник, если вы не археолог ;)

Лучший способ ускорить WAMP - это вынести его за подоконник.
Гравитация придаст ему необходимое ускорение.

Какой Ёксель? Зачем создавать геморрой на ровном месте?
HTML + mPDF -> все довольны.
Можно заодно хранить этот HTML и позволять его поправить (скажем, через CKEditor) и вывести заново.

Чисто умозрительная аналитика тоже может натолкнуть на верное решение.
Как давно появились тормоза? Стоит посмотреть измененные за это время файлы (хотя бы просто определить их find-ом).
Какие таблицы в БД сильно разбухли? Какие скрипты их используют? Возможно, запросы, которые раньше успевали пройти и освободить место новым, теперь выполняются несколько медленнее и создают пробку (скажем, ajax-запрос автодополнения, который повторяется при нажатии каждой клавиши, в условиях медленного ответа может создавать ощущение, что сайт вообще висит).

1. Купивший движок имеет право поставить только одну копию сайта? А как же сервер для разработки и тестирования, например? А если он не имеет выхода в интернет?
2. Что вы будете делать, если ваши скрипты просигналят о нелицензионном использовании? Это, собственно, лучшее, на что вы можете рассчитывать - всякие там "запрещалки" все равно сломают, а вот "стучалку" могут и пропустить. Ну и?
3. Посмотрите вокруг. Где вы видите людей, торгующих движками? Торгуют возможностью обновления, плагинами и прочим сервисом. Знаете, почему?..

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

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

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

Когда настроите - возьмите файл index.php, переименуйте его в index.php.jpg и проверьте, чего стоят эти настройки.

Формируете заказ с уникальным номером.
Поля заказа: id фотки, цена, мыло пользователя.
Отправляете его на РК оплачивать.
Когда РК сообщит вам, что проплата произошла (это может быть позже того, как пользователь уже выполнил все свои действия и был возвращен на ваш сайт) - отправляете ему по мылу ссылку на загрузку готовой фотографии. Все.

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

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

Google Sitemap Generator - работает который год именно по этой схеме.
Только не забудьте при настройке исключить все непубличные разделы из списка и убедиться, что никакие важные данные не передаются GET-аргументами (и, соответственно, не появятся в sitemap).