Fuf.com.ua

Генератор sitemap для mp3fiesta

Posted by rebbort under Google, SEO инcтрументы, Партнерки, Программирование

Сабж

Скрипт умеет создавать sitemap для каталога ver. 3.1. от партнерской программы mp3fiesta, бить его на куски заданного размера, создавать индекс sitemap’ов.

Как использовать

1. Скачиваем файл в корень каталога
2. Открываем в редакторе, чтобы поправить настройки:
   • _file_size_ — максимальный размер файла для sitemap. Google парсит только первые 50к ссылок в карте и файлы не более 4Mb. Лучше задавать размер 1Mb. По умолчанию 4Mb.
     
   • _with_songs_ — 1 - делать карту песен, 0 не делать.  Если делать карту песен, то общий размер файлов превысит 100Mb. По умолчанию 0.
3. Через браузер открываем скрипт. В случае успеха скрипт выдаст сообщение “Sitemap.xml successfully created!“, в корне сайта появится набор файлов sitemap.xml и индекс карт. Если карты не создались проверьте права на запись в корень каталога.

Скачать

  Генератор sitemap для партнерского сайта от mp3fiesta (5.3 KiB, 122 hits)

Мультисайтовость на основе WordPress MU

Posted by rebbort under Программирование, Продвижение сайтов

Недавно у меня возникла проблема: необходимо было сделать сразу много сайтов с уникальными доменами на основе wordpress, но в плане хостинга был установлен лимит на 7 доменов в одном аккаунте. Но, так как на каждый домен можно вешать разные алиасы (например, mysite.com, mybestsite.com и simplesite.com могут ссылаться на один и тот же сайт), тут же родилась идея. Почему бы не потанцевать с бубном вокруг файлика .htaccess и не наколдовать схемку, по которой бы отслеживался домен и запрос перенаправлялся на нужную папку со скриптами.

Как и ожидалось, танец с бубном ничего не дал, после чего естественно последовали поиски реализации этой идеи в Google. Искать пришлось не долго, умные дядьки уже все давно придумали. Мультисайтовость можно сделать на основе движка WordPress MU. Это видоизмененный многопользовательский движок стандартного WP. Самый известный сайт, где установлен данный движок, Wordpress.com.

