Бетке Сергей: iT блог

Попробуем решить проблему с заменой в url протокола http на https, зафиксированную здесь.

Итак рассмотрим пример. По подписке приходят письма с подобным url http://feedproxy.google.com/~r/novgaro/sergey-s-betke/~3/iQYanT7RCJM/ps-join?utm_source=feedburner&utm_medium=email , которая (при открытии) направляет нас на другой url https://sergey-s-betke.blogs.novgaro.ru/ps-join#utm_source=feedburner&utm_medium=email&utm_campaign=Feed%3A+novgaro%2Fsergey-s-betke+%28IT+%D0%B1%D0%BB%D0%BE%D0%B3+%D0%91%D0%B5%D1%82%D0%BA%D0%B5+%D0%A1%D0%B5%D1%80%D0%B3%D0%B5%D1%8F%29. У меня сейчас протокол https не поддерживается для моего блога. И у Вас он также может не поддерживаться на публичном хостинге. Что делать?

FeedBurner отдаёт нам свою ссылку для того, чтобы иметь возможность анализа чтения подписки. Далее, после регистрации клика, он отправляет уже ссылку непосредственно в блог, передавая параметры utm_source, utm_medium, utm_campaign блогу для сбора статистики (речь – о google analytics), если мы таковую ведём. Но почему https?

На самом деле, после первого перенаправления мы получаем следующий url: http://sergey-s-betke.blogs.novgaro.ru/ps-join?utm_source=feedburner&utm_medium=email&utm_campaign=Feed%3A+novgaro%2Fsergey-s-betke+%28IT+%D0%B1%D0%BB%D0%BE%D0%B3+%D0%91%D0%B5%D1%82%D0%BA%D0%B5+%D0%A1%D0%B5%D1%80%D0%B3%D0%B5%D1%8F%29, а уж запрос GET на который и пытается нас перекинуть на https протокол. Итак – feedburner не при чём – он отдаёт http ссылку.

Тогда “грешить” остаётся только на wordpress или плагин к нему. В первое не верю, поэтому приступаю к анализу кода плагинов. Также должен обратить внимание, что параметры в url (после ?) заменены на #. Причём уже даже при следующем url получаем это “странное” преобразование http://sergey-s-betke.blogs.novgaro.ru/ps-join?utm_source=feedburner. Причём по результатам экспериментов могу заявить ответственно – важно наличие параметра utm_source. Именно его наличие в url приводит к указанному эффекту. Если быть ещё более точным – любой параметр с префиксом utm_ приводит к такому эффекту.

Итак, по результатам разборок спешу доложить, что виной подобному поведению стал плагин Google Analytics for WordPress. Именно он определяет и использует параметры с префиксом utm_. Ну и, судя по всему, нашёл ошибку в коде плагина, из-за которой он и меняет протокол. Для начала обратим наше внимание на описание $_SERVER[‘HTTPS’]. А теперь – сам код:

/**
 * If setAllowAnchor is set to true, GA ignores all links tagged "normally", so we redirect all "normally" tagged URL's
 * to one tagged with a hash. 
 */
function ga_utm_hashtag_redirect() {
	if (isset($_SERVER['REQUEST_URI'])) {
		if (strpos($_SERVER['REQUEST_URI'], "utm_") !== false) {			
			$url = 'http://';
			if ( isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] != "") {
				$url = 'https://';
			}
			$url .= $_SERVER['SERVER_NAME'];
			if ( strpos($_SERVER['REQUEST_URI'], "?utm_") !== false ) {
				$url .= str_replace("?utm_","#utm_",$_SERVER['REQUEST_URI']);
			} else if ( strpos($_SERVER['REQUEST_URI'], "&utm_") !== false ) {
				$url .= substr_replace($_SERVER['REQUEST_URI'], "#utm_", strpos($_SERVER['REQUEST_URI'], "&utm_"), 5); 
			}
			wp_redirect($url, 301);
			exit;
		}
	}
}

Обратили внимание на проверку использования протокола https? А вот, что написано:

Note that when using ISAPI with IIS, the value will be off if the request was not made through the HTTPS protocol.

Другими словами, приведённый выше код должен быть следующим для IIS:

			$url = 'http://';
			if(isset($_SERVER['HTTPS'])) { 
				if ($_SERVER["HTTPS"] == "on") { 
					$url = 'https://';
				} 
			} 

Честно говоря – жутковато. Привык, что подобные мелочи кроссплатформенности на себя должен брать интерпретатор, а не программист. Рецепт здесь.

После исправления проверяем – и изменения протокола на https более нет. Всё, наконец-то, работает, как полагается. Поражают меня такое качество портирования продуктов, после которого вместо кроссплатформенности программисты получают проблемы.

P.S. Пока разбирался, обнаружил ещё массу неприятных моментов. В частности, и тема, и целый ряд плагинов используют jQuery. Это замечательно, но при этом мы мало того, что получаем массу копий сценариев jQuery, так ещё и загружаем их в страницу неоднократно. Следует переработать загрузку jQuery, благо wordpress предоставляет для этого прекрасные возможности. Но об этом – отдельная статья.