Содержание

10 отличных приемов с .htaccess для WordPress / Хабр

Внимание!

Перед изменением файла .htaccess не забудьте сделать его резервную копию.

1 — Перенаправляем WordPress RSS поток на feedburner с использованием .htaccess

Почему некоторые вебмастера не используют feedburner? Ведь это такой замечательный инструмент для контроля за подписками на RSS. Проблема в том, что приходится руками исправлять файлы шаблонов. Этот прием поможет сохранить Ваше время.

И не забудьте исправить в строке 6 на Ваш код

<IfModule mod_rewrite.c>
 RewriteEngine on
 RewriteCond %{HTTP_USER_AGENT} !FeedBurner    [NC]
 RewriteCond %{HTTP_USER_AGENT} !FeedValidator [NC]
 RewriteRule ^feed/?([_0-9a-z-]+)?/?$ httр://feeds2.feedburner.com/wordpress[R=302,NC,L]
</IfModule>

2 — Удалить /category/ из пути в адресе WordPress

По умолчанию категории в WordPress отображаются так: httр://www.wordpress.com/blog/category/wordpress

А это не очень красиво, да и адрес выглядит длинновато.

Сейчас Вы узнаете как исправить это с помощью .htaccess

RewriteRule ^category/(.+)$ httр://www.yourblog.com/$1 [R=301,L]

Теперь категории будут выглядеть как:

httр://www.wordpress.com/blog/wordpress

3 — Использование кэша браузера

Очень хороший путь оптимизации твоего блога это использование кэша браузера. Этот код улучшает кэширование браузером статических файлов.

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

FileETag MTime Size
<ifmodule mod_expires.c>
  <filesmatch "\.(jpg|gif|png|css|js)$">
       ExpiresActive on
       ExpiresDefault "access plus 1 year"
   </filesmatch>
</ifmodule>

4 — Сжатие статических данных

Этот код уменьшит объём данных передаваемых между сервером и пользователем за счет их сжатия.

AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch bMSIE !no-gzip !gzip-only-text/html

5 — Перенаправление постоянных ссылок на основе Дня и имени на /%postname%/

Сначала зайдите в админку WordPress, зайдите в Settings → Permalinks и выберите custom.

Заполните поле с /%postname%/.

Теперь постоянные ссылки будут выглядеть так: httр://www.yourblog.com/name-of-the-post

Теперь нам нужно перенаправить все старые ссылки на новые постоянные.

Внесите в .htaccess следующие строки:

RedirectMatch 301 /([0-9]+)/([0-9]+)/([0-9]+)/(.*)$ httр://www.domain.com/$4

6 — Запретить комментирование если отсутствует referrer

Метод построен на том, что многие спам-боты не передают referer когда постят данные.

Этот код проверяет поле referrerи блокирует отправку комментария если отсутствует referer при обращении к файлу wp-comments-post.php.

Не забудьте в строке 4 вписать домен своего блога

RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-comments-post\.php*
RewriteCond %{HTTP_REFERER} !.*yourblog.com.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) ^http://%{REMOTE_ADDR}/$ [R=301,L]

7 — Перенаправить пользователя на страницу-заглушку

на время работ на сайте желательно перенаправлять пользователей на временную страницу-заглушку

Замените в строке 2 maintenance.html на название вашего файла.

И в строке 3 впишите свой IP, чтобы вас не перенаправляло на эту заглушку.

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

RewriteEngine on
RewriteCond %{REQUEST_URI} !/maintenance.html$
RewriteCond %{REMOTE_ADDR} !^123\.123\.123\.123
RewriteRule $ /maintenance.html [R=302,L]

8 — Защита блога от хотлинков

Хотлик — это использование файлов размещенных на вашем сайте на страницах других сайтов с целью сэкономить свой серверный трафик.

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

RewriteEngine On
#Replace ?mysite\.com/ with your blog url
RewriteCond %{HTTP_REFERER} !^http://(.+\.)?mysite\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
#Replace /images/nohotlink.jpg with your "don't hotlink" image url
RewriteRule .*\.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpg [L]

9 — Разрешить доступ к wp-admin только с Вашего IP

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

Не забудьте вставить свой IP в строке 8.

Если Вы захотите использовать дополнительные адреса для доступа добавьте строки allow from xx.xx.xxx.xx

AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName "Example Access Control"
AuthType Basic
<LIMIT GET>
order deny,allow
deny from all
allow from xx.xx.xx.xx
</LIMIT>

10 — Блокирование спамеров в WordPress через .htaccess

Часто спам-боты ходят с одних и техже IP. Следующий прием поможет блокировать доступ с этих адресов.

Внеси адрес спамера в строке 3.

Можно расширить список заблокированных адресов добавив строки deny from xxx.xx.xxx.xxx.

<Limit GET POST>
order allow,deny
deny from 200.49.176.139
allow from all
</Limit>

UPD: Оригинал статьи можно найти здесь. Наткнулся случайно, но не смог проигнорировать такие полезности, вот и вышло то, что вышло — эта статья.

Файл .htaccess по-умолчанию для WordPress — Технический блог

Эта статья будет полезна тем кто утратил оригинальный файл .htaccess от WordPress сайта. Он (файл) необходим если вы используете веб-сервер Apache.

В повседневной жизни для своих блогов на хостинге я использую связку веб-сервера NGINX и интерпретатор PHP в режиме php-fpm. И со временем «зачистил» код сайта от всех ненужных на мой взгляд файлов, в том числе я удалил .htaccess.

При проведении тестирования нового хостинга, где использовалась связка Apache+Nginx, я с удивлением обнаружил, что мой тестовый блог на WordPress не работает и виной тому оказался отсутствующий файл .htaccess в корне сайта.

Стандартный файл .htaccess для WordPress

Минимально необходимый для работы сайта на WordPress файл .htaccess должен содержать следующие строки:


# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Данный код был успешно протестирован на WordPress версии 4.9.8

Для чего нужен файл .htaccess

Файл .htaccess — это файл дополнительной конфигурации, в котором находятся инструкции для веб-сервера Apache. Он не затрагивает основной файл конфигурации веб-сервера и его действие распространяется только на каталог, в котором он располагается, и на его дочерние каталоги.

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

Переадресация на HTTPS версию сайта

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


RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]

Размещать эти строки следует в начале файла выше инструкций для WordPress.

Что еще может файл .htaccess

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

Благодарности

При написании статьи были использованы следующие источники:

  1. https://codex.wordpress.org/htaccess

Защита админ панели WordPress при помощи файла .htaccess

Автор Игорь Градов На чтение 2 мин.

При помощи .htaccess можно установить http авторизацию или «двойную авторизазацию» для вашего сайта. Покажу на примере движка WordPress.

Вначале переходим сюда http://www.htaccesstools.com/htpasswd-generator/ и генерируем файл .htpasswd, указывая любые логин и пароль.

Генерируем файл .htpasswd

Сгенерированный файл помещаем в корень своего сайта.

Далее, в корневом файле .htaccess добавляем следующие строки:

AuthUserFile .htpasswd
AuthName "Private access"
AuthType Basic
<FilesMatch "wp-login.php">
Require valid-user
</FilesMatch>

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

AuthUserFile /home/k/lucky/lucky-seo.com/public_html/.htpasswd

Чтобы узнать абсолютный путь от корня сервера нужно создать любой файл .php и вписать туда:

<?php
echo $_SERVER['DOCUMENT_ROOT'];
?>

и поместить в файл в корень, затем перейти на него.

Если все сделано правильно, то при переходе в админ панель сайта по адресу /wp-admin или /wp-login.php будет запрашиваться аутентификация:

Аутентификация

Запрет по IP

Также, при помощи .htaccess можно запретить доступ к админке wordpress по IP адресу.

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

<Files "wp-login.php">
    Order deny,allow
    Allow from All
    Deny from 00.00.00.00
</Files>

Где 00.00.00.00 — это IP адрес, которому вы хотите закрыть доступ к админке.

