Если "СрокДействияС" и "СрокДействияПо" - измерения, то просто убрать их из выборки (хотя учитывая, что там ещё и в условии они используются - все равно придется сгруппировать).
Если они нужны далее по алгоритму для чего-то типа ФИФО - то можно добавить общие итоги.
Но я бы изменил структуру регистра вообще убрав сроки и добавил еще один РН с плановыми начислениями и списаниями в будущем (или РС или измерение в имеющемся РН типа Булево) из которого бы переносил раз в день регламентным заданием сгорающие бонусы отдельным документом.
Если обычная статика html то можно собирать с помощью gulp/webpack/rollup из кусков и получать статический сайт. Если не нужно сильно со стилями бороться и это что-то типа сборника документации - то вообще что-то типа https://vuepress.vuejs.org/ можно использовать.
Потом просто набор статических файлов класть на хостинг и всё.
Хотя что подразумевается под "настраивать php на сервере" не очень понятно.
регулярно выходят новые фичи в текущей мажорной версии, см. https://blog.vuejs.org/ последняя 3.5 вышла в сентябре
новый режим vapor mode который может быть (или нет) https://www.vuemastery.com/blog/the-future-of-vue-... основой для v4, а может потихоньку интегрироваться в v3. Судя по тому, что реактивность сильно меньше стала кушать памяти и стала быстрее в 3.5 - какие-то наработки из vapor попадают в v3.
Если дизайнер дизайнерит в фигме - то не надо давать имена экспортируемым сущностям (например иконки) с использованием запрещенных в именах файлов символов. Причем на всей иерархии (хз, почему так), иначе при экспорте они будут заворачиваться в zip
Нужно внимательно прочитать раздел документации https://laravel.com/docs/11.x/filesystem, особенно The Public Disk, File Uploads и потом Downloading Files и File URLs (для получения ранее загруженных файлов)
Проблема оказалась в том, что в тексте СМС до кода не должно быть точки. Ну или еще в чем-то подобном, все проверять лень да и невозможно. Но в СМС "Ваш код для входа на site.ru: 123456" код не распознается, а в смс "Ваш код для входа на site: 123456" - все ок. С длиной кода и 4 и 6 знаков поведение одинаковое - точка всё портит.
Да. А еще лучше - и на ssd и опубликовать на веб сервере (если база на управляемых формах).
Основная причина в том, что при подключении второго пользователя к шаре винда вырубает файловый кэш для неё, что особенно больно на hdd. Да и вообще всё сильно живее будет, даже с одним пользователем. Практическое отсутствие пенальти за рандомное чтение/запись делает свое дело.
Заменить сайт на SPA (опционально + SSR), тогда при переходе по "страницам" сайта фактической перезагрузки страницы не будет. Заодно всякие фичи типа веб плеера тоже возможны.
Учитывая, что по факту это деструктурирующее присваивание, то нет. Ну либо сделать fname (param) и дальше уже с param работать, но тогда там будут лишние ключи, которые надо фильтровать, что также убивает идею.
Еще можно запихнуть всё в в компоненты, в теги <template id="component-id"> в качестве источника шаблона компонента, а уже компоненты поместить в корень приложения (<div id="app"> или что-то подобное) https://codepen.io/FragsterAt/pen/gONyzdJ
Мои телепатические способности говорят мне, что автор получает данные, выводит их в шаблон а потом хочет через DOM что-то с этим сделать (зачем?). В данном случае поможет nextTick