WordPress index php: WordPress/index.php at master · WordPress/WordPress · GitHub

Содержание

WordPress-все страницы ссылаются на файл index.php

[НОВОЕ В WORDPRESS]

Я создаю свою собственную тему wordpress с собственным css и т. д. Мне удалось получить все хорошее в файле index.php,и теперь я пытаюсь сделать и другие страницы.

Когда я делаю файл home.php, blog.php, about.php и contact.php (в моей папке темы), они не ссылаются на него. Я следую «WordPress 3: Creating and Editing Custom Themes with Chris Coyier» на Lynda.com, и пример показывает, что всякий раз, когда вы создаете файл с тем же именем, что и ваша страница, он берет это непосредственно (что работает в его учебнике).

Кто-нибудь, кто мог бы знать, что происходит?

Пример:
У меня есть файл blog.php в папке темы, и когда я захожу в www.mydomain.com / blog, загруженный файл — это файл index.php, а не файл blog.php

php

html

wordpress

wordpress-theming

Поделиться

Источник

Warre Buysse

06 февраля 2014 в 15:54

2 ответа

Остановите WordPress с 301 перенаправление /index.php на /
Мне нужно иметь возможность перейти к http://www.example.com/index.php , но WordPress автоматически 301 перенаправляет это на http://www.example.com/ . Можно ли остановить это перенаправление ONLY для главной страницы? Вот мой файл .htaccess: # BEGIN WordPress <IfModule mod_rewrite.c>…
Apache2+Wordpress, не отображая index.php, но скачать
Я просто переместил свой сайт WordPress с использования nginx на Apache2 и обнаружил, что домашняя страница не может быть показана, вместо этого браузер предлагает мне загрузить ее (загрузка файла точно такая же, как у index.php). Однако самое странное, что, кроме домашней страницы, все остальные…

Есть два способа заставить это работать с помощью пользовательских шаблонов страниц.

Создайте шаблон для одной конкретной страницы, используя page slug или ID. В этом случае измените имя файлов php следующим образом, чтобы оно соответствовало имени страницы, созданной в UI: страница-home.php, страница-blog.php, страница-about.php и страница-contact.php
Гораздо более гибким является создание пользовательского шаблона, который можно использовать на странице ANY. Просто добавьте имя шаблона в верхнюю часть файла php следующим образом (внутри блока php):
/*
Имя шаблона: Шаблон моей домашней Страницы
*/

Затем отредактируйте страницы и выберите свой пользовательский шаблон из выпадающего меню шаблона (я думаю, с правой стороны, если он виден).

Обратитесь к этой странице для получения дополнительной информации: https://developer.wordpress.org/темы/шаблоны-файлы-section/page-template-файлы/

Поделиться

Michael J

06 февраля 2014 в 16:10

Нашел решение моей (глупой) проблемы.

Создание страницы в каталоге тем & добавление комментария к шаблону в верхней части файла php недостаточно. Вам нужно зайти в панель администратора->страницы->ВАША СТРАНИЦА-> и проверить атрибуты страницы. Там вы можете связать страницу с определенным шаблоном: http://d.pr/i/a0m0

Поделиться

Warre Buysse

06 февраля 2014 в 16:09

WordPress просмотр index.php — CodeRoad

У меня есть клиентский сайт на domain.com/index.html и установлен WordPress на том же сервере.. Мне нужно сохранить html страницы до тех пор, пока сайт WP не будет завершен. Как я могу просмотреть сайт WordPress на интерфейсе через domain.com/index.php? Нужно ли мне менять файл .htaccess? Спасибо..

wordpress

Поделиться

Источник

Brent

03 августа 2010 в 20:41

4 ответа

Apache2+Wordpress, не отображая index.php, но скачать
Я просто переместил свой сайт WordPress с использования nginx на Apache2 и обнаружил, что домашняя страница не может быть показана, вместо этого браузер предлагает мне загрузить ее (загрузка файла точно такая же, как у index.php). Однако самое странное, что, кроме домашней страницы, все остальные…
Как настроить предварительный просмотр URL для черновиков сообщений в WordPress?
Я заменил файл index.php в моем корневом каталоге wordpress на index.html (FYI — по причинам, которые находятся вне моего контроля). Все отлично работает, кроме предварительного просмотра URLs для черновиков постов. Это вполне понятно, потому что страница .html правильно ничего не делает с…

Установите WP в другой каталог, как указано, а затем используйте плагин, такой как WordPress «Абсолютная конфиденциальность» WordPress плагина , чтобы ограничить доступ к тем, кто вошел в систему, и отключить каналы RSS. Установите параметры конфиденциальности WP, чтобы блокировать поисковых ботов, пока сайт находится в стадии разработки.

Поделиться

markratledge

03 августа 2010 в 20:52

Возможно, самым простым решением было бы установить WordPress в каталог /blog, а затем сделать перенаправление 301 в каталог блога, когда вы будете счастливы начать жить.

В противном случае вы, скорее всего, столкнетесь с проблемами, если переименуете основной файл WordPress index.php.

[UPDATE]
Я бы также рекомендовал добавить файл robots.txt в каталог /blog, чтобы данные WordPress не были преждевременно проиндексированы Google и т. Д.

Поделиться

John Parker

03 августа 2010 в 20:45

Спасибо за ответы, но я не мог переместить установку, так как у клиента все было настроено таким образом. Вот почему мне нужен был способ сохранить index.html, имея возможность просматривать index.php для разработки и не перенаправлять меня в корень при просмотре.

Итак, вот решение, которое сработало для меня..

Я установил плагин «Maintenance Mode»
http://wordpress.org/extend/plugins/maintenance-mode/
Я взял полный HTML со страницы index.html и поместил его в файл шаблона плагина режима обслуживания.
Активировал плагин, и он сработал как заклинание

Таким образом, я мог бы сохранить старый сайт и работать на сайте wordpress. Когда вы войдете в систему, вы сможете увидеть полный сайт wordpress. Когда вы не вошли в систему, вы видите шаблон «Maintenance mode».. Который для меня был Старым сайтом index.html.

Спасибо всем!

Поделиться

Brent

05 августа 2010 в 04:28

Настройте поддомен, например preview.example.com, и развивайтесь там, пока сайт не будет готов к запуску. Вы даже можете добавить .htacess, чтобы добавить защиту паролем.

Поделиться

Tom

03 августа 2010 в 20:57

Удаление index.php из адресной строки браузера (WordPress)

Обычно index.php это файл, отвечающий за обработку всех запросов к сайту. Многие вебсерверы поддерживают технику, называемую перезаписью URL (URL rewriting), которая позволяет скрыть часть URL за кулисами.

Зачем нужно скрывать index.php в адресной строке? Вот почему:

Наличие index.php в структуре ссылок WordPress не приносит никакой пользы ни вашим читателям, ни поисковой системе.
Такие ссылки не дружественны поисковой системе, и вы упускаете возможность занять более высокое место в выдаче поисковиков.

Вот скриншот одного из веб-сайтов, где index.php виден в ссылке:

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

Удаление /Index.php и создание более дружественных ссылок для поисковых систем

Итак, как убрать index php из URL? Самое первое, что вы должны сделать перед внесением каких-либо изменений, это сделать резервную копию вашего WordPress. В этом случае достаточно сделать резервную копию вашей базы данных. Вы можете использовать любой популярный плагин, такой как WP DB backup, DB manager, чтобы сделать резервную копию базы данных WordPress.

После этого перейдите в Настройки > Постоянная ссылка:

Далее нужно нажать на название публикации и сохранить структуру постоянных ссылок.

WordPress автоматически позаботится о перенаправлении, а ваши старые ссылки будут перенаправлены на новые ссылки. Это постоянное перенаправление 301, которое означает, что ваш поисковый трафик не будет затронут.

Вот несколько дополнительных вещей, которые вы должны сделать:

пересоздайте карту сайта
повторно отправьте карту сайта в Yandex/Google/Bing
используйте плагин Broken link checker для исправления внутренних ссылок.

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

В этой статье мы узнали о том, как убрать index php из адреса.

перепутано с index.php, front-page.php, home.php

Логика главной страницы — одна из самых запутанных функций в WordPress, и ее чрезвычайно сложно объяснить и обобщить. Как упомянуто в комментарии, когда я возвращался, я потратил нечестивое количество времени, чтобы собрать для этого свою шпаргалку логики на первой странице .

Но так как это популярная тема, позвольте мне ответить на эти очень конкретные вопросы, которые у вас были.

Какая разница между home.phpи index.php?

home.phpявляется шаблоном для индекса сообщений (архив с собственным типом записей Post, который является частным случаем в WP). WP попытается найти индекс сообщений, независимо от того, отображаются ли они в корне сайта или на отдельной странице сообщений.