Но лучше закрыть доступ всем IP, кроме своего (если у вас постоянный IP), тогда код будет таким:

<Files "wp-login.php">
    Order deny,allow
    Deny from All
    Allow from 00.00.00.00
</Files>

Где вместо 00.00.00.00 — должен быть ваш IP адрес.

В случае, если вы хотите закрыть доступ всем, то нужно убрать строку Allow:

<Files "wp-login.php">
    Order deny,allow
    Deny from All
</Files>
Зачем это нужно?

Это самая простая и надежная защита от брутфорс атак на ваш сайт.

Если вы хотите защитить админ панель по максимуму, то дополнительно используйте плагин Сlearfy. Подробнее про плагин я писал в этом посте.

Время кеширования статики .htaccess | WordPress.org Русский

Указываю время кеширования как «access plus 1 year» но google speed inside мне упорно пишет что время установлено как 4 часа.
Может я не так указываю, подскажите пожалуйста как правильно указать время кеширования файлов?

Вот все содержимое моего .htaccess

# BEGIN WpFastestCache
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTPS} =on
RewriteCond %{HTTP_HOST} ^webmastera.blog
# Start WPFC Exclude
# End WPFC Exclude
# Start_WPFC_Exclude_Admin_Cookie
RewriteCond %{HTTP:Cookie} !wordpress_logged_in_[^\=]+\=webmastera
# End_WPFC_Exclude_Admin_Cookie
RewriteCond %{HTTP_HOST} ^webmastera.blog
RewriteCond %{HTTP_USER_AGENT} !(facebookexternalhit|WhatsApp|Mediatoolkitbot)
RewriteCond %{HTTP_USER_AGENT} !(WP\sFastest\sCache\sPreload(\siPhone\sMobile)?\s*Bot)
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{REQUEST_URI} !(\/){2}$
RewriteCond %{REQUEST_URI} \/$
RewriteCond %{QUERY_STRING} !.+
RewriteCond %{HTTP:Cookie} !comment_author_
RewriteCond %{HTTP:Cookie} !wp_woocommerce_session
RewriteCond %{HTTP:Cookie} !safirmobilswitcher=mobil
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/all/$1/index.html -f [or]
RewriteCond /var/www/vhosts/webmastera.blog/httpdocs/wp-content/cache/all/$1/index.html -f
RewriteRule ^(.*) "/wp-content/cache/all/$1/index.html" [L]
</IfModule>
<FilesMatch "index\.(html|htm)$">
AddDefaultCharset UTF-8
<ifModule mod_headers.c>
FileETag None
Header unset ETag
Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires "Mon, 29 Oct 1923 20:30:00 GMT"
</ifModule>
</FilesMatch>
# END WpFastestCache
# BEGIN GzipWpFastestCache
<IfModule mod_deflate.c>
AddType x-font/woff .woff
AddType x-font/ttf .ttf
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
AddOutputFilterByType DEFLATE font/opentype font/ttf font/eot font/otf
</IfModule>
# END GzipWpFastestCache
# BEGIN LBCWpFastestCache
<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|webp|js|css|swf|x-html|css|xml|js|woff|woff2|ttf|svg|eot)(\.gz)?$">
<IfModule mod_expires.c>
AddType application/font-woff2 .woff2
ExpiresActive On
ExpiresDefault "access 7 days"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/ico "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType text/css "access plus 1 year"
ExpiresByType text/javascript "access plus 1 year"
ExpiresByType application/javascript "access plus 1 year"
ExpiresByType application/x-javascript "access plus 1 year"
ExpiresByType application/font-woff2 "access plus 1 year"
</IfModule>
<IfModule mod_headers.c>
Header set Expires "max-age=86400"
Header unset ETag
Header set Connection keep-alive
FileETag None
</IfModule>
</FilesMatch>
# END LBCWpFastestCache
# BEGIN WordPress

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Попытка номер раз создать почти идеальный htaccess / Хабр

    - Google выше ранжирует сайты, которые загружаются быстрее.
    - Если на eBay или Amazone увеличить время загрузки страниц на 9% они теряют 1% прибыли.
    - Сделать свой сайт быстрее, чтобы сэкономить на клиентском трафике и на числе обращений к серверу.

.htaccess — наш герой

Профессионалы знают, что такое htaccess.
Тем кто собираются уйти с народ.ру на php-хостинг только предстоит узнать, что это такое.
Те кто только что установил свои первые jooml’у или wordpress срочно должны узнать о нашем герое — htaccess

Зачем нам .htaccess ?

Представьте, что вы купили себе хостинг и кажется, почти обрели счастье. Но однажды (а может быть дважды, а может и трижды) ваш сайт перестает отвечать на запросы. Начинает медленно грузиться и вообще вести себя странно. А виртуальный хостинг это такая хитрая штука, что помимо вашего сайта на этом сервере находится ещё два десятка других сайтов. Все они разные по мощности, организованности и трафику. И когда ваш сосед по случайности, а может и умыслу запускает на своем хостинге сложные или избыточные в алгоритмах скрипты, это отзывается и на вас.

Или другой пример. Скажем ваш ресурс начинает набирать популярность, но переезжать на выделенный сервер ещё рано, а мощностей VPS уже не хватает. Вас очень может выручить htaccess.

А ещё htaccess может решить некоторые вопросы с безопасностью вашего сайта.

А ещё…

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

1. Первой строкой задаем основные опции:

Options All -ExecCGI -Indexes -Includes +FollowSymLinks

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

Опция -ExecCGI запрещает запуск CGI скриптов. Лучше разрешить только для конкретных папок. Повысит безопасность.

Опция -Indexes запрещает показывать содержимое каталогов, если в них нет индексного файла. На виртуальном хостинге обычно включена по умолчанию. Изменив минус на плюс +Indexes можете наоборот разрешить просмотр содержимого каталога (или каталогов).

Опция -Includes запрещает SSI. Если не знаете, что это — запрещайте (Можно поЯндексировать(!) по запросу Server Side Include если хотите узнать об этом побольше). Можно использовать опцию IncludesNOEXEC, которая разрешит использовать SSI без запуска скриптов.

Опция +FollowSymLinks позволяет использовать символические ссылки на файлы или каталоги, не находящиеся в пределах корня вашего сайта.

ПримечаниеВы можете использовать htaccess с разными настройками для разных каталогов. В корне сайта вы можете объявить -Indexes, а в избранных каталогах создать ещё один файл .htaccess и в нем объявить +Indexes. Помните, что действие опций htaccess распространяет сверху вниз по дереву каталогов до самой глубокой вложенности, пока не будут отменены другим htaccess.

Необязательно полностью перечислять все опции в дочерних .htaccess если они не изменяются. Достаточно указать (переназначить) только те опции и директивы, которые изменяются. Остальные опции также унаследуются от родителя.

ПримерСкажем, у вас есть вот такой путь /site/folder_one/subfolder/other/
В файле /site/.htaccess вы указываете:

Options  -Indexes
Allow from all

В файле /site/folder_one/.htaccess указываете:

Deny from all

В файле /site/folder_one/subfolder/.htaccess указываете:

Options  +Indexes
Allow from all

Получиться вот что:
В папке site будут показываться файлы любого содержания, если только к ним напрямую обратиться. Или индексный файл, если не явного обращения к одному из файлов. В случае отсутствия индексного файла получена 403 ошибка.
К папке folder_one доступ закрыт. Даже если знать имя файла и набрать его в адресной строке в ответ сервер вернет ошибку 403.
Папка subfolder разрешена для обращений по прямому адресу или же в случае отсутствия индексного файла покажет содержимое каталога. Эти же права распространяться и на папку other.
Если убрать файл ,htaccess из папки folder_one, то она унаследует права от родительской site.

2. Немного SEO (куда же без него)

<IfModule mod_rewrite.c>
	RewriteEngine on
	RewriteBase /
	RewriteCond %{HTTP_HOST} ^black-web
	RewriteRule (.*) http://www.black-web.ru/$1 [R=301,L]
	RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/
	RewriteRule ^index\.php$ http://www.black-web.ru/ [R=301,L]
