dmitriy

Я бы посоветовал завести себе какой-нибудь сервис для Continous Integration, например Jenkins.
Он позволит несколько усложнить задачу (кто бы мог подумать, что усложнить - это что-то хорошее!), например:
* Мониторит git / svn / hg / что угодно на предмет новой версии
* Забирает новую версию
* Прогоняет тесты
* В случае невыполнения тестов отправляет провинившемуся разработчику push / email
* В случае выполнения тестов выполняет деплой, и/или например отправляет артефакт в репозитарий, или образ докера в репозитарий.

Для маленького проекта на 5 файлов, конечно, Jenkins это из пушки по воробьям, и тут наверняка лучше будет rsync (если применимо). Но чем больше проект и чем больше тестов и вариантов сборки, тем полезнее может быть Jenkins.

У нас как только не используется: и собирает докер образы (в случае успешной сборки и тестов - в репозитарий), и собирает java-артефакты (аналогично, собрался - пошёл в maven). Собирает приложения на spring-boot, копирует их на целевой сервер, делает из них сервис и сам его перезапускает.

Да, многое можно возложить на хуки, но:
* хуки выполняются на компьютере разработчика (и зачем мне у себя выполнять 300 тестов при каждом коммите, если рядом специально обученный сервер стоит?). К тому же, бывали ситуации, когда что-то собирается на компьютере разработчика только потому, что у него есть какие-то локальные хаки. И потом приходит новый человек (или он меняет компьютер) и два дня только и делает, что настраивает себе всякое :). С отдельным сборщиком такого не бывает.
* деплой и редеплой может запускать специально обученный PM, а не разработчик. Или вообще кто угодно.
* Есть всякие красивые графики, что успешных тестов выполняется всё больше и больше, например. В любой момент PM может посмотреть, какие изменения были в каждой конкретной сборке.

Видел всякие разные конфигурации, даже такую, когда для сборки проекта покупалась виртуалка на amazon, делала сборку и уничтожалась :) Вопрос лишь в извращённости сознания администратора Jenkins. Ну и, конечно, максимально хорошо он интегрирован с Java. JetBrains TeamCity, Atlassian Bamboo - в общем-то тоже.

https://habrahabr.ru/company/softmart/blog/310502/
Может быть это вам поможет.

Smarty можно найти наверное только в древних проектах.
Twig очень даже да. его киллер фича - extends главное его понять.

Нужно писать бизнес-логику независимой от фреймворка. Обкладывая доменную модель интерфейсами со всех сторон. Тогда при переезде на любой другой фреймворк переписать придется только реализации этих интерфейсов, контроллеры фреймворка, которые должны состоять из 2-3 строк кода и вьюшки. Можете погуглить и посмотреть реализации DDD архитектур например.

Но сейчас нет выбора, нужно пересматривать каждый кусок кода, который делает обращения к codeigniter. То есть по-сути заново написать проект. На Yii2 тоже 99% пишут зависимый от фреймворка код. Можно перед переездом почитать что-то по архитектуре и сделать БЛ максимально независимой от фреймворка. Чтобы в будущем здесь не появился очередной вопрос "Как перенести проект с Yii2 на Symfony?".

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

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

Для начинающего, с целью понять сущность MVC, "пощупать" некоторые аспекты фреймворка, такие например, как загрузка библиотек и пр. подобности, я бы порекомендовал Вам CodeIgniter. Отличная документация, довольно много людей, кто сможет Вам ответить на возникающие вопросы, есть документация на русском. А так же, минимальное количество "лишнего" из коробки, например, шаблонизаторов (которые Вы можете самостоятельно подключить, если очень хочется).

После этого фреймворка, промежуточным, можно было бы считать Kohana, но, он что-то то "умирает", то снова "воскресает"... С документацией на него, по моему, всё так же плохо (читай "не очень хорошо") как и всегда... но, по нему есть несколько неплохих видео-уроков.

Суда же можно отнести Yii, на мой взгляд, он застрял где-то между "большими" и "маленькими" фреймворками. Маленьким его уже не назовёшь, по ряду признаков, а до большого и целостного - он ещё не дотягивает. Но, он довольно популярен на просторах бывшего СССР (по понятным для многих причинам), в виду чего имеет довольно большое русскоговорящее сообщество и целую толпу ярых фанатов.

Далее, в обязательном порядке будет идти Laravel - превосходная документация, примеры и фантастическое количество видео-уроков (если хорошо понимаете английский). Отличный фреймворк собранный на базе Symfony. Относится уже к "большим".

Ну а когда станете совсем матёрым программистом, и "лишний" код будет писать уже не в моготу, когда изучите все основные аспекты разработки, в том числе "сервис контейнеры", "внедрение зависимостей", будете понимать основные сетевые протоколы на низком уровне... а качество и разделяемость кода - будет одним из приоритетных условий - рекомендую обязательно ознакомиться с Symfony. Уроков по нему, довольно небольшое количество, вменяемого материала на русском языке - практически нет вообще... Но, достаточно легко изучается когда есть хороший багаж знаний и опыт работы с другими фреймворками.

P.S. Я понимаю, что Вы спрашивали "какой фреймворк учить первым?", а не какие они бывают вообще. Но, дабы предостеречь Вам от вопросов типа "какой фреймворк учить вторым?" или "почему Symfony в роли первого фреймворка так тяжело изучать?" и массы прочих подобных - озвучил одни из самых популярных фреймворков в мире веб-разработок в ракурсе PHP.

Как вариант:

if (file_exists('install.php')) {
  header('Location: /install.php');
}

Это если в install.php не используется роутинг.

Каждый виджет - отдельный класс, унаследованный от общего класса Widget.

создайте файл .gitignore в корне, напишите там правило: игнорить все, кроме www. Что-то типо:

**
!www

Гуглите glob gitignore

Лучше выбирать по 1000/5000 записей получать максимальное значение id (PK) и идти дальше, смещаясь по primary key. where id > ? limit 1000 order by id asc
Limit/offset не гуд на больших объемах - так как, к примеру, offset 10000 limit 1000 переберет 10к строчек чтобы отдать 1000