index.phpэто ловить — весь шаблон. Это окончательный выбор во всех ветвях иерархии шаблонов, и он будет выбран, когда ничего не подходит, как для архивов, так и для единичных представлений.

Можно использовать только индекс сообщений home.php, но все остальные контексты могут и будут использовать index.php.

Какое идеальное условие для использования, home.phpчемindex.php

Вы используете home.phpдля настройки индекса сообщений.

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

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

Какое идеальное условие для использования front-page.php?

front-page.php используется для индексирования сообщений на корневой или статической главной странице, если включено.

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

Лучше всего его использовать в частных проектах, так как его легче настроить, чем шаблон страницы.

Когда я использую front-page.phpто, что конкретное задание index.phpделает для меня тогда?

index.phpпо- прежнему является универсальным шаблоном для всех остальных случаев./(codeigniter).*$ игнорируется. Есть ли лучший способ справиться с этим?

Заранее спасибо!

RewriteBase в каталоге codeigniter должен сказать /codeigniter/

 RewriteBase /codeigniter

В противном случае переписывание в index.php заканчивается переходом на wordpress-маршрутизатор.

Установка WordPress с помощью Docker Compose

Введение

WordPress — бесплатная система управления контентом (CMS) с открытым исходным кодом, которая опирается на базу данных MySQL и обрабатывает запросы с помощью PHP. Благодаря огромному количеству плагинов и системе шаблонов, а также тому факту, что большая часть административных функций может производиться через веб-интерфейс, WordPress завоевала популярность среди создателей самых разных сайтов, от блогов и страниц с описанием продукта и до сайтов электронной торговли.

Для запуска WordPress, как правило, требуется установка стека LAMP (Linux, Apache, MySQL и PHP) или LEMP (Linux, Nginx, MySQL и PHP), что может занять много времени. С помощью таких инструментов, как Docker и Docker Compose, вы можете упростить процесс настройки предпочитаемого стека и установки WordPress. Вместо установки отдельных компонентов вручную, вы можете использовать образы, которые обладают такими стандартными элементами, как библиотеки, файлы конфигурации и переменные среды, и запускать эти образы в контейнерах, т. е. изолированных процессах, запущенных в общей операционной системе. Кроме того, используя Compose, вы можете координировать действия нескольких контейнеров, например приложения и базы данных, которые будут коммуницировать друг с другом.

В этом обучающем руководстве вы будете выполнять установку WordPress с несколькими контейнерами. Ваши контейнеры будут включать базу данных MySQL, веб-сервер Nginx и непосредственно WordPress. Также вы должны будете обеспечить защиту установки, получая с помощью Let’s Encrypt сертификаты TLS/SSL для доменов, которые вы хотите привязать к вашему сайту. Наконец, вы настроите задание cron для обновления ваших сертификатов, чтобы ваш домен оставался защищенным.

Предварительные требования

Для данного обучающего руководства вам потребуется следующее:

Сервер на базе Ubuntu 18.04, а также пользователь без прав root с привилегиями sudo и активный брандмауэр. Дополнительную информацию о настройке этих параметров см. в руководстве по первоначальной настройке сервера.
Система Docker, установленная на сервере в соответствии с шагами 1 и 2 руководства Установка и использование Docker в Ubuntu 18.04.
Docker Compose, установленный на сервере, в соответствии с шагом 1 руководства Установка Docker Compose в Ubuntu 18.04.
Зарегистрированное доменное имя. В этом обучающем руководстве мы будем использовать example.com. Вы можете получить бесплатный домен на Freenom или зарегистрировать доменное имя по вашему выбору.
На вашем сервере должны быть настроены обе нижеследующие записи DNS. Вы можете воспользоваться введением в работу с DigitalOcean DNS, чтобы получить подробную информацию о добавлении доменов в учетную запись DigitalOcean, если вы используете этот способ:
- Запись A, где example.com указывает на публичный IP-адрес вашего сервера.
- Запись A, где www.example.com указывает на публичный IP-адрес вашего сервера.

Шаг 1 — Настройка конфигурации веб-сервера

Перед запуском контейнеров прежде всего необходимо настроить конфигурацию нашего веб-сервера Nginx. Наш файл конфигурации будет включать несколько специфических для WordPress блоков расположения наряду с блоками расположения, которые будут направлять передаваемые Let’s Encrypt запросы верификации клиенту Certbot для автоматизированного обновления сертификатов.

Во-первых, создайте директорию проекта для настройки WordPress с именем wordpress и перейдите в эту директорию:

mkdir wordpress && cd wordpress

Затем создайте директорию для файла конфигурации:

Откройте файл с помощью nano или своего любимого редактора:

nano nginx-conf/nginx.(.+\.php)(/.+)$;
                fastcgi_pass wordpress:9000;
                fastcgi_index index.php;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PATH_INFO $fastcgi_path_info;
        }

        location ~ /\.ht {
                deny all;
        }

        location = /favicon.ico {
                log_not_found off; access_log off;
        }
        location = /robots.txt {
                log_not_found off; access_log off; allow all;
        }
        location ~* \.(css|gif|ico|jpeg|jpg|js|png)$ {
                expires max;
                log_not_found off;
        }
}

Наш серверный блок содержит следующую информацию:

Директивы:

listen: данный элемент просит Nginx прослушивать порт 80, что позволит нам использовать плагин webroot Certbot для наших запросов сертификатов. Обратите внимание, что мы пока не будем включать порт 443, мы обновим нашу конфигурацию и добавим SSL после успешного получения наших сертификатов.
server_name: этот элемент определяет имя вашего сервера и серверный блок, которые должны использоваться для запросов к вашему серверу. Обязательно замените example.com в этой строке на ваше собственное доменное имя.
index: директива index определяет файлы, которые будут использоваться в качестве индексов при обработке запросов к вашему серверу. Здесь мы изменили порядок приоритета по умолчанию, поставив index.php перед index.html, в результате чего Nginx будет давать приоритет файлам с именем index.php при наличии возможности.
root: наша директива root назначает имя корневой директории для запросов к нашему серверу. Эта директория, /var/www/html, создается в качестве точки монтирования в момент сборки с помощью инструкций в Dockerfile WordPress. Эти инструкции Dockerfile также гарантируют, что файлы релиза WordPress монтируются в этот том.

Блоки расположения:

location ~ /.well-known/acme-challenge: этот блок расположения будет обрабатывать запросы в директории .well-known, где Certbot будет размещать временный файл для подтверждения того, что DNS для нашего домена будет работать с нашим сервером. Настроив данную конфигурацию, мы сможем использовать плагин webroot Certbot для получения сертификатов для нашего домена.
location /: в этом блоке расположения мы будем использовать директиву try_files для проверки файлов, соответствующих отдельным запросам URI. Вместо того, чтобы возвращать по умолчанию статус 404 не найдено, мы будем передавать контроль файлу index.php WordPress с аргументами запроса.
location ~\.php$: этот блок расположения будет обрабатывать PHP-запросы и проксировать эти запросы в наш контейнер wordpress. Поскольку наш образ WordPress Docker будет опираться на образ php:fpm, мы также добавим параметры конфигурации, принадлежащие протоколу FastCGI, в этот блок. Nginx требует наличия независимого процессора PHP для запросов PHP: в нашем случае эти запросы будут обрабатываться процессором php-fpm, который будет включать образ php:fpm. Кроме того, этот блок расположения содержит директивы FastCGI, переменные и опции, которые будут проксировать запросы для приложения WordPress, запущенного в нашем контейнере wordpress, задавать предпочитаемый индекс захваченного URI запроса, а также выполнять парсинг URI-запросов.
location ~ /\.ht: этот блок будет обрабатывать файлы .htaccess, поскольку Nginx не будет обслуживать их. Директива deny_all гарантирует, что файлы .htaccess никогда не будут отображаться для пользователей.
location = /favicon.ico, location = /robots.txt: эти блоки гарантируют, что запросы для /favicon.ico и /robots.txt не будут регистрироваться.
location ~*\ (css|gif|ico|jpeg|jpg|js|png)$: этот блок отключает запись в журнал для запросов статичных активов и гарантирует, что эти активы будут иметь высокую кэшируемость, поскольку обычно их трудно обслуживать.

Дополнительную информацию о проксировании FastCGI см. в статье Понимание и реализация проксирования FastCGI в Nginx. Информацию о серверных блоках и блоках расположения см. в статье Знакомство с сервером Nginx и алгоритмы выбора блоков расположения.

Сохраните и закройте файл после завершения редактирования. Если вы используете nano, нажмите CTRL+X, Y, затем ENTER.

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

`Шаг 2 — Настройка переменных среды`

Контейнеры базы данных и приложения WordPress должны получить доступ к определенным переменным среды в момент выполнения для сохранения данных приложения и предоставления доступа к этим данным для вашего приложения. Эти переменные включают чувствительные и нечувствительные данные: к чувствительным данным относятся root-пароль MySQL и пароль и пользователь базы данных приложения, а к нечувствительным данным относится информация об имени и хосте базы данных приложения.

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