</IfModule>


Обязательно не забыть про условие . Не окажись у хостера данного модуля и ваш сайт станет выдавать 500-ую ошибку. Данный конкретный модуль входить в сборку Апача по-умолчанию. Ну а вдруг… Хостеры и их админы бывают всякие.

В данной части пользы больше для SEO. Модуль rewrite как следует из его названия занимается перенаправлениями (привет Кэпу).

В этой части файла мы указали две склейки: мы склеили ваш_сайт и www.ваш_сайт Даже если пользователь наберет ваш сайт без WWW его перебросить 301 редериктом на www.ваш_сайт.

А также мы избавились /index.php в строке запроса. Если пользователь наберет www.ваш_сайт/index.php его перебросит (снова 301 редериктом) на www.ваш_сайт.

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

3. Кто в папке главный?

Если у вас папке есть файлы index.html и index.php (не знаю, зачем и кому такое было нужно, но не раз видел такое) то как указать серверу кто их них более индексный?

DirectoryIndex index.php

А ещё можно там указать скажем roosso.php и тогда набрав в строке запроса адрес сайт.бла/бла/бла/ вы увидете не index, а roosso

4. Ещё настройки…

<IfModule mod_setenvif.c>
	SetEnv TZ Europe/Moscow
</IfModule>
ServerSignature Off
AddDefaultCharset UTF-8

Первая строчка устанавливает часовой пояс. Например в Apache 2.22.22 был баг связанный с этой опцией. Функции времени в php не работали, пока не установишь часовой пояс.

Вторая строка это подпись сервера. Вы их не раз видели на всяких системных страницах типа 500ой ошибки или 403ей. Обычно там какая-нибудь техническая информация и почта вебмастера. Я предпочитаю даже в таких мелочах скрывать данные о софте на сервере. Коллеги параноики меня поддержат.

Угадайте, что делает третья строка?

5. Когда нет доступа к php.ini

С помощью .htaccess мы также можем управлять рядом настроек PHP. На виртуальном хостинге, как правило, нет возможности изменять настройки php.ini. Чаще всего этого и не требуется. Но все же есть ряд опций контроль над которыми может нам быть полезен. Например, увеличить лимит на загрузку файлов, или лимит передачи данным методом POST.

<ifModule mod_php.c>
  php_value	upload_max_filesize	32M
  php_value	post_max_size		10M
  php_value	default_charset utf-8
  php_value	max_execution_time 200
</ifModule>

Первая строчка разрешить загружать файлы размером до 32 Мегабайт. По умолчанию в php обычно это значение 8 или 16 мегабайт.
Второй строкой разрешаем постинг объемом до 10 мегабайт. По умолчанию это значение обычно 2 Мегабайта.
Третья строка устанавливает кодировку по используемую вашими скриптами. По своей сути она дублирует строку: «AddDefaultCharset UTF-8». Но я чаще прибегаю к установке кодировки именно через php.
Четвертой строкой изменяем лимит времени выделенный на выполнение скрипта. По умолчанию он обычно равен 30 секундам. Но иногда для выполнения каких нибудь сложных обработок требуется больше времени.

6. Типы файлов. Ловкость рук и ни какого мошенничества.

В моей практике случалось пару раз, что после какого либо обновления провайдером софта, слетали типы файлов. Хотя такое редко. За 10 лет, всего два случая. Но иногда мне нужно было заставить html работать как php. А иногда требуется научить апач различать типы файлов, которые ему неизвестно. (Как оказалось Апачу вообще мало что известно из редких типов файлов.) В такой ситуации нас спасет следующий код:

AddHandler application/x-httpd-php .html
AddHandler cgi-script .pl .py .jsp .asp .htm .shtml .sh .cgi
AddType application/x-javascript .js
AddType text/css .css
AddType text/xml .xml
AddType application/octet-stream .doc .mov .avi .pdf .xls 
# ForceType application/x-httpd-php

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

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

Интересный трюкКстати, вы можете легко написать к примеру вот такую строку:

AddHandler application/x-httpd-php .i

Потом переименовать все ваши файлы, изменив расширение на .i (не забыв конечно про ссылки) и адреса файлов у вас на сайте будут не сайт.мой/index.php?uri а сайт.мой/index.i?uri

Например я пишу

AddHandler application/x-httpd-php .roosso

и создаю в корне своего сайта файл alex.roosso внутри обычный php код. Это вроде как страница обо мне любимом. И в адресной строке она будет выглядеть как www.black-web.ru/alex.roosso (ссылка рабочая, можете посмотреть что это так).
Второй строкой указано, какие расширения файлов должны выполняться как cgi скрипты.

Третья, четвертая и пятая строки, на всякий случай уточняют мим-тип файлов с разрешением css, js, xml. Не путайте с присвоением заголовка в ответе сервера на запрос, как это сделано в первых двух строках.

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

Седьмую строку я закомментировал. Это строчка в принудительно-добровольном порядке, будет все файлы с вашего сервера запустить как php. Её лучше использовать лишь в отдельных папках, при необходимости.

7. Знают взрослые и дети, что архивы меньше весят…

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

У Апача есть два модуля сжатия. Оба не являются модулями по умолчанию, поэтому необязательно могут присутствовать у вашего провайдера. Но как показала практика у 99% провайдеров один из них стоит. Наиболее распространен mod_deflate. Чтобы его с помощью сжимать весь контент на вашем сайте добавьте в .htaccess следующие строки:

<ifModule mod_deflate.c>
	AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/css text/javascript application/javascript application/x-javascript
</ifModule>

Как видите мы должны перечислить mime type файлов, которые следует подвергать сжатию. Сюда можно добавить и видео и картинки, но толку это даст мало. Потому что jpeg или gif уже сами по себе являются сжатыми форматами. Также как avi или flv. Вы фактически нечего не выиграете указав их.

Второй менее популярный модуль это mod_gzip, Чтобы включить сжатие с его помощью добавьте вот такие строчки:

<IfModule mod_gzip.c>
	mod_gzip_on         Yes
	mod_gzip_dechunk    Yes
	mod_gzip_item_include file		\.(html?|txt|css|js|php|pl)$
	mod_gzip_item_include mime		^text\.*
	mod_gzip_item_include mime		^application/x-javascript.*
	mod_gzip_item_exclude mime		^image\.*
	mod_gzip_item_exclude rspheader	^Content-Encoding:.*gzip.*
</IfModule>

Данный модуль умеет работать с масками, что несомненно большой плюс. Да и синтаксис у него куда более гибкий чем у предыдущего. Но используют его реже. А по сжатию я даже не берусь судить, который из модулей лучше. Я сильной разницы не заметил при тестах.

8. А ещё быстрее можно?

Можно. Если применить кеширование страниц. У кеширования есть и плюсы и минусы, поэтому подходить к этому вопросу надо подготовившись. Для динамически обновляющегося сайт каждый 2-3 минуты, например популярного форума, нужно учесть, что пользователь должен видеть актуальную информацию. Но у любого сайт есть контент, который более или менее статичен. Например те же картинки, или файлы стилей. Поэтому нам потребуется по разному использовать кеширование различного содержимого на сайте. В html разметки мы всегда можем использовать meta теги. И через php мы может устанавливать заголовки ответа сервера. Остается вопрос, как быть с css, js, image и т.д. и т.п.

Помочь нам в этом могут два модуля: mod_headers и mod_expires которые могут установить заголовки в ответ сервера и подсказать вашему браузеру, что и как нужно кешировать. Один из модулей обычно стоит у провайдера, но как и в случае с любым модулем, который не входит в стандартную сборку Апача, 100% гарантии никто вам не даст. Поэтому снова во избежание 500й ошибки указывает условия для каждого из модулей.