Скачать дистрибутив можно отсюда. Но сам движок позволяет создавать разные блоги только на основе субдоменов (http://blog1.mysite.com, http://blog2.mysite.com) или папок (http://mysite.com/blog1/, http://mysite.com/blog2/). Это не совсем то, что мне нужно было, но весьма близко. Поиски продолжились. Решение последней проблемы называется Multi-Site-Manager, скачать можно отсюда. Это плгаин для WP MU, позволяющий создавать самодостаточные сайты на одном движке WP MU.

Установка WP MU также проста, как и установка обычного WP. Но работа с самим движком немного отличается от стандартного. В папке wp-content появилась дополнительная папочка mu-plugins, куда и нужно будет положить Multi-Site-Manager (файл njsl-sites-004.php). Плагины в этой папке активировать не нужно, они подключаются автоматически. После добавления плагина в пунке меню Site Admin появится новый раздел Sites, откуда можно будет добавлять новые сайты.

Для примера приведу несколько сайтов, которые были реализованы с помощью описанного движка и плагина Multi-Site-Manager:

• 50cent.dp.ua
• pussycat-dolls.dp.ua
• eminem.dp.ua
• linkin-park.dp.ua
• lil-wayne.dp.ua
• avril-lavigne.dp.ua

Автоматическая регистрация на чужом сайте при помощи PHP.

Posted by rebbort under Программирование

Как-то раз один мой знакомый попросил написать для него спамилку форумов и досок объявлений. Составили ТЗ, оговорили цену, сошлись на том, что спамилка должна уметь самостоятельно регистрироваться на форумах, при необходимости парсить CAPTCHA, заходить на почтовый ящик и переходить по ссылке активации аккаунта. После формирования аккаунта программа должна была уметь рассылать сообщения в разные ветки форума.

Я и сам давно уже хотел было писать подобную программу, но не было стимула и вот он появился, да еще и в денежном эквиваленте. Но как только я начал писать программу возникло куча проблем: не понятно было, как отсылать на PHP данные POST методом, как парсить CAPTCHA и вытаскивать оттуда разные буковки и циферки, как заходить на почтовый ящик и т. д.

Первая проблема решилась использованием сокетов. Вторая решалась долго – распарсить картинку на PHP дело не из легких. Немножко понапрягав серое вещество, было решено использовать нейронные сети. Но PHP очень медленный язык, чтоб писать подобные программы, поэтому из нейронных сетей была выдрана основная идея, а весь метод заключался в следующем:
- скачиваем картинку,
- устанавливаем для картинки порог, например, черные буквы на сером фоне, дальше все, что темнее порога – это буквы, все остальное – мусор,
- обрезаем все лишнее пространство, оставляем только буквы,
- заносим картинку в двумерный массив: если пиксель белый – 0, если не белый – 1,
- выделяем буквы, находим в массиве по Y ряд, где все элементы равны 0, все, что левее какая-то буква,
- создаем массив-эталон, заносим в него все цифры и буквы алфавита в двоичном представлении; шрифт букв должен совпадать с тем, что и на CAPTCHA, например:

,
на картинке зашифровано слово ПРИВЕТ.
- распознаем буквы.

PHP как шаблонизатор

Posted by rebbort under Программирование

Кто-нибудь задумывался, зачем разделять HTML-код от PHP? Задумывались, наверно, все, кто хоть раз сталкивался с шаблонизаторами или с теми, кто их пропагандирует. Я считаю, что разделять нужно и делать это по очень простой причине: поддерживать проект становится значительно легче:

• в PHP-файлах содержится чистый удобоваримый и легкочитаемый код;
• один и тот же скрипт может выдавать данные для разных языковых версий и подгружать для этой версии шаблон на нужном языке, таким образом упрощается поддержка мультиязычности.

Можно, конечно, привести еще много разных «за» и «против», но на мой вгляд, эти две причин являются основными, особенно для меня.

Другой вопрос: как делать это самое разделение? Обычно при обсуждении данной темы от «нужны или не нужны» шаблонизаторы, народ быстро переключается на как «быстро или медленно» они должны работать, потому как уже есть целая куча разных шаблонизаторов и можно выбирать. Я в свое время начинал работать с шаблонами при помощи шаблонизатора из библиотеки PHPLIB. Работать с ним было просто как два пальца об ас…, но жизнь портило отсутствие условий на проверку существования переменных.

Позже, уже на работе, хотелось перейти на Smarty, но его громоздкость и правила студии (не использовать чужие решения) не позволили это сделать. Пришлось писать свой шаблонизатор. Чтобы долго не долбаться, я начал использовать XSLT шаблоны, так как по возможностям XSLT-шаблонизатор по-моему ничем не уступает Smarty. Но поддержка больших проектов показала, что я круто лоханулся, используя такие шаблоны. Верстальщица просто «зашивалась», когда начинала редактировать шаблон, так как один проставленный не там лишний слеш или запятая ломали страницу сайта наповал. И кроме этого шаблоны на XSLT начинали разрастаться до неприличных размеров из-за конструкций типа:

	…
	<tr>
		<xsl:if test="position() mod 2 = 0">
			<xsl:attribute name="bgcolor">
				<xsl:value-of
				disable-output-escaping="yes"
				select="color" />
			</xsl:attribute>
		</xsl:if>
		<td>
			…
		</td>
	</tr>
	…

хотя все это можно было бы представить компактней, например, так:

	…
	<tr [*IF($k%2==0):*]bgcolor="[*=$color*]"[*ENDIF*]>
		<td>
			…
		</td>
	</tr>
	…

И последнее, что добило в XSLT, это то, что при генерации больших объемов информации время генерации страниц увеличивалось экспоненциально. В общем, промучившись так несколько месяцев и издав на гора 5 сайтов, было решено написать новый шаблонизатор.

Основные требования к шаблонизатору были выдвинуты следующие:

• скрипт должен был быть маленьким (всего один файл),
• синтаксис языка в шаблонизаторе максимально похожий на уже используемый, например, на тот же PHP,
• шаблонизатор должен был отрабатывать максимально быстро,
• шаблонизатор должен был минимально использовать или вообще не использовать регулярные выражения при генерации страницы.