В главной директории проекта ~/wordpress, откройте файл с именем .env:

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

Добавьте в файл следующие имена и значения переменных: Обязательно предоставьте здесь ваши собственные значения для каждой переменной:

~/wordpress/.env

MYSQL_ROOT_PASSWORD=your_root_password
MYSQL_USER=your_wordpress_database_user
MYSQL_PASSWORD=your_wordpress_database_password

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

Сохраните и закройте файл после завершения редактирования.

Поскольку ваш файл .env содержит чувствительную информацию, вы можете убедиться, что в файлы .gitignore и .dockerignore вашего проекта включены инструкции, указывающие Git и Docker, какие файлы не копировать в ваши репозитории Git и образы Docker.

Если вы планируете использовать Git для контроля версий, инициализируйте текущую рабочую директорию в качестве репозитория с помощью git init:

Затем откройте файл .gitignore:

Добавьте .env в файл:

~/wordpress/.gitignore

.env

Сохраните и закройте файл после завершения редактирования.

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

Откройте файл:

Добавьте .env в файл:

~/wordpress/.dockerignore

.env

Ниже вы можете дополнительно добавить файлы и директории, связанные с разработкой вашего приложения:

~/wordpress/.dockerignore

.env
.git
docker-compose.yml
.dockerignore

Сохраните файл и закройте его после завершения.

Теперь, когда все чувствительные данные на месте, вы можете перейти к определению ваших служб в файле docker-compose.yml.

`Шаг 3 — Определение служб с помощью Docker Compose`

Ваш файл docker-compose.yml будет содержать определения службы для вашей настройки. Служба в Compose — это запущенный контейнер, а определения службы содержат информацию о том, как каждый контейнер будет работать.

Используя Compose, вы можете определить различные службы для запуска приложений с несколькими контейнерами, поскольку Compose позволяет привязать эти службы к общим сетям и томам. Это будет полезно для нашей текущей настройки, поскольку мы создадим различные контейнеры для нашей базы данных, приложения WordPress и веб-сервера. Также мы создадим контейнер для запуска клиента Certbot, чтобы получить сертификаты для нашего веб-сервера.

Откройте файл docker-compose.yml:

Добавьте следующий код для определения версии файла Compose и базы данных db:

~/wordpress/docker-compose.yml

version: '3'

services:
  db:
    image: mysql:8.0
    container_name: db
    restart: unless-stopped
    env_file: .env
    environment:
      - MYSQL_DATABASE=wordpress
    volumes:
      - dbdata:/var/lib/mysql
    command: '--default-authentication-plugin=mysql_native_password'
    networks:
      - app-network

Определение службы db включает следующие параметры:

image: данный элемент указывает Compose, какой образ будет загружаться для создания контейнера. Мы закрепим здесь образ mysql:8.0, чтобы избежать будущих конфликтов, так как образ mysql:latest продолжит обновляться. Дополнительную информацию о закреплении версии и предотвращении конфликтов зависимостей см. в документации Docker в разделе Рекомендации по работе с Dockerfile.
container_name: данный элемент указывает имя контейнера.
restart: данный параметр определяет политику перезапуска контейнера. По умолчанию установлено значение no, но мы задали значение, согласно которому контейнер будет перезапускаться, пока не будет остановлен вручную.
env_file: этот параметр указывает Compose, что мы хотим добавить переменные среды из файла с именем .env, расположенного в контексте сборки. В этом случае в качестве контекста сборки используется наша текущая директория.
environment: этот параметр позволяет добавить дополнительные переменные среды, не определенные в файле .env. Мы настроим переменную MYSQL_DATABASE со значением wordpress, которая будет предоставлять имя нашей базы данных приложения. Поскольку эта информация не является чувствительной, мы можем включить ее напрямую в файл docker-compose.yml.
volumes: здесь мы монтируем именованный том с названием dbdata в директорию /var/lib/mysql в контейнере. Это стандартная директория данных в большинстве дистрибутивов.
command: данный параметр указывает команду, которая будет переопределять используемое по умолчанию значение инструкции CMD для образа. В нашем случае мы добавим параметр для стандартной команды mysqld образа Docker, которая запускает сервер MySQL в контейнере. Эта опция --default-authentication-plugin=mysql_native_password устанавливает для системной переменной --default-authentication-plugin значение mysql_native_password, которое указывает, какой механизм аутентификации должен управлять новыми запросами аутентификации для сервера. Поскольку PHP и наш образ WordPress не будут поддерживать новое значение аутентификации MySQL по умолчанию, мы должны внести изменения, чтобы выполнить аутентификацию пользователя базы данных приложения.
networks: данный параметр указывает, что служба приложения будет подключаться к сети app-network, которую мы определим внизу файла.

Затем под определением службы db добавьте определение для вашей службы приложения wordpress:

~/wordpress/docker-compose.yml

...
  wordpress:
    depends_on:
      - db
    image: wordpress:5.1.1-fpm-alpine
    container_name: wordpress
    restart: unless-stopped
    env_file: .env
    environment:
      - WORDPRESS_DB_HOST=db:3306
      - WORDPRESS_DB_USER=$MYSQL_USER
      - WORDPRESS_DB_PASSWORD=$MYSQL_PASSWORD
      - WORDPRESS_DB_NAME=wordpress
    volumes:
      - wordpress:/var/www/html
    networks:
      - app-network

В этом определении службы мы называем наш контейнер и определяем политику перезапуска, как уже делали это для службы db. Также мы добавляем в этот контейнер ряд параметров:

depends_on: этот параметр гарантирует, что наши контейнеры будут запускаться в порядке зависимости, и контейнер wordpress запускается после контейнера db. Наше приложение WordPress зависит от наличия базы данных приложения и пользователя, поэтому установка такого порядка зависимостей позволит выполнять запуск приложения корректно.
image: для этой настройки мы будем использовать образ WordPress 5.11-fpm-alpine. Как было показано в шаге 1, использование этого образа гарантирует, что наше приложение будет иметь процессор php-fpm, который требуется Nginx для обработки PHP. Это еще и образ alpine, полученный из проекта Alpine Linux, который поможет снизить общий размер образа. Дополнительную информацию о преимуществах и недостатках использования образов alpine, а также о том, имеет ли это смысл в случае вашего приложения, см. в полном описании в разделе Варианты образа на странице образа WordPress на Docker Hub.
env_file: и снова мы укажем, что хотим загрузить значения из файла .env, поскольку там мы определили пользователя базы данных приложения и пароль.
environment: здесь мы будем использовать значения, определенные в файле .env, но мы привяжем их к именам переменных, которые требуются для образа WordPress: WORDPRESS_DB_USER и WORDPRESS_DB_PASSWORD. Также мы определяем значение WORDPRESS_DB_HOST, которое будет указывать сервер MySQL, который будет работать в контейнере db, доступный на используемом по умолчанию порту MySQL 3306. Наше значение WORDPRESS_DB_NAME будет тем же, которое мы указали при определении службы MySQL для MYSQL_DATABASE: wordpress.
volumes: мы монтируем том с именем wordpress на точку монтирования /var/www/html, созданную образом WordPress. Использование тома с именем таким образом позволит разделить наш код приложения с другими контейнерами.
networks: мы добавляем контейнер wordpress в сеть app-network.

Далее под определением службы приложения wordpress добавьте следующее определение для службы Nginx webserver:

~/wordpress/docker-compose.yml

...
  webserver:
    depends_on:
      - wordpress
    image: nginx:1.15.12-alpine
    container_name: webserver
    restart: unless-stopped
    ports:
      - "80:80"
    volumes:
      - wordpress:/var/www/html
      - ./nginx-conf:/etc/nginx/conf.d
      - certbot-etc:/etc/letsencrypt
    networks:
      - app-network

Мы снова присвоим имя нашему контейнеру и сделаем его зависимым от контейнера wordpress в отношении порядка запуска. Также мы используем образ alpine — образ Nginx 1.15.12-alpine.

Это определение службы также включает следующие параметры:

ports: этот параметр открывает порт 80, чтобы активировать параметры конфигурации, определенные нами в файле nginx.conf в шаге 1.
volumes: здесь мы определяем комбинацию названных томов и связанных монтируемых образов:wordpress:/var/www/html: этот параметр будет монтировать код нашего приложения WordPress в директорию /var/www/html, директорию, которую мы задали в качестве root-директории в нашем серверном блоке Nginx. ./nginx-conf:/etc/nginx/conf.d: этот элемент будет монтировать директорию конфигурации Nginx на хост в соответствующую директорию в контейнере, гарантируя, что любые изменения, которые мы вносим в файлы на хосте, будут отражены в контейнере. certbot-etc:/etc/letsencrypt: этот элемент будет монтировать соответствующие сертификаты и ключи Let’s Encrypt для нашего домена в соответствующую директорию контейнера.

