WordPress: Кнопки HTML тэгов в редакторе WordPress без плагинов.

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

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

В общем как обычно все дело в правке functions.php – ‘корень сайта/wp-content/themes/ваша тема/functions.php

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// Добавляем кнопки в текстовый html-редактор
add_action( 'admin_print_footer_scripts', 'add_volkov_quicktags' );

function add_volkov_quicktags() {
    if (wp_script_is('quicktags')) : ?>
    <script type="text/javascript">
      if (QTags) {  
        // QTags.addButton( id, display, arg1, arg2, access_key, title, priority, instance );
        QTags.addButton( 'volkov_p', 'p', '<p>', '</p>', 'p', 'Параграф', 1 );
        QTags.addButton( 'volkov_h2', 'h2', '<h2>', '</h2>', 'h', 'Заголовок 2 уровня', 2 );
      }
    </script>
<?php endif;
}

Вы можете заметить, что частенько можно увидеть различный стиль написания того или иного оператора. В частности многие не могут определить в каких ситуация целесообразней использовать if с фигурными скобками, а когда с двоеточием. Оператор с фигурными скобками следует использовать в файлах, где у вас кроме PHP кода больше ничего нет, а вот альтернативный синтаксис подойдёт для файлов шаблонов, где чистый HTML код не должен затрагиваться PHP стороной

В нашем случае текстовые кнопки работают с помощью javascript-библиотеки Quicktags. Библиотека располагается в wp-includes/js/quicktags.js

Docker: установка актуальной версии docker-ce в CentOS7

Требования к ОС

Чтобы установить Docker Engine – Community, вам нужна поддерживаемая версия CentOS 7. Архивные версии не поддерживаются и не тестируются.
Хранилище centos-extras должно быть включено. Этот репозиторий включен по умолчанию, но если вы его отключили, вам нужно снова включить его.

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

В прочем, мальчикам убунтоидам это не понять)

“Docker: установка актуальной версии docker-ce в CentOS7”Continue reading

Docker: docker и iptables или файерволы

По умолчанию, docker daemon модифицирует iptables правила файервола без какого-либо уведомления или согласования с администратором. Для этого он используте к примеру цепочку с именем DOCKER и не только.

1
2
3
4
5
6
7
Chain FORWARD (policy DROP)
target     prot opt source               destination
DOCKER     all  --  0.0.0.0/0            0.0.0.0/0
...

Chain DOCKER (1 references)
target     prot opt source               destination

Более того, когда вы указываете docker открывать порт контейнера, он открывает его всему миру, нарушая ваши возможные правила iptables. Итак … если вы запускаете docker на хосте, на котором уже установлен брандмауэр на основе iptables, вам, вероятно, следует установить –iptables = false. Давайте возьмем пример. Вы хотите запустить nginx и связать containerPort 80 с hostPort 9090:

1
docker run --name some-nginx -d -p 9090:80 nginx

За сценой он добавляет правило iptables в цепочку фильтров DOCKER:

1
2
3
4
5
6
7
8
Chain FORWARD (policy DROP)
target     prot opt source               destination
DOCKER     all  --  0.0.0.0/0            0.0.0.0/0
...

Chain DOCKER (1 references)
target     prot opt source               destination
ACCEPT     tcp  --  0.0.0.0/0            172.17.0.2           tcp dpt:9090 <-- это было добавлено при запуске контейнера

Теперь порт 9090 доступен со всего мира. Потому что мы слушаем 9090 на любых IP-адресах (‘0.0.0.0)’из-за правил пересылки, которые динамически добавляются в цепочку фильтров DOCKER. Обратите внимание, что правила пересылки docker разрешают все внешние IP-адреса по умолчанию. Вы, вероятно, не хотите этого. Возможно, вы захотите публиковать порты только локально, а не в ‘0.0.0.0’, для внутреннего использования. Давайте прочитаем документацию по docker-run:

1
2
3
4
5
-p=[]      : Publish a container&#39;s port or a range of ports to the host
               format: ip:hostPort:containerPort | ip::containerPort | hostPort:containerPort | containerPort
               Both hostPort and containerPort can be specified as a range of ports.
               When specifying ranges for both, the number of container ports in the range must match the number of host ports in the range. (e.g., `-p 1234-1236:1234-1236/tcp`)
               (use &#39;docker port&#39; to see the actual mapping)

Как видите, вы можете привязать hostPort к IP.

1
docker run --name some-nginx -d -p 127.0.0.1:9090:80 nginx
1
2
3
4
5
6
# BEFORE
netstat -an | grep 9090
tcp6       0      0 :::9090                 :::*                    LISTEN
# AFTER
netstat -an | grep 9090
tcp        0      0 127.0.0.1:9090          0.0.0.0:*               LISTEN

Докер, хватит возиться с моими правилами iptables!

Допустим, вы используете докер на сервере, доступном в Интернете. У вас уже настроен межсетевой экран на основе iptables. Чтобы запретить docker вносить изменения в правила iptables вашей системы, вы должны установить –iptables=false при запуске демона. Для систем на основе sysvinit и upstart вы можете отредактировать /etc/default/docker. Для systemd вы можете сделать это – ‘systemd edit docker.service’ и добавить следующий код и перегрузить docker:

1
2
3
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --iptables=false

Теперь перезагрузите брандмауэр и перезапустите демон Docker. Вы можете видеть, что цепочка с именем DOCKER и ссылки на нее в цепочке FORWARD исчезли.

1
2
3
4
5
[root@vms csf]# csf -ra | egrep '(ERR|WARN)'
*WARNING* RESTRICT_SYSLOG is disabled. See SECURITY WARNING in /etc/csf/csf.conf.
[root@vms csf]#
[root@vms csf]# iptables-save | egrep DOCK
[root@vms csf]#

Настройте iptables для работы с докером

Если вы все еще используете мост Ethernet, созданный docker и названный docker0, вы можете установить следующие правила для пересылки:

1
2
3
4
[root@vms csf]# iptables-save | egrep docker0
-A INPUT -i docker0 -j ACCEPT
-A OUTPUT -o docker0 -j ACCEPT
[root@vms csf]#

Теперь, если вы хотите открыть TCP-порт 10000 работающего контейнера для всего мира, этот контейнер должен предоставить порт любому IP-адресу (0.0.0.0) на стороне хоста:

1
2
3
4
docker run --name some-nginx -d -p 10000:80 nginx

netstat -an | grep 10000
tcp6       0      0 :::10000                :::*                    LISTEN

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

1
-A INPUT -p tcp -m tcp --dport 10000 -j ACCEPT

Docker: systemd в docker контейнере

В одной из предыдущих статей я показал как собрать образ с нуля для контейнера на основе пакетной базы CentOS7. Однако все эти контейнеры на базе некоторого исполняемого кода, берушего на себя функции начального процесса с PID 1 далеки от какой-либо эмуляции “контейнерной” ОС. Для этого нужен полноценный init процесс, способный работать с сервисами в контейнере docker как в обычной полной виртуализации или на обычном сервере.

В “родных” контейнерах построенных на базе systemd-nspawn все это заложено изначально, и такие контейнеры сразу запуcкают полноценный процесс init – systemd. Но так ли сложно обойти костыли архитектуры docker и запустить systemd под его изрляцией? Давайте разбираться.

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

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

Допустим, что как в предыдущей статье мы уже знаем как создать базовую сущность supermin5 только с одним пакетом – yum. Теперь попробуем создать это с двумя пакетами – systemd и yum:

“Docker: systemd в docker контейнере”Continue reading

Docker: создание собственного локального CentOS образа и контейнера с нуля.

Для создания образа будем использовать один из популярных инструментов старых админов – supermin.


supermin [-o OUTPUTDIR] – Имена СПИСОК PKGS …
supermin [-o OUTPUTDIR] Имена файлов PKG …
Supermin – это инструмент для создания программных “сущностей”.
Они крошечные и похожи на виртуальные машины, обычно около 100 КБ в размере, которые создаются полностью на лету за доли секунды когда нужно.
Начиная с версии 4 этот инструмент является независимым от дистрибутива и может создавать “супер-сущности” для нескольких популярных дистрибутивов Linux, а добавить поддержку других достаточно просто.

и пару слов о том как он работает ))


Есть два режима использования супермина:

С параметром –names supermin берет список имен пакетов и создает supermin сущность, содержащюю эти пакеты и все зависимости, которые требуются для этих пакетов.
В этом режиме supermin обычно требуется доступ к сети потому что, возможно, потребуется проконсультироваться с репозиториями пакетов, чтобы определить зависимости и загрузить пакеты.

Без –names supermin принимает список пакетов (т.е. имена файлов уже локально доступных пакетов). Этот пакет должен быть полным и в соответствии с отсутствием зависимостей вне набора пакетов, которые вы предоставляете. В этом режиме супермин не требует доступа к сети. Он видит файлы пакета сами.

Под «пакетом» мы понимаем пакет RPM, DEB и т. д.
Имя пакета может быть полным именем (например, “coreutils-8.22-24.el7.x86_64”) или некоторое сокращение (например, “coreutils”).
Точный формат имени и допустимые сокращения зависят от менеджера пакетов.

Файловая программная сущность supermin, которая создается supermin, состоит из двух файлов, называемых «hostfiles» и «base.img».
По умолчанию они записываются в текущий каталогm, но если укажем опцию -o OUTPUTDIR, то эти файлы будут записаны в этот каталог
(традиционно этот каталог называется «supermin.d», но вы можете называть его как хотите).

Во всех случаях supermin может создавать только файловые сущности, идентичные дистрибутиву, версии и архитектуре хосту. Он не делает кросс сборки.

Исходя из сказанного вышею для создание своего образа с нуля нам уже будет нужна целевая ОС с установленными пакетами.
Устанавливаем 5 версию и создаем рабочий каталог:

“Docker: создание собственного локального CentOS образа и контейнера с нуля.”Continue reading

Scroll to top