<ifModule mod_headers.c>
	#кэшировать html и htm файлы на один день
	<FilesMatch "\.(html|htm)$">
		Header set Cache-Control "max-age=43200"
	</FilesMatch>
	#кэшировать css, javascript и текстовые файлы на одну неделю
	<FilesMatch "\.(js|css|txt)$">
		Header set Cache-Control "max-age=604800"
	</FilesMatch>
	#кэшировать флэш и изображения на месяц
	<FilesMatch "\.(flv|swf|ico|gif|jpg|jpeg|png)$">
		Header set Cache-Control "max-age=2592000"
	</FilesMatch>
	#отключить кэширование
	<FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
		Header unset Cache-Control
	</FilesMatch>
</IfModule>

Вот такой синтаксис у mod_headers. Думаю по комментариям ясно что к чему.
В данной секции я отключил кеширование php файлов. Хотя по моему мнению небольшой временной интервал кеширования им не повредит. 5-30 секунд, это интервал времени, за который мало что меняется. А многие пользователи любят пользоваться клавишей back (вернуться назад). Чтобы не загружать им страницу второй раз, а подхватить её из кеша, разумный интервал кеширования все же уместен.

Во второй секции где идут условия для mod_expires я именно так и делаю — для php ставлю небольшой интервал кеширования.

<ifModule mod_expires.c>
	ExpiresActive On
	#по умолчанию кеш в 5 секунд
	ExpiresDefault "access plus 5 seconds"
	#кэшировать флэш и изображения на месяц
	ExpiresByType image/x-icon "access plus 2592000 seconds"
	ExpiresByType image/jpeg "access plus 2592000 seconds"
	ExpiresByType image/png "access plus 2592000 seconds"
	ExpiresByType image/gif "access plus 2592000 seconds"
	ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
	#кэшировать css, javascript и текстовые файлы на одну неделю
	ExpiresByType text/css "access plus 604800 seconds"
	ExpiresByType text/javascript "access plus 604800 seconds"
	ExpiresByType application/javascript "access plus 604800 seconds"
	ExpiresByType application/x-javascript "access plus 604800 seconds"
	#кэшировать html и htm файлы на один день
	ExpiresByType text/html "access plus 43200 seconds"
	#кэшировать xml файлы на десять минут
	ExpiresByType application/xhtml+xml "access plus 600 seconds"
</ifModule>

9. Правила вежливого тона…

В процессе модернизации своего сайта, мы часто оставляем хвосты ввиде ссылок, которые ведут на страницы, которые мы удалили. Иногда такие ссылки идут с других сайтов или из поисковых систем. Чтобы не терять пользователей вежливым тоном считается иметь собственные страницы для различного типа ошибок. Включая даже ошибки сервера. Например стандартное сообщение о 500й ошибки очень скучное и мрачное, и вряд ли вызовет у пользователя желание посетить вашу страницу ещё раз. Но в htaccess есть приемы, которые могут сделать даже эту страницу приветливей.

# Bad Rquest
ErrorDocument 400 /400.html
# Authorization Required
ErrorDocument 401 /401.html
# Forbidden
ErrorDocument 403 /403.html
# Not found
ErrorDocument 404 /404.html
# Method Not Allowed
ErrorDocument 405 /405.html
# Request Timed Out
ErrorDocument 408 /408.html
# Request URI Too Long
ErrorDocument 414 /414.html
# Internal Server Error
ErrorDocument 500 /500.html
# Not Implemented
ErrorDocument 501 /501.html
# Bad Gateway 
ErrorDocument 502 /502.html
# Service Unavailable 
ErrorDocument 503 /503.html
# Gateway Timeout
ErrorDocument 504 /504.html

Для 400-х ошибок можно использовать и динамические страницы на php. А вот для 500 лучше сделать на html и js. Это часть ошибок обычно связана с ошибками сервера (в большинстве случаев) и php или cgi как правило в такой ситуации не работают.

Если вам лень делать столько страниц устанавливайте страницей ошибок главную страницу своего сайта или карту сайта.

Все это вы делаете исключительно для людей. Поисковым роботам плевать на то есть у вас страницы ошибок или нет. Они видят ответ сервера с кодом ошибки и блокируют вашу страницу в поиск. Так что имейте ввиду, это не панацея. Это лишь вежливость к вашей аудитории и имидж вашего сайта.

10. Подведем итог

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

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

Options All -ExecCGI -Indexes -Includes +FollowSymLinks

<IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteBase /
    RewriteCond %{HTTP_HOST} ^black-web
    RewriteRule (.*) http://www.black-web.ru/$1 [R=301,L]
    RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/
    RewriteRule ^index\.php$ http://www.black-web.ru/ [R=301,L]
</IfModule>

DirectoryIndex index.php

<IfModule mod_setenvif.c>
	SetEnv TZ Europe/Moscow
</IfModule>
ServerSignature Off
#AddDefaultCharset UTF-8
<ifModule mod_php.c>
	php_value	upload_max_filesize	32M
	php_value	post_max_size		10M
	php_value	default_charset utf-8
	php_value	max_execution_time 200
</ifModule>
AddHandler application/x-httpd-php .html
AddHandler cgi-script .pl .py .jsp .asp .htm .shtml .sh .cgi
AddType application/x-javascript .js
AddType text/css .css
AddType text/xml .xml
AddType application/octet-stream .doc .mov .avi .pdf .xls 
# ForceType application/x-httpd-php

<ifModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/css text/javascript application/javascript application/x-javascript
</ifModule>

<IfModule mod_gzip.c>
    mod_gzip_on         Yes
    mod_gzip_dechunk    Yes
    mod_gzip_item_include file		\.(html?|txt|css|js|php|pl)$
    mod_gzip_item_include mime		^text\.*
    mod_gzip_item_include mime		^application/x-javascript.*
    mod_gzip_item_exclude mime		^image\.*
    mod_gzip_item_exclude rspheader	^Content-Encoding:.*gzip.*
</IfModule>

<ifModule mod_headers.c>
    #кэшировать html и htm файлы на один день
    <FilesMatch "\.(html|htm)$">
        Header set Cache-Control "max-age=43200"
    </FilesMatch>
    #кэшировать css, javascript и текстовые файлы на одну неделю
    <FilesMatch "\.(js|css|txt)$">
        Header set Cache-Control "max-age=604800"
    </FilesMatch>
    #кэшировать флэш и изображения на месяц
    <FilesMatch "\.(flv|swf|ico|gif|jpg|jpeg|png)$">
        Header set Cache-Control "max-age=2592000"
    </FilesMatch>
    #отключить кэширование
    <FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
        Header unset Cache-Control
    </FilesMatch>
</IfModule>

<ifModule mod_expires.c>
    ExpiresActive On
    #по умолчанию кеш в 5 секунд
    ExpiresDefault "access plus 5 seconds"
    #кэшировать флэш и изображения на месяц
    ExpiresByType image/x-icon "access plus 2592000 seconds"
    ExpiresByType image/jpeg "access plus 2592000 seconds"
    ExpiresByType image/png "access plus 2592000 seconds"
    ExpiresByType image/gif "access plus 2592000 seconds"
    ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
    #кэшировать css, javascript и текстовые файлы на одну неделю
    ExpiresByType text/css "access plus 604800 seconds"
    ExpiresByType text/javascript "access plus 604800 seconds"
    ExpiresByType application/javascript "access plus 604800 seconds"
    ExpiresByType application/x-javascript "access plus 604800 seconds"
    #кэшировать html и htm файлы на один день
    ExpiresByType text/html "access plus 43200 seconds"
    #кэшировать xml файлы на десять минут
    ExpiresByType application/xhtml+xml "access plus 600 seconds"
</ifModule>

# Bad Rquest
ErrorDocument 400 /400.html
# Authorization Required
ErrorDocument 401 /401.html
# Forbidden
ErrorDocument 403 /403.html
# Not found
ErrorDocument 404 /404.html
# Method Not Allowed
ErrorDocument 405 /405.html
# Request Timed Out
ErrorDocument 408 /408.html
# Request URI Too Long
ErrorDocument 414 /414.html
# Internal Server Error
ErrorDocument 500 /500.html
# Not Implemented
ErrorDocument 501 /501.html
# Bad Gateway 
ErrorDocument 502 /502.html
# Service Unavailable 
ErrorDocument 503 /503.html
# Gateway Timeout
ErrorDocument 504 /504.html