Здесь мы снова добавили этот контейнер в сеть app-network.

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

~/wordpress/docker-compose.yml

  certbot:
    depends_on:
      - webserver
    image: certbot/certbot
    container_name: certbot
    volumes:
      - certbot-etc:/etc/letsencrypt
      - wordpress:/var/www/html
    command: certonly --webroot --webroot-path=/var/www/html --email [email protected] --agree-tos --no-eff-email --staging -d example.com -d www.example.com

Это определение попросит Compose извлекать образ certbot/certbot из Docker Hub. Также оно использует имена томов для обмена ресурсами с контейнером Nginx, включая доменные сертификаты и ключ в certbot-etc и код приложения в wordpress.

Мы использовали depends_on, чтобы указать, что контейнер certbot следует запускать только после запуска службы webserver.

Также мы включили параметр command, указывающий субкоманду для запуска с используемой контейнером по умолчанию командой certbot. Субкоманда certonly будет получать сертификат со следующими параметрами:

--webroot: данный элемент говорит Certbot о необходимости использования плагина webroot для размещения файлов в папке webroot для аутентификации. Работа плагина основана на методе валидации HTTP-01, который использует запрос HTTP, чтобы доказать, что Certbot может получить доступ к ресурсам с сервера, который отвечает на заданное доменное имя.
--webroot-path: данный элемент указывает путь директории webroot.
--email: предпочитаемый адрес электронной почты для регистрации и восстановления.
--agree-tos: данный элемент указывает, что вы принимаете Соглашение о подписке ACME.
--no-eff-email: данный элемент указывает Certbot, что вы не хотите делиться адресом электронной почты с Electronic Frontier Foundation (EFF). Вы можете пропустить этот элемент.
--staging: данный элемент говорит Certbot, что вы хотите использовать промежуточную среду Let’s Encrypt для получения тестовых сертификатов. При использовании этого параметра вы можете протестировать параметры конфигурации и избежать возможных пределов для запросов домена. Дополнительную информацию об этих предельных значениях см. в документации по ограничениям скорости Let’s Encrypt.
-d: данный элемент позволяет указать доменные имена, которые вы хотите использовать для вашего запроса. В нашем случае мы включили example.com и www.example.com. Обязательно замените эти данные на имя вашего домена.

Под определением службы certbot добавьте определения сети и тома:

~/wordpress/docker-compose.yml

...
volumes:
  certbot-etc:
  wordpress:
  dbdata:

networks:
  app-network:
    driver: bridge

Наш ключ верхнего уровня volumes определяет тома certbot-etc, wordpress и dbdata. Когда Docker создает тома, содержимое тома сохраняется в директории файловой системы хоста, /var/lib/docker/volumes/, а данным процессом управляет Docker. После этого содержимое каждого тома монтируется из этой директории в любой контейнер, использующий том. Таким образом мы можем делиться кодом и данными между контейнерами.

Создаваемая пользователем мостовая система app-network позволяет организовать коммуникацию между нашими контейнерами, поскольку они находятся на одном хосте демона Docker. Это позволяет организовать трафик и коммуникации внутри приложения, поскольку она открывает все порты между контейнерами в одной мостовой сети, скрывая все порты от внешнего мира. Таким образом, наши контейнеры db, wordpress и webserver могут взаимодействовать друг с другом, и нам нужно будет только открыть порт 80 для внешнего доступа к приложению.

Итоговый файл docker-compose.yml будет выглядеть примерно так:

~/wordpress/docker-compose.yml

version: '3'

services:
  db:
    image: mysql:8.0
    container_name: db
    restart: unless-stopped
    env_file: .env
    environment:
      - MYSQL_DATABASE=wordpress
    volumes:
      - dbdata:/var/lib/mysql
    command: '--default-authentication-plugin=mysql_native_password'
    networks:
      - app-network

  wordpress:
    depends_on:
      - db
    image: wordpress:5.1.1-fpm-alpine
    container_name: wordpress
    restart: unless-stopped
    env_file: .env
    environment:
      - WORDPRESS_DB_HOST=db:3306
      - WORDPRESS_DB_USER=$MYSQL_USER
      - WORDPRESS_DB_PASSWORD=$MYSQL_PASSWORD
      - WORDPRESS_DB_NAME=wordpress
    volumes:
      - wordpress:/var/www/html
    networks:
      - app-network

  webserver:
    depends_on:
      - wordpress
    image: nginx:1.15.12-alpine
    container_name: webserver
    restart: unless-stopped
    ports:
      - "80:80"
    volumes:
      - wordpress:/var/www/html
      - ./nginx-conf:/etc/nginx/conf.d
      - certbot-etc:/etc/letsencrypt
    networks:
      - app-network

  certbot:
    depends_on:
      - webserver
    image: certbot/certbot
    container_name: certbot
    volumes:
      - certbot-etc:/etc/letsencrypt
      - wordpress:/var/www/html
    command: certonly --webroot --webroot-path=/var/www/html --email [email protected] --agree-tos --no-eff-email --staging -d example.com -d www.example.com

volumes:
  certbot-etc:
  wordpress:
  dbdata:

networks:
  app-network:
    driver: bridge

Сохраните и закройте файл после завершения редактирования.

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

`Шаг 4 — Получение сертификатов SSL и учетных данных`

Мы можем запустить наши контейнеры с помощью команды docker-compose up, которая будет создавать и запускать наши контейнеры и службы в указанном нами порядке. Если наши запросы доменов будут выполнены успешно, мы увидим корректный статус выхода в нашем выводе и нужные сертификаты, установленные в папке /etc/letsencrypt/live на контейнере webserver.

Создайте контейнеры с помощью команды docker-compose up и флага -d, которые будут запускать контейнеры db, wordpress и webserver в фоновом режиме:

Вы увидите вывод, подтверждающий, что ваши службы были успешно созданы:

OutputCreating db ... done
Creating wordpress ... done
Creating webserver ... done
Creating certbot   ... done

С помощью docker-compose ps проверьте статус ваших служб:

Если все будет выполнено успешно, ваши службы db, wordpress и webserver должны иметь статус Up, а работа контейнера certbot будет завершена с сообщением о статусе 0:

Output  Name                 Command               State           Ports       
-------------------------------------------------------------------------
certbot     certbot certonly --webroot ...   Exit 0                      
db          docker-entrypoint.sh --def ...   Up       3306/tcp, 33060/tcp
webserver   nginx -g daemon off;             Up       0.0.0.0:80->80/tcp
wordpress   docker-entrypoint.sh php-fpm     Up       9000/tcp

Если вы увидите любое значение, кроме Up в столбце State для служб db, wordpress и webserver, или любое сообщение о статусе выхода, отличающееся от 0, для контейнера certbot, проверьте журналы службы с помощью команды docker-compose logs:

docker-compose logs service_name

Теперь вы можете убедиться, что ваши сертификаты были смонтированы в контейнер webserver с помощью команды docker-compose exec:

docker-compose exec webserver ls -la /etc/letsencrypt/live

Если запросы сертификата были выполнены успешно, вы увидите следующий результат:

Outputtotal 16
drwx------    3 root     root          4096 May 10 15:45 .
drwxr-xr-x    9 root     root          4096 May 10 15:45 ..
-rw-r--r--    1 root     root           740 May 10 15:45 README
drwxr-xr-x    2 root     root          4096 May 10 15:45 example.com

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

Откройте docker-compose.yml:

Найдите раздел файла с определением службы certbot и замените флаг --staging в параметрах command на флаг --force-renewal, который будет указывать Certbot, что вы хотите запросить новый сертификат с теми же доменами, что и в уже существующем сертификате. Определение службы certbot должно будет выглядеть следующим образом:

~/wordpress/docker-compose.yml

...
  certbot:
    depends_on:
      - webserver
    image: certbot/certbot
    container_name: certbot
    volumes:
      - certbot-etc:/etc/letsencrypt
      - certbot-var:/var/lib/letsencrypt
      - wordpress:/var/www/html
    command: certonly --webroot --webroot-path=/var/www/html --email [email protected] --agree-tos --no-eff-email --force-renewal -d example.com -d www.example.com
...

Теперь вы можете запустить команду docker-compose up для воссоздания контейнера certbot. Также мы будем использовать параметр --no-deps, чтобы сообщить Compose о том, что можно пропустить запуск службы webserver, поскольку она уже запущена:

docker-compose up --force-recreate --no-deps certbot

Вы увидите вывод, указывающий, что запрос сертификата выполнен успешно:

