Архив метки: Web

Получаем сертификаты Let’s Encrypt для домена.

Сегодня в статье разберем установку SSL сертификата от Let’s Encrypt для домена, при помощи cerbot на UbuntuDebian системы.






Certbot – это клиент протокола ACME предназначенный для автоматического управления SSL-сертификатами от Let’s Encrypt, он позволяет полностью автоматизировать процесс получения и продления сертификата, а при использовании соответствующих плагинов даже может автоматически конфигурировать веб-сервер или иное, использующее сертификат приложение.




Дальнейшие инструкции будут предназначены для операционных систем Debian и Ubuntu, но многое будет справедливо и для иных дистрибутивов Linux.




Установка в Ubuntu/Debian




В новом выпуске Ubuntu/Debian все просто, отныне Certbot представлен в официальном списке пакетов и для его установки достаточно выполнить одну простую команду:




sudo apt install certbot




Подготовка к получению сертификатов




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




В случае с одним доменом это не вызывает проблем, но если их много или вам требуется сертификат сразу на несколько доменов (основной домен и поддомены), корневые директории у которых отличаются, то у вас возникнут затруднения. Поэтому сам Let’s Encrypt рекомендует перейти в таком случае на единую точку подтверждения сертификатов. Сделать это несложно.




В доступной для веб-сервера директории создадим отдельный каталог, назовем его, letsencrypt, который затем мы будем использовать для всех обслуживаемых доменов и установим ее владельцем веб-сервер:




mkdir /var/www/letsencrypt
chown www-data:www-data /var/www/letsencrypt




Теперь нам нужно сделать так, чтобы любой запрос вида:




http://example.com/.well-known/acme-challenge




приводил к физическому размещению:




/var/www/letsencrypt/.well-known/acme-challenge




Это несложно, но для каждого из веб-серверов делается по-разному, ниже мы рассмотрим самые популярные из них.




Apache 2.x




Для подготовки к работе с Certbot добавьте в основной конфигурационный файл /etc/apache2/apache2.conf следующую секцию:




Alias /.well-known/acme-challenge/ /var/www/letsencrypt/.well-known/acme-challenge/

<Directory "/var/www/letsencrypt/.well-known/acme-challenge/">
    Options None
    AllowOverride None
    ForceType text/plain
    Require all granted
    RedirectMatch 404 "^(?!/.well-known/acme-challenge/[w-]{43}$)"
</Directory>




Для устаревшей версии Apache 2.2 данный блок должен выглядеть следующим образом:




Alias /.well-known/acme-challenge/ /var/www/letsencrypt/.well-known/acme-challenge/

<Directory "/var/www/letsencrypt/.well-known/acme-challenge/">
    Options None
    AllowOverride None
    ForceType text/plain
    Order allow,deny
    Allow from all
    RedirectMatch 404 "^(?!/.well-known/acme-challenge/[w-]{43}$)"
</Directory>




Данная секция создает для любого запроса к /.well-known/acme-challenge алиас (псевдоним), указывающий на физическую директорию /var/www/letsencrypt/.well-known/acme-challenge, а ее расположение в основном конфигурационном файле позволит распространить действие директив для любого обслуживаемого домена. Остальные параметры задают необходимые параметры безопасности.




Nginx




Nginx предполагает несколько иной подход к настройке. Для каждого виртуального хоста в секцию server следует добавить блок:




location ^~ /.well-known/acme-challenge/ {
   default_type "text/plain";
   root /var/www/letsencrypt;
}
location = /.well-known/acme-challenge/ {
   return 404;
}




Я также рекомендуем вынести указанный блок в отдельный шаблон, например, /etc/nginx/letsencrypt.conf и впоследствии подключать в конфигурацию виртуального хоста именно его и в общих чертах это должно выглядеть так:




server {   
    server_name example.com   
..   
    include /etc/nginx/letsencrypt.conf;
}




Данный подход является хорошей практикой, так как в случае внесения каких-либо изменений их придется делать только в одном месте, вне зависимости от числа обслуживаемых виртуальных хостов.




Lighttpd




В русскоязычной среде данный веб-сервер недостаточно распространен, так как пользователи отдают предпочтение Nginx, но в мировом масштабе он входит в число наиболее популярных веб-серверов. Если вы используете именно его, то откройте основной конфигурационный файл /etc/lighttpd/lighttpd.conf и убедитесь, что в секции server.modules присутствует значение mod_alias, в противном случае его необходимо добавить.




