Павел Волынцев

Судя по всему это не таблица, а вычислимая функция, возвращающая датасет.
Не используй ActiveRecord для работы с этим записями, формируй SQL запросы вручную.

Расскажите плиз о технологии, и чем развёрнутей, тем лучше.

Вот захотел ты сделать сайт SPA или PWA с любимой тебе вёрсткой на базе Twitter Bootstrap и любимой библиотеки Vue. Сверстал. Поповеры не появляются, дропдауны не выпадают, модалки не открыватся, формы не валидируются, клики не работают.

Оригинальный Twitter Bootstrap имеет поддержку интерактивных элементов на Javascript. Реализовано это на библиотеке jQuery. Если делаешь на Vue, придётся подключать ещё и jQuery, что лишняя библиотека на 100+ килобайт, что, конечно, не катастрофа (пока ты не на мобилке).

Vue работает с состояниями привязывает данные к отображению, а jQuery работает с DOM и событиями. Это вопрос производительности. Работа JQuery начитается когда загружен и распарсен JS и HTML. Работа Vue начинается в тот момент, когда загружен и распарсен JS, то есть чуть раньше. jQuery модифицирует DOM на лету, перестраивая текущий документ. Vue работает с shadow DOM, а затем подсовывает уже готовую интерактивную страницу в пустой документ, что быстрее (разница в секунды на десктопе, десятки секунд на м...).

Vue реализует компонентную парадигму. Куски страницы являются изолированными кусочками кода (HTML CSS JS), которые цепляются между собой динамически, а обмениваются данными через аттрибуты и события. Предположим, что вы решили следовать компонентной парадигме, тогда согласно вот такому примеру нужно будет увязать самостоятельно все интерактивные компоненты. Компонента-кнопка. Компонента-поле ввода. Компонента-форма. Компонента-контейнер. Получается около 50 компонент. Для некоторых надо будет написать логику на jQuery. Если посмотреть на код jQuery этих микрокомпонент, то он окажется несложный, его вполне можно переписать на Vue. Ну там класс заменить или клик отработать. Когда от кода jQuery не останется следа, его можно будет из проекта удалить.

И вот получается Bootstrap-Vue

На компоненты побили. От Jquery избавились. Написано в единой парадигме. Работает быстрее.

Добавляем тот факт, что в Vue можно не импортировать компоненты, которые не нужны (например, я не работаю с дропдаунами и модальным окнами) и код становится меньше, грузится быстрее, работает быстрее.

Так же будет Не лишним оценить технологию: плюсы, минусы, стоит ли вообще с этим работать ...

Это сам изучай и сравнивай. Навыки и опыт воздушно-капельным и через Internet не передаётся

1. Хорошая ли идея стягивать все исключительно по тегам т.е. поставил я на фронте и на беке тег v0.4 и скрипт на сервере стянул и то и другое
2. Самонаписанный скрипт постоянно чекающий теги гитлаба это вообще идея хорошая? В чем +\- деплоя по тегам?

Метки ставить можно. Даже полезно релизы метками отмечать. Всегда можно определить, на какой комит надо откатиться, чтобы локально восстановить версию кода как на сервере. И release notice писать по git log между метками, а не в памяти держать.

Постоянно чекать git не надо. Лишняя нагрузка на проц. Совершенно лишняя. Рекомендую веб-хуки или деплоить по SSH команде.

3. Как быть с адресами и портами.

Выносите в конфигурационные файлы или в параметры окружения

10+ вариантов на странице https://css-tricks.com/deployment/
Я для разного размера проектов пользовался
1. deployhq - как только обновляется ветка master - сервис обновляет сервер по SSH
2. веб-хуками из bitbacket + самописным веб-скриптом на PHP без таймлимита - как только приходит хук об обновлении ветки master, выполняется скрипт типа такого

