runprogr

используйте
https://github.com/iksaku/laravel-mass-update - под капотом CASE/WHEN/THEN

сырым sql такое можно сделать через CASE/WHEN/THEN

UPDATE table
SET column2 = (CASE column1 WHEN 1 THEN 'val1'
                 WHEN 2 THEN 'val2'
                 WHEN 3 THEN 'val3'
         END)
WHERE column1 IN(1, 2 ,3);

или как работает UPSERT в laravel

INSERT into `table` (id, fruit)
    VALUES (1, 'apple'), (2, 'orange'), (3, 'peach')
    ON DUPLICATE KEY UPDATE fruit = VALUES(fruit);

в postgress вместо `ON DUPLICATE KEY UPDATE` будет `ON CONFLICT (xxx) DO UPDATE `

Массивы хранятся в 2^x. Когда размер массива переваливает за выделенное количество памяти, то php автоматически выделяет под размер массива в 2 раза больше памяти. Что у вас и происходит.

Если стоит задача поиграть с range, то лучше написать свой аналог на генераторах.

function xrange(int $min, int $max): iterable {
    for ($i = $min; $i < $max; $i++) {
        yield $i;
    }
}

$startMemory = memory_get_usage();

$array = xrange(1, 34000000);
foreach ($array as $item) {}

print_r($endMemory = memory_get_usage() - $startMemory); // 568
print_r(round($endMemory / 1024 / 1024) . ' MB'); // 0 MB

Давайте определим точную границу, где проходит увеличение объёма потребляемой памяти. Это 33554432 элементов.
33554432₁₀ = 2000000₁₆
Поищем предыдущий скачок. Он происходит на 16777216 элементах.
16777216₁₀ = 1000000₁₆
Проверим дальше. Получим следующие значения:
8388608₁₀ = 800000₁₆
4194304₁₀ = 400000₁₆
2097152₁₀ = 200000₁₆
1048576₁₀ = 100000₁₆
...
8₁₀ = 8₁₆
Вывод - PHP резервирует память округляя количество элементов вверх до ближайшей степени двойки.

Коллеги уже ответили, а чтобы удостоверить вас, прилагаю скрин, без адБлока

1. Если уж выбирать, то лучше web
2. Отдельный контроллер не нужен. Я создаю в нужном мне контроллере новый action с окончанием "function ***Ajax()". Также добавь middleware который будет проверять это ли Ajax запрос (Request::ajax())
3. Да, лучше удалять с БД соответствующая запись, так как нет смысла сохранять статусы и тд

В профиле пользователя есть раздел "подписки". Вот ваши, например.

Первый вариант не годится.
Второй случай - не совсем понятно, зачем вам два форыча - первые посты вы захотите вывести при отображении списка топиков (как я понимаю), второй раз выведите все посты, связанные с топиком, но тут main 1|0 уже не играет роли. Т.е. на одну задачу вам нужно один раз вытягивать посты, просто по разным критериям.
Основной пост для топика можно определять по дате создания (первый при сортировке по дате) и кешировать (чтобы не расходовать ресурсы на поиск первого поста каждый раз), чтобы не использовать доп. колонку для флага.
На уровне бизнес-логики (php-кода) надо запретить удалять первый пост.

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

Есть исключения когда мы имитирируем структуры данных через классы-DTO(В PHP нету встроенных типов структур/data-классов), но заполнение и там должно быть через конструктор.

Странно, здесь же на тостере Когда использовать static метода? например, пишут что правильная работа с ооп, это как раз задавать параметры через методы, а не через конструктор.

На Тостере много чего пишут, не стоит всему верить, точнее стоит ничему не верить, а анализировать :)
В плане каких-то конкретных терминов часто можно узнать очень много интересных вещей загуглив первоисточник термина/историю появления(в т.ч. причины).

Постарайтесь определить цели и понять как эти варианты помогают вам эти цели достичь. А "правильных" вариантов без заданной цели не может быть.
В будущем в этом плане стоит смотреть на концепты Coupling/Cohesion, и почему они важны(книжки Clean Architecture, Clean Code и т.п., так же принцип Low Coupling + High Cohesion входит в паттерны GRASP).

По теме - задавая параметры через set() методы мы:
- Подразумеваем что все пользователи нашего класса знают какие у него параметры, и более того - что они означают. Это создаёт большую нагрузку на пользователей класса, усложняет клиентский код.
- Позволяем в любом месте где используется класс поменять что-то внутри, и неожиданно обнаружить ошибки в других местах системы. А ещё настройки могут конфликтовать друг с другом, и одни свойства зависеть от других. Установка одного поля может требовать установки другово, и такие вещи стоит указывать на уровне интерфейса, то есть сделать вместо условных setStartDate() и setEndDate() метод setDatePeriod(DatePeriod period), даже если внутри класса это два поля.

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

И ещё - есть разница между методами которые меняют состояние класса, и конкретно "сеттерами". Семантика важна. То что внутри класса что-то меняется нас не интересует. Нам важно лишь чтобы выполнилось то, что мы ожидаем от класса. Если мы хотим обновить статью, мы вызовем метод updateArticle(), или какой-нибудь changeTitle(), например. Если мы хотим кофе мы скажем машинке makeEspresso(), а не будем указывать количество зёрен, упростив таким образом клиентский код.

Мы разрабатываем под WordPress по методологии БЭМ и придерживаемся следующих правил:
1) Отдельный блок (компонент) включает в себя файл инициализации php, файл шаблона php, один или несколько файлов css - под модификаторы стилей создаются отдельные файлы, файл javascript.
2) Под каждый блок создаётся своя папка
3) В зависимости от блока у него может отсутствовать JS, CSS, файл инициализации или темплейта, например, у блока "Анимация" нет темплейта, но есть CSS и JS.
4) Для нативных тегов HTML без классов есть отдельный блок Component, в котором прописываются стили, например, для типографики

