Игорь Воротнёв

nginx + php 7.3 + OPcache + MariaDB
и никакие плагины не нужны

Давным давно (года 2-3 назад) заварилась тема рисования с помощью CSS. Я тогда даже небольшую заметку на хабр писал по этому поводу. В те времена мы делали простые картинки вроде таких:

Это было интересно и познавательно. С одной стороны это челлендж, с другой - способ самообразования. На тот момент картинки были не очень сложными для понимания и тема людям понравилась. Время шло, народ постепенно изучал основы CSS (правда как всегда не у нас, у нас это дело в основном критиковали со словами "фигней маятесь, зачем это нужно" или "ну я же фронтенд-сеньер-реакт-помидор-разработчик, зачем мне нужно знать CSS"), но так или иначе картинки становились все более интересными, появлялись новые квесты и на данный момент можно сказать, что это своеобразный вид искусства с практически полезной составляющей. Понятное дело, что в продакшен такие картинки делать долго - проще взять SVG, но для обучения они хорошо подходят. Магии там нет.

Фигурные скобки создают новый блок со своей областью видимости (к последнему выражению это отношения не имеет):

int A = 0;

{
    int A = 1;
    int B = 1;
    std::cout << A << "\n"; // 1
    std::cout << B << "\n"; // 1
}
  
std::cout << A << "\n"; // 0
//std::cout << B << "\n"; // <-- error: B was not declared in this scope

Рекомендую telescope там можно будет проанализировать подробно время, запросы к бд и многое другое, раньше пользовался laravel-debugbar но в telescope можно спокойно и подробно все посмотреть

Чаще происходит так, что не вы нанимаете агента для поиска заказов, а есть посредник, который нанимает вас в качестве исполнителя.
Таких много.
Если найдете 3-5 адекватных посредников они легко загрузят вас работой настолько, что не придется самому искать заказы.

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

/**
*  @return Product|false
*/
public function getProduct(int $id)
{
    // ...
}

Как правило это неправильно (Битрикс особенно любит так делать), зато док-блок точно описывает что может вернуть метод. Здесь, кстати, еще один тонкий момент: можно написать не bool, а именно false, потому что хоть тип и bool, значения true там не будет никогда. Короче нужны эти штуки)

Если я изучу в достаточной мере JS ,то смогу потом изучить Node.Js и работать с серверной часть

Знание JS однозначно поможет начать работать с JS на сервере. Язык тот же, только другие API, потому что другая среда. Я бы порекомендовал не распылять силы на разные языки и освоить сначала что-то одно. Тем более, что работа отдельно по фронтенду, вообще без бэкенда (вам надо будет понимать, как они взаимодействуют, но совсем не обязательно уметь это реализовывать самим), достаточно распространена.

Отдельно отмечу, что бэкенд это не только PHP.

Думаю, самый популярный плагин для произвольных полей — Advanced Custom Fields.

Лишний пробел после dbname=

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

Полноценный CI/CD поднимать не вижу смысла ввиду размеров

вы ж все равно собираетесь какие-то скрипты мутить и чото выдумывать,
какая разница это будут крон скрипты на сервере или джоба в дженкинсе? по-скорости написания - одно и тоже будет. так что по-моему размер тут не имеет значение
единственное что имеет значение - насколько явно у вас описан процесс(алгоритм) билда/разворачивания приложений
с этой точки зрения мое видение примерно такое:

1) git не есть инструмент для развертывания по, git лишь для версионирования кода
и по-идее результатом вашей работы должен быть не код в гитхабе, а какой-то вменяемый артефакт, готовый к деплою (docker-image, pip пакет, npm пакет, deb пакет, jar, war, zip в крайнем случае, и тд и тп). Если производить артефакты то вопрос с тегами отпадет сам собой - у вас будет артефакт какой-то версии и все
сервер не должен знать ни про какие гиты и ни про какие-то теги в нем
Здесь я бы рекомендовал паковать все в докер-имеджи хотя бы только потому, что сервер в итоге не будет знать ничего о зависимостях приложения, нужных библиотеках, ниочем вообще, вам нужно установить только докер
Огромное преимущество использование докера - в Dockerfile вы вынуждены волей/неволей описать точно и явно все шаги требуемые для установки приложения. И что самое замечательное - это все будет храниться в том же репозитории, под контролем гит - шикарно.
Артефакты желательно хранить в каком-то артефактории,
но если реально все просто - то можно хранить несколько последних версий прямо на сервере в какой-нибудь папочке

2) как только вы получили артефакт - его можно деплоить
неплохо было б знать особенности вашего проекта, но грубо говоря допустим что достаточно его зааплоадить на сервер, положить в нужное место
опять же с этим дженкинс справится на ура и займет у вас это все дело 10 минут . Если вы опишете логику в Jenkinsfile вы выиграете еще раз потому что процесс развертывания(алгоритм) будет описан опять же ЯВНО. И будет тоже под контролем гита. (Jenkins должен знать только в каком репозитарии и в каком месте ему искать Jenkinsfile)
Если же вы будете крутить какой-то спрятанный cron скрипт на сервере - о нем никому ничего не будет известно. Поверьте уже через короткое время все это дело начнет усложнятся, что-то забудется, что-то измениться и это все вместе больно ударит вас по яйцам.

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

3) Env Variables
когда приложение стартует - считывает все что ему нужно из переменных окружения
деплой джоба может каждый раз эти переменные устанавливать перед тем как деплоить - это было бы тоже круто потому что вы сделали бы это знание так же явным

Итого имеем
- логика сборки проекта описана в Dockerfile и находится под гитом
- логика деплоя находится в Jenkinsfile и находится под гитом, и что самое главное является кодом (Jenkinsfile пишем на груви, для простых вещей вам понадобиться 30 минут изучения и все)
- на сервере мы ничего не устанавливали совершенно кроме самого докера
- мы храним несколько версий нашего приложения на всякий случай и можем быстро откатиться не прибегая к гиту вообще
- сервер не знает ничего о гитах
- на сервере нет НИКАКОЙ дополнительной логики по разворачиванию вашего приложения
- имея все это очень легко добавлять другие сервера для деплоя - что нам нужно - грубо говоря указать другой айпи и набор env variables к нему ( если они конечно отличаются)

Сам факт наличия плагинов никак не влияет на загруженность сайта. Всё зависит от того, что эти плагины делают и как написан код. То есть, если в 50 плагинах 10 строчек кода и они особо ничего не делают, а в 1 плагине 1000 строчек кода, и он совершает запросы в БД, включает фильтры, обновляет данные и т.д. то этот один плагин нагрузит сайт больше, чем все 50 плагинов вместе взятых.

Подробнее