На Блогуне недавно сделали нововведения
По одному из этих нововведений рекламодатель имеет право самостоятельно, кнопкой, отказаться от оплаты задания, которое было им послано на доработку и не было доработано блогером в течение двух дней.
К чему это привело в одном реальном случае. Сделал блогер задание и послал на проверку. Рекламодатель возвращает на доработку с требованием сделать исправления, не указанные в задании. Блогер ему отвечает, что мол нет у вас в задании этих требований. Рекламодатель пишет блогеру в ответ, что всё равно, без указанных исправлений не примет задание. Попререкались блогер с рекламодателем еще пару раз и отправил блогер жалобу в техподдержку. Как и в большинстве случаев, техподдержка встала на сторону рекламодателя, выразившись в том духе, что дескать неужели вам так трудно сделать ту мелочь, о которой просит рекламодатель. Блогер ответил техподдержке ссылкой на правила и еще кое-какими аргументам, надеясь дождаться ответа.
Пока он ждал ответа от техподдержки (и ждет его видимо до сих пор) прошло как раз два дня, отведенные на доработку задания и рекламодатель задание отменил как недоработанное в течение двух дней.
Похоже теперь у рекламодателей появляется неплохой прием для получения бесплатных ссылок, пусть даже и на короткий срок. Его суть в тому, что можно под надуманным предлогом посылать задания на доработку и если блогер замешкается, то отменить задание и получить бесплатную ссылку. А блогер может и не узнать, о том, что вы отменили задание, посланное на доработку - никакой информации об этом в контрольной панели не появляется.
четверг, 7 октября 2010 г.
суббота, 17 июля 2010 г.
Особенность Ротапоста
Помимо Блогуна есть еще несколько бирж по рекламе в блогах. Одна из них rotapost.ru . Ей еще далековато по оборотам до Блогуна, но мало-помалу она набирает темпы. Некоторое время, дня 3-4 назад, , владелец этой биржи, небезызвестный Димок ( blog.dimok.ru ) рассылал блогерам, зарегистрированным в этой бирже рекламное предложение с целью через этих блогеров приманить в Ротапост других блогеров. Предложение простое и довольно обычное - 99 рублей на покупку ссылок. У меня в Ротапосте тоже есть пара блогов и на один из них пришло рекламное предложение Димка.
Я сделал постовой и отправил на оплату. Через день выполненное мною задание было отклонено в соответствии с каким-то пунктом правил и оплаты я не получил. Я пишу данную заметку не из обиды (с Ротапоста прибыли у меня фактически и нет), а чтобы обратить внимание блогеров на особенность Ротапоста - рекламодатель может отказаться от уже выполненного задания. В Блогуне отказаться от выполненного задания может только блогер, а рекламодатель может только послать на переделку.
К чему может привести вышеуказанная особенность Ротапоста? К простой схеме злоупотребления, когда рекламодатель дожидается индексации своих ссылок, а потом отказывается от задания. Повод при желании можно найти. Ссылки получены, а деньги сэкономлены.
Я сделал постовой и отправил на оплату. Через день выполненное мною задание было отклонено в соответствии с каким-то пунктом правил и оплаты я не получил. Я пишу данную заметку не из обиды (с Ротапоста прибыли у меня фактически и нет), а чтобы обратить внимание блогеров на особенность Ротапоста - рекламодатель может отказаться от уже выполненного задания. В Блогуне отказаться от выполненного задания может только блогер, а рекламодатель может только послать на переделку.
К чему может привести вышеуказанная особенность Ротапоста? К простой схеме злоупотребления, когда рекламодатель дожидается индексации своих ссылок, а потом отказывается от задания. Повод при желании можно найти. Ссылки получены, а деньги сэкономлены.
вторник, 11 мая 2010 г.
Особенность переименования в Живом журнале
Как я уже писал ранее, при переименовании аккаунта в livejournal.com на имя, уже когда-то существовавшее в ЖЖ, старое имя в ссылках, имеющихся в профилях других журналов, получает приставку “ex-“ и несколько цифр после имени. Оказалось, что так бывает не всегда. Набрел на такую ссылку - ex-bishopdio424.livejournal.com . ТИЦ данного адреса равен 30. Судя по приставке “ex-“ кто-то уже воспользовался купоном переименования. Осталось удалить эту приставку, а также цифры после слова “bishopdio”, чтобы найти нынешний дневник и посмотреть какой же у него ТИЦ. Однако ни адрес bishopdio.livejournal.com , ни адрес bishopdio42.livejournal.com , ни bishopdio4.livejournal.com не существуют. Зато существует адрес bishopdion.livejournal.com . Зайдя в профиль этого журнала, увидим, что: 1) блог создан 16.11.2009, последний раз обновлялся 20.12.2009, то есть попользовались этим блогом всего месяц и забросили, 2) отправлено ноль комментариев 3) друзей и в друзьях – 14+6=20. В сообществах не состоит и не читает. То есть внешние ссылки только от друзей – 20 ссылок. При этом ТИЦ = 60. Ясно, что такой ТИЦ унаследован при переименовании, а не является следствием существуещей ссылочной массы. Поскольку сло́ва “ex-bishopdion” ни в Яндексе, ни в Гугле мне найти не удалось, то по-моему мнению все адреса вида ex-bishopdio424.livejournal.com (например тут - ) раньше указывали на сайт bishopdion.livejournal.com, на что, кстати, косвенно указывает и ник юзера – Dion (см. эту ссылку - )
Кэш страницы Яндекса по вышеуказанному адресу ( ) на дату написания данного поста подтвердил мою догадку – ник юзера значится как di и ссылка на блог значится как bishopdion.livejournal.com .
Ссылка на кэш -
Таким образом, при переименовании аккаунта старые ссылки не только получают префикс “ex-“ и несколько цифр после имени пользователя, но и в некоторых случаях теряют последнюю букву имени пользователя (было bishopdion, стало bishopdio). Возможно, данная особенность касается только латинской буквы “n”.
Кэш страницы Яндекса по вышеуказанному адресу ( ) на дату написания данного поста подтвердил мою догадку – ник юзера значится как di и ссылка на блог значится как bishopdion.livejournal.com .
Ссылка на кэш -
Таким образом, при переименовании аккаунта старые ссылки не только получают префикс “ex-“ и несколько цифр после имени пользователя, но и в некоторых случаях теряют последнюю букву имени пользователя (было bishopdion, стало bishopdio). Возможно, данная особенность касается только латинской буквы “n”.
суббота, 3 апреля 2010 г.
Живой журнал, ТИЦ и удалённые аккаунты часть 3
Срок полной, до нуля, потери ТИЦ-а переименованным аккаунтом точно неизвестен, но составляет не менее 2-ух месяцев, то есть за два месяца первоначальный ТИЦ не исчезнет. Причем о том потерян ТИЦ или нет, примерно можно судить по тому отличен ли от нуля ТИЦ старого названия аккаунта (того, что с приставкой ex-).
Например: есть переименованный аккаунт orcanoid.livejournal.com (старое имя теперь выглядит как ex-orcanoid937.livejournal.com ). ТИЦ orcanoid.livejournal.com равен 60, ТИЦ ex-orcanoid937.livejournal.com равен нулю. Журнал создан 30 января 2010 года. То есть за 2 месяца ТИЦ не потерялся. В вышеприведенном примере с журналом kridma.livejournal.com наблюдается потеря ТИЦ-а, однако за срок с 10 сентября 2009 года, т. е. за 7 месяцев. Причем журнал kridma.livejournal.com более показателен в качестве иллюстрации срока потери ТИЦ-а, так как этот журнал заброшен и не ведется – последнее обновление датировано 22.11.2009, ссылок на него мало (5 друзей и всего 1 комментарий), в то время как в журнале orcanoid.livejournal.com ведется более-менее активная работа – последнее обновление от 10.03.2010, ссылок 1107 (992 друзей и сообществ + 13 тех у кого он в друзьях + 102 отправленных комментария), и поэтому ТИЦ журнала orcanoid.livejournal.com может быть обусловлен не наследованным от переименования ТИЦ-ем, а вновь приобретенным за счет новых ссылок. Еще один пример – журнал zelezkin.livejournal.com (старое имя теперь выглядит как ex-zelezkin828.livejournal.com ). Блог создан 27 января 2010 года, т. е. ему 2 месяца. Ссылок 6 (пять друзей и один отправленный комментарий). ТИЦ равен 60. ТИЦ ex-zelezkin828.livejournal равен нулю. То есть за два месяца ТИЦ еще не потерян.
Искать окончательно удаленные журналы ТИЦ можно путем парсинга страницы http://www.livejournal.com/misc/expunged_list.bml с последующей проверкой на ТИЦ, либо путем парсинга профилей или комментариев популярных блогов и сообществ на предмет перечеркнутых ссылок. Во втором случае кроме окончательно удаленных аккаунтов будут попадаться и замороженные (suspended) аккаунты и неокончательно удаленные (те, с момента удаления которых не прошло 30 дней). Но такие аккаунты тоже пригодятся, так как со временем могут стать окончательно удаленными и их можно будет использовать для переименования.
Использовать ЖЖ-шки с ТИЦ-ем можно в качестве доноров ТИЦ-а для своих сайтов, либо для заработка на партнерках по продаже постовых, типа Блогуна. Можно также заняться перепродажей аккаунтов имеющих ТИЦ.
Выбирать удаленный аккаунт, имя которого вы хотите вновь зарегистрировать, необходимо исходя из следующих факторов: 1) величина ТИЦ-а; 2) количество ссылок непосредственно из текста постов и комментариев. Чем больше ТИЦ и больше количество таких ссылок, тем медленнее будет падать ТИЦ, если конечно вообще ничего не делать в плане размещения новых ссылок, а довольствоваться унаследованным ТИЦ-ем.
Например: есть переименованный аккаунт orcanoid.livejournal.com (старое имя теперь выглядит как ex-orcanoid937.livejournal.com ). ТИЦ orcanoid.livejournal.com равен 60, ТИЦ ex-orcanoid937.livejournal.com равен нулю. Журнал создан 30 января 2010 года. То есть за 2 месяца ТИЦ не потерялся. В вышеприведенном примере с журналом kridma.livejournal.com наблюдается потеря ТИЦ-а, однако за срок с 10 сентября 2009 года, т. е. за 7 месяцев. Причем журнал kridma.livejournal.com более показателен в качестве иллюстрации срока потери ТИЦ-а, так как этот журнал заброшен и не ведется – последнее обновление датировано 22.11.2009, ссылок на него мало (5 друзей и всего 1 комментарий), в то время как в журнале orcanoid.livejournal.com ведется более-менее активная работа – последнее обновление от 10.03.2010, ссылок 1107 (992 друзей и сообществ + 13 тех у кого он в друзьях + 102 отправленных комментария), и поэтому ТИЦ журнала orcanoid.livejournal.com может быть обусловлен не наследованным от переименования ТИЦ-ем, а вновь приобретенным за счет новых ссылок. Еще один пример – журнал zelezkin.livejournal.com (старое имя теперь выглядит как ex-zelezkin828.livejournal.com ). Блог создан 27 января 2010 года, т. е. ему 2 месяца. Ссылок 6 (пять друзей и один отправленный комментарий). ТИЦ равен 60. ТИЦ ex-zelezkin828.livejournal равен нулю. То есть за два месяца ТИЦ еще не потерян.
Искать окончательно удаленные журналы ТИЦ можно путем парсинга страницы http://www.livejournal.com/misc/expunged_list.bml с последующей проверкой на ТИЦ, либо путем парсинга профилей или комментариев популярных блогов и сообществ на предмет перечеркнутых ссылок. Во втором случае кроме окончательно удаленных аккаунтов будут попадаться и замороженные (suspended) аккаунты и неокончательно удаленные (те, с момента удаления которых не прошло 30 дней). Но такие аккаунты тоже пригодятся, так как со временем могут стать окончательно удаленными и их можно будет использовать для переименования.
Использовать ЖЖ-шки с ТИЦ-ем можно в качестве доноров ТИЦ-а для своих сайтов, либо для заработка на партнерках по продаже постовых, типа Блогуна. Можно также заняться перепродажей аккаунтов имеющих ТИЦ.
Выбирать удаленный аккаунт, имя которого вы хотите вновь зарегистрировать, необходимо исходя из следующих факторов: 1) величина ТИЦ-а; 2) количество ссылок непосредственно из текста постов и комментариев. Чем больше ТИЦ и больше количество таких ссылок, тем медленнее будет падать ТИЦ, если конечно вообще ничего не делать в плане размещения новых ссылок, а довольствоваться унаследованным ТИЦ-ем.
Живой журнал, ТИЦ и удалённые аккаунты часть 2
Ссылки с других ЖЖ можно разделить на три категории: 1) ссылки из профилей чужих журналов и сообществ, то есть из списков друзей и из списков читателей сообществ; 2) ссылка как автора комментария при комментировании чужих постов; 3) ссылка непосредственно из текста, то есть из текста поста или текста комментария.
Первую категорию ссылок можно проиллюстрировать страницей http://community.livejournal.com/interesniy_kiev/profile . На этой странице, в списке смотрителей и модераторов имеется окончательно удаленный аккаунт mushynska.livejournal.com . ТИЦ у него нулевой, так, что не покушайтесь на него, чтобы не испортить мне пример. Как видите, он перечеркнут и при заходе на такой аккаунт вы увидите либо надпись “This journal has been deleted and purged.”, либо при заходе на профиль этого аккаунта ( http://mushynska.livejournal.com/profile ) увидите надпись «Этот журнал был удалён вместе со всем его содержимым», а в заголовке страницы (тэг title) увидите надпись «Окончательно удалённый аккаунт».
Вторую категорию ссылок можно проиллюстрировать страницей
http://tema.livejournal.com/512485.html . На этой странице имеется комментарий пользователя anatole-cnorris, чье имя перечеркнуто и журнал соответственно удален или заморожен. В данном случае удален окончательно и его можно перерегистрировать, но поскольку ТИЦ данного ЖЖ равен нулю, то перерегистрация нецелесообразна.
Третью категорию ссылок можно проиллюстрировать страницей
http://bella-bellavita.livejournal.com/42262.html?thread=81430 . На этой странице имеется комментарий пользователя tidelander_0000. В тексте комментария имеется ссылка на страницу http://buntovshik.livejournal.com/11139.html . Данная ссылка не перечеркнута, однако, перейдя по этой ссылке, увидим, что данный ЖЖ (buntovshik.livejournal.com ) удален. То есть, несмотря на удаление дневника, ссылки на него не перечеркиваются, если находятся в тексте поста или комментария.
При переименовании все имеющиеся в ЖЖ перечеркнутые названия (т. е. названия аккаунтов, принадлежащих к первой и второй категории) окончательно удаленного аккаунта, имя которого переносится на переименовываемый аккаунт, меняются на другое название, тоже перечеркнутое, состоящее из приставки “ex-“ и нескольких цифр непосредственно после имени пользователя (точное их количество может быть разное, но больше трех цифр не встречал). Например, аккаунт kridma.livejournal.com (ТИЦ 90) принадлежал раньше одному человеку (см. http://kridma.livejournal.com/584.html#comments ), а затем, после удаления был перерегистрирован. Старый, перечеркнутый аккаунт получил новый адрес - http://ex-kridma740.livejournal.com/ (ТИЦ 10). Кстати на данном примере видно, как переименованный аккаунт постепенно теряет ТИЦ в пользу старого удаленного аккаунта (в данном случае аккаунта ex-kridma740) за счет потери ссылок с профилей других пользователей и появления новых ссылок на старый удаленный аккаунт (т. е. на ex-kridma740). Еще один вероятный пример потери ТИЦ-а - shrek3.livejournal.com (ТИЦ 60), создан 4 января 2010 года и ex-shrek3722.livejournal.com (ТИЦ 10). В данном случае ТИЦ начинает теряться спустя 3 месяца.
Названия аккаунтов из третьей категории при переименовании не меняются, то есть эти ссылки вы приобретаете вместе с переименованием.
Первую категорию ссылок можно проиллюстрировать страницей http://community.livejournal.com/interesniy_kiev/profile . На этой странице, в списке смотрителей и модераторов имеется окончательно удаленный аккаунт mushynska.livejournal.com . ТИЦ у него нулевой, так, что не покушайтесь на него, чтобы не испортить мне пример. Как видите, он перечеркнут и при заходе на такой аккаунт вы увидите либо надпись “This journal has been deleted and purged.”, либо при заходе на профиль этого аккаунта ( http://mushynska.livejournal.com/profile ) увидите надпись «Этот журнал был удалён вместе со всем его содержимым», а в заголовке страницы (тэг title) увидите надпись «Окончательно удалённый аккаунт».
Вторую категорию ссылок можно проиллюстрировать страницей
http://tema.livejournal.com/512485.html . На этой странице имеется комментарий пользователя anatole-cnorris, чье имя перечеркнуто и журнал соответственно удален или заморожен. В данном случае удален окончательно и его можно перерегистрировать, но поскольку ТИЦ данного ЖЖ равен нулю, то перерегистрация нецелесообразна.
Третью категорию ссылок можно проиллюстрировать страницей
http://bella-bellavita.livejournal.com/42262.html?thread=81430 . На этой странице имеется комментарий пользователя tidelander_0000. В тексте комментария имеется ссылка на страницу http://buntovshik.livejournal.com/11139.html . Данная ссылка не перечеркнута, однако, перейдя по этой ссылке, увидим, что данный ЖЖ (buntovshik.livejournal.com ) удален. То есть, несмотря на удаление дневника, ссылки на него не перечеркиваются, если находятся в тексте поста или комментария.
При переименовании все имеющиеся в ЖЖ перечеркнутые названия (т. е. названия аккаунтов, принадлежащих к первой и второй категории) окончательно удаленного аккаунта, имя которого переносится на переименовываемый аккаунт, меняются на другое название, тоже перечеркнутое, состоящее из приставки “ex-“ и нескольких цифр непосредственно после имени пользователя (точное их количество может быть разное, но больше трех цифр не встречал). Например, аккаунт kridma.livejournal.com (ТИЦ 90) принадлежал раньше одному человеку (см. http://kridma.livejournal.com/584.html#comments ), а затем, после удаления был перерегистрирован. Старый, перечеркнутый аккаунт получил новый адрес - http://ex-kridma740.livejournal.com/ (ТИЦ 10). Кстати на данном примере видно, как переименованный аккаунт постепенно теряет ТИЦ в пользу старого удаленного аккаунта (в данном случае аккаунта ex-kridma740) за счет потери ссылок с профилей других пользователей и появления новых ссылок на старый удаленный аккаунт (т. е. на ex-kridma740). Еще один вероятный пример потери ТИЦ-а - shrek3.livejournal.com (ТИЦ 60), создан 4 января 2010 года и ex-shrek3722.livejournal.com (ТИЦ 10). В данном случае ТИЦ начинает теряться спустя 3 месяца.
Названия аккаунтов из третьей категории при переименовании не меняются, то есть эти ссылки вы приобретаете вместе с переименованием.
Живой журнал, ТИЦ и удалённые аккаунты часть 1
Более-менее опытным сеошникам хорошо известно, что блоги на Живом журнале (livejournal.com или ЖЖ) хорошо набирают ТИЦ за счет перелинковки с другими блогами Живого журнала при комментировании, внесении в списки друзей (френдовании) и вступлении в сообщества. Это обусловлено тем, что ссылки этих блогов не заключаются ни в тэг noindex, ни снабжаются атрибутом rel=nofollow (или rel=external nofollow). Адреса сайтов, входящих на ЖЖ через OpenID, при комментировании не получают тэг noindex, но получают атрибут nofollow, а при френдовании и вступлении в сообщества адреса таких сайтов вообще в виде ссылки не фигурируют.
На ЖЖ имеется много удаленных так называемых "окончательно удаленных аккаунтов". Такие аккаунты можно зарегистрировать заново, заплатив 15 долларов. По-английски такие аккаунты называются - "deleted and purged". Какие аккаунты окончательно удалены и доступны для регистрации можно посмотреть по адресу
http://www.livejournal.com/misc/expunged_list.bml
В самом Живом журнале полностью удаленные аккаунты выделяются перечеркиванием названия аккаунта, например, такvasya чему в html коде соответствует тэг strike (в списках друзей и читателей сообществ) и кусок кода вида lj:user="имя юзера" style="white-space: nowrap; text-decoration: line-through;"><a href="http: при обозначении автора комментария в чужом посту.
Перечеркиванием отмечаются не только окончательно удаленные аккаунты, но и замороженные (suspended) и просто удаленные, но с момента удаления которых не прошло еще 30 дней. Чтобы выяснить, можно ли перерегистрировать перечеркнутый аккаунт проще всего на него зайти. Если появится надпись "This journal has been deleted and purged.", то такой аккаунт можно перерегистрировать. Во всех остальных случаях перерегистрировать аккаунт не получится.
В ЖЖ довольно много окончательно удаленных ЖЖ, имеющих ТИЦ. Из-за этого ТИЦ-а и имеет иногда смысл потратить 15 долларов на купон переименования.
Но тут надо понимать вот что. Рано или поздно ТИЦ переименованного аккаунта упадет до нуля. Почему это происходит? ТИЦ живых журналов, как и всякого сайта держится и наращивается за счет внешних ссылок, но в основном это ссылки с других страниц сервиса Живого журнала - с других ЖЖ, сообществ (community) и иногда, но редко, со страниц ЖЖ другого типа. Ссылки из-за пределов Живого журнала редки и большой роли в подъеме и удержании ТИЦ-а не играют. При переименовании аккаунта бо́льшая часть ссылок из самого ЖЖ на этот журнал теряется. Причина потери ссылок состоит в том, что одновременно с переименованием аккаунта автоматически переименовываются все перечеркнутые ссылки, ранее указывавшие на этот аккаунт, поэтому, переименовывая аккаунт, вы получаете ТИЦ без обратных ссылок. Потеря обратных ссылок и является причиной потери ТИЦ-а. Теряются, правда, не все ссылки, но подавляющая их часть.
На ЖЖ имеется много удаленных так называемых "окончательно удаленных аккаунтов". Такие аккаунты можно зарегистрировать заново, заплатив 15 долларов. По-английски такие аккаунты называются - "deleted and purged". Какие аккаунты окончательно удалены и доступны для регистрации можно посмотреть по адресу
http://www.livejournal.com/misc/expunged_list.bml
В самом Живом журнале полностью удаленные аккаунты выделяются перечеркиванием названия аккаунта, например, так
Перечеркиванием отмечаются не только окончательно удаленные аккаунты, но и замороженные (suspended) и просто удаленные, но с момента удаления которых не прошло еще 30 дней. Чтобы выяснить, можно ли перерегистрировать перечеркнутый аккаунт проще всего на него зайти. Если появится надпись "This journal has been deleted and purged.", то такой аккаунт можно перерегистрировать. Во всех остальных случаях перерегистрировать аккаунт не получится.
В ЖЖ довольно много окончательно удаленных ЖЖ, имеющих ТИЦ. Из-за этого ТИЦ-а и имеет иногда смысл потратить 15 долларов на купон переименования.
Но тут надо понимать вот что. Рано или поздно ТИЦ переименованного аккаунта упадет до нуля. Почему это происходит? ТИЦ живых журналов, как и всякого сайта держится и наращивается за счет внешних ссылок, но в основном это ссылки с других страниц сервиса Живого журнала - с других ЖЖ, сообществ (community) и иногда, но редко, со страниц ЖЖ другого типа. Ссылки из-за пределов Живого журнала редки и большой роли в подъеме и удержании ТИЦ-а не играют. При переименовании аккаунта бо́льшая часть ссылок из самого ЖЖ на этот журнал теряется. Причина потери ссылок состоит в том, что одновременно с переименованием аккаунта автоматически переименовываются все перечеркнутые ссылки, ранее указывавшие на этот аккаунт, поэтому, переименовывая аккаунт, вы получаете ТИЦ без обратных ссылок. Потеря обратных ссылок и является причиной потери ТИЦ-а. Теряются, правда, не все ссылки, но подавляющая их часть.
понедельник, 29 марта 2010 г.
Аномалия ТИЦ-а в живом журнале
Известно, что для поднятия ТИЦ-а довольно эффективно комментирование в живом журнал (livejournal.ru). Для поднятия ТИЦ-а с нуля до 10 и выше обычно достаточно примерно 300-от ссылок. Эти ссылки можно получить как путем комментирования чужих блогов, так и путем френдования. Комментирование относится как к блогам на самом ЖЖ и так и (в несколько меньшей степени) к сайтам, которые комментируют ЖЖ через OpenID. Для поднятия ТИЦ-а имеет также значение количество друзей (френдов) у ЖЖ-шного журнала, так как в списке друзей они отражаются практически по своему веб-адресу, с добавлением страницы profile. Френдование сайта, зашедшего через OpenID, почти бесполезно, так как в списке друзей будет отражаться не адрес вашего сайта, а адрес вашего профиля на ЖЖ. В адресе профиля адреса вашего сайта не будет.
Попалась мне ЖЖ-ешка ( mxc2.livejournal.com ) всего с 4-мя отправленными комментариями плюс 219 ЖЖ-ешек в списке друзей. Поскольку адрес этой ЖЖ-шки будет отражаться и на блогах из списка друзей, как взаимных, так и невзаимных, то общее количество ссылок составляет 219+4 = 223 ссылки. Кроме того, по поиску можно найти, что адрес этого блога отмечен еще в 66 случаях. Всего 223+66=289 ссылок и ТИЦ равен 90.
Теперь возьмем другой пример - demon-anarhist.livejournal.com . Отправленных комментариев – 301, в списках друзей 47 блогов, по поиску находятся еще 2 ссылки. Итого 301+47+2=350 ссылок. ТИЦ блога равен 10. Думаю этих примеров достаточно для того, чтобы понять, что нужно примерно 300 (плюс-минус 50 штук) ссылок для того, чтобы ТИЦ ЖЖ-шного блога стал отличен от нуля.
Но вот нашел аномалию. Блог-пародию на Льва Щаранского - lev-sharansky.livejournal.com . 313 комментариев отправлено. В списках друзей 297+88=355 блогов. По поиску находится еще 1000 упоминаний этого блога. Итого 1355 ссылок. А ТИЦ равен нулю! Интересно чем это можно объяснить? Я в некоторой растерянности.
Попалась мне ЖЖ-ешка ( mxc2.livejournal.com ) всего с 4-мя отправленными комментариями плюс 219 ЖЖ-ешек в списке друзей. Поскольку адрес этой ЖЖ-шки будет отражаться и на блогах из списка друзей, как взаимных, так и невзаимных, то общее количество ссылок составляет 219+4 = 223 ссылки. Кроме того, по поиску можно найти, что адрес этого блога отмечен еще в 66 случаях. Всего 223+66=289 ссылок и ТИЦ равен 90.
Теперь возьмем другой пример - demon-anarhist.livejournal.com . Отправленных комментариев – 301, в списках друзей 47 блогов, по поиску находятся еще 2 ссылки. Итого 301+47+2=350 ссылок. ТИЦ блога равен 10. Думаю этих примеров достаточно для того, чтобы понять, что нужно примерно 300 (плюс-минус 50 штук) ссылок для того, чтобы ТИЦ ЖЖ-шного блога стал отличен от нуля.
Но вот нашел аномалию. Блог-пародию на Льва Щаранского - lev-sharansky.livejournal.com . 313 комментариев отправлено. В списках друзей 297+88=355 блогов. По поиску находится еще 1000 упоминаний этого блога. Итого 1355 ссылок. А ТИЦ равен нулю! Интересно чем это можно объяснить? Я в некоторой растерянности.
суббота, 23 января 2010 г.
Еще один способ обойтись без cron’a
Зачастую при размещении сателлитов нет смысла использовать платный хостинг, так как в свете нынешних алгоритмов Яндекса сателлиты долго не живут. В Интернете много бесплатных хостингов с поддержкой php и многими другими полезными функциями. Но в большинстве случаев на них нет cron'a. Это обстоятельство мешает публиковать запланированные записи в CMS типа Wordpress. Чтобы обойти отсутствие cron'a используют либо сервисы веб-крона (например, WebCron.org), либо используют заходы посетителей на сайт для активации псевдокрона.
Есть еще один способ с использованием отсылки опубликованных записей на емэйл и публикации запланированных записей на бесплатных блогосервисах. Из блогосервисов выберем blogger.com (blogspot.com) как один из наиболее известных и вполне нам подходящий.
Итак, в чем суть.
Теперь записи на блогспоте будут публиковаться без вашего участия и дублироваться на любом другом вашем блоге. При желании можно сделать блог на блогспоте приватным и тем самым избежать дублирования контента.
Есть еще один способ с использованием отсылки опубликованных записей на емэйл и публикации запланированных записей на бесплатных блогосервисах. Из блогосервисов выберем blogger.com (blogspot.com) как один из наиболее известных и вполне нам подходящий.
Итак, в чем суть.
- На блогспоте создаем блог и наполняем его записями с будущими датами публикаций, напротив этих записей появится отметка «запланированный».
- На нашем блоге Wordpress на другом бесплатном хостинге настраиваем публикацию записей по электронной почте.
- Емэйл, полученный на шаге два для Wordpress'a вписываем на блогспоте в «Настройки» → «Электронная почта и мобильные устройства» → «Уведомления по электронной почте. Адрес BlogSend»
Теперь записи на блогспоте будут публиковаться без вашего участия и дублироваться на любом другом вашем блоге. При желании можно сделать блог на блогспоте приватным и тем самым избежать дублирования контента.
воскресенье, 3 января 2010 г.
Создание своей сборки Wordpress. Предустановочная настройка. Install.php
Теперь перейдем к работе с файлом wp-admin\install.php. В нем можно задать все те же настройки по умолчанию, что и в файле wp-admin\includes\schema.php не трогая при этом файл schema.php.
Этот способ более громоздкий, требует применения полного синтаксиса запросов к базе данных, знания PHP и не так нагляден, как при использовании файла schema.php. Во многих случаях код, необходимый для активации того или иного параметра через install.php, может оказаться настолько сложным, что рядовой пользователь не сможет его применить.
Например, эквивалент команды add_option('permalink_structure', '/%category%/%postname%.htm'); в schema.php, реализованный через install.php будет состоять из 9 строк с использованием семи переменных и нескольких вордпрессовских функций.
Использование файла wp-admin\install.php обычно обусловлено незнанием синтаксиса некоторых параметров в файле schema.php, так как документации по этому синтаксису практически нет. Я, например, не нашел в интернете как активировать плагины через файл schema.php, а в немногих найденных сборках предустановочная активация плагинов осуществлялась только через wp-admin\install.php. Так что, возможно, что я первый кто обнаружил, как активировать плагины через schema.php.
Рассмотрим предустановочную активацию параметров через install.php на примере активации плагинов.
Первый способ. Плагины активируются на локальном сервере (например, denwer'e). В таблице options на локальном сервере находим поле с option_name равном active_plugins и копируем оттуда значение сериализованного массива. Для активированных плагинов из примера, приведенного в посте о schema.php, такой сериализованный массив будет выглядеть так:
a:3:{i:0;s:14:"rus-to-lat.php";i:1;s:16:"russian-date.php";i:2;s:34:"wp-contact-form/wp-contactform.php";}
Экранируем в этом сериализованном массиве двойные кавычки косой чертой (вот так - \") и помещаем полученную строку в SQL запрос вида
$wpdb->query("UPDATE ".$table_prefix."options SET option_value = 'вот тут и помещаем сериализованный массив' WHERE option_name = 'active_plugins'");
получаем запрос вида
$wpdb->query("UPDATE ".$table_prefix."options SET option_value = ' a:3:{i:0;s:14:\"rus-to-lat.php\";i:1;s:16:\"russian-date.php\";i:2;s:34:\"wp-contact-form/wp-contactform.php\";}
' WHERE option_name = 'active_plugins'");
Этот запрос размещаем в файле wp-admin\install.php после следующих строк:
$wpdb->show_errors();
$result = wp_install($weblog_title, 'admin', $admin_email, $public);
extract($result, EXTR_SKIP);
Всё, теперь нужные плагины будут активированы непосредственно при установке.
Второй способ. Предварительная активация плагинов в базе данных не требуется и сериализованный массив нам тоже не нужен. Способ сложнее, так как требует знания внутренних функций Wordpress'а – одним запросом к базе данных не обойдешься. В файл wp-admin\install.php после строки
<p><?php printf(__('WordPress has been installed. Were you expecting more steps? Sorry to disappoint.'), ''); ?></p>
вставляется следующий код (плагины взяты из предыдущего примера):
<?php
$current = array("rus-to-lat.php", "russian-date.php", "wp-contact-form/wp-contactform.php");
foreach($current as $plugin) {
do_action('activate_' . $plugin);
}
update_option('active_plugins', $current);
?>
Массив $current в вышеприведенном коде можно инициализировать и в виде:
$current[] = "wp-contact-form/wp-contactform.php";
$current[] = "rus-to-lat.php";
$current[] = "russian-date.php";
на работоспособности кода это не отражается.
Как видим, активация параметров через файл wp-admin\install.php вместо wp-admin\includes\schema.php никаких преимуществ не дает, а только приводит к усложнению кода.
Этот способ более громоздкий, требует применения полного синтаксиса запросов к базе данных, знания PHP и не так нагляден, как при использовании файла schema.php. Во многих случаях код, необходимый для активации того или иного параметра через install.php, может оказаться настолько сложным, что рядовой пользователь не сможет его применить.
Например, эквивалент команды add_option('permalink_structure', '/%category%/%postname%.htm'); в schema.php, реализованный через install.php будет состоять из 9 строк с использованием семи переменных и нескольких вордпрессовских функций.
Использование файла wp-admin\install.php обычно обусловлено незнанием синтаксиса некоторых параметров в файле schema.php, так как документации по этому синтаксису практически нет. Я, например, не нашел в интернете как активировать плагины через файл schema.php, а в немногих найденных сборках предустановочная активация плагинов осуществлялась только через wp-admin\install.php. Так что, возможно, что я первый кто обнаружил, как активировать плагины через schema.php.
Рассмотрим предустановочную активацию параметров через install.php на примере активации плагинов.
Первый способ. Плагины активируются на локальном сервере (например, denwer'e). В таблице options на локальном сервере находим поле с option_name равном active_plugins и копируем оттуда значение сериализованного массива. Для активированных плагинов из примера, приведенного в посте о schema.php, такой сериализованный массив будет выглядеть так:
a:3:{i:0;s:14:"rus-to-lat.php";i:1;s:16:"russian-date.php";i:2;s:34:"wp-contact-form/wp-contactform.php";}
Экранируем в этом сериализованном массиве двойные кавычки косой чертой (вот так - \") и помещаем полученную строку в SQL запрос вида
$wpdb->query("UPDATE ".$table_prefix."options SET option_value = 'вот тут и помещаем сериализованный массив' WHERE option_name = 'active_plugins'");
получаем запрос вида
$wpdb->query("UPDATE ".$table_prefix."options SET option_value = ' a:3:{i:0;s:14:\"rus-to-lat.php\";i:1;s:16:\"russian-date.php\";i:2;s:34:\"wp-contact-form/wp-contactform.php\";}
' WHERE option_name = 'active_plugins'");
Этот запрос размещаем в файле wp-admin\install.php после следующих строк:
$wpdb->show_errors();
$result = wp_install($weblog_title, 'admin', $admin_email, $public);
extract($result, EXTR_SKIP);
Всё, теперь нужные плагины будут активированы непосредственно при установке.
Второй способ. Предварительная активация плагинов в базе данных не требуется и сериализованный массив нам тоже не нужен. Способ сложнее, так как требует знания внутренних функций Wordpress'а – одним запросом к базе данных не обойдешься. В файл wp-admin\install.php после строки
<p><?php printf(__('WordPress has been installed. Were you expecting more steps? Sorry to disappoint.'), ''); ?></p>
вставляется следующий код (плагины взяты из предыдущего примера):
<?php
$current = array("rus-to-lat.php", "russian-date.php", "wp-contact-form/wp-contactform.php");
foreach($current as $plugin) {
do_action('activate_' . $plugin);
}
update_option('active_plugins', $current);
?>
Массив $current в вышеприведенном коде можно инициализировать и в виде:
$current[] = "wp-contact-form/wp-contactform.php";
$current[] = "rus-to-lat.php";
$current[] = "russian-date.php";
на работоспособности кода это не отражается.
Как видим, активация параметров через файл wp-admin\install.php вместо wp-admin\includes\schema.php никаких преимуществ не дает, а только приводит к усложнению кода.
Создание своей сборки Wordpress. Предустановочная настройка. Schema.php
За активацию тех или иных настроек в файле schema.php отвечает функция populate_options(). Находите место инициализации этой функции (т. е. строку function populate_options() ) и в теле функции увидите перечень конкретный настроек. Для версий Wordpress'a 2.6.*, 2.7.* этот перечень будет выглядеть примерно так:
add_option('siteurl', $guessurl);
add_option('blogname', __('My Blog'));
add_option('blogdescription', __('Just another WordPress weblog'));
add_option('users_can_register', 0);
add_option('admin_email', 'you@example.com');
и так далее,
а для версий Wordpress'a, начиная с 2.8, будет выглядеть вот так:
$options = array(
'siteurl' => $guessurl,
'blogname' => __('My Blog'),
'blogdescription' => __('Just another WordPress weblog'),
'users_can_register' => 0,
'admin_email' => 'you@example.com',
и так далее. Если перевести название опций с английского языка, то всё становится более или менее понятным. Например 'blogdescription' переводится как «описание блога». Следовательно, если в schema.php в теле функции populate_options() вставить строку
add_option(' blogdescription ', 'My Splendid Blog'); или строку
' blogdescription ' => 'My Splendid Blog',
соответственно версии Wordpress'а
то у всех ваших блогов будет описание «My Splendid Blog».
Оговорюсь сразу, что в данном случае пример будет работать только для строк, состоящих из латинских букв, для кириллицы требуются дополнительные настройки.
Параметр вида add_option('blogname', 'Wonderful Blog'); вообще не будет работать, ни в варианте с латинскими буквами, ни в варианте с кириллицей, так как требует ввода названия блога с клавиатуры. Можно заставить работать и этот вариант, но он требует редактирования не только файла schema.php. Подробнее на этом останавливаться не будем.
Параметр, устанавливающий адрес постов в виде их названия, работает без нареканий и выглядит так:
add_option('permalink_structure', '/%postname%/');
или так:
'permalink_structure' => '/%postname%/', .
Все прочие параметры, требующие в качестве параметра одну-единственную константу, числовую или строковую, также нормально работают при задании этих параметров в файле schema.php
Иногда в параметре настройки надо задать несколько значений. Делается это по-разному для каждой конкретной настройки.
Так, например, запись о плагинах, подлежащих активации сразу после установки, является массивом, и поэтому будет выглядеть примерно так:
add_option('active_plugins', array("rus-to-lat.php", "russian-date.php", "wp-contact-form/wp-contactform.php"));
или так:
'active_plugins' => array("rus-to-lat.php", "russian-date.php", "wp-contact-form/wp-contactform.php"),
В массив можно вписать любое количество активируемых плагинов. Обратите внимание, что если плагин располагается в собственной папке, то кроме запускающего файла плагина надо прописать и папку, - "wp-contact-form/wp-contactform.php".
А вот для параметра ping_sites запись будет выглядеть точно так же как и в базе данных, т. е. отдельные пинг-сервисы будут отделяться друг от друга переводом строки (клавиша Enter). То есть будут выглядеть так:
add_option('ping_sites', 'http://rpc.pingomatic.com/
http://bg.ping.com/
http://c.gomatic.com/');
или так:
'ping_sites' => 'http://rpc.pingomatic.com/
http://bg.ping.com/
http://c.gomatic.com/',
Судя по рекомендациям в интернете, список пинг-сервисов можно также отделять пробелом или экранированным переводом строки (эскейп-последовательностью – \n). Эти варианты я не проверял, поскольку вариант с разделением Enter'ом вполне нормально работает.
add_option('siteurl', $guessurl);
add_option('blogname', __('My Blog'));
add_option('blogdescription', __('Just another WordPress weblog'));
add_option('users_can_register', 0);
add_option('admin_email', 'you@example.com');
и так далее,
а для версий Wordpress'a, начиная с 2.8, будет выглядеть вот так:
$options = array(
'siteurl' => $guessurl,
'blogname' => __('My Blog'),
'blogdescription' => __('Just another WordPress weblog'),
'users_can_register' => 0,
'admin_email' => 'you@example.com',
и так далее. Если перевести название опций с английского языка, то всё становится более или менее понятным. Например 'blogdescription' переводится как «описание блога». Следовательно, если в schema.php в теле функции populate_options() вставить строку
add_option(' blogdescription ', 'My Splendid Blog'); или строку
' blogdescription ' => 'My Splendid Blog',
соответственно версии Wordpress'а
то у всех ваших блогов будет описание «My Splendid Blog».
Оговорюсь сразу, что в данном случае пример будет работать только для строк, состоящих из латинских букв, для кириллицы требуются дополнительные настройки.
Параметр вида add_option('blogname', 'Wonderful Blog'); вообще не будет работать, ни в варианте с латинскими буквами, ни в варианте с кириллицей, так как требует ввода названия блога с клавиатуры. Можно заставить работать и этот вариант, но он требует редактирования не только файла schema.php. Подробнее на этом останавливаться не будем.
Параметр, устанавливающий адрес постов в виде их названия, работает без нареканий и выглядит так:
add_option('permalink_structure', '/%postname%/');
или так:
'permalink_structure' => '/%postname%/', .
Все прочие параметры, требующие в качестве параметра одну-единственную константу, числовую или строковую, также нормально работают при задании этих параметров в файле schema.php
Иногда в параметре настройки надо задать несколько значений. Делается это по-разному для каждой конкретной настройки.
Так, например, запись о плагинах, подлежащих активации сразу после установки, является массивом, и поэтому будет выглядеть примерно так:
add_option('active_plugins', array("rus-to-lat.php", "russian-date.php", "wp-contact-form/wp-contactform.php"));
или так:
'active_plugins' => array("rus-to-lat.php", "russian-date.php", "wp-contact-form/wp-contactform.php"),
В массив можно вписать любое количество активируемых плагинов. Обратите внимание, что если плагин располагается в собственной папке, то кроме запускающего файла плагина надо прописать и папку, - "wp-contact-form/wp-contactform.php".
А вот для параметра ping_sites запись будет выглядеть точно так же как и в базе данных, т. е. отдельные пинг-сервисы будут отделяться друг от друга переводом строки (клавиша Enter). То есть будут выглядеть так:
add_option('ping_sites', 'http://rpc.pingomatic.com/
http://bg.ping.com/
http://c.gomatic.com/');
или так:
'ping_sites' => 'http://rpc.pingomatic.com/
http://bg.ping.com/
http://c.gomatic.com/',
Судя по рекомендациям в интернете, список пинг-сервисов можно также отделять пробелом или экранированным переводом строки (эскейп-последовательностью – \n). Эти варианты я не проверял, поскольку вариант с разделением Enter'ом вполне нормально работает.
Создание своей сборки Wordpress. Предустановочная настройка.
Предустановочная настройка Wordpress'а – это изменение некоторых файлов сборки с тем, чтобы после установки Wordpress'а определенные функции были бы уже включены и не требовалось бы лезть в админку, чтобы их включать. Обычно предустановочная настройка сводится к активации ряда плагинов, но может включать в себя активацию и других функций.
Все настройки Wordpress'а хранятся в базе данных, в таблице options. Поэтому для того, чтобы активировать эти настройки непосредственно при установке, необходимо выполнение ряда запросов к базе данных, а сами эти запросы прописать в специальных файлах. Таких файлов в Wordpress'е два: 1. wp-admin\install.php и 2. wp-admin\includes\schema.php.
Собственно говоря, для записи предустановочных настроек предназначен только файл wp-admin\includes\schema.php, который содержит в себе весь перечень настроек Wordpress'a, которым присвоено некоторое значение по умолчанию или не присвоено никакого значение. Поэтому достаточно вписать нужное значение и соответствующая функция будет работать сразу же по завершению установки сайта. Файл wp-admin\install.php изначально не предназначен для записи предустановочных настроек и поэтому списка настроек, подобного тому, что имеется в файле wp-admin\includes\schema.php в нем нет. Что же касается использования файла wp-admin\install.php, то по своим результатам оно ничем не отличается от использования файла wp-admin\includes\schema.php, за исключением того, что приходится использовать полный синтаксис запросов к базе данных, что требует определенной квалификации.
Надо заметить, что значение конкретной настройки в большинстве случаев должны быть записаны именно так, как это значение выглядит в таблице базы данных, особенно при использовании файла install.php.
Поэтому прежде чем начинать вписывать в файл значения конкретных настроек своей сборки надо сборку установить на локальный сервер (например, denwer) активировать все необходимые настройки и плагины, а затем уже из конкретных таблицах базы данных копировать эти значения в запрос к базе данных, размещаемый в файле install.php.
При использовании файла schema.php запись значений конкретной настройки в том виде, как эта запись фигурирует в базе данных, не всегда нужна, а иногда просто не будет работать.
Бытует также способ предустановочной настройки с помощью создания пустой базы. Его суть в том, что Wordpress устанавливается на локальный сервер, через админку производятся все необходимые настройки, делается дамп этой базы. Потом этот дамп заливается в базу данных блога на конкретном домене и с помощью ряда запросов к новой базе дамп настраивается на данный домен и базу данных с сохранением всех настроек. При написании скрипта с набором необходимых запросов к базе является достаточно простым способом создания собственной сборки, хотя и требует определенных навыков программирования. Возможно также редактирование дампа текстовым редактором для настройки под конкретный домен до заливки в базу данных. В этом случае знание синтаксиса SQL запросов не нужно.
Все настройки Wordpress'а хранятся в базе данных, в таблице options. Поэтому для того, чтобы активировать эти настройки непосредственно при установке, необходимо выполнение ряда запросов к базе данных, а сами эти запросы прописать в специальных файлах. Таких файлов в Wordpress'е два: 1. wp-admin\install.php и 2. wp-admin\includes\schema.php.
Собственно говоря, для записи предустановочных настроек предназначен только файл wp-admin\includes\schema.php, который содержит в себе весь перечень настроек Wordpress'a, которым присвоено некоторое значение по умолчанию или не присвоено никакого значение. Поэтому достаточно вписать нужное значение и соответствующая функция будет работать сразу же по завершению установки сайта. Файл wp-admin\install.php изначально не предназначен для записи предустановочных настроек и поэтому списка настроек, подобного тому, что имеется в файле wp-admin\includes\schema.php в нем нет. Что же касается использования файла wp-admin\install.php, то по своим результатам оно ничем не отличается от использования файла wp-admin\includes\schema.php, за исключением того, что приходится использовать полный синтаксис запросов к базе данных, что требует определенной квалификации.
Надо заметить, что значение конкретной настройки в большинстве случаев должны быть записаны именно так, как это значение выглядит в таблице базы данных, особенно при использовании файла install.php.
Поэтому прежде чем начинать вписывать в файл значения конкретных настроек своей сборки надо сборку установить на локальный сервер (например, denwer) активировать все необходимые настройки и плагины, а затем уже из конкретных таблицах базы данных копировать эти значения в запрос к базе данных, размещаемый в файле install.php.
При использовании файла schema.php запись значений конкретной настройки в том виде, как эта запись фигурирует в базе данных, не всегда нужна, а иногда просто не будет работать.
Бытует также способ предустановочной настройки с помощью создания пустой базы. Его суть в том, что Wordpress устанавливается на локальный сервер, через админку производятся все необходимые настройки, делается дамп этой базы. Потом этот дамп заливается в базу данных блога на конкретном домене и с помощью ряда запросов к новой базе дамп настраивается на данный домен и базу данных с сохранением всех настроек. При написании скрипта с набором необходимых запросов к базе является достаточно простым способом создания собственной сборки, хотя и требует определенных навыков программирования. Возможно также редактирование дампа текстовым редактором для настройки под конкретный домен до заливки в базу данных. В этом случае знание синтаксиса SQL запросов не нужно.
Подписаться на:
Сообщения (Atom)