OutputRecreating certbot ... done
Attaching to certbot
certbot      | Saving debug log to /var/log/letsencrypt/letsencrypt.log
certbot      | Plugins selected: Authenticator webroot, Installer None
certbot      | Renewing an existing certificate
certbot      | Performing the following challenges:
certbot      | http-01 challenge for example.com
certbot      | http-01 challenge for www.example.com
certbot      | Using the webroot path /var/www/html for all unmatched domains.
certbot      | Waiting for verification...
certbot      | Cleaning up challenges
certbot      | IMPORTANT NOTES:
certbot      |  - Congratulations! Your certificate and chain have been saved at:
certbot      |    /etc/letsencrypt/live/example.com/fullchain.pem
certbot      |    Your key file has been saved at:
certbot      |    /etc/letsencrypt/live/example.com/privkey.pem
certbot      |    Your cert will expire on 2019-08-08. To obtain a new or tweaked
certbot      |    version of this certificate in the future, simply run certbot
certbot      |    again. To non-interactively renew *all* of your certificates, run
certbot      |    "certbot renew"
certbot      |  - Your account credentials have been saved in your Certbot
certbot      |    configuration directory at /etc/letsencrypt. You should make a
certbot      |    secure backup of this folder now. This configuration directory will
certbot      |    also contain certificates and private keys obtained by Certbot so
certbot      |    making regular backups of this folder is ideal.
certbot      |  - If you like Certbot, please consider supporting our work by:
certbot      |
certbot      |    Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
certbot      |    Donating to EFF:                    https://eff.org/donate-le
certbot      |
certbot exited with code 0

После добавления ваших сертификатов вы можете перейти к изменению конфигурации Nginx для использования SSL.

`Шаг 5 — Изменение конфигурации веб-сервера и определения службы`

Активация SSL в нашей конфигурации Nginx будет включать организацию перенаправления HTTP на HTTPS, указание расположения сертификата и ключей SSL и добавление параметров безопасности и заголовков.

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

docker-compose stop webserver

Прежде чем мы самостоятельно изменим файл конфигурации, нам нужно предварительно получить рекомендуемые параметры безопасности Nginx от Certbot с помощью curl:

curl -sSLo nginx-conf/options-ssl-nginx.conf https://raw.githubusercontent.com/certbot/certbot/master/certbot-nginx/certbot_nginx/_internal/tls_configs/options-ssl-nginx.conf

Данная команда будет сохранять эти параметры в файле с именем options-ssl-nginx.conf, расположенном в директории nginx-conf.

Затем удалите ранее созданный файл конфигурации Nginx:

Откройте другую версию файла:

nano nginx-conf/nginx.conf

Добавьте следующий код в файл для перенаправления HTTP на HTTPS и добавления учетных данных, протоколов и заголовков безопасности SSL. Обязательно замените example.com на ваше доменное имя:

~/wordpress/nginx-conf/nginx.conf

server {
        listen 80;
        listen [::]:80;

        server_name example.com www.example.com;

        location ~ /.well-known/acme-challenge {
                allow all;
                root /var/www/html;
        }

        location / {
                rewrite ^ https://$host$request_uri? permanent;
        }
}

server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;
        server_name example.com www.example.com;

        index index.php index.html index.htm;

        root /var/www/html;

        server_tokens off;

        ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

        include /etc/nginx/conf.d/options-ssl-nginx.conf;

        add_header X-Frame-Options "SAMEORIGIN" always;
        add_header X-XSS-Protection "1; mode=block" always;
        add_header X-Content-Type-Options "nosniff" always;
        add_header Referrer-Policy "no-referrer-when-downgrade" always;
        add_header Content-Security-Policy "default-src * data: 'unsafe-eval' 'unsafe-inline'" always;
        # add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
        # enable strict transport security only if you understand the implications

        location / {
                try_files $uri $uri/ /index.php$is_args$args;
        }

        location ~ \.php$ {
                try_files $uri =404;
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass wordpress:9000;
                fastcgi_index index.php;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PATH_INFO $fastcgi_path_info;
        }

        location ~ /\.ht {
                deny all;
        }

        location = /favicon.ico {
                log_not_found off; access_log off;
        }
        location = /robots.txt {
                log_not_found off; access_log off; allow all;
        }
        location ~* \.(css|gif|ico|jpeg|jpg|js|png)$ {
                expires max;
                log_not_found off;
        }
}

Блок сервера HTTP указывает webroot для запросов обновления Certbot в директории .well-known/acme-challenge. Также он содержит директиву перезаписи, которая перенаправляет запросы HTTP в корневую директорию HTTPS.

Блок сервера HTTPS активирует ssl и http2. Дополнительную информацию о том, как выполняется итерация HTTP/2 в протоколах HTTP и какие преимущества это может дать для повышения производительности веб-сайта, см. во вводной части руководства по настройке Nginx с поддержкой HTTP/2 в Ubuntu 18.04.

Этот блок также включает расположение наших сертификата SSL и ключа, а также рекомендованные параметры безопасности Certbot, которые мы сохранили в nginx-conf/options-ssl-nginx.conf.

Кроме того, мы включили ряд заголовков безопасности, которые позволят нам получить оценки A на сайтах серверных тестов SSL Labs и Security Headers. Эти заголовки включают X-Frame-Options, X-Content-Type-Options, Referrer Policy, Content-Security-Policy и X-XSS-Protection. Заголовок HTTP Strict Transport Security (Строгая безопасность передачи информации по протоколу HTTP) закомментирован, активируйте этот элемент, только если вы понимаете возможные последствия и оценили его «предварительно загруженный» функционал.

Наши директивы root и index также расположены в этом блоке, равно как и остальные блоки расположения WordPress, описанные в шаге 1.

После завершения редактирования сохраните и закройте файл.

Перед повторным созданием службы webserver вам потребуется добавить распределение порта 443 в определение службы webserver.

Откройте ваш файл docker-compose.yml:

В определении службы webserver добавьте следующее распределение порта:

~/wordpress/docker-compose.yml

...
  webserver:
    depends_on:
      - wordpress
    image: nginx:1.15.12-alpine
    container_name: webserver
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - wordpress:/var/www/html
      - ./nginx-conf:/etc/nginx/conf.d
      - certbot-etc:/etc/letsencrypt
    networks:
      - app-network

Файл docker-compose.yml будет выглядеть следующим образом после завершения настройки:

~/wordpress/docker-compose.yml

version: '3'

services:
  db:
    image: mysql:8.0
    container_name: db
    restart: unless-stopped
    env_file: .env
    environment:
      - MYSQL_DATABASE=wordpress
    volumes:
      - dbdata:/var/lib/mysql
    command: '--default-authentication-plugin=mysql_native_password'
    networks:
      - app-network

  wordpress:
    depends_on:
      - db
    image: wordpress:5.1.1-fpm-alpine
    container_name: wordpress
    restart: unless-stopped
    env_file: .env
    environment:
      - WORDPRESS_DB_HOST=db:3306
      - WORDPRESS_DB_USER=$MYSQL_USER
      - WORDPRESS_DB_PASSWORD=$MYSQL_PASSWORD
      - WORDPRESS_DB_NAME=wordpress
    volumes:
      - wordpress:/var/www/html
    networks:
      - app-network

  webserver:
    depends_on:
      - wordpress
    image: nginx:1.15.12-alpine
    container_name: webserver
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - wordpress:/var/www/html
      - ./nginx-conf:/etc/nginx/conf.d
      - certbot-etc:/etc/letsencrypt
    networks:
      - app-network

  certbot:
    depends_on:
      - webserver
    image: certbot/certbot
    container_name: certbot
    volumes:
      - certbot-etc:/etc/letsencrypt
      - wordpress:/var/www/html
    command: certonly --webroot --webroot-path=/var/www/html --email [email protected] --agree-tos --no-eff-email --force-renewal -d example.com -d www.example.com

volumes:
  certbot-etc:
  wordpress:
  dbdata:

networks:
  app-network:
    driver: bridge

Сохраните и закройте файл после завершения редактирования.

Повторно создайте службу webserver:

docker-compose up -d --force-recreate --no-deps webserver

Проверьте ваши службы с помощью команды docker-compose ps:

Вы должны получить результат, указывающий, что ваши службы db, wordpress и webserver запущены:

Output  Name                 Command               State                     Ports                  
----------------------------------------------------------------------------------------------
certbot     certbot certonly --webroot ...   Exit 0                                           
db          docker-entrypoint.sh --def ...   Up       3306/tcp, 33060/tcp                     
webserver   nginx -g daemon off;             Up       0.0.0.0:443->443/tcp, 0.0.0.0:80->80/tcp
wordpress   docker-entrypoint.sh php-fpm     Up       9000/tcp

После запуска ваших контейнеров вы можете завершить процесс установки WordPress через веб-интерфейс.

`Шаг 6 — Завершение установки через веб-интерфейс`

После запуска контейнеров мы можем завершить установку через веб-интерфейс WordPress.