11. Послесловие.

Я старался не спешить в написании статьи и на это ушли почти сутки. Но все же где то я мог допустить ошибки в орфографии или пунктуации. Прошу не казнить, а миловать. А лучше писать в личку, чтобы я поправил ошибки.

И напоследок для любителей экспериментов несколько строк .htaccess. Сужу по своему опыту — на практике знания усваиваются лучше чем в теории.

Разные интересные примеры

# SECURE ____________________
<IfModule mod_ssl.c>
	SSLOptions +StrictRequire
	SSLRequireSSL
	SSLRequire %{HTTP_HOST} eq "black-web.ru"
</IfModule>
<IfModule mod_rewrite.c>
	RewriteCond %{HTTPS} !on
	RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</IfModule>

# HOTLINKING ________________
<IfModule mod_rewrite.c>
	RewriteCond %{HTTP_REFERER} !^$
	RewriteCond %{HTTP_REFERER} !^http://([ -a-z0-9]  \.)?black-web\.ru [NC]
	RewriteRule \.(gif|jpe?g|png)$ - [F,NC,L]
</IfModule>

# REDIRICT __________________
Redirect 301 /index.html /index.php
<IfModule mod_rewrite.c>
	RewriteRule ^news/([^/\.]+)/?$ news.php?news=$1 [L]
	RewriteRule ^(.*\.((js)|(css)))$ plugin/GzipFile.php?file=$1
	RewriteRule \.css$ plugin/GzipFile.php?file=$1
	RewriteRule \.js$ plugin/GzipFile.php?file=$1
</IfModule>
RedirectMatch 301 /blog(.*) http://www.black-web.ru/$1

P.S.

… Для тех у кого всё получилось, идём на www.webpagetest.org мерять красоту до и после.
Andrey_Zentavr

Кому надо берите полностью готовый .htaccess здесь

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

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

htaccess | WordPress.org

.htaccess — это распределенный файл конфигурации, и именно так Apache обрабатывает изменения конфигурации для каждого каталога.

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

Эта страница может использоваться для восстановления поврежденного файла .htaccess (например, некорректно работающего плагина).

 # НАЧАТЬ WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^ index \.- [L]
RewriteRule. index.php [L]
# КОНЕЦ WordPress
 

Наверх ↑

Наверх ↑

Опции № Опции

Любые параметры, которым предшествует + , добавляются к действующим в данный момент параметрам, а любые параметры, которым предшествует , удаляются из действующих в настоящее время параметров.

Возможные значения для директивы Options представляют собой любую комбинацию:

Нет

Все опции выключены.

Все

Все опции, кроме MultiView.Это значение по умолчанию.

ExecCGI

Разрешено выполнение сценариев CGI с использованием mod_cgi.

FollowSymLinks

Сервер будет переходить по символическим ссылкам в этом каталоге.

Включает

Разрешены включения на стороне сервера, предоставляемые mod_include.

Включает NOEXEC

Включения на стороне сервера разрешены, но #exec cmd и #exec cgi отключены.

Индексы

URL соответствует каталогу, а не DirectoryIndex — форматированному списку каталога.

Мультипросмотр

Согласованное содержимое «MultiViews» разрешено с использованием mod_negotiation.

SymLinksIfOwnerMatch

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

Это отключит все параметры, а затем включит только FollowSymLinks, что необходимо для mod_rewrite.

 Опции Нет
Параметры FollowSymLinks
 

Наверх ↑

DirectoryIndex # DirectoryIndex

DirectoryIndex устанавливает файл, который Apache будет обслуживать при запросе каталога.

Можно указать несколько URL-адресов, и в этом случае сервер вернет первый найденный.

 DirectoryIndex index.php index.html /index.php
 

Наверх ↑

DefaultLanguage # DefaultLanguage

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

 DefaultLanguage ru
 

Наверх ↑

Кодировка по умолчанию # Кодировка по умолчанию

Установите кодировку символов по умолчанию, отправляемую в заголовке HTTP. См .: Установка информации о кодировке в .htaccess

 AddDefaultCharset UTF-8
 

Установить кодировку для определенных файлов

 AddType 'text / html; charset = UTF-8 '.html
 

Набор для конкретных файлов

 AddCharset UTF-8 .html

 

Наверх ↑

ServerSignature # ServerSignature

Директива ServerSignature позволяет конфигурировать завершающую строку нижнего колонтитула в документах, созданных сервером.При желании добавьте строку, содержащую версию сервера и имя виртуального хоста, на страницы, созданные сервером (внутренние документы об ошибках, списки каталогов FTP, вывод mod_status и mod_info и т. Д., Но не документы, созданные CGI или пользовательские документы об ошибках).

по телефону

добавляет строку с номером версии сервера и ServerName обслуживающего виртуального хоста

Off

подавляет строку нижнего колонтитула

Электронная почта

создает ссылку mailto: на ServerAdmin указанного документа

.

 SetEnv SERVER_ADMIN admin @ site.com
Сервер Подпись Электронная почта
 

Наверх ↑

Принудительная загрузка файлов # Принудительная загрузка файлов

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

 Приложение AddType / поток октетов .avi .mpg .mov .pdf .xls .mp4
 

Наверх ↑

Сжатие HTTP # Сжатие HTTP

Директива AddOutputFilter сопоставляет расширение расширения имени файла с фильтрами, которые будут обрабатывать ответы от сервера перед их отправкой клиенту.Mozilla / 4 \ .0 [678] no-gzip
BrowserMatch \ bMSIE! No-gzip! Gzip-only-text / html

Принудительное сжатие для определенных файлов

 SetOutputFilter DEFLATE

 

Наверх ↑

Директива Header позволяет отправлять заголовки HTTP для каждого запроса или только для определенных файлов. Вы можете просматривать HTTP-заголовки сайтов с помощью Firebug, Chrome Dev Tools, Wireshark или онлайн-инструмента.

 Заголовочный набор X-Pingback "http://www.askapache.com/xmlrpc.php"
Набор заголовков Content-Language "en-US"
 

Наверх ↑

Это отключит заголовки HTTP, всегда используя . будет очень стараться удалить их.

 Заголовок не установлен Pragma
Заголовок всегда отключен WP-Super-Cache
Заголовок всегда отключен X-Pingback
 

Наверх ↑

Защита паролем логина # Защита паролем логина

Это очень полезно для защиты файла wp-login.php . Вы можете использовать этот генератор htpasswd.

Базовая аутентификация

 AuthType Basic
AuthName "Защищено паролем"
AuthUserFile /full/path/to/.htpasswd
Требовать действительного пользователя
Удовлетворить все

 

Дайджест-аутентификация

 Дайджест AuthType
AuthName "Защищено паролем"
AuthDigestDomain / wp-login.php https://www.askapache.com/wp-login.php
AuthUserFile /full/path/to/.htpasswd
Требовать действительного пользователя
Удовлетворить все

 

Наверх ↑

Требуется особый IP # Требуется особый IP

Это способ разрешить доступ только определенным IP-адресам.

 ErrorDocument 401 по умолчанию
ErrorDocument 403 по умолчанию


Заказать отказать, разрешить
Запретить всем
Разрешить от 198.101.159.98 localhost

 

Наверх ↑

Защита конфиденциальных файлов # Защита конфиденциальных файлов

Это запрещает любой веб-доступ к вашему файлу wp-config, error_logs, php.ini и htaccess / htpasswds.

 Заказать отклонить, разрешить
Запретить всем

 

Наверх ↑

Требовать SSL # Требовать SSL

Это приведет к принудительному использованию SSL и потребует точного имени хоста, иначе будет выполнено перенаправление на версию SSL. Полезно в файле /wp-admin/.htaccess .

 SSLOptions + StrictRequire