После чего дополните конфигурацию следующей секцией:




$HTTP["url"] =~ "^/.well-known/" {
    server.document-root = "/var/www/letsencrypt/.well-known/"
    alias.url = ( "/.well-known/" => "/var/www/letsencrypt/.well-known/" )
    dir-listing.activate = "enable"
}




Не забывайте, что после внесения изменений в конфигурационные файлы любой веб-сервер необходимо перезапустить.




Регистрация в Let’s Encrypt




Регистрация нужна для формирования ключевой пары, которой впоследствии подписываются все запросы, что позволяет удостовериться в подлинности отправителя. Это важно, так как все запросы передаются по открытым каналам и теоретически возможен их перехват и модификация.




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




Для регистрации выполните команду:




certbot register -m admin@example.com




Для успешного прохождения процедуры вам потребуется всего-лишь согласиться с условиями использования. Учетная информация будет сохранена в каталог /etc/letsencrypt/accounts, если содержимое данной директории будет утрачено, то вы не сможете продлить сертификаты и вам придется получать их заново, создав новый аккаунт. Это следует учитывать, например, при переносе системы на новый сервер.




Если вам необходимо изменить адрес электронной почты аккаунта, скажем при смене администратора, то это можно сделать следующей командой:




certbot register --update-registration -m new_admin@example.com




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




Получение сертификата




Наконец-то мы подошли к самому главному – получению сертификата, но не стоит спешить, количество запросов на сертификат в единицу времени ограничено (20 запросов на регистрацию в неделю и 5 неудачных запросов в час), поэтому следует убедиться, что все сделано правильно. Для этого следует использовать возможность тестового запуска Certbot, наберем в консоли:




certbot certonly --dry-run --webroot -w /var/www/letsencrypt -d example.com -d www.example.com




Ключ --dry-run включает тестовый режим, при котором производится симуляция получения сертификата, --webroot – указывает используемый плагин, после ключа -w указываем путь к директории для letsencrypt, а затем через ключ -d указываем домены для которых мы получаем сертификат. Как минимум это должно быть основное имя сайта и имя c www, хотя никто не мешает включить вам в сертификат все нужные поддомены или вообще разные домены. Лимит на количество доменов в сертификате равен 100.




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




После того как тестовый запуск увенчался успехом можно переходить к получению сертификата:




certbot certonly --webroot -w /var/www/letsencrypt -d example.com -d www.example.com




Сертификат получен, отлично! Но где нам его искать? Перейдем в директорию:




cd /etc/letsencrypt/live 




где для каждого полученного сертификата будет создана директория с именем первого указанного в запросе домена, т.е. для нашего примера – example.com. Внутри будут находиться четыре файла:







Именно эти файлы следует использовать в конфигурационных файлах служб при настройке SSL.




При внимательном рассмотрении выяснится, что файлы в директории /live являются символьными ссылками на аналогичные файлы в /etc/letsencrypt/archive:




Настоящие файлы хранятся в аналогичной по структуре директории /archive и имеют в наименовании порядковый номер, который увеличивается при каждом продлении сертификата. Например, при первом получении сертификата ссылка cert.pem из /live будет указывать на cert1.pem из/archive, после продления туда добавится cert2.pem, и ссылка начнет указывать на него. Как видим процесс обновления сертификатов реализован прозрачно для использующих их служб и достаточно все настроить один единственный раз, остальное Certbot берет на себя.




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




Полученный сертификат можно в любой момент расширить, добавив в него новые домены, для этого следует использовать ключ --expand:




certbot certonly --webroot -w /var/www/letsencrypt --expand -d example.com -d www.example.com -d forum.example.com




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




Продление сертификатов




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




Поэтому основное назначение Certbot – это именно автоматическое продление сертификатов. Производится оно одной простой командой renew. Если мы заглянем в /etc/cron.d, то найдем там файл certbot в котором дважды в день запланирован запуск команды:




certbot -q renew




Как видим, никаких дополнительных параметров не передается, и Cerbot сам определяет что нужно продлевать. Каким образом он это делает? Вернемся в /etc/letsencrypt и заглянем еще в одну директорию /renewal, там мы обнаружим некие конфигурационные файлы с именами доменов, например, example.com.conf, откроем его. В начале будут перечислены файлы сертификата и пути к ним, эта информация нас мало интересует, гораздо интереснее вторая часть файла, которая выглядит примерно так:




# Options used in the renewal process
[renewalparams]
authenticator = webrootinstaller = Noneaccount = 4073d66415ef4c5a89e2cbca53e5f899
[[webroot_map]]
example.com = /var/www/letsencrypt
www.example.com = /var/www/letsencrypt
forum.example.com = /var/www/letsencrypt




Секция renewalparams указывает основные параметры получения сертификата: плагин – webroot, инсталлятор сертификата – в нашем случае отсутствует и аккаунт, к которому привязаны данные сертификаты. В секции webroot_map перечислены требующие продления домены и указан путь к корневой директории для Let’s Encrypt.




Здесь скрыт один из подводных камней, допустим сначала у вас был один домен, и вы просто получали сертификат для него указывая:




--webroot -w /var/www/example.com




Затем доменов стало больше, и вы перешли на единую точку подтверждения сертификатов /var/www/letsencrypt, но в конфигурационном файле по-прежнему останется /var/www/example.com и такой домен автоматически продлиться не сможет.




Поэтому мы рекомендуем всегда проверять возможность продления командой:




certbot renew --dry-run




Как и в случае с получением сертификата ключ --dry-run предписывает провести тестовый запуск с симуляцией продления, что позволит своевременно выявить возможные ошибки и устранить их.




Сама же команда renew, как многие успели догадаться, последовательно получает конфигурационные файлы из директории /renewal и выполняет продление согласно указанным там параметрам.




В принципе, убедившись в успешности тестового продления можно оставить все как есть, но лучше произвести тонкую настройку. Прежде всего добавим к команде продления ключ --allow-subset-of-names:




certbot -q renew --allow-subset-of-names




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




Но это еще не все, после того как сертификат будет продлен нужно перезапустить все службы его использующие, например, веб-сервер. Можно прописать еще одно задание в cron, но правильно будет сделать по-другому. Certbot поддерживает специальные ключи, которые позволяют выполнять некие действия перед и после запуска утилиты:







Наиболее удобным в использовании является ключ --renew-hook, который будет перезапускать службы только тогда, когда получит новый сертификат, а не два раза в день, как это будет делать --post-hook.




Как использовать данные ключи? В простейшем случае можно просто добавить их к команде продления в cron:




certbot -q renew --allow-subset-of-names --renew-hook "service nginx reload; service vsftpd restart"




В указанном нами примере будут перезапущены веб-сервер Nginx и ftp-сервер vsftpd. Однако разные сертификаты могут быть привязаны к разным службам, поэтому более правильно будет указать эти параметры в конфигурационных файлах в директории /renewal. Для этого в секцию [renewalparams] добавьте:




renew-hook  = service nginx reload; service vsftpd restart




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



[endtxt]




RSS




[РЕШЕНО] ошибка “data-vocabulary.org” в WordPress на Linux

Сегодня в статье разберемся как можно исправить ошибку “data-vocabulary.org” в WordPress. Google анонсировали, отключение поддержки словаря data-vocabulary. Из-за этого многие в консоли получают ошибки, связанные с этим. Пока что – это предупреждения, чтобы успеть с этим что-то сделать. Но в будущем может оказаться и серьезной ошибкой для поисковых роботов от Google. Поэтому давайте разберемся как исправить ошибку “data-vocabulary.org” в WordPress.




Для начала нам необходимо найти файлы где присутствует надпись разметки data-vocabulary.org.




Для этого открываем терминал и набираем следующий текст:




grep -R --color data-vocabulary.org /var/www/




Данная команда рекурсивно пробежится по всем категориям и найдет в файлах нашу заветную фразу data-vocabulary.org. Вот пример вывода:




/var/www/public_html/wp-content/mythemes/template-parts/content-single.php:<div class="breadcrumb" xmlns:v="http://rdf.data-vocabulary.org/#"><?php mytheme_breadcrumb(); ?></div> 




У вас вывод конечно же будет отличаться, но суть остается та же. Из вывода видно какой файл необходимо открыть на редактирование. В файле необходимо произвести замену data-vocabulary.org на schema.org




Меняем микроразметку со словаря data-vocabulary на schema.org




Вот парочка примеров:




Новый вариант разметки со словарём schema.org