В браузере перейдите на домен вашего сервера. Не забудьте заменить здесь example.com на ваше доменное имя:

https://example.com

Выберите язык, который вы хотите использовать:

После нажатия Continue (Продолжить) вы перейдете на главную страницу настройки, где вам нужно будет выбрать имя вашего сайта и пользователя. Рекомендуется выбрать запоминающееся имя пользователя (не просто «admin») и надежный пароль. Вы можете использовать пароль, который генерирует WordPress автоматически, или задать собственный пароль.

Наконец, вам нужно будет ввести ваш адрес электронной почты и указать, хотите ли вы, чтобы движки поисковых систем могли индексировать ваш сайт:

После нажатия Install WordPress (Установить WordPress) внизу страницы на экране появится запрос выполнения входа:

После входа вы получите доступ к панели управления WordPress:

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

`Шаг 7 — Обновление сертификатов`

Сертификаты Let’s Encrypt действительны в течение 90 дней, поэтому вам нужно будет настроить автоматический процесс обновления, чтобы гарантировать, что сертификаты не окажутся просроченными. Один из способов — создание задания с помощью утилиты планирования cron. В нашем случае мы настроим задание для cron с помощью скрипта, который будет обновлять наши сертификаты и перезагружать конфигурацию Nginx.

Откройте скрипт под названием ssl_renew.sh:

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

~/wordpress/ssl_renew.sh

#!/bin/bash

COMPOSE="/usr/local/bin/docker-compose --no-ansi"
DOCKER="/usr/bin/docker"

cd /home/sammy/wordpress/
$COMPOSE run certbot renew --dry-run && $COMPOSE kill -s SIGHUP webserver
$DOCKER system prune -af

Данный скрипт привязывает двоичный код docker-compose для переменной COMPOSE и задает параметр --no-ansi, который запускает команды docker-compose без управляющих символов ANSI. Затем он делает то же самое с двоичным файлом docker. В заключение он меняет директорию проекта на ~/wordpress и запускает следующие команды docker-compose:

docker-compose run: данный параметр запускает контейнер certbot и переопределяет параметр command, указанный в определении службы certbot. Вместо использования субкоманды certonly мы используем здесь субкоманду renew, которая будет обновлять сертификаты, срок действия которых близок к окончанию. Мы включили параметр --dry-run, чтобы протестировать наш скрипт.
docker-compose kill: данный параметр отправляет сигнал SIGHUP контейнеру webserver для перезагрузки конфигурации Nginx. Дополнительную информацию об использовании этого процесса для перезагрузки конфигурации Nginx см. в этой публикации блога Docker, посвященной развертыванию официального образа Nginx с помощью Docker.

После этого он выполняет команду docker system prune для удаления всех неиспользуемых контейнеров и образов.

Закройте файл после завершения редактирования. Сделайте его исполняемым:

Далее откройте root-файл crontab для запуска скрипта обновления с заданным интервалом:

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

Outputno crontab for root - using an empty one

Select an editor.  To change later, run 'select-editor'.
  1. /bin/nano        <---- easiest
  2. /usr/bin/vim.basic
  3. /usr/bin/vim.tiny
  4. /bin/ed

Choose 1-4 [1]:
...

Добавьте внизу файла следующую строку:

crontab

...
*/5 * * * * /home/sammy/wordpress/ssl_renew.sh >> /var/log/cron.log 2>&1

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

Через 5 минут проверьте cron.log, чтобы убедиться, что запрос обновления выполнен успешно:

tail -f /var/log/cron.log

Вы должны увидеть вывод, подтверждающий успешное обновление:

Output- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/example.com/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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

crontab

...
0 12 * * * /home/sammy/wordpress/ssl_renew.sh >> /var/log/cron.log 2>&1

Также вы можете изменить параметр --dry-run из скрипта ssl_renew.sh:

~/wordpress/ssl_renew.sh

#!/bin/bash

COMPOSE="/usr/local/bin/docker-compose --no-ansi"
DOCKER="/usr/bin/docker"

cd /home/sammy/wordpress/
$COMPOSE run certbot renew && $COMPOSE kill -s SIGHUP webserver
$DOCKER system prune -af

Ваше задание cron гарантирует, что ваши сертификаты Let’s Encrypt не окажутся устаревшими, обновляя их в случае истечения срока действия. Также вы можете настроить замену журнала с помощью утилиты Logrotate, которая будет выполнять ротацию и сжатие файлов журнала.

`Заключение`

В этом руководстве вы использовали Docker Compose для создания установки WordPress с веб-сервером Nginx. В рамках этого рабочего процесса вы получили сертификаты TLS/SSL для домена, который вы хотите подключить к вашему сайту WordPress. Кроме того, вы создали задание cron для обновления этих сертификатов при необходимости.

В качестве дополнительных мер по повышению производительности сайта и создания запаса мощности, вы можете ознакомиться со следующими статьями, посвященными передаче и поддержке активов WordPress:

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

`Где найти файлы WordPress: .htaccess; robots.txt; php.ini?`

Несмотря на простоту использования и понятный интерфейс WordPress, иногда возникают определенного рода вопросы. Одним из таких является: “Где найти тот или иной файл?”. В данном посте попробуем отыскать несколько замаскировавшихся системных файлов, нужных для обеспечения слаженной работы сайта созданного с помощью шаблона WordPress.

`Что такое .htaccess в WordPress?`

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

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

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

Откройте любой текстовый редактор (Notepad++ или простой Блокнот).
В меню Файл выберите Сохранить как.
В списке Тип файла выберите Все файлы.
Присвойте имя .htaccess.
Сохраните.

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

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

Для UTF-8:

AddDefaultCharset UTF-8

Для windows-1251:

AddDefaultCharset CP1251

6. Поместите .htaccess файл в корень сайта, где находится файл index (обычно он называется index.html или index.php).

`Где лежит файл robots.txt в WordPress?`

Этот текстовый файл, находится в корневой папке сайта, в который записываются для поисковых роботов особые инструкции. Именно поэтому при входе на сайт, любой поисковой робот сразу ищет robots.txt файл.

Как и предыдущий текстовый системный файл, robots.txt может быть и не создан.

Как узнать существует ли robots.txt файл?

Чтоб проверить наличие файла robots.txt, впишите в строке браузера ваш сайт.ru/robots.txt, если откроется документ, и появится текст, например:

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

Где на сервере лежит WordPress файл robots.txt?

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

В данной корневой папке, размещаются все имеющиеся файлы вашего сайта:

Где находится файл php.ini в WordPress?

Чтоб в WordPress найти php.ini файл, позволяющий изменять размер импортируемых данных, нужно создать файл info.php и присвоить ему любое имя.

В этот файл вставляете:

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

Открываете страницу сайта и вводите в адресной строке:

http://ваш_сайт.ru/1.php.

После этого появится php конфигурация, а также данные про скрытый файл php.ini. Точный путь к файлу указан в строчке Loaded Configuration File.

Вывод

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

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

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

Иерархия шаблонов

`: путают с index.php, front-page.php, home.php`

Логика главной страницы — одна из самых запутанных функций WordPress, которую чрезвычайно сложно объяснить и резюмировать. Как упоминалось в комментарии, в то время как назад я потратил нечестивое количество времени, чтобы собрать мою шпаргалку по логике на первой странице.

Но поскольку это популярная ветка, позвольте мне попытаться ответить на те очень конкретные вопросы, которые у вас возникли.

Чем отличается дом .php и index.php ?

home.php — шаблон для индекса постов (архив собственного типа постов, который является частным случаем в WP). WP попытается найти в нем индекс сообщений, независимо от того, отображаются ли они в корне сайта или на специальной странице сообщений.

index.php — универсальный шаблон. Это окончательный выбор во всех ветвях иерархии шаблонов, и он будет выбран, когда больше ничего не подходит, как для архивов, так и для отдельных представлений.

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

Каковы идеальные условия для использования home.php , чем index.php

Вы используете home.php для настройки индекса сообщений.

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

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

Каковы идеальные условия для использования front-page.php ?

front-page.php используется для индекса сообщений на корневой или статической главной странице, если он включен.

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

Лучше всего использовать его в частных проектах, так как его проще настроить, чем шаблон страницы.

Когда я использую front-page.php , тогда какую конкретную задачу за меня выполняет index.php ?

index.php — это по-прежнему — шаблон для всех остальных случаев.

Если вы используете статическую главную страницу (к которой будет применяться front-page.php ), то ваша страница сообщений попытается использовать home.php , а затем index.php .

`Как удалить index.php из постоянной ссылки в WordPress`

После успешной миграции вашего сайта WordPress на другой сервер первое, что вам нужно сделать, это ввести настройки постоянных ссылок и удалить index.php из постоянной ссылки в WordPress. Наличие index.php в постоянной ссылке часто может привести к ошибке 404 пропущенной страницы и нарушению удобных для пользователя URL-адресов.

