Александр Торопов

Нет конечно.
у гуглотаблиц есть api, а для экселя есть PHPOffce

Если не нужны навороты вроде формул и графиков, то и то и другое сохраняется как CSV, а для него уже есть встроенная функция fgetcsv().

laravel нежели на CMS- битрикс?

- как можно сравнивать продукт с фреймворком. Если взять любую доступную админку на Ларавел, то она даже близко не превзойдёт админку Битрикс.
Если уж сравнивать тогда ларавел с коммерческим фреймворком Битрикс. По техническим моментам фреймворк битрикса скорее всего уступает ларавел, но как это упрощает и решает задачи бизнеса?

прикрутить личный кабинет пользователя, с графиками + vue

- на самом деле Битрикс это коммерческий фреймворк, а админка это продукт на его основе. Если вы будете писать новый функционал, которого нет в продукте, что в Битриксе, что в ларавел вы будете это делать с нуля, писать и там и там на фреймворке.

1) Удобная система ( админ панель) с быстрой тех поддержкой

- это реальный большой плюс, который сокращает расходы на поддержку проекта.

2) Много функционала из коробки

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

3) Удобно интегрировать с CRM битрикс

- хороший плюс, который сокращает расходы на создание аналогичного функционала.

масштабировать проект очень сложно

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

Очень сложных проектов на Yii2 с открытым, да ещё и хорошим кодом очень мало)) Прежде всего, потому что Yii создан для быстрой разработки нарушая все правила сложных архитектур. А учитывая его устарелость, то тем более таких проектов мало. На форуме давно обсуждался этот вопрос. Там есть ссылки на проекты и код. Так же на сайте yiipowered.com есть список проектов, у некоторых с исходным кодом.

Вам лучше изменить тактику и искать проекты с хорошей архитектурой вне зависимости от фреймворка. Так ваша вероятность найти что-то стоящее на много выше. В целом, хорошая архитектура - это всегда дорого. Мало кто будет выкладывать проект большой команды, на которую были потрачены сотни тысяч и миллионы в открытый доступ. Кроме того хорошая архитектура всегда зависит от требований, задач и самого проекта. Что и где применять, как строить - придет только со знанием и опытом. Здесь не получится сделать по примеру.

Если по теме, то начните изучать или искать DDD, CQRS, SOA, Микросервисы. В принципе это основные архитектурные подходы в разработке. На Yii по DDD есть хороший пример. Однако начинать НОВЫЙ проект на Yii2 используя даже самую сложную архитектуру - путь в никуда. Yii2 создан для других целей. Чтобы понять можно посмотреть ответ на вопрос: Актуален ли Yii2 Фреймворк в 2020?

...
.skill_block:hover {
    position: relative;
    opacity: 1;
    transform: scale(1.1); /*вот так*/
}
...

P.S. может не поддерживаться в некоторых браузерах, используите перфиксы.

Смотря зачем)). Я когда делаю Code Review критерии следующие:

* Безопасность:
- Каждый аргумент метода простого типа должен проверяться на тип в случае его проксирования и на граничные значения в случае обработки. Чуть что не так - бросается исключение. Если метод с кучкой аргументов на 80% состоит из поверки из аргументов - это вполне норм))
- Никаких trigger_error, только исключения.
- Исключения ДОЛЖНЫ быть человеко-понятны, всякие "Something went wrong" можно отдавать пользователю, но в лог должно попасть исключение со стектрейсом и человеко-понятным описанием, что же там пошло не так.
- Каждый аргумент (объект) метода должен быть с тайпхинтингом на этот его класс, или интерфейс.
- За eval как правило шлю на **й.
- @ допускается только в безвыходных ситуациях, например проверка json_last_error.
- Перед работой с БД - обязательная проверка данных.
- Никаких == и !=. Со swtich - единственное исключение, по ситуации.
- Если метод возвращает не только bool, а еще что-то - жесткая проверка с ===, или !== обязательна.
- Никаких условий с присваиваниями внутри. while($row = ...) - тоже идет лесом.
- Магические геттеры/сеттеры разрешаются только в безвыходных ситуациях, в остальном - запрещены.
- Конкатенации в sql - только в безвыходных ситуациях.
- Параметры в sql - ТОЛЬКО через плейсхолдеры.
- Никаких глобальных переменных.
- Даты в виде строки разрешаются только в шаблонах и в БД, в пхп коде сразу преобразуется в \DateTimeImmutable (в безвыходных ситуациях разрешено \DateTime)
- Конечно зависит от проекта, но как приавло должно быть всего две точки входа: index.php для web и console(или как-то по другому назваться) - для консоли.

* Кодстайл PSR-2 + PSR-5 как минимум, + еще куча более жестких требований (для начала все то что в PSR помечено как SHOULD - становится MUST)
- В PhpStorm ни одна строчка не должна подсвечиваться (исключением является typo ошибки, например словарик не знает какой-то из аббревиатур, принятых в вашем проекте). При этом разрешается использовать /** @noinspection *** */ для безвыходных ситуаций.
- Если кто-то говорит, что пишет в другом редакторе и у него не подсвечивается, на эти отговорки кладется ВОТ ТАКЕЕЕНЫЙ мужской половой **й и отправляется на доработку)).