<?php mytheme_set_post_views( get_the_ID() ); ?>
<article id="post-<?php the_ID(); ?>" <?php post_class(); ?>>
        <div class="breadcrumb" xmlns:v="http://schema.org/BreadcrumbList"><?php mytheme_breadcrumb(); ?></div>
        <header class="entry-header">
                <?php the_title( '<h1 class="entry-title">', '</h1>' ); ?>
...




или вот.




Старый вариант разметки по data-vocabulary.org

<div class="breadcrumbs">
  <span itemscope itemtype="http://data-vocabulary.org/Breadcrumb">
    <a href="https://obu4alka.ru/" itemprop="url">
      <span itemprop="title">Obu4alka.ru</span>
    </a> ›
    <span itemprop="child" itemscope itemtype="http://data-vocabulary.org/Breadcrumb">
      <a href="https://obu4alka.ru/home" itemprop="url">
        <span itemprop="title">Главная</span>
      </a> ›
      <span itemprop="child" itemscope itemtype="http://data-vocabulary.org/Breadcrumb">
        <a href="https://obu4alka.ru/home/seo/" itemprop="url">
          <span itemprop="title">SEO</span>
        </a>
      </span>
    </span>
  </span>
</div>




Новый вариант разметки со словарём schema.org

<div class="breadcrumbs">
  <span itemscope itemtype="http://schema.org/BreadcrumbList">
    <span itemprop="itemListElement" itemscope itemtype="http://schema.org/ListItem">
      <a href="https://obu4alka.ru/" itemprop="item">
        <span itemprop="name">Obu4alka.ru</span>
      </a>
      <meta itemprop="position" content="1" />
    </span> ›
    <span itemprop="itemListElement" itemscope itemtype="http://schema.org/ListItem">
      <a href="https://obu4alka.ru/home" itemprop="item">
        <span itemprop="name">Главная</span>
      </a>
      <meta itemprop="position" content="2" />
    </span> ›
    <span itemprop="itemListElement" itemscope itemtype="http://schema.org/ListItem">
      <a href="https://obu4alka.ru/home/seo/" itemprop="item">
        <span itemprop="name">SEO</span>
      </a>
      <meta itemprop="position" content="3" />
    </span>
  </span>
</div>



[endtxt]




RSS



Добавление RSS-ленты на главную страницу этого сайта не поддерживается, так как это может привести к зацикливанию, замедляющему работу вашего сайта. Попробуйте использовать другой блок, например блок Последние записи, для отображения записей сайта.


2020-07-07T07:00:00
WEB

Как можно отобразить дату последнего изменения поста на WordPress?

Сегодня в статье разберемся как можно отобразить дату последнего изменения поста на CMS WordPress.




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




Существуют много различных способов как изменить дату публикации вордпресс, например:




  • через SQL скрипт;
  • вручную через phpMyAdmin с выгрузкой дат из базы;
  • с использованием TextKit (программа позволяет обновлять и редактировать большие базы данных);
  • различные скрипты, которые располагаются в корне сайта; и работают при запуске из строки браузера;
  • в ручном режиме из административной части сайта;
  • автоматическое обновление даты публикации в WordPress.




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




Большинство
тем оформления WordPress показывают дату публикации поста. Это
стандартная функция, которая подходит для всех блогов.




Однако, WordPress также часто используется на проектах, где старые публикации могут часто обновляться или дополняться новым контентом. Это типично для сайтов с новостями. Когда появляются новые уточненные сведения, они вносятся в уже опубликованный материал. И в таком случае намного полезнее показывать дату последнего изменения поста такой публикации.




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




Дата последнего изменения поста на WordPress




Чтобы выводить дату последнего изменения поста перед началом текста, скопируйте и добавьте этот код в ваш файл functions.php текущей темы оформления в самый конец файла:




<?php
function wpb_last_updated_date( $content ) {
$u_time = get_the_time('U'); 
$u_modified_time = get_the_modified_time('U'); 
if ($u_modified_time >= $u_time + 86400) { 
$updated_date = get_the_modified_time('d.m.Y');
$updated_time = get_the_modified_time('h:i'); 
$custom_content .= '<p class="last-updated">Last updated on '. $updated_date . ' at '. $updated_time .'</p>';  
} 
$custom_content .= $content;
return $custom_content;
}
add_filter( 'the_content', 'wpb_last_updated_date' );
?>




Этот код выполняет проверку и сравнивает 2 даты: дату публикации и дату последнего изменения. Если эти даты не совпадают, тогда код выводит дату последнего изменения перед началом контента записи.