Поскольку вы, вероятно, импортировали базу данных, есть большая вероятность, что вы увидите «index.php ’уже встроен в вашу структуру URL. Если вы хотите удалить index.php из постоянной ссылки, вот что вы можете сделать:

`Удаление index.php из постоянной ссылки WordPress`

Выполните следующие 3 простых шага —

Шаг 1. Убедитесь, что на вашем сервере включен mod_rewrite.

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

В cPanel Mod_Rewrite по умолчанию компилируется с Apache. Например.

  root @ server [~] # httpd -l | grep rewrite
  mod_rewrite.c

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

Добавьте в этот файл следующий код.

После этого создайте файл.. * $ mod_rewrite.php

Зайдите на ваш сайт. Если вы видите сообщение типа «Mod_rewrite активирован», значит, он включен на вашем сервере. Если вы обнаружите что-нибудь еще, например «mod_rewrite is disable», обязательно удалите файл .htaccess, который вы создали ранее, и переименуйте исходный файл в «.htaccess».

Шаг 2. Установите структуру постоянной ссылки

Теперь перейдите в Панель управления -> Настройки -> Постоянные ссылки , затем выберите опцию «Пользовательская структура» и введите /% postname%.index \ .php $ — [L] RewriteCond% {REQUEST_FILENAME}! -F RewriteCond% {REQUEST_FILENAME}! -D RewriteRule. /index.php [L] # КОНЕЦ WordPress

Этого будет достаточно, чтобы удалить index.php из постоянной ссылки на сайте WordPress.

Дополнительные известные проблемы, которые могут возникнуть

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

  
SecFilterEngine Off

Последние слова

Еще одна вещь, проверьте конфигурационный файл для Apache, который также может переопределять ваши директивы .htaccess. Найдите файл Ubuntu default /etc/apache2/apache2.conf и измените запись для / и / var / www с AllowOverride None на AllowOverride All.После этого перезапустите сервер apache и, надеюсь, это решит и эту проблему.

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

Что означает этот комментарий WordPress?

Если вы когда-либо использовали файловый менеджер для изучения своего сайта WordPress, возможно, вы нашли что-то, что вас удивило, в каталоге, например / wp-content. Взглянув на файлы вашего сайта, вы обнаружили индекс .php файл, содержащий только:

// Молчание - золото.

Это свидетельство злонамеренного взлома? Ваш сайт был взломан? Этот небольшой фрагмент кода сейчас ставит под угрозу безопасность вашего сайта? Не волнуйтесь, это на самом деле помогает защитить ваш сайт - "код" просто не очень хорошо объясняет себя. Давайте рассмотрим подробнее.

`Файлы PHP и каталоги веб-сайтов`

PHP - чрезвычайно популярный язык программирования.Сайты, темы и плагины WordPress созданы с использованием PHP. Если вы хотите, вы можете думать обо всей системе управления контентом (CMS) WordPress как о тщательно продуманной структуре CMS. В то время как веб-разработчики ежедневно работают напрямую с файлами PHP, многим пользователям WordPress нужно открывать файлы PHP только при попытке решить проблему.

`Изучение файла`

Давайте еще раз взглянем на этот файл index.php .

// Молчание - золото.

Первая строка представляет собой начальную точку файла PHP. Все файлы PHP будут содержать где-то внутри файла - обычно в начале. Вторая строка - это комментарий . Компьютеры всегда игнорируют комментарии; программисты добавляют комментарии, чтобы помочь людям, читающим эти файлы, понять их. Комментарии PHP создаются с помощью двух слэшей в начале строки: // .

Комментарии должны быть полезными. Хорошие комментарии объясняют, что происходит в программе и почему вообще существует код.Это не лучший комментарий: он ничего не объясняет о том, что происходит!

`Но в чем смысл?`

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

Зачем нужен пустой файл? Разработчики помещают пустой index.php в такие каталоги, как / wp-content, чтобы ограничить доступ к каталогам и файлам вашего сайта. Без index.php любой может просто зайти в папку / wp-content вашего сайта и увидеть все медиафайлы, файлы и каталоги, которые она содержит. Вы, вероятно, сталкивались с этим раньше на неработающих или очень старых сайтах. Файл index.php работает как экран конфиденциальности: он блокирует прямой доступ посетителей к вашим каталогам.Это небольшая, но жизненно важная часть безопасности WordPress!

Связанные

`Разница между home.php и front-page.php в WordPress`

Разным веб-сайтам нужны разные файлы для вызова нужных им функций и отображения контента для посетителей. Вот почему вам нужно знать разницу между home.php и front-page.php.

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

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

WordPress - самая популярная в мире система управления контентом (CMS), которая представляет собой платформу, которая помогает владельцам бизнеса публиковать и поддерживать веб-сайты в Интернете.

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

Вот все, что вы узнаете из этой статьи:

Вы готовы?

Что такое файлы home.php и front-page.php?

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

То же самое с home.php и front-page.php. Эти два файла присутствуют в вашей установке WordPress и служат схожим, но разным целям.

Вот почему вы должны знать разницу между home.php и front-page.php в WordPress. Их неправильное использование может повлиять на производительность вашего сайта, привести к поломке страниц и ухудшить взаимодействие с пользователем.

Как и большинство других шаблонных php-файлов WordPress, home.php и front-page.php обычно находятся внутри папки wp-content в каталоге темы. Если они присутствуют, вы сможете найти их с помощью браузера файлов FTP хостинга WordPress.

Что такое иерархия шаблонов?

Чтобы шаблон правильно работал с WordPress, он должен следовать соответствующей иерархии среди своих файлов и функций.

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

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

В случае, если выбран вариант «последние сообщения», WordPress сначала будет искать файл front-page.php. Если он не найден, он попытается отобразить home.php. Если не удается найти ни front-page.php, ни home.php, то будет использоваться index.php.

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

На изображении ниже вы можете увидеть всю иерархию шаблонов WordPress, включая все файлы:

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

В чем разница между home.php и front-page.php?

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

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

Файл front-page.php относится к функции, которая позже была добавлена в WordPress. По мере того, как он перерос свою ориентацию на ведение блогов, пользователям понадобился способ отображения статической настраиваемой страницы в качестве индекса вместо списка последних публикаций.

Чтобы понять разницу между home.php и front-page.php, вам следует подумать, когда следует использовать каждый файл. См. Ниже:

Последние сообщения на главной странице

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

В этом случае файл home.php используется для вызова и отображения ваших последних сообщений в активном макете шаблона. Следуя иерархии шаблонов, если WordPress не найдет home.php, он вернется к front-page.php, а затем к index.php, если это необходимо.

Статическая страница в качестве первой

Если ваш веб-сайт не является блогом или вы хотите отображать определенную страницу в качестве первой части контента, которую видят ваши посетители, вам необходимо выбрать эту опцию. Любую страницу, созданную в WordPress, можно сделать главной.

Когда эта опция активна, WordPress по умолчанию использует front-page.php. Затем этот файл вызовет выбранную главную страницу и отобразит ее.

Почему разница?

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

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

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

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

Конечно, бывают случаи, когда вы загружаете и устанавливаете шаблон, который не содержит в своем каталоге ни home.php, ни front-page.php. В этом случае иерархия шаблонов будет использоваться WordPress для поиска нужного контента для отображения в качестве домашней страницы.

Узнав разницу между home.php и front-page.php в WordPress , вы сможете работать с этими инструментами, чтобы отображать то, что вы хотите, на главной странице вашего веб-сайта.

Поскольку не все используют WordPress для поддержки блогов, такая гибкость доступна благодаря файлам типа home.php и front-page.php. В следующий раз, когда вы будете иметь дело с этими файлами, следите за своими конфигурациями и их поведением.

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

`Как исправить загрузку WordPress Index.php вместо отображения сайта 2021`

«WordPress загружает сжатый файл вместо открытия index.php или когда я пытаюсь получить доступ к своему wp-admin».

Этот вопрос задал нам один из наших читателей, и он хотел знать, как его решить.

Поскольку я понятия не имею, как это происходило, я отложил этот вопрос в своем списке вопросов, пока это не произошло с моим блогом. Так что это меня напугало, так как я потерял доступ к своему wp-admin, хотя у меня есть ежедневная резервная копия моего блога. Но это не лучший вариант для восстановления моего блога, так как это длинный список работы, которую нужно сделать, а что касается других, у них нет ежедневной резервной копии.

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

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

Насколько я знаю, я попробовал:

Переименование моей темы в old- [name-of-theme]
Переименование папки плагинов в старые плагины (чтобы отключить их все)
Очистка кеша для Firefox, Safari и Chrome.

Ничего не заработало. Я погуглил и нашел ответы вроде

удалить приложение AddHandler / x-httpd-php52 .php .php5 .php4 .php3