Конкретно по вашим вопросам:
1,2) header, footer и wrapper - должны быть или отдельными блоками, тогда вам нужно в header прописать класс header, а в footer прописать класс footer, либо должны быть элементами более общего блока, например, layout, тогда будет файл layout.css в котором вы пропишите стили для header, footer, wrapper.
Секция также является отдельным блоком.
3) Блокам block2 и block3 миксуются классы section1__block2 и section1__block3 и css прописывается только блоку section1
4) Можно, и даже нужно, если это исключает дублирование кода, но таким образом вы создаёте зависимость одних компонентов от других (это может быть как хорошо, так и плохо, в зависимости от архитектуры вашего кода). Вообще БЭМ - это не про жёсткие правила
5) Медиа-запросы должны быть частью блока "Сетка с колонками". Все остальные блоки помещаются в эту сетку при необходимости.

1. Общий файл стилей либо файл other.scss. Не столь важно ибо на выходе должен быть один файл стилей
2. Для хедера и футера свои файлы header.scss и footer.scss
3. Порядок элементов можно изменить добавив класс с соответствующим свойством нужному элементу например класс с модификатором _order. Модификаторы пишут рядом с основными стилями блока
4. font-size задавайте только там, где меняется шрифт. Если не хотите дублирования используйте extend в scss
5. Я предпочитаю хранить медиазапросы в том же файле где стили блока, в самом конце

В целом это все условности, нужно делать так чтоб бы было удобно и интуитивно понятно потом редактировать не только вам, но и другому человеку

каком файле мы прописываем стили для .wrapper ? Поскольку это не блок, я так понимаю, что создавать файл не надо и стили надо прописывать просто в начале main.scss ?

Почему не блок? Он вполне может быть блоком без смыслового функционала. Оберточный. Так же через него, через его элементы позиционируются вложенные в него блоки.

2) В каком файле прописывать стили для header, footer, section-1, section-2 ? Они не являются блоками по БЭМ, насколько я понимаю, значит ли это что их надо описывать в main.scss или все таки надо создавать отдельный файл под стили для каждой секции ?

Если вы имеете ввиду теги, то это не одобряется БЭМ. БЭМ оперирует только классами. теги стилизуются через них же. Это сделано для атомизации проекта и легкого переноса блоков из проекта в проект.

Если нам надо изменить это свойство у одного блока, соответственно придется менять и у всех остальных, находящихся в section-1.

Блоки не должны влиять друг на друга, это основопологающая идея БЭМ. Если блоки связаны или влияют друг на друга это уже не БЭМ, а что-то похожее на него. Так же внутри блока следует избегать использования каскада и наследования, это может внести дополнительную путаницу и увеличить связанность блока.

Придется лезть в файл каждого блока и менять свойства, что не слишком удобно, особенно если блоков много

Это вполне удобно и это и есть БЭМ. Ты не лазишь по огромному файлу со стилями, а идешь в маленький конкретный файл где все находится перед глазами.

это не спасает нас от огромного дублирования кода

От дублирования кода спасают миксы. Читайте про них здесь

5) Правильная практика - помещать все медиа запросы, относящиеся к блоку в файл с версткой этого блока, или должен быть отдельный файл под все медиа -запросы ?

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

<head class="head"> 
<div class="block head__block"> </div>
</head>

Соответственно блок класса .block c примиксованным классом .head__block является элементом блока .head и можно менять его геометрию и позиционирование через класс .head__block используя медиазапросы например. Естественно элемент head__block с медиазапросами будет храниться в блоке head и лежать в его подпапке с элементами.
Другой случай это когда через медиа запросы меняется например стиль блока, скажем его цвет. Тогда медиа запрос должен быть внутри блока, а конкретно в его модификаторе например в данном случае у блока block может быть модификатор block_red в котором будет медиазапрос со свойствами при маленьком экране окрашивать элемент в красный. Этот файл с медиазапросами уже будет находиться в родном блоке block в подпапке с модификаторами.
Если где-то не согласны или я ошибся пишите в комментарии обсудим.

1) можно создать отдельный файл для сетки и прописать там. Если нет сетки то сделать его page__wrapper.
класс page повешать на боди
2) сделать их блоками по бем. Вообще это и есть блоки в твоем примере. Все что внутри лучше сделать элементами и выносить в блоки только если нужно переиспользовать еще где то.
3) все изменения блоков через модификатор. При этом блок ничего не знает о своем положении, оно задается через элемент родительского блока
4) для этого можно сделать файлик с базовыми стилями
5) все что относится к блоку в его файле

Я обычно разделяю так: ---------> сделаю на примере синтаксиса sass

main.sass     --------> файл где хранятся глобальные стили(импорты, body, wrapper(центровщик) и тд.
var.sass       -------> переменные с цветами, размерами которые импортируются в main.sass
/blocks/*.sass ------> подпапка в которой хранятся все блоки.

blocks/header.sass ------> хранятся общие стили для блока header, с позиционированием элемента logotype.
blocks/logotype.sass -----> общие стили для логотипа без позионирования блока

А теперь самый главный момент который я поняла, такие вещи подходят когда вы делаете большой, сложно компонентый проект, если вы разрабатываете мелкий корпоративный сайт или лендинг, можно смело "рубить сайт" на отдельные крупные блоки(header,footer,section) - а элементы\блоки, повторяющиеся много раз как logotype выносить в main.sass.