cd /var/www/project
cp web/closed.bak web/closed.html # закрыть приложение
git pull
composer update && php yii migrate # как то код бэка обновить
npm run build # как то код фронта обновить
rm web/closed.html # открыть приложение

3. такой же командой, запускаемой через ssh, без веб-хуков. Это когда понадобилось сразу бэк и фронт пересобирать из разных репо и из разных веток. Ну типа демо из ветки develop, а релизы из ветки master на несколько серверов.
4. настраивали Jenkins для авто-установки

В принципе устраивает

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

Скорость работы регулярных выражений заметны на бенчмарках с объёмными текстами. Ну там в HTML найти все гиперссылки. А UserAgent слишком короткая строка.

Светлана Галенко, у вас в файле composer.json

"minimum-stability": "stable"

В репозитории пакетов указано
https://packagist.org/packages/2amigos/translitera...

If you are looking for Yii 2.* version please check its own repository https://github.com/2amigos/yii2-transliterator-helper

Стало быть у вас устанавливается какая-то нестабильная или несовместимая версия.
Попробуйте поставить пакет из репозитория как описано тут https://getcomposer.org/doc/05-repositories.md#loa... и тут www.andrew-kirkpatrick.com/2012/10/add-a-git-repos...

Может такое решение подойдёт
https://css-tricks.com/pure-css-horizontal-scrolling/
Повернуть блоки на 90 градусов и разрешить скролл :)

И вот такой: через white-space или flex
https://codeburst.io/how-to-create-horizontal-scro...

Чтобы понять, как это взломать, надо понимать, как это работает и как такие проверки защищают от взлома.

if (isset($_POST['go']))
Для прохождения такой проверки нужно отправить запрос методом POST с параметром go в теле запроса
curl -d "go=1" -X POST somedomain/someurl

if (!isset($_SESSION['admin']))
Сессия - это ресурс на стороне сервера, например файл с определённым именем. К нему нет прямого доступа.

Для открытия сессии (то есть конкретного файла) используется идентификатор, сохраняемый в cookies. Обычно это PHPSESSID. Например, в куке PHPSESSID записано "2n24161uqm7ctl2tmp8b10sng3" - значит на сервер есть файл например /var/tmp/session_2n24161uqm7ctl2tmp8b10sng3.php (имя файла условное), а внутри записаны все значения массива $_SESSION, закодированные с помощью функции serialize.

Тут два варианта взлома:
1. В своём браузере записать в ту же куку то же значение, что и у админа. Для этого конечно, это значение надо у админа украсть.
2. На сервере открыть файл сессии, декодировать, подставить там параметр "admin" = 1, закодировать и записать обратно в тот же файл.

Оба вариант трудно реализуемы. Возможно, украсть куку админа будет чуть проще :) Например, украсть его ноутбук :) Или пошариться в его браузере, пока он душ принимает. Шпионство.
Для таких как мы - шпионов-лузеров - в $_SESSION на стороне сервера при авторизации также записывают UserAgent браузера и IP адрес компьютера админа, чтобы подмена куки не сработала. То есть там не только !isset($_SESSION['admin']) но и несколько других проверок например. Если проверка на user-agent - нужно будет ещё подменить UserAgent своего браузера или в curl передать в заголовках. Если проверка на IP - тупик, IP подменить будет нереально, это на уровне протокола TCP

Для подмены значений на сервере нужно взломать сервер. То есть либо подсунуть туда хитрый скрипт, который может быть выполнен путём запроса HTTP, он должен сделать описанное выше. Либо авторизоваться через FTP или SSH, затем либо искать файл сессии, чтобы поправить вручную, либо искать этот скрипт с проверкой !isset($_SESSION['admin']), чтобы закомментировать условие. Чтобы войти на сервер, понадобится стырить логин пароль у админа, либо украсть его ноут.

Иногда сессии хранятся не в файлах, а в других сервисах. Например, в memcached или redis или ещё где угодно.

В общем, юный хакер, изучай. Взломай для начала свой сервер с такими же проверками :)