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

Когда в проекте много php-классов, то возникает проблема подключения их файлов. Например есть классы Class1 и Class2. Для того, чтобы их использовать, вначале нужно подключить их php-файлы. Само по себе подключение — это обычные require или include, поэтому задача сводится к тому, чтобы указать правильный путь к php-файлу. По мере, того как классов становится всё больше, возникает серьезная проблема с подключением каждого файла класса. В идеале процесс подключения должен быть автоматизирован и в PHP для этого используется механизм автозагрузчика.

Пока я не стал баловаться программированием на Javа, особо не задумывался над использованием MVC в PHP. Обычно действуешь по своему опыту или как это принято в php-фреймворке (или CMS, не важно). Тем более почти все фреймворки декларируют свою преданность концепции MVC: дескать вот у нас всё сделано правильно, по теории.

В последнее время всё больше шума вокруг js-фреймворков React, Angular и Vue. Порой складывается впечатление, что без этих библиотек веб-разработка уже не существует и единственный верный путь - бросать «никому не нужный» PHP, и срочно изучать реакт, поскольку он сейчас самый якобы востребованный на рынке. :-)

Можно сказать, что Singleton в PHP наиболее часто используемый паттерн. Смысл его работы в том, чтобы гарантировать существование одного единственного экземпляра переменной (класс, массив, не важно) во всём приложении. Зачем это вообще нужно?

MAX Bootes — ещё один новый шаблон, построенный на базе MF. Шаблон рассчитан на сайты, где активно используются изображения, поэтому сам шаблон выполнен в минималистическом дизайне.

MAX Auriga — это новый шаблон, построенный на базе MF, поэтому совместим с ним по блокам, компонентам, стилям и т.п.

После выхода WP5 с его «Гуттенбергом», я решил немного освежить старую информацию о том, как сейчас обстоят дела со свойством contenteditable. Кто не в курсе, то это такое свойство любого html-тэга, которое заставляет браузер включить режим редактирования.

Главная сложность с подвалом, как оказалось — это многообразие блоков и их настроек. По задумке подвалов может быть много (десятки). Изначально я планировал их сделать в виде компонентов, что в итоге приводит к некоторой путанице в админке. Кроме того, каждый такой компонент должен иметь свои настройки: даже элементарное — название сайта и какие-то ссылки. Тут ещё нюанс в том, что блоки подвала как правило, имеют одну html-разметку в виде flex-колонок: меняется только содержимое внутренних ячеек. Я тогда подумал остановится на универсальном решении, что-то вроде footer-cols1 из Default-шаблона. Но такой компонент настраивается через опции, и если их немного, то проблем нет, но что делать, если я захочу предложить 10 блоков? Настраивать все поля опций — ещё то занятие...

При всех своих плюсах, Open Server Panel имеет один существенный недостаток — невозможность обновления. Это обусловлено в первую очередь тем, что сама программа Open Server Panel (далее по тексту OSP), является неким менеджером конфигураций для различных модулей. Когда нужно запустить PHP 5.5, то OS вначале скопирует нужную конфигурацию, а после запустит PHP. Если нужна PHP 7.1, то вначале подготовится конфигурация, после опять запуск.