Не знаю, как это туда попало! Но я нашел свое решение.

`Метод исправления загрузки WordPress Index.php`

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

Если по какой-либо причине вы не можете найти .htaccess в корневом каталоге установки WordPress, нажмите «Диспетчер файлов», обязательно отметьте «Показать скрытые файлы (точечные файлы)» и нажмите «Перейти». .htaccess должен появиться там, где установлен wp (wp-admin, wp-content, wp-includes), то есть корневой каталог WordPress.

Я изучил код и обнаружил, что некоторые лишние строки кода возятся с моим WordPress. Я удалил лишний код, и он начал работать.(. +) $ 1 / [R = 301, L]

# КОНЕЦ WordPress

Надеюсь, это кому-то поможет, и хорошего дня !!!

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

`Заключение`

Причина, по которой загружается ваш index.php, связана с тем, что ваш плагин или функция кеширования на вашем хосте добавляет несколько строк кода, которые делают ваш WordPress быстрым, поскольку он сжимает файл, но в некоторых случаях также кэшируется wp-admin, который делает невозможным доступ.

Так что просто отредактируйте свой .htaccess и вставьте приведенный выше код, и ваш блог снова готов к работе

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

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

`Что большинство веб-дизайнеров ошибается в иерархии тем WordPress`

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

Но вот и хорошие новости: За путаницей скрывается логическая система. Если вы готовы засучить рукава и немного изучить PHP, вы, , можете, , превратить ваши статические HTML-проекты в динамические веб-сайты WordPress.

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

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

`Самый большой секрет разработки тем WordPress`

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

Что, если бы я сказал вам, что вы можете создать простую тему WordPress всего из двух файлов?

Это два файла: index.php и style.css . В конечном итоге они не будут всем, что вам нужно, , но они все, что вам нужно.

Если вы уже создали статический дизайн с файлом index.html и style.css , вы можете буквально скопировать и вставить содержимое каждого в новый файл index.php и style.css , добавьте немного дополнительной информации, заархивируйте файлы в папку и загрузите их в WordPress. Привет, ваша первая тема WordPress!

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

.

 

    
        
        <название>
            Моя первая тема WordPress
        
    
    
         Привет, мир!

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

Что касается вашего файла style.css , для работы ему нужно только одно: заголовок таблицы стилей . Он состоит из нескольких частей информации, которые позволяют WordPress идентифицировать вашу тему.

Вот простой пример, который нужно вставить как комментарий в вашем стиле .css файл:

 / *

Название темы: Моя первая тема WordPress
Автор: Мое имя
Описание: Моя первая тема WordPress!
Версия: 1.0

* /

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

Название темы.
URI темы. Если у вашей темы есть домашняя страница, вы можете добавить ее сюда.
Автор. Не стесняйся!
URI автора. Если у вас есть личный веб-сайт или веб-сайт с портфолио, вы можете сделать ссылку на него здесь.
Описание.
Версия.
Лицензия. Щелкните здесь, чтобы узнать больше о лицензировании WordPress.
URI лицензии. Рекомендуется добавить обратную ссылку на лицензию, которую вы выбираете для своей темы.
Теги. Эти теги используются в WordPress.org для фильтрации вашей темы по определенным характеристикам (например,г. «Один столбец», «настраиваемый заголовок»).
Текстовый домен. Используется для целей интернационализации / перевода.

(Обратите внимание, что имя вашей темы должно быть уникальным. Если вы выберете имя, которое уже существует, вы создадите конфликт в WordPress.)

Сохраните файл index.php и style.css в папку и присвойте ему уникальное имя. Используйте дефисы вместо пробелов. Как только вы закончите, заархивируйте файл.

Затем перейдите к Внешний вид> Темы в вашей установке WordPress и нажмите кнопку Добавить новый .На открывшемся экране вы можете загрузить и активировать новую тему.

Как только вы это сделаете, перейдите на свою домашнюю страницу, и вы увидите свою самую первую тему WordPress:

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

Конечно, на данном этапе о вашей теме особо нечего писать, но приведенный выше пример демонстрирует, насколько простым может быть дизайн темы WordPress.

Он также раскрывает тот большой секрет, о котором я упоминал выше: index.php не просто представляет домашнюю страницу вашего сайта (хотя может) - это основа для всего в дизайне темы WordPress .

`Знакомство с`

index.php и иерархией шаблонов тем WordPress

Вам будет простительно предположить, что index.php предназначен для использования в качестве домашней страницы вашего веб-сайта WordPress. Ну это не так. Это гораздо важнее.

Выше я сказал, что вы можете создать тему WordPress только с двумя файлами, один из которых - index.php . Ну, я имел в виду, что в каждый смысл - не только с точки зрения создания простого «Hello World!» пример.

Видите ли, иерархия шаблонов тем WordPress работает таким образом, что, если более конкретного файла шаблона не существует, по умолчанию он возвращается к следующему наиболее «старшему» файлу. И угадайте, какой файл самый старший; что в конечном итоге использует WordPress по умолчанию? Правильно: индекс .php .

Чтобы вы лучше понимали, что я имею в виду, вот визуальное представление иерархии шаблонов тем WordPress:

Как видите, существует огромное количество файлов шаблонов, которые можно использовать для создания темы WordPress - все, от одной страницы сообщения в блоге ( single-post.php ) до страницы с ошибкой 404 ( 404 .php ). Но самое главное: , если WordPress не находит самый конкретный файл, по умолчанию возвращается следующий по старшинству файл .

В конечном итоге это ведет к index.php : папочка файлов шаблонов тем WordPress.

Итак, index.php вообще не является домашней страницей - в идеале WordPress сначала будет искать для этой цели front-page.php , или впоследствии home.php . Index.php - последнее средство.

`Куда вы идете дальше?`

В этой статье мы коснулись лишь поверхности разработки тем WordPress, но теперь вы должны знать, что каждый файл шаблона в теме WordPress относится к определенному типу страницы, которую вы увидите во внешнем интерфейсе.Например, отдельная запись в блоге наиболее конкретно представлена single-post.php , затем single.php , затем index.php .

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

Как только вы это поймете, вы можете начать с простой позиции (например, index.php ) и оттуда реализовать свой дизайн.Как я сказал; вы можете создать тему WordPress всего из двух файлов, но на самом деле вы захотите максимально использовать то, что WordPress может предложить, и более полно использовать иерархию шаблонов тем.

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

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

`Как удалить index.php по постоянной ссылке в WordPress`

После миграции WordPress на другой сервер, который не обязательно должен иметь те же настройки, что и тот, с которого вы мигрируете, есть вероятность, что к вашему URL будет добавлено « index.php ». Это часто может привести к ошибке 404 пропущенной страницы и нарушению дружественных URL. Узнайте, как удалить index.php из постоянной ссылки в WordPress.

После успешной миграции вашего сайта WordPress на другой сервер первое, что вы, вероятно, захотите сделать, это войти в настройки постоянных ссылок и проверить желаемый вариант постоянных ссылок, который в большинстве случаев будет « Имя сообщения », и сохранить этот параметр. в базу данных.Но поскольку вы, вероятно, импортировали базу данных, есть вероятность, что вы увидите « index.php », уже созданный в структуре URL. Если вы хотите удалить index.php из постоянной ссылки в WordPress, вот что вы можете попробовать сделать:

`1. Узнайте, включен ли «mod_rewrite» на вашем сервере.`

Если у вас нет прямой информации от вашего хостинг-провайдера, активен ли этот модуль на вашем сервере, вы можете создать информационный файл и проверить его самостоятельно. Узнайте, как создать информационный файл PHP в этом посте.

`2. Задайте структуру постоянных ссылок`

Перейдите на панель инструментов > Настройки> Постоянные ссылки и выберите опцию « Custom Structure », введите в поле: /% postname% / и нажмите кнопку Save Changes .

`3. Отредактируйте файл .htaccess`

Скопируйте следующую директиву в файл .htaccess , который находится в корне папки вашего веб-сайта:

 
# НАЧАТЬ WordPress

# КОНЕЦ WordPress

Этого должно быть достаточно, чтобы удалить index.php из структуры URL.

Узнайте больше о постоянных ссылках в WordPress на официальной странице WordPress Codex.

`Дополнительные известные проблемы`

Иногда описанные выше шаги не дают никаких результатов при удалении index.php из вашей структуры постоянных ссылок, и вот что может вызвать проблемы.На некоторых серверах с жесткой безопасностью mod_security блокирует ваши настройки, поэтому index.php все еще остается в структуре URL. Попробуйте добавить этот фрагмент кода в файл .htaccess выше правил, описанных в шаге 3 этого сообщения:

 

SecFilterEngine Off

Еще одна вещь, которую нужно проверить, - это файл конфигурации для Apache, который также может переопределять ваши директивы .htaccess .