* Организация кода:
- Никаких глобальных функций.
- Классы без неймспейса разрешаются только в исключительно безвыходных ситуациях.

* Тестируемость (в смысле простота тестирования) кода должна быть высокая.
- Покрытие кода обязательно для всех возможных кейсов использования каждого публичного метода с моками зависимостей.

* Принципы MVC:
- Никаких обработок пользовательского ввода в моделях, от слова совсем.
- Никаких ***ть запросов в БД из шаблонов.
- Никаких верстки/js/css/sql-ин в контроллерах.
- В моделях НИКАКОЙ МАГИИ, только приватные свойства + геттеры с сеттерами.
- В моделях разрешено использовать метод save(при наличии такого разумеется) только в исключительных ситуациях. Во всех остальных - либо insert, либо update.

* Принципы SOLD:
- Никаких божественных объектов умеющих во все.
- Если метод для внутреннего пользования - private, никаких public.
- Статические методы разрешаются только в случае безвыходности.

* Принцип DRY разрешено нарушать в случаях:
- Явного разделения обязанностей
- В тестах (каждый тест должен быть независимым, на сколько это возможно)

* Работа с БД:
- Запрос в цикле должен быть РЕАЛЬНО обоснован.
- За ORDER BY RAND() - шлю на***й.
- Поиск не по ключам (конечно если таблица НЕ на 5 строк) запрещен.
- Поиск без LIMIT (опять же если таблица НЕ на 5 строк) запрещен.
- SELECT * - запрещен.
- Денормализация БД должна быть обоснована.
- MyISAM не используется (так уж)) )
- Множественные операции обязательно в транзакции, с откатом если чо пошло не так.
- БД не должна содержать бизнес логики, только данные в целостном виде.
- Не должно быть нецелесообразного дерганья БД там, где без этого можно обойтись.

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

* О людях:
- "Я привык писать так и буду дальше" - не вопрос, ревью пройдешь только когда поменяешь свое мнение.
- "Я пишу в vim-е и мне так удобно" - здорово, код консолью я тоже в нем пишу)) но есть требования к коду, если в них не сможешь - не пройдешь ревью.
- "Я скопировал этот страшный метод и поменял 2 строчки" - это конечно замечательно, но по блейму автор всего этого метода ты, так что давай без говняшек, хорошо?
- "Оно же работает!" - вот эта фраза переводится примерно так: "да, я понимаю, что пишу полную хрень, но не могу писать нормально потому, что руки из жо", я правильно тебя понял?))
- "У меня все работает!" - рад за тебя, а как на счет продакшна?
- "Там все просто" - не используй слово "просто", от слова "совсем". Вот тебе кусок кода (первого попавшегося с сложной бизнес логикой), где там ошибка (не важно есть она, или нет)? Ты смотришь его уже 2 минуты, в чем проблема, там же все "просто"))