SSLRequireSSL
SSLRequire% {HTTP_HOST} eq "www.wordpress.com"
ErrorDocument 403 https://www.wordpress.com
 

Наверх ↑

Наверх ↑

.

Htaccess от BestWebSoft — плагин для WordPress

Плагин

Htaccess — это простой и полезный инструмент, который помогает контролировать доступ к вашему сайту WordPress. Разрешить или запретить доступ на основе имени хоста, IP-адреса, диапазона IP-адресов и т. Д. Отключите хотлинкинг и доступ к xmlrpc.php.

Защитите свой сайт WordPress с легкостью!

Бесплатные функции
  • Задайте поля заказа:
  • Задайте информацию аргумента в форме директивы:
  • Настроить.htaccess файл
  • Создать резервную копию с возможностью восстановления файла .htaccess
  • Совместимость с последней версией WordPress
  • Невероятно простые настройки для быстрой настройки без изменения кода
  • Подробная пошаговая документация и видео
  • Многоязычный и RTL готов

Pro Характеристики

Включены все функции из бесплатной версии плюс:

  • Установите доступ к xmlrpc.php:
    • Запрет доступа
    • Перенаправить на главную
  • Включение / отключение хотлинкинга
  • Разрешить хотлинкинг на основе имен хостов
  • Настроить все дочерние сайты в сети
  • Получите ответ на свой вопрос о поддержке в течение одного рабочего дня (Политика поддержки)

Перейти на Pro сейчас

Если у вас есть предложение или идея, которую вы хотели бы включить в плагин, мы будем рады услышать об этом! Предложить функцию

Документация и видео
Справка и поддержка

Посетите наш справочный центр, если у вас есть какие-либо вопросы, наша дружелюбная команда поддержки будет рада помочь — https: // support.bestwebsoft.com/

Перевод

Некоторые из этих переводов не завершены. Мы постоянно добавляем новые функции, которые нужно переводить. Если вы хотите создать свой собственный языковой пакет или обновить существующий, вы можете отправить текст файлов PO и MO в BestWebSoft, и мы добавим его в плагин. Вы можете скачать последнюю версию программы для работы с PO и MO файлами Poedit.

Рекомендуемые плагины
  • Updater — Автоматическая проверка и обновление ядра веб-сайта WordPress со всеми установленными плагинами и темами до последних версий.
  • Limit Attempts — Защитите сайт WordPress от атак грубой силы. Ограничьте количество попыток входа в систему.
  • Страница настроек плагина.
  • Страница сетевых настроек плагина.
  • Страница редактора плагинов.

Как плагин будет работать с существующим файлом .htaccess?

Если файл существует и в нем есть блок директив, плагин добавит настройки этого блока на страницу настроек и после сохранения изменений обновит только блок директив в существующем.htaccess файл.

Что делать, если файл .htaccess не существует?

Плагин сохранит настройки в базе данных и автоматически добавит все необходимые условия блока директив в настройки WordPress.

Как будет работать плагин, если после сохранения изменений в корневом каталоге сайта появится файл .htaccess?

Плагин получит данные блока Директивы из.htaccess автоматически независимо от ранее настроенных параметров.

Что делать, если после внесения изменений в файл .htaccess с помощью плагина мой сайт перестал работать?

.htaccess находится в корне сайта. С помощью программы FTP или Сpanel перейдите в корень сайта, откройте файл .htaccess и вручную удалите нужные строки.
Воспользуйтесь следующей информацией: https://codex.wordpress.org/FTP_Clients

Что такое кража контента (хотлинкинг) и как от этого защититься?

Чтобы узнать о хотлинкинге и способах его предотвращения, ознакомьтесь с нашей статьей, посвященной этой теме.В этой статье вы найдете все необходимые данные, которые подскажут вам и помогут избежать хотлинкинга на вашем сайте.

Как мне обновить список IP-адресов после обновления плагина до версии V1.7.2?

В Htaccess от BestWebSoft V1.7.2 мы переместили все IP-адреса, которые были добавлены в .htaccess автоматически через хуки взаимодействия плагина, в «автоматически добавленные» параметры плагина. После этого обновления они будут храниться не в базе данных, а в формате «.htaccess »только файл. Это было сделано для того, чтобы уменьшить размер базы данных.

Если вы используете плагины, которые взаимодействуют с плагином Htaccess by BestWebSoft (например, Limit Attempts или Limit Attempts Pro by BestWebSoft), перейдите на страницу настроек Htaccess и убедитесь, что все IP-адреса из списков IP-адресов этого плагина были перемещены в «Deny от (добавляется автоматически) »и« Разрешить от (добавляется автоматически) »правильно. Если некоторые IP-адреса из этих списков все еще находятся в параметрах «Запретить от» и «Разрешить от», удалите их вручную и сохраните изменения.

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

