Это вопрос для разработчиков прокси и плагинов.
Обычное мышление, когда дело касается конкретных сайтов, – «Они вносят изменения, которые нарушают наш плагин, мы меняем логику, чтобы заставить ее работать снова» .
Но что, если другая сторона тоже беспокоится об этом? Если мы хотим скомпилировать набор руководств и рекомендаций по разработке сайтов для сайта с прокси-сайтами, что вы предлагаете, то следует пойти на него? Подумайте о жестких гайках, которые вы должны были взломать. Вы помните те моменты, которые, по вашему мнению, разработчик сайта сделал по-разному? Как?
Поскольку это связано с кодированием, я не думаю, что он должен перейти на serverfault.
Редактировать: прочитав комментарий Пекки, я чувствую, что должен добавить дополнительную справочную информацию.
Существуют сценарии веб-прокси, такие как glype и PHProxy. Поскольку скрипт должен справляться со многими неизвестными условиями, он не может обслуживать многие сайты. Поскольку количество таких сайтов является ошеломляющим, не имеет смысла пытаться сделать внутреннюю логику прокси сложной, чтобы справиться с этим огромным разнообразием. Это то, где плагины пригождаются. Основной или базовый скрипт реализует механизм для вызова кода плагина на основе каждого сайта.
Итак, если прокси-сервер не обслуживается, скажем, facebook.com, что, кстати, кстати, кодер, заинтересованный в вызове, проводит некоторые исследования и отладки, чтобы найти, где и почему цепочка сломана, и что нужно сделать для решения проблема. Кодер реализует свое исправление как плагин для этого конкретного сайта, и пользователи могут удалить плагин в свою директорию плагинов.
Но также случается, что что-то на сайте меняется, и это изменение заставляет плагин снова ломаться. Таким образом, это постоянное совпадение, чтобы догнать самые последние изменения сайта. Ирония ситуации заключается в том, что многие разработчики сайтов не знают и не заботятся о том, какое влияние их дизайнерские решения могут оказать на прокси-сервисы контента. Но на некоторых сайтах есть все основания заботиться о способности посетителей получать доступ к своему контенту через прокси. Не хочу вступать в политику здесь, поэтому я оставляю это для вас, чтобы понять, почему это может быть важно для некоторых сайтов.
Этот вопрос является попыткой использовать коллективные знания и опыт авторов прокси и плагинов, чтобы составить набор рекомендаций для создания прокси-сайта.
Я не отмечал вопрос php изначально, поскольку он в основном касается вывода сайта, а не того, как вы его генерируете. Но решил отметить его так, потому что он улучшит видимость вопроса, и тег может быть оправдан и на целевой аудитории. Я также создаю эту вики сообщества, поэтому, если вы чувствуете, что php-тег должен быть удален, просто сделайте это.
Это интересный вопрос, и я не думаю, что есть хорошее общее решение. В основном вы хотите, чтобы контент вашего сайта был трансформируемым какой-либо третьей стороной, над которой у вас нет контроля и, возможно, нет знаний о преобразованиях.
Традиционным способом решения этой проблемы является наличие опубликованного API, который позволяет третьим сторонам запрашивать данные, которые они хотят контролируемым образом, которые не зависят от скрипирования экрана. API часто обнаруживает только подмножество функциональных возможностей, обычно потому, что сайт требует, чтобы пользователи просматривали страницы, чтобы генерировать доход от рекламы (или какой-либо другой доход).
Вы могли бы создавать очень простые страницы, в действительности используя HTML API, и использовать Javascript и CSS, чтобы сделать страницы более удобными для пользователя. Однако это может быть неприемлемо для большинства сайтов. Но подход «прогрессивного улучшения», который транслируется jQuery и другими, идет по тем же направлениям: обслуживать базовый, семантический контент и добавлять функциональность и pizzazz через JS и CSS.
Вы можете использовать микроформаты, чтобы сделать доступ к определенному содержимому страницы более доступным. Вы должны использовать семантический HTML и помещать много классов и идентификаторов в элементы страницы, чтобы авторы плагинов могли найти соответствующий контент, в котором они нуждаются.
Мне кажется, что независимо от того, что эти прокси потребуются, вам нужно научиться анализировать свои страницы хотя бы один раз. Вы можете документировать процесс (возможно, выпустить плагин или два).
Я не думаю, что вы сможете избежать принуждения авторов плагинов к повторному кодированию при выпуске новых версий вашего сайта. Вы можете установить политику периода бета-тестирования, где доступны как старые, так и новые версии сайта, и это даст авторам плагина возможность обновлять свои плагины без прерываний обслуживания для своих пользователей.
Я не уверен, что это вас беспокоит или нет, но в настоящее время я помню только две вещи, о которых следует заботиться при работе на дружественном прокси-сайтах. Один из них – заголовок, который может влиять на сайты, посещаемые за прокси-сервером, а другой – на обнаружение IP-адресов. Заголовок кэша управления (общедоступный / закрытый) и другой заголовок могут влиять на скорость и конфиденциальность пользователя. IP-обнаружение может иметь прокси-сервер, а не пользователя. Итак, эти вещи следует иметь в виду.