alexalexes

https://habr.com/ru/post/183666/
Нужно вооружиться схемой в конце статьи, мультиметром, а лучше осциллографом и убедиться, что микросхема живая и выдает логические сигналы на выводы дисплея. А там уже смотреть, что не так - микросхема, резина или дисплей.

Тип файла вы получили, теперь нужно отдать его заголовком.

$mime_type = mime_content_type($_SERVER['DOCUMENT_ROOT'] . '/assets/js/@ckeditor/ckeditor5-upload/src/adapters/simpleuploadadapter.js');
header( 'Content-type: '.$mime_type);

SELECT  *
FROM  multfilms as m
where m.title like '%Шрек%'
union
SELECT  *
FROM  multserials as m
where m.title like '%Шрек%'

union будет работать, при условии, что выборках одинаковое кол-во колонок и данные в них одинакового типа.

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

И у вас будет единственная таблица с фильмами:
films
атрибуты
id - идент. фильма
content_type_id - тип фильмового контента (внешний ключ к таблице film_content_type)
title - Название фильма
... другие атрибуты фильма

Тогда запрос будет такой:

SELECT  f.*, 
       t.full_name
FROM  films f
join film_content_type t on t.id = f.content_type_id
where f.title like '%Шрек%'

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

Методов перемешивания столько же сколько методов сортировки (разработанных на коленке или имеющие конкретные названия). Просто применяете к функции сравнения в ядре функции сортировки random с разной вероятностью перестановки двух элементов - получаете свой метод перемешивания.

usort($a, function($elem_1, $elem_2)
{
  return rand(0, 1) == 1 ? 1 : -1;
});

parents => '0, -10'
Пропишите id родителей, потомков, которых не хотите обрабатывать сниппетом меню, через отрицательные значения.

Возможно, но вы должны быть на "ты" с технологией Google Sheets API реализованной, например, в виде библиотеки PHP или компонента Modx.
Вам нужно создать сниппет, который будет запускаться периодически, например, раз в 1 минуту и забирать через этот API необходимые параметры и вносить изменения в TV параметры Modx. Сам вызов сниппета, скорее всего, придется привязать к какой-нибудь скрытой странице, к которой будете обращаться через cron.
На изменение TV, скорее всего, будет мало просто вызвать страницу сайта, нужно чтобы сниппет автоматически сам себя авторизовал под учеткой Modx, в которой бы было доступно право на изменение TV (нужно создать отдельного пользователя Modx с обрезанным перечнем прав доступа).

Ничего не понятно. Но из того, что привели в примере и проговорили словами можно слепить это:

$table = Model::selectRaw('title, name_list, count(*) as count, sum(count_model * 2) as total, min(created_at) AS date') // в выбираемые поля нужно добавить title - вы же хотите его извлечь?
            ->groupBy('title, name_list') // сюда нужно прописать группируемые поля, которые не участвуют в агрегирующих функциях count, sum, min и т.д.
            ->orderBy('name_list', 'DESC') // тут пишите поле, по которому сортируете, ASC или DESC - направления сортировки
            ->take(10)
            ->get();

Если вы делали механизм связывания похожих новостей (в ручном режиме указания связей), то с точки зрения реляционной теории баз данных хранение связей реализовано не корректно.
Сложно использовать атрибут rel_id, когда в него записывают несколько значений через запятую.
Вместо данного атрибута нужно создать отдельную таблицу для хранения связей:
news_relation - таблица связей похожих новостей:
атрибуты:
id - идент. связи (первичный ключ)
news_id_1 - идент. новости (первый конец ребра связи, внешний ключ, создайте индекс)
news_id_2 - идент. новости (второй конец ребра связи, внешний ключ, создайте индекс)
Для новости, с id = 1 таблица будет заполнена так:
id, news_id_1, news_id_2
1, 1, 3
2, 1, 4
3, 1, 5
4, 1, 6
5, 1, 7
Если ребра связей равнозначны (неориентированный граф), то достаточно иметь запись, подтверждающую связь от news_id_1 к news_id_2. Например, у вас есть запись связи 3, 1, 5 - связь от новости 1 к новости 5, то не нужно создавать еще одну запись вида 6, 5, 1 - связь от новости 5 к новости 1. При создании и редактировании новости отслеживайте этот момент - не допускайте создание повторных связей в другом направлении (иначе придется использовать distinct в запросе ниже, он будет работать медленнее). Эту неориентированность можно реализовать текстом запроса, не записывая дополнительных данных в таблицу (обратите внимание на условие с or в запросе).
Запрос для получения связанных новостей будет такой:

select n.*
from news as n
join news_relation as nr on (:id = nr.news_id_1 and n.id = nr.news_id_2) -- выявляем связь в одну сторону
                         or (:id = nr.news_id_2 and n.id = nr.news_id_1) -- выявляем связь в другую сторону
order by n.id desc

:id - входной параметр текущей новости

И правильно что убрали, не нужны eval возможности, там где должен быть текстовый параметр.
Для пользовательской обработки есть отдельная функция с явным callback параметром:
https://www.php.net/preg_replace_callback
Получается, что нужно убрать модификатор /e и сделать обертку анонимной функции для нормального вызова функции.

В чем проблема? Пользуйтесь псевдонимами столбцов в селекте.

CREATE TABLE AS SELECT таб_1.стар_название_1 as нов_название_1 from таблица as таб_1

Нужно рекурсивно погрузиться внутрь дерева по ветке первого ребенка на нужный уровень вложенности.

$doc = new DOMDocument;
$doc->load('company.xml');
function get_children($doc, $max_level, $level)
{
  if($max_level > $level)
  {
     if($doc->count() > 0)
     {
       $childs = $doc->children(); 
       return get_children($childs[0], $max_level, $level + 1);
     }
     else
       return null;
  }
  return $doc;
}
$employee = get_children($doc, 2, 0); 2 -  целевой уровень, 0 - стартовое значение уровня.

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

У каждой формулы есть граничные условия применения.
Если входные данные будут неконсистентны для метода, где работает эта формула, будете получать #ЗНАЧ! (если это Excel) и ничего не поминать, почему так случилось.
А со знаниями математики вы будете понимать:
1. Как урезать данные, или заполнить участок, где получаете #ЗНАЧ!.
2. Какие методы применить для автоматической оценки неконсистентности данных, чтобы ваш скрипт сам выявлял эти проблемы на конкретном типе выборки и делал корректировки.

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

SELECT c.id, c.region,
(select count(*)
   from `class_item` c2
   where c.data <= c2.data-- знак будет влиять на направление нумерации
       ) as row_num
FROM `class_item` c
order by с.data desc

Поле data должно иметь индекс, иначе скорость выборки будет падать с ростом числа строк.

Используйте подготовленные запросы, чтобы вставлять параметры в текст запроса.

$stmt = mysqli_prepare($link, 'UPDATE your_table SET name = ? where ID = ?');
mysqli_stmt_bind_param($stmt, 'si', $name, $id);
mysqli_stmt_execute($stmt);
echo "строк изменено: ".mysqli_stmt_affected_rows($stmt);