* Всякое:
ActiveRecord (это я вам как в прошлом фанат Yii говорю) - полное говно, примите за исходную. По факту у вас бесконтрольно по проекту гуляют модельки с подключением к БД. Не раз натыкался на то, что в тех же шаблонах вызывают save, или update (за такое надо сжигать).
То, что используется Laravel - это печально((. Что бы выполнить требования приведенные выше, приходится "воевать" с фреймворком.

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

UPD

Формализировал данные критерии по ссылочке: https://github.com/index0h/php-conventions

https://getcomposer.org/doc/04-schema.md#classmap
Положить файлики библиотеки в отдельную директорию (e.g. legacy-lib/) и прописать

"autoload": {
    "psr-4": {
        "App\\": "src/"
    },
    "classmap": ["legacy-lib/"]
},

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

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

Как ты, наверное, уже знаешь, строки в SQL берутся в кавычки:
SELECT * FROM table WHERE name='vasya'
Вот чтобы vasya не приняли за имя таблицы или ключевое слово, его берут в кавычки. Очень просто. Но иногда у человека имя не просто вася. Что будет вот с таким запросом?

SELECT * FROM table WHERE name='Я Д'Артаньян, а все вокруг ...'

Мясорубка будет. БД решит, что имя - это 'Я Д', а дальше какая-то фигня, которую она не понимает. И выдаст ошибку.
Поэтому кавычки надо экранировать.

SELECT * FROM table WHERE name='Я Д\'Артаньян, а все ...'

никаких ошибок не выдаст.
Вот mysqli_real_escape_string() как раз этим и занимается - экранирует кавычку слешем, а заодно и сам слеш, потому что если слеш окажется в конце строки,

SELECT * FROM table WHERE text='Мну сегодня в любви вкладкой ошиблись :\'

то БД решит, что последняя кавычка экранирована, и строка не заканчивается. Снова мясорубка.
Также mysqli_real_escape_string() экранирует еще несколько символов, но уже из чисто эстетических соображений.

Еще одна функция этой функции - принимать в расчет кодировку текста. Есть кодировки, в которых слеш - это не слеш, а часть другого символа. И когда БД будет парсить запрос, она не поймет, что это слеш, а решит что это просто буква. И снова мясорубка.
Поэтому перед использованием mysqli_real_escape_string() надо сказать БД, в какой кодировке у нас данные, с помощью функции mysqli_set_charset().

Но читатель уж сучит ножками в нетерпении - а что же SQL инъекции, о которых так долго говорили большевики? Не может же быть, чтобы они были совсем не при чем. Окей, в качестве побочного эффекта, строка, в которой экранированы спецсимволы (слеш и кавычка), не пропустит инъекцию. Но здесь следует понимать две вещи:

1. Строки надо форматировать в любом случае, независимо от того, ждем мы инъекцию, или нет. Мясорубка нам точно так же не нужна.
2. Строками синтаксис SQL запросов не исчерпывается. Есть числовые литералы, есть имена полей. Для всех них mysqli_real_escape_string() бесполезна чуть более чем полностью.

То есть, отсюда можно сделать вывод, что нельзя использовать mysqli_real_escape_string() для защиты от инъекций. Она предназначена для другого. Вот для этого другого, для форматирования строк, ее использовать можно. Но не нужно.

Нашлись умные люди, которые придумали, что колупаться вручную с форматированием переменных для SQL запроса - это долго, неудобно, и можно что-то забыть или перепутать. И пусть лучше БД сама этим занимается. И придумали вместо переменных подставлять в запрос специальные маркеры, а сами переменные передавать отдельно. А БД уже потом сама разберется, что и как форматировать.

В принципе, mysqli умеет так делать, но не так удобно как PDO. Поэтому при возможности вместо нее лучше использовать PDO:

$stmt = $pdo->prepare("SELECT * FROM table WHERE name=? or name=?")
$stmt->execute(["Vasya", "Д'Артаньян"]);
$rows = $stmt->fetchAll();

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

$stmt = $mysqli->prepare("SELECT * FROM table WHERE name=? or name=?")
$stmt->bind_param("ss", ...["Vasya", "Д'Артаньян"]);
$stmt->execute();
$rows = $stmt->fetch_all(MYSQLI_ASSOC);

Но при этом всё равно никакой тебе возни с кавычками, слешами, real, escape, и прочей ерундой. Просто, быстро, лаконично и безопасно.

Завсит от цели, для чего это спрашивается.

Если чтобы поприставать с нубскими вопросами - то нигде.
Если чтобы почитать умных мыслей - РНР дайджест на Хабре прекрасно суммирует все, что было написано за две недели. У меня например никогда не хватает времени, чтобы прочесть всё. Куда больше-то - я уж и не знаю.
Если чтобы поучаствовать в серьезном прокете - на гитхабе, выбирай любой.
Если чтобы послушать интересные доклады и пообщаться вживую - то конференции.
Если интересует внутренне устройство языка - то php internals.
Если интересует, что пишут пхп селебрити про что угодно, кроме программирования - то твиттер (Расмус показывает картинки из аэропортов и роботов, которых собирает его сын, Сара постит котиков - и так далее).

Где точно не тусуются:
Тостер и всякие подобные ресурсы типа стаковерфлоя.
Ну то есть специалиста можно найти, если поискать, но концентрация будет гомеопатическая, если учитывать количество восторженных щеночков, которые увидели язык вчера, и спешат срочно поделиться уже накопленным багажом знаний.
Чаты. Телеграм, дискорд - вот это вот все.
Самая адовая трата времени, которая в принципе бывает в жизни.
Опять же, люди пишут о чем угодно, кроме программирования, и ради пары полезных строчек надо убить весь день.

Для начала почитайте что такое SAPI. Затем представьте что apache + mod_php разделили на web-сервер, который проксирует запросы на php-fpm и отдает статику, и собственно отдельный web-сервер который имплементит SAPI и выполняет запросы связанные только с php. То есть статику отдавать мы можем только через php. Суть примерно та же что и у apache2 + prefork + mod_php но оптимизированный только для работы с php. Так же можно поставить на фронт более быстрый и легковесный сервер который умеет проксировать запросы.

То есть php-fpm это эдакий fast-cgi сервер который постоянно держит готовые для работы пул-процессов (сколько в пуле процессов настраивается, так же как и от какого пользователя их запускать и все такое прочее). Каждый новый запрос уходит в какой-либо процесс из пула, запрос отрабатывает, возвращаем результат тому кто попросил (web-серверу обычно). Если процесс падает (fatal допустим) - поднимаем новый.

Принципиальной разницы между apache2+mod_php нету, просто упрощается инфраструктура. Наш web-сервер должен только уметь проксировать запросы и отдавать статику, а php-frpm вообще может быть на разных машинах (балансировщиком можно раскидывать запросы). Ну и сами понимаете, nginx + php-fpm будет быстрее обрабатывать запросы чем apache2+mod_php какой бы мы менеджер процессов не использовали в апаче. Минусов по сравнению с apache+mod_php я даже не могу предложить.

А php-runtime не зависит от этого. Он один на всех, CLI, FPM, mod_php...