Вот еще один пример для отображения даты изменения поста. Данный код необходимо вставить в файл single.php или его аналоги, например content-single.php.




<div>Последнее изменение поста: <?php the_modified_date('F j Y года'); ?></div><br />




Место в ставки подбираете сами в зависимости от вашей темы. В моем случае я вставил перед функцией




<?php the_content(); ?>




Также можете изменить дату публикации вашего поста еще одним способом , для этого необходимо вставить вот такой код в файл function.php вашей темы.




<?php
function reset_post_date_wpse_121565($data,$postarr) {
  // var_dump($data,$postarr); die; // debug
  $data['post_date'] = $data['post_modified'];
  $data['post_date_gmt'] = $data['post_modified_gmt'];
  return $data;
}
add_filter('wp_insert_post_data','reset_post_date_wpse_121565',99,2);
?>




Примечание: Рекомендую запомнить, то что при каждом нажатии на кнопку «Обновить» в записи, будет обновляться и дата публикации вашего поста.



[endtxt]




RSS



Добавление RSS-ленты на главную страницу этого сайта не поддерживается, так как это может привести к зацикливанию, замедляющему работу вашего сайта. Попробуйте использовать другой блок, например блок Последние записи, для отображения записей сайта.


2020-05-01T12:09:11
WEB

Защищаем WordPress от спам-ботов и авто-ботов.

Рассмотрим скрипт, который позволяет «вычислить» как спам-ботов, так и авто-ботов и закрывать им доступ на весь сайт.




Всех «нехороших» ботов объединяет следующее: попадая на
любую страницу сайта, подобные боты первым делом пробегаются по всем
ссылкам на страничке для того, чтобы выяснить, где еще можно наспамить
или что-нибудь скачать. Вот на этом и будет основан наш скрипт защиты от
ботов.




Для начала создайте папку bad_bot в корне сайта. В папке bad_bot создайте четыре файла:




1) black_list.dat — изначально пустой файл, в который будет помещаться информация о ботах, «попавших в ловушку»;




2) pixel.gif — прозрачный файл размером в 1 пиксель. Простой человек его не видит, но только не бот. Скачать данный файл Вы можете по ссылке;




3) black_list.php — страничка, со скриптом
перейдя на которую бот будет «в ловушке», а вся необходимая информация о
боте будет помещена в файл black_list.dat;




4) index.php — скрипт, проверяющий есть ли данный IP в списке ботов. Если есть, то доступ для данного IP блокируется.




Теперь поместите в файл black_list.php следующий код:




<?php
echo '<html><body><p>Как Вы сюда попали?</p>';
echo '<p><a href="https://Ваш_домен.ru/">вернуться на главную страницу</a></p>';
if(phpversion() >= "4.2.0") {extract($_SERVER);}
$bad_bot = 0;
/* Смотрим, имеется ли такой же IP в базе */
$file_name = "black_list.dat";
$fp = fopen($file_name, "r") or die ("Ошибка, файл black_list.dat не найден <br>");
while ($line = fgets($fp, 255)) {
$u = explode(" ", $line);
if (preg_match("/".$u[0]."/", $REMOTE_ADDR)) {$bad_bot++;}
}
fclose($fp);
if ($bad_bot == 0) {
$tmestamp = time();
$datum = date("H:i:s d.m.Y",$tmestamp);
/* отсылаем отчет на email */
$to = "ваш@email.ru";
$subject = "Заголовок сообщения";
$msg = "Пришёл с $REQUEST_URI $datum IP: $REMOTE_ADDR, User-агент $HTTP_USER_AGENT";
mail($to, $subject, $msg);
/* Если отсылать отчет на email не надо, то 4 строки выше можно удалить*/

/* Добавляем запись в файл black_list.dat */
$fp = fopen($file_name,'a+');
fwrite($fp,"$REMOTE_ADDR $datum $REQUEST_URI $HTTP_REFERER $HTTP_USER_AGENTrn");
fclose($fp);
}
echo '</body></html>';
?>




Далее в файл index.php поместите следующий код:




