НЕ
Просто учитываю то, что режет по знакам препинания..
..или сайт в большей мере для гугла,
для себя убедитесь что в Разделе-с-windows:>Windows>System32>drivers>etc>hosts
нет ничего подозрительного (лишний раз заглянуть не помешает)
далее посмотрите в консоле браузера какой href="" ссылки, на которую кликаете..
далее нажмите Ctrl+U и сравните href="" ссылки из консоли с href="" этой же ссылки в коде страницы..
1. в консоле не верная, в коде верная - срабатывает javascrypt код на подмену href=""
2. в консоле не верная, в коде не верная - ссылки изменяются на стороне сервера
3. в консоле и в коде верная (одинаковые) - причина скорее не в коде сайта..
хотя не исключается и более умный javascrypt код через onClick к примеру..
возможно что-то установили кривое - расширение для браузера, инсталлировали *.exe накануне.. нет?
т.е. выбрать из текста все даты
используйте для строк preg_match_all.. к примеру:
$string = file_get_contents('абсолютный-путь-к-файлу-с-текстом');
if (preg_match_all("~((Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)[^\s]*\s+[0-9]{1,2},\s+20[0-1][0-9])~is", $string, $match)) {
print_r($match);
}
результатом в $match будет подобный массив:
Array
(
[0] => Array
[0] => Jan. 05, 2001
[1] => February 7, 2011
[2] => March 15, 2007
...
[11] => December 5, 2012
[12] => Dec. 5, 2012
)
[1] => Array
[0] => Jan
[1] => Feb
[2] => Mar
[11] => Dec
[12] => Dec
Успеха! :)
Чтобы не попадать больше на http//левый.поддомен.мой-сайт.ru есть простое Решение для ISPManager 4.
В ISPManager 5 такой проблемы (собственно как и такой возможности) не заметил.
Ежели на ip не настроен редирект на дефолтную страницу,
то возможен и такой вариант - яндексу скормили (недруги), к примеру, 10к реальных урлов сайта
с добавленными к ним в начале разнообразных несуществующих поддоменов и как следствие
индексатор посетит их все, получит 200 ОК и соответствующие страницы с http//мой-сайт.ru
Что в конечном итоге яндекс может счесть за дубли - реальные урлы
или урлы с приклеенным левым поддоменами?.. решать видимо ему.
При условии, что все сайтов 8 на одном user хостинга, или VDS, или сервера..
потому как Выражение include включает и выполняет указанный файл..
Иначе как написал rerighter - file_get_content, fopen, curl.. 🍿
2) Было что-то подобное с сайтом год назад.
Хостер без уведомления обновил PHP 5.3 на PHP 5.4 что привело к некоторым Обратно несовместимым изменениям
При стандартно отключенном в php.ini выводе ошибок на экран - ошибки пишутся в лог. На экране всё как обычно.
Скрипт сайта надоооолго зависал потому, что одна из стандартных функций php стала возвращать array() вместо FALSE.
Добавьте в корень сайта .htaccess со строкой:
php_flag display_errors on
ежели .htaccess уже существует, просто добавьте строку в начало или конец файла.
Выведет ошибки скрипта на экран (если они есть) для начала...
далее исправляем шаг за шагом.
и да.. согласен с deltahost.com.ua неожиданно длительная загрузка страницы с php
обычно говорит, что скрипт страницы виснет на одном или нескольких этапах выполнения.
p.s. или как вариант попробуйте попросить хостера - временно откатить версию PHP на момент "до обновления".
на php можно и так..
возьмет указанный файл, каждую строку разобьет по разделителю "|" на подстроки
и добавит в файл с именем: file-(номер подстроки).txt
$patch = 'путь_к_файлу';
$new_dir = dirname($patch).'/new_file/';
if (!file_exists($new_dir)) mkdir($new_dir, 0777, true);
$content = file_get_contents($patch);
$content = explode("\n", str_replace("\r", "", $content));
foreach ($content as &$line) {
if ($cseparator = substr_count($line, '|')) {
$line = explode("|", $line);
for ($i=0; $i<$cseparator; $i++) {
file_put_contents($new_dir.'file-'.$i.'.txt', $line[$i], FILE_APPEND | LOCK_EX);
} else {
file_put_contents($new_dir.'file-0.txt', $line, FILE_APPEND | LOCK_EX);
(в постах видимо trim-аются пробелы и табы в начале и конце строк)
elseif, Вы правы 🙄
Нельзя видимо слишком продолжительно работать 😂
3 сайта к утру так и не ожили.. Но..
После пересоздания доменов на хостинге эта троица бодро заработала.
Видимо ситуация плавно нормализуется. Всем успехов :).
Jet D., Вы правы писать стоит..
почти сутки фиды крутились вперемешку с отказами сервера,
а теперь вот:
[ATTACH]136731[/ATTACH]
Это возвращает браузер на запрос с IP провайдера к главной доменов с ns*.r01.ru,
а любая запрашиваемая страница этих доменов возвращает 404 ошибку.
Запросы к тем-же страницам с той-же машины через различные прокси, или Тор, или анонимайзеры возвращают реальные страницы.
Expire стал 604800 (неделя)
Домены, в настройках которых с утра прописал NS хостеров, сейчас вроде стабилизируются - возвращают реальные страницы с IP провайдера.
И к стати вот сайт (не мой), о котором упоминается в статье roem.ru/2014/08/05/r01down104635/,
совсем не восстановился та-же заглушка на главной и ответы сервера (IP моего провайдера).
Как то вдруг происходящее стало не сладко..
Какая-то чушь на главной и 404 ответ nginx-а на всех страницах, хотя nginx у меня на сервере не установлен 🙄.
R01 пишет об аппаратном сбое, результатом которого видимо стал массовый рерайт записей в файлах тысяч доменов...
Странно, как тогда на наших доменах крутились фиды с платными ссылками и рекламой,
а теперь заглушка о которой в гугле всего 9 упоминаний и ничего конкретного и 404.
Jet D., Можете ещё порекомендовать шаги - как это одолеть?
Как вариант - просто подождать 604800 (неделю)... Да только вот беда, значение параметра Expire,
R01 восстановить пока позабыл.. А у меня, к примеру, в панели нет такой возможности, либо просто её не нашёл.
P.S. 2 часа назад 3 домена из нескольких, с изменёнными утром ns хостинга, перестали отвечать на любые запросы и умерли.
Видимо кэш совсем здесь не причём.. Домены хаотично включаются/отключаются.
Очень Надеюсь к утру воскреснут.
На моих, время-от-времени, недостуаных сайтах с ns*.r01.ru
плюс в гугле нашел несколько с такими-же ns,
при рефреше страницы 2 результата:
1) Веб-страница недоступна;
2) в браузер отдается фид объявлений www gstatic.com, либо блоки рекламы Ads.
Чего трафику пропадать-то. Видимо случайно и временно.
