Маэстро

Рейтинг
223
Регистрация
08.09.2006

Да, согласно этим рекомендация я все и делал.

---------- Добавлено 21.08.2013 в 19:26 ----------

komdir:
если вы все знаете, зачем спрашиваете?

:)

Так я спрашиваю про то, чего не знаю

---------- Добавлено 21.08.2013 в 19:28 ----------

manarh:
Вы считаете это сроком? Подождите еще 1 месяц и посмотрите, что будет. Яндекс у нас медленный в отличии от Google..

А ну то есть, вы склоны считать, что даже если Яндекс уже домены склеил все равно может потребоваться какое то время на восстановление позиций?

komdir:
молча))))))))

Может тогда еще и погода влияет?)

komdir:
во первых вы не озвучили причину переезда)
во вторых, если нет криминала, то:
проверьте регион нового домена, работайте с ним, как с новым доменом и не забывайте про старый.
Другими словами, работает стандартный режим склейки.
При учете всех показателей, позиции изменятся, но на насколько значительно зависит от тематики)

А как причина переезда может влияеть на алогоритма ранжирования? Роботу не все ли равно переезд был просто из-за нового более красивого имени или по какой то другой причине?

Региональной привязка, что у старого, что у нового домена : "не имеет региональной принадлежности". То что работать надо это понятно. Вопрос в другом, после склейки двух сайтов, если позиции сразу не встали на старые позиции, то можно не ждать у моря погоды, они уже не встанут? Или после склейки доменов восстановление позиций может занимать какое то время

Огромне все спасибо, все тепреь понятно, все работает!

Милованов Ю.С:

echo urldecode($_GET['option']);

Option взят из примера в 1-ом посте.

UPDATE:
совсем забыл.
В $_GET и других сеперглобальных массивах уже декодированные данные храняться.
Код указанный выше - не стоит юзать:)
Так что просто применяйте $_GET['option']

urldecode($_GET['option']) вот так помогло, без urldecode получался код.

---------- Добавлено 13.03.2013 в 20:48 ----------

siv1987:
В вашем первом варианте они не в нормальном явление, они экранированные. Их конечно можно декодировать и получить нормальное значение, но фактически это будут два разных адреса.

Не нормальное: %25D1%2582%25D0%25B5%25D1%2581%25D1%2582
Нормальное: %D1%82%D0%B5%D1%81%D1%82
строка: тест

хмм, а как экранирование убрать?

По большому счету все проблемы решение:

1) флаг NE - оставляет русские буквы в адресе

2) urldecode($_GET['option']); преобразует экранированные как я понял коды , в руские буквы.

Просто уже хочется до конца понять, а как экранированный код преобразовать к неэкранированный, то есть чтобы вместо %25D1%2582%25D0%25B5%25D1%2581%25D1%2582 был %D1%82%D0%B5%D1%81%D1%82

Кажется разобрался, огромное спасибо. Но в ходе решения данной проблемы, я задался вопросом. По идеи , как я понял эти шестнадцатиричные симолы нормальноя явление, теже поисковики понимают эти коды и сопостовляют им русские запросы... Отсюда вопрос, посредстмов php как можно преобразовать шестнадцетирчный код в сивольный?

siv1987:
Попробуйте добавить флаг NE. Кодировка и переводы строк в данном случае не важны.

А куда этот флаг добавить? у меня сразу 500 ошибка вылетает.

Проверил, кодирока UTF-8 без BOM стоит, но это не решает проблему с редиректом русских букв.

---------- Добавлено 13.03.2013 в 18:13 ----------

Код такой..

RewriteCond %{HTTP_HOST} ^sub\.domain\.com$

RewriteCond %{REQUEST_URI} !^/dir/

RewriteRule ^(.*) /dir/$1 [L]

RewriteCond %{HTTP_HOST} ^www\.domain\.com$

RewriteRule ^dir/(.*) http://sub.domain.ru/$1 [R=301,L]

То есть я не прописываю кокрентно русские страницы.. захватываются все адреса, среди которых есть адреса с русскими буквами.

iren K:
вам нужно чтобы файл .htaccess был в кодировке UTF-8 без BOM

Что то непонятное происходит. Открываю htaccess меню кодировку на utf-8 сохраняю, заново открываю его и смотрю кодировка все равно старая стоит.. Прием если файл переименовать в какой то другой, то кодировка сохраняется, а вот в .htaccess нет.. Как такое может быть?

mrxmry:
А CMS случайно не DLE 9.8 ? Просто я читал в нововведениях у 9.8 версии, что там какие то функции по поводу авторизации на поддоменах новые будут, как раз что-то из вашей оперы.

Joomla 1.5

---------- Добавлено 13.02.2013 в 02:21 ----------

Обнаружил еще один ньанс. Авторизация происходит через обращение к основному домену. Если же сделать чтобы авторизация происходила через поддомен, то тогда ситуация будет противоположная - чтобы оказаться авторизованным на основноме домене, надо вначале открыть поддомен.

То есть можно прийти к выводу, что через какой домен происходит авторизация, к тому домену и нужно обратиться, чтобы восстановить сессию на остальных доменах (поддоменах). Похоже на то, какому соседу ключ оставил, к тому нужно зайти чтобы его забрать)

Всего: 1098