Убедитесь, что проблема еще не обсуждалась на нашем форуме (https://support.bestwebsoft.com). Если нет, укажите следующие данные вместе с описанием проблемы:
— Ссылка на страницу, на которой возникает проблема.
— Название плагина и его версия. Если вы используете про версию — номер вашего заказа.
— Версия вашей установки WordPress
— Скопируйте и вставьте в сообщение отчет о состоянии вашей системы. Подробнее читайте здесь: Инструкция по статусу системы

Очень полезный инструмент, он мне так нравится
Thnx 🙂

извините, ребята, но всего 3 звезды. плагин работает как надо, но имеет 10% необходимой функциональности. возьмите WP htaccess Control в качестве примера, который, кстати, бесплатный.

Читать все 2 отзыва

«Htaccess by BestWebSoft» — программное обеспечение с открытым исходным кодом. Следующие люди внесли свой вклад в этот плагин.

авторов

V1.8.2 — 10.03.2020
  • Исправление: исправлены уязвимости и проблемы безопасности.
  • Обновление

  • : Изменена страница настроек плагина.
V1.8.1 — 04.09.2019
  • Обновление: изменен отзыв о деактивации. Убраны вводящие в заблуждение кнопки.
V1.8.0 — 09.01.2019
  • Исправление: исправлена ​​ошибка с добавлением и удалением IP-адреса в полях Разрешить от и Запретить от.
  • Исправление: исправлена ​​ошибка с опцией «Отключить хотлинкинг».
  • Обновление

  • : обновлен весь функционал WordPress 5.0.2.
V1.7.9 — 21.09.2018
  • НОВИНКА: Добавлена ​​возможность настройки файла .htaccess.
  • НОВИНКА: добавлена ​​возможность создания резервной копии файла .htaccess.
  • НОВИНКА: добавлена ​​возможность восстановления файла .htaccess перед резервным копированием.
V1.7.8 — 01.02.2018
  • Обновление: обновлен весь функционал WordPress 4.9.2.
V1.7.7 — 13.07.2017
  • Обновление: обновлен весь функционал WordPress 4.8.
V1.7.6 — 14.04.2017
  • Исправление: исправлена ​​уязвимость, связанная с множественными межсайтовыми скриптами (XSS).
V1.7.5 — 21.02.2017
  • Обновление: мы обновили все функции для wordpress 4.7.2.
  • Обновление

  • : обновлена ​​функция анализа файла .htaccess.
V1.7.4 — 15.08.2016
  • Обновление: обновлен весь функционал WordPress 4.6.
V1.7.3 — 28.06.2016
  • Обновление: обновлен польский языковой файл.
V1.7.2 — 05.05.2016
  • Обновление: все IP-адреса, которые были автоматически добавлены в .htaccess с помощью хуков взаимодействия плагина, перемещены в «автоматически добавленные» параметры и не будут сохраняться в базе данных.Если вы также используете плагины Limit Attempts или Limit Attempts Pro от BestWebSoft, обратите внимание на то, что вам может потребоваться обновить список IP-адресов на странице настроек Htaccess by BestWebSoft. Для получения дополнительной информации см. FAQ.
  • Обновление

  • : обновлен весь функционал WordPress 4.5.1.
  • Исправление: исправлена ​​ошибка с преобразованием диапазонов IPv4 типа xxx.xxx.xxx.xxx-yyy.yyy.yyy.yyy в CIDR.
V1.7.1 — 19.02.2016
  • Обновление: обновлен функционал для сохранения настроек плагина.
  • Обновление

  • : обновлена ​​совместимость с плагином Limit Attempts.
  • Исправление: исправлена ​​ошибка с добавлением направлений плагина в .htaccess.
  • Исправление: исправлена ​​ошибка с дублированием меню плагина.
V1.7.0 — 05.10.2015
  • Обновление: обновлен весь функционал WordPress 4.3.1.
  • Обновление

  • : добавлены вспомогательные уведомления. Обновлено отображение всплывающих подсказок.
V1.6.9 — 20.08.2015
  • НОВИНКА: Возможность разрешить доступ к файлам xml (для сети, основанной на подкаталогах).
V1.6.8 — 14.07.2015
  • НОВИНКА: Возможность восстановления настроек по умолчанию.
V1.6.7 — 11.06.2015
  • Исправление: Исправлена ​​ошибка с переполнением строк Order Deny Alow в файле .htaccess.
V1.6.6 — 11.05.2015
  • НОВИНКА: в плагин добавлен польский языковой файл.
  • Обновление

  • : обновлен весь функционал WordPress 4.2.2.
V1.6.5 — 01.04.2015
  • Исправление: ошибка, возникающая при добавлении записей Order Deny и Alow вручную.htaccess был исправлен.
  • Обновление

  • : обновлен раздел плагинов BWS.
V1.6.4 — 02.03.2015
  • Исправление: Исправлены ошибки плагина при работе на мультисайте
  • Исправление: исправлена ​​ошибка удаления IP-адресов при работе с плагином Limit Attempts
V1.6.3 — 20.02.2015
  • Обновление: обновлен весь функционал WordPress 4.1.1
  • Обновление

  • : обновлен раздел плагинов BWS.
V1.6.2 — 28.01.2015
  • Обновление: обновлен весь функционал плагина Limit Attempts Pro.
V1.6.1 — 12.01.2015
  • Обновление: обновлен раздел плагинов BWS.
  • Обновление

  • : обновлен весь функционал WordPress 4.1.
V1.6 — 06.10.2014
  • Исправление: исправлена ​​ошибка с правами доступа к файлу .htaccess.
V1.5 — 07.08.2014
  • Исправление: исправлен эксплойт безопасности.
V1.4 — 28.07.2014
  • Обновление: обновлен весь функционал плагина Limit Attempts.
V1.3 — 14.05.2014
  • NEW: В плагин добавлен украинский языковой файл.
  • Обновление

  • : Мы обновили весь функционал WordPress 3.9.1.
В1.2 — 04.04.2013
  • Обновление: Обновлены скриншоты.
  • Обновление

  • : обновлен раздел плагинов BWS.
  • Budfix: Оптимизация плагина завершена.
Версия 1.1
  • НОВИНКА: добавлена ​​возможность изменять блок директив существующего файла .htaccess. Оптимизация плагина сделана.

.

Htaccess File Editor — Safely Edit Htaccess File — плагин для WordPress

WP Htaccess Editor обеспечивает простой, безопасный и быстрый способ для редактирования, исправления и тестирования файла htaccess сайта от администратора WP. Перед сохранением файл htaccess можно проверить на синтаксические ошибки. Он также автоматически создает резервную копию htaccess каждый раз, когда вы вносите изменения в файл htaccess. Резервные копии Htaccess могут быть восстановлены непосредственно из плагина или через FTP, если ошибки в файле htaccess мешают нормальной работе WP.Отлично подходит для исправления ошибок htaccess. По всем вопросам, включая поддержку, используйте официальный форум.

Доступ к редактору WP Htaccess через WP Admin — меню настроек.

Тестирование синтаксиса Htaccess

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

Автоматическое резервное копирование Htaccess

Htaccess Editor делает автоматические резервные копии файла htaccess каждый раз, когда вы вносите в него изменения. Резервные копии расположены в / wp-content / htaccess-editor-backups / и имеют отметку времени, поэтому вы можете легко найти последнюю резервную копию htaccess и восстановить ее.

Поддержка сети WordPress (WPMU)

WP Htaccess Editor полностью совместим и протестирован с WP Network (WPMU). Он отображается в меню настроек в администраторе сети. Он недоступен на отдельных сайтах, так как в каждой сети используется только один файл htaccess.

Плагин был первоначально разработан Lukenzi в марте 2011 года.

  • Страница администратора WP Htaccess Editor
  • Действия должны быть дважды подтверждены, чтобы предотвратить несчастные случаи

Следуйте обычному распорядку;

  1. Откройте админку WordPress, перейдите в раздел «Плагины», нажмите «Добавить новый».
  2. Введите «редактор htaccess» в поиск и нажмите Enter
  3. Плагин

  4. появится первым в списке, нажмите «Установить сейчас».
  5. Активировать и открыть страницу настроек плагина, расположенную в меню «Настройки».

Или, если необходимо, загрузите вручную;

  1. Загрузите последнюю стабильную версию из списка загрузок.wordpress.org/plugin/wp-htaccess-editor.latest-stable.zip
  2. Распакуйте его и загрузите в / wp-content / plugins /
  3. Откройте админку WordPress — плагины и нажмите «Активировать» рядом с «WP Htaccess Editor».
  4. Откройте страницу администратора плагина, расположенную в меню настроек.

Я убил свой сайт! Помогите!?

Ничего не потеряно и не удалено. Вы можете легко вернуть свой сайт.
Вероятно, вы получаете ошибку 500 или белый экран (смерти).Сначала подключитесь к своему сайту через FTP и найдите файл .htaccess. Удалите его или переименуйте. Попробуйте еще раз сайт — он должен открыться. Если он нашел резервную копию старого рабочего файла .htaccess в / wp-content / htaccess-editor-backups / , скопируйте файл в корневую папку своего сайта, и вы снова в деле.

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

К сожалению, мы не можем изменить права доступа к файлам, установленные вашим сервером.Вам нужно будет отредактировать файл через FTP.

Зайдите на наш форум поддержки. Мы с радостью вам поможем.

Как мне получить поддержку?

Зайдите на наш форум поддержки. Мы с радостью вам поможем.

Поддерживаете ли вы WP-CLI?

Пока нет, но планируем.

«Редактор файлов Htaccess — Безопасное редактирование файлов Htaccess» — это программа с открытым исходным кодом. Следующие люди внесли свой вклад в этот плагин.

авторов

версия 1.65
  • 16.08.2019
  • исправил несколько ошибок
  • Новая функция

  • : проверьте файл htaccess на наличие синтаксических ошибок перед сохранением
  • новая функция: резервное копирование htaccess
  • 50000 установок на 10.08.2019
версия 1.60
  • 12.03.2019
  • исправил несколько ошибок
  • новое: размер редактора постоянный; сохранено в localStorage
  • Пункт меню

  • перемещен из Инструменты в Настройки
  • Полная совместимость с сетью WordPress (WPMU)
v1.55
  • 2019.01.15
  • добавлена ​​функция изменения размера редактора кода
  • исправил несколько ошибок
  • 9 января 2019 г. было установлено

  • 40 тыс. Установок с 172 000 загрузок
v1.50
  • 21.12.2018
  • WebFactory взялась за разработку
  • полная перезапись плагина
  • 30 000 установок; 162,200 загрузок
v1.3.0
  • Добавлен испанский перевод (спасибо Эндрю Куртису из WebHostingHub.com)
  • Обновленный дизайн
  • Обновлены информационные ссылки
версия 1.2.0
  • Улучшенный код
  • Улучшенная конструкция
  • Повышенная безопасность
  • Удалена панель отладки
  • Обновленные переводы
  • Обновлены ссылки
  • Обновлены скриншоты
  • Добавление логотипа плагина
v1.1.1
версия 1.1.0
  • Добавление чешского и английского языков
  • Добавление панели отладки
  • Добавлена ​​информация об авторе и переводчиках
  • Исправлена ​​уязвимость
  • Исправлена ​​ошибка загрузки файлов переводов
  • Оптимизирован для минимальных требований к памяти
  • Небольшие модификации кода
v1.0,1
  • Кнопка добавления для создания файла .htaccess, если он не существует
  • Исправлена ​​ошибка в разрешениях на просмотр плагина
  • Оптимизирован для небольших требований к памяти
версия 1.0.0
  • 24.03.2011
  • Первая стабильная версия
  • Добавление в репозиторий WordPress

.

Безопасность, SSL, перенаправление, правила, уловки и многое другое

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

Файл .htaccess или просто файл htaccess — отличный инструмент, который позволяет разместить на вашем веб-сайте несколько интересных вещей. Он управляет тем, как Apache обслуживает файлы из своего корневого каталога и всех подкаталогов в WordPress.Файл WordPress Htaccess — важный, но в то же время темпераментный системный файл. Небольшая ошибка кода в файле htaccess может привести к сбоям в работе сервера. Таким образом, всегда следует поддерживать резервную копию и проявлять особую осторожность при работе с ней. Здесь, в конструкторе тем WordPress Templatetoaster, я расскажу обо всех основах работы с файлом htaccess, настройке безопасности, SSL, перенаправлениях на постоянные ссылки и т. Д. В файле htaccess WordPress. Итак, давайте рассмотрим, как оптимизировать файл htaccess для вашего сайта WordPress.

  Содержание  
  1. Что такое файл .htaccess в WordPress?
  2. Как создать файл .htaccess?
    1. Путем установки постоянных ссылок
    2. Ручной метод
  3. Как редактировать файл .htaccess?
  4. Оптимизация производительности с использованием HTACCESS
  5. Защитите сайт WordPress с помощью файла HTACCESS
  6. URL-адреса перенаправления с использованием файла HTACCESS
  7. Правила файла HTACCESS для постоянных ссылок WordPress
    1. Настройка постоянных ссылок
    2. Добавить и настроить постоянные ссылки блога
    3. Изменение постоянных ссылок WordPress с помощью.htaccess
  8. Как заставить SSL с .htaccess?
  9. Дополнительные советы и рекомендации для файла .htaccess WordPress
  10. Подводя итоги
 

Что такое файл .htaccess на веб-сайте WordPress?

Файл htaccess WordPress — это файл гипертекстового доступа к конфигурации сервера. Это поможет вам определить правила, по которым сервер Apache будет обрабатывать ваш сайт. В начале имени файла стоит точка (.), Указывающая, что это скрытый файл. Этот файл изменен для настройки постоянных ссылок, оптимизированных для SEO, повышения безопасности и производительности сайта, перенаправления ссылок и многого другого.

Но иногда пользователю может быть трудно найти файл htaccess после установки WordPress. Впервые он автоматически создается в каталоге WordPress, когда вы настраиваете свои постоянные ссылки. Если нет, вам нужно создать его вручную. Здесь, в программе для создания веб-сайтов Templatetoaster и конструкторе веб-сайтов WordPress, давайте рассмотрим детали, чтобы создать файл WordPress htaccess.

Как создать файл .htaccess в WordPress?

Существует два следующих метода создания файла htaccess:

1.Установив постоянные ссылки

Вам не нужно много делать. Просто перейдите в Настройки → Постоянные ссылки на панели инструментов WordPress. Затем нажмите кнопку «Сохранить изменения» на экране «Постоянная ссылка». Он сгенерирует файл «.htaccess» в корневом каталоге вашего сайта.

2. Ручной метод

В некоторых редких случаях файл не создается автоматически из-за некоторых разрешений на чтение / запись / создание на стороне сервера. В этом случае вы создадите файл cess .htac
вручную. Для этого вы можете выполнить следующие простые шаги:

а.index \ .php $ — [L] RewriteCond% {REQUEST_FILENAME}! -F RewriteCond% {REQUEST_FILENAME}! -DRewriteRule. /index.php [L] # КОНЕЦ WordPress

г. Измените расширение текстового файла с .txt на .htaccess.

г. Теперь загрузите файл .htaccess в корневой каталог веб-сайтов через диспетчер файлов в cPanel по следующему адресу:… / home / yourweb / public_html / .htaccess

Как отредактировать файл .htaccess в WordPress?

Возможно, вам потребуется изменить файл HTACCESS по умолчанию WordPress, чтобы оптимизировать сайт по скорости, безопасности и другим параметрам.Существует три различных метода редактирования файла htaccess WordPress:

1. Редактирование файла WordPress .htaccess с помощью cPanel

  • Прежде всего, войдите в свою cPanel.
  • Перейдите в «Управление файлами» и выберите «Диспетчер файлов».

create htaccess file using cpanel 2 - open file manager create htaccess file using cpanel 2 - open file manager

  • Выберите public_html / www или корень документа. Установите флажок «Включить скрытый файл», если он еще не установлен.

create htaccess file using cpanel 1 - browse location create htaccess file using cpanel 1 - browse location

  • Наконец, щелкните правой кнопкой мыши файл .htaccess и выберите «Изменить».Следуйте инструкциям cPanel, чтобы отредактировать файл.

create htaccess file using cpanel 3 - edit file create htaccess file using cpanel 3 - edit file

2. Редактирование файла .htaccess с помощью FTP-клиента

Второй метод редактирования файла .htaccess WordPress — через FTP-клиент. Доступно множество бесплатных клиентских решений FTP. FileZilla — один из популярных FTP-клиентов. Здесь мы иллюстрируем шаги с использованием FileZilla:

  • Войдите в свою учетную запись FTP-хостинга.
  • Перейдите в корневой каталог вашей установки, чтобы включить Показать скрытый I = ”ftp” class = ”alignnone size-full wp-image-8077 ″ src =” https: // blog.templatetoaster.com/wp-content/uploatems, чтобы найти файл .htaccess.

Параметры меню → Выбрать сервер → Принудительно показать скрытые файлы

  • Перейдите в корневую папку вашего домена и загрузите файл .htaccess.
  • Вот и все. Теперь вы можете редактировать файл .htaccess.

3. Редактирование .htaccess из панели управления WordPress с помощью подключаемого модуля

Третья альтернатива редактированию файла .htaccess WordPress — использование плагинов.Существует множество бесплатных плагинов, которые позволяют редактировать файл .htaccess с панели инструментов WP. Один из самых популярных плагинов, который вы можете использовать, — Yoast SEO Plugin.

  • После того, как вы установили и активировали этот плагин, вы увидите опцию SEO на левой панели панели инструментов WordPress.
  • При нажатии на нее откроется новое окно. На верхней панели выберите «Функции» и «Включить страницы дополнительных настроек». Затем нажмите кнопку «Сохранить изменения».

create htaccess file using yoast 1 - enable advanced settings - create htaccess file using yoast 1 - enable advanced settings -

  • Затем на левой панели панели инструментов перейдите в раздел Инструменты в разделе SEO, чтобы открыть редактор файлов, как показано ниже.

SEO → Инструменты → Редактор файлов

create htaccess file using yoast 2 - create file create htaccess file using yoast 2 - create file

  • Внесите изменения в свой файл .htaccess здесь и нажмите «Сохранить изменения в .htaccess после редактирования».

create htaccess file using yoast 3 - save code create htaccess file using yoast 3 - save code

Вы также можете использовать плагин WP Htaccess Editor для редактирования файла WordPress .htaccess.

(* Примечание. Не забудьте сделать резервную копию вашего файла .htaccess WordPress. Небольшая ошибка может привести к серьезным изменениям на вашем сайте. Внесенные вами изменения, которые вы можете отменить в случае необходимости.)

В файле htaccess вы можете сделать множество вещей, чтобы повысить скорость, производительность и безопасность WordPress.Давайте посмотрим поближе.

Общие проблемы производительности из-за

.