<?php
if(phpversion() >= "4.2.0") {extract($_SERVER);}
$bad_bot = 0;
/* перебираем все записи в файле black_list.dat */
$file_name = "bad_bot/black_list.dat";
$fp = fopen($file_name, "r") or die ("Ошибка, файл black_list.dat не найден<br>несуществующий путь<br>");
while ($line = fgets($fp, 255)) {
$data = explode(" ", $line);
if (preg_match("/".$data[0]."/", $REMOTE_ADDR)) {$bad_bot++;}
}
fclose($fp);
if ($bad_bot > 0) { /* это бот и мы запрещаем ему вход на сайт */
sleep(3);            /* задержка загрузки странички */
echo '<html><head>';
echo '<title>Сайт временно недоступен.</title>';
echo '</head><body><br>';
echo '<center><h1>Сайт временно недоступен!</h1></center><br>';
echo '<p><center>Приносим свои извинения ...</center></p><br>';
echo '</body></html>';
exit;
}
?>




Обязательно в файле robots.txt запрещаем индексацию данной папки путем добавления строчки:




disallow: /bad_bot/




Теперь для защиты вашего сайта от ботов, на всех страницах сайта разместите невидимую ссылку следующим образом:




<a href="https://Baш_домен.ru/bad_bot/black_list.php">
<img src="https://Baш_домен.ru/bad_bot/pixel.gif" border="0" alt="" width="1" height="1">
</a>




Перед выводом каждой странички необходимо постоянно проверять содержимое файла black_list.dat, чтобы отсеивать «попавшихся» ботов. Для этого просто добавьте на все странички следующий код:




<?php include("https://Baш_домен.ru/bad_bot/index.php"); ?>




Файлу blacklist.dat необходимо дать на сервере права доступа для чтения и записи – 666.




Использовать данный скрипт необходимо с осторожностью,
т.к. он может заблокировать и некоторых «хороших» ботов. Например,
ботов, которые создают карту Вашего сайта.



[endtxt]



2019-09-16T00:55:15
WEB

Список проверенных пинг сервисов WordPress 2019

Составил и отсортировал повторяющиеся пинг сервисы для блогов WordPress в 2019 году. Копируйте и пользуйтесь моим списком пинг сервисов чтобы ускорить индексацию.




Пинг сервисы WordPress 2019




Чтобы ускорить индексацию сайта поисковым системам нужно каким-то образом сообщить про обновление. Делают это через пинг сервисы. Раньше я использовал более 200 пинг сервисов, но сегодня в 2019 году я оставил только рабочие и не повторяющиеся, который занес в этот список.




http://ping.blogs.yandex.ru/RPC2
http://api.my.yahoo.co.jp/RPC2 http://audiorpc.weblogs.com/RPC2 
http://blo.gs/ping.php http://blog.goo.ne.jp/XMLRPC 
http://blogpeople.net/ping 
http://blogpeople.net/servlet/weblogUpdates 
http://blogsearch.google.ae/ping/RPC2 
http://blogsearch.google.at/ping/RPC2 
http://blogsearch.google.be/ping/RPC2 
http://blogsearch.google.bg/ping/RPC2 
http://blogsearch.google.ca/ping/RPC2 
http://blogsearch.google.ch/ping/RPC2 
http://blogsearch.google.cl/ping/RPC2 
http://blogsearch.google.co.cr/ping/RPC2 
http://blogsearch.google.co.hu/ping/RPC2 
http://blogsearch.google.co.id/ping/RPC2 
http://blogsearch.google.co.il/ping/RPC2 
http://blogsearch.google.co.in/ping/RPC2 
http://blogsearch.google.co.jp/ping/RPC2 
http://blogsearch.google.co.ma/ping/RPC2 
http://blogsearch.google.co.nz/ping/RPC2 
http://blogsearch.google.co.th/ping/RPC2 
http://blogsearch.google.co.uk/ping/RPC2 
http://blogsearch.google.co.ve/ping/RPC2 
http://blogsearch.google.co.za/ping/RPC2 
http://blogsearch.google.com.ar/ping/RPC2 
http://blogsearch.google.com.au/ping/RPC2 
http://blogsearch.google.com.br/ping/RPC2 
http://blogsearch.google.com.co/ping/RPC2 
http://blogsearch.google.com.do/ping/RPC2 
http://blogsearch.google.com.mx/ping/RPC2 
http://blogsearch.google.com.my/ping/RPC2 
http://blogsearch.google.com.pe/ping/RPC2 
http://blogsearch.google.com.sa/ping/RPC2 
http://blogsearch.google.com.sg/ping/RPC2 
http://blogsearch.google.com.tr/ping/RPC2 
http://blogsearch.google.com.tw/ping/RPC2 
http://blogsearch.google.com.ua/ping/RPC2 
http://blogsearch.google.com.uy/ping/RPC2 
http://blogsearch.google.com.vn/ping/RPC2 
http://blogsearch.google.com/ping/RPC2 
http://blogsearch.google.ru/ping/RPC2 
http://blogshares.com/rpc.php 
http://geourl.org/ping 
http://godesigngroup.com/blog/feed/ 
http://ipings.com http://lasermemory.com/lsrpc
http://mod-pubsub.org/kn_apps/blogchatt 
http://mod-pubsub.org/kn_apps/blogchatter/ping.php 
http://mod-pubsub.org/ping.php 
http://ping.amagle.com 
http://ping.bitacoras.com 
http://ping.bloggers.jp/rpc/ 
http://ping.blogs.yandex.ru/RPC2 
http://ping.fc2.com http://ping.fc2.com/ 
http://ping.feedburner.com 
http://ping.rootblog.com/rpc.php 
http://pinger.onejavastreet.com 
http://rpc.bloggerei.de/ping/ 
http://rpc.icerocket.com:10080/ 
http://rpc.pingomatic.com/ 
http://rpc.twingly.com/ 
http://rpc.weblogs.com/RPC2 
http://services.newsgator.com/ngws/xmlrpcping.aspx 
http://wasalive.com/ping/ 
http://www.blogpeople.net/servlet/weblogUpdates 
http://www.blogshares.com/rpc.php 
http://www.godesigngroup.com 
http://www.lasermemory.com/lsrpc 
http://www.mod-pubsub.org/kn_apps/blogchatter/ping.php 
http://www.ping.blo.gs/ 
http://www.pingerati.net 
http://www.pingmyblog.com 
http://www.rpc.technorati.jp/rpc/ping 
http://www.wasalive.com/ping/ 
http://www.xmlrpc.bloggernetz.de/RPC2 
http://xmlrpc.bloggernetz.de/RPC2 http://xping.pubsub.com/ping/






