Дорген PandoraBox - вопросы и ответы + апдейты

TopperHarley, пожалуйста, верни "старый" алгоритм расчета плотности ключей.

Топпер, поддерживаю предыдущую прозбьу, верни пожалуста.

Может лучше не старый возвращать, а новый до ума довести

---------- Добавлено 28.01.2016 в 19:33 ----------

ro--ot, Force68, напишите ваши претензии к новому алгоритму.

Если текст собран из маленьких блоков и длинные кеи, то плотность не предсказуема.

да, там проблема если кеи допустим из 4-5-6 слов,

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

можно расшифровать сий опус

и что значат циферки после add

что бы юзать для инг. доров что нужно сделать

я так понял заменить содержимое internal.anchors.txt содержимым

internal.anchors.eng.sample.txt

Этого быть не может, так как пхп код:

function is_bot()

{

	global $visitor_type;

	return $visitor_type == 1;

}



function is_human()

{

	global $visitor_type;

	return $visitor_type == 2;

}

Переменная $visitor_type не может бывна одновременно и 1 и 2. Поэтому никак не может показываться оба блока. Может проблема в том что у вас контент внутри блоков одинаковый?

---------- Добавлено 28.01.2016 в 23:16 ----------

Нужно слегка его допилить.

Поменять в нем строчку:

+ Uri.EscapeUriString(key)

на

+ Uri.EscapeUriString(key.Split('|')[0])

Если у вас разделитель такой ^, то поменяйте | на ^

Фактически строчку макроса

key.Split('|')[0]

читать как:

строчка.Разбить(символ)[нулевой кусочек]

---------- Добавлено 28.01.2016 в 23:22 ----------

В принципе просьбы двух старожил достаточно чтобы вернуть старый алгоритм который я грозился удалить 2 года назад. Но давайте еще раз взглянем на него. Почему возникла необходимость в новом. 2 года назад я нашел банально глупую опечатку: При расчете плотности проверлось не отношение числа слов в тексте к числу слов в ключе, а проверялось отношение числа БУКВ в текст к числу слов в ключе. То есть бред полный. Но почему-то на эту ошибку в старом алгоритме никто не обращал внимание.

Так что я не против вернуть этот глючный странный способ считать плотность, но все же хотелось бы допилить новый.

Может считать плотность нужно по числу символов? Сайчас расчет по числу слов, но слова бывают разной длины..

---------- Добавлено 28.01.2016 в 23:29 ----------

Все верно, нужно заменить текст файла из internal.anchors.eng.sample.txt

А теперь насчет расшифровки.

Данный файл используется для настройки перелинковки.

В файле есть список фраз для безанкорной перелинковки, то есть ссылок вида [a hre="xxx"]смотри тут и подобные фразы[/]

И еще добавленные к этому списку макросы, разбавляющие безанкорные ссылки другими типами ссылок.

Строка ADD:10:ANCHOR добавляет к нашему списку безанкорных ссылок еще 10 вариантов обычных анкорных ссылок

Строка ADD:10:THINANCHOR добавляет к полученному списку еще 10 прореженных анкоров целевой страницы

Строка ADD:10:EXTENDANCHOR добавляет к полученному списку еще 10 раcширенных анкоров целевой страницы, это такие где к анкору прибавляется спереди и сзади рандомное слово

Строка ADD:2:MIXANCHOR добавляет к полученному списку еще 2 анкора целевой страницы с перемешанными словами анкора

Строка ADD:10:URL добавляет к полученному списку еще 10 анкоров состоящих просто из урла страницы

Таким образом получается примерно 100 вариантов ссылок. Каждый тип может в этом списке преобладать(Строка ADD:77:EXTENDANCHOR) либо наоборот - его может быть мало(Строка ADD:2:MIXANCHOR)

Надеюсь суть понятна :)

Спасибо заработало.

А как можно сделать что бы если видео пустое, то его не вставлять?

Или например не парсить видео по минус словам.

☝ вот теперь более чем понятно

ну вроде по числу символов конешно логичней, но боюсь в коротких блоках текстовки тоже будет плохо работать, вообще конешно надо смотреть :)