2019-08-12T17:34:36
WEB

[РЕШЕНО] Ошибка обновления WordPress – Сайт ненадолго закрыт на техническое обслуживание. Зайдите через минуту

Иногда, после очередного обновления WordPress или при обновлении плагина вместо сайта и административной панели в браузере отображается запись «Сайт ненадолго закрыт на техническое обслуживание. Зайдите через минуту». Исправить ошибку не помогает ни чистка браузера, ни перезагрузка сайта. Такую ошибку с уверенностью можно отнести к элементарным и ее лучше исправить, чем откатываться с бэкапу сайта.




Причина ошибки




Для начала о причинах появления ошибки «Сайт ненадолго закрыт на техническое обслуживание. Зайдите через минуту» – это не что иное, как заглушка, которая появляется вместо сайта при любом автоматическом обновлении системы, включая обновление плагинов из административной панели сайта.




То есть, если вы попытаетесь открыть сайт, когда идет обновление, вы увидите такую заглушку. Прерванный процесс обновления, по любым причинам, может эту заглушку оставить, а не удалить после завершения обновления. Если мы видим на экране надпись «Сайт ненадолго закрыт на техническое обслуживание. Зайдите через минуту», значит, заглушка не была удалена и осталась в корне сайта.




Заглушка с надписью «Сайт ненадолго закрыт на техническое обслуживание. Зайдите через минуту» это не что иное, как технический файл .maintenance. Он подгружается в корень сайта на период обновления и должен удаляться после завершения обновления.




Как исправить ошибку обновления




Отсюда элементарное решение проблемы:




  • Идем в корень сайта по FTP;
  • Удаляем файл .maintenance;
  • Все проблема решена.




Второе решение проблемы




Если удаление файла .maintenance не помогает, есть другая припарка:




  • Идем в корень сайта по FTP;
  • Ищем wp-activate.php;




В текстовом редакторе в строке:




define("WP_INSTALLING", true);




значение true меняем на значение false.




Сохраняемся, переносим редактированный файл на сайт в режиме перезаписи и смотрим результат.




Вывод




Чтобы не «ловить» такие глупые ошибки, следуйте советам системы. На странице обновлений WordPress постоянно пишут, Перед обновлением сделайте резервную копию сайта и базы данных. Не расслабляйтесь, делайте резервную копию сайта и никакие ошибки (белые экраны) не страшны.



[endtxt]



2019-05-24T08:00:55
WEB