Rsa97

Получаете инпуты по input[type="text"]

Массивы сложить в массив (const arrs = [ arr1, arr2 ];), дальше есть варианты:

const result = arrs[0].map((_, i) => arrs.flatMap(arr => arr[i]));

или

const result = arrs.reduce((acc, arr) => (
  arr.forEach((n, i) => (acc[i] ??= []).push(...n)),
  acc
), []);

или

const result = [];

for (const arr of arrs) {
  for (const [ i, n ] of arr.entries()) {
    if (!result[i]) {
      result[i] = [];
    }

    for (const m of n) {
      result[i][result[i].length] = m;
    }
  }
}

или

function* zip(data, defaultValue = null) {
  const iterators = Array.from(data, n => n[Symbol.iterator]());

  for (let doneAll = false; (doneAll = !doneAll);) {
    const values = [];

    for (const n of iterators) {
      const { value, done } = n.next();
      values.push(done ? defaultValue : value);
      doneAll &&= done;
    }

    if (!doneAll) {
      yield values;
    }
  }
}


const result = Array.from(zip(arrs), n => n.flat());

Никак не очищать.

На самом деле этот вопрос встречается довольно часто. Вот например популярный ответ на Stack Overflow, который подробно разбирает этот распространённое заблуждение: https://stackoverflow.com/a/3126175. И основная мысль там:

Понятие такой генерализованной "очистки данных" изначально бессмысленное и вредное.

Особенно такой вот индусской функцией, которая сама по себе - пример редкого идиотизма: сначала заменяем символы < и > на HTML сущности... а потом бодро пытаемся вырезать HTML теги. Которых к этому моменту в тексте не останется ни одного!
Или функция stripcslashes, которая здесь вообще ни к селу, ни к городу. Если я хочу написать сочетание \n, то с какой стати эта функция будет заменять его на перевод строки?
Всё что можно оставить из этого безумного набора - это trim(). Да и то не всегда. Как правильно заметил Rsa97, могут быть случаи, когда лидирующие пробелы имеют значение, например, при выводе форматированного кода. Кстати, этим как раз грешит Хабр. Если запостить код с отступами, то первый будет "съеден"!

Очистка

Любая "очистка" (хотя правильнее говорить про форматирование), имеет смысл только в определённом контексте.
И поэтому "очищать" надо только адресно, строго перед использованием в том или ином конкретном случае.

Например, базе данных ни жарко, ни холодно от наличия HTML тегов.
А проблемы могут начаться только при выводе данных в HTML. Но если мы будем предотвращать эти проблемы заранее, то просто попортим кучу данных. Поэтому форматировать данные для использования в контексте отрисовки HTML следет строго перед этой отрисовкой. То есть при выводе.
Что и делают все популярные РНР шаблонизаторы автоматически.
То есть вручную колупаться с "очисткой" вообще не нужно.

Больше того, "очистка" HTML поможет данным, выводимым в яваскрипт, как мёртвому припарки. То есть опять же - всегда надо понимать, в какой именно контекст мы выводим данные, и форматировать соответствующим образом. В частности любые данные передавать в яваскрипт только через json_encode()

И таких контекстов неисчислимое множество. Например, если мы используем переменную для передачи параметров в консольный скрипт, то надо обязательно обрабатывать её через escapeshellarg(). Если в регулярку - то preg_quote(). Имя файла для инклюда из переменной (хотя так делать вообще не стоит) надо хотя бы обрабатывать через basename(). И так далее.

Валидация

Если же наличие HTML тегов в поступающих данных противоречит техническому заданию, то надо заниматься не "очисткой", а валидацией: проверить регулярным выражением, есть ли в строке HTML теги. И если есть, то вернуть пользователю с сообщением об ошибке.

Защита БД

И кстати, по поводу "использую pdo".
На всякий случай уточню, что само по себе использование PDO не защищает ни от каких проблем
Важно помнить, что защита - это когда в базу данных отправляется строго константная строка запроса, полностью на 100% составленная из значений, прописанных в коде РНР, и в ней не используется ни одно значение, пришедшее в код извне. Причем PDO помогает здесь только наполовину, позволяя использовать в запросе подстановки вместо самих данных.
Но при этом для всех остальных частей запроса - например имен полей - у ПДО нет никакой защиты и её надо организовывать самостоятельно. Либо проверяя по белому списку, лабо, по крайней мере, прогоняя через регулярку.

Никак не делать .
Этот вопрос очень часто задают новички, от непонимания базовых принципов

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

Либо тебе это поле вообще не нужно, и его надо убрать, либо просто оставь его в покое и никогда не трогай его руками

Всё здесь https://www.virtualbox.org/wiki/Licensing_FAQ и дальше по ссылкам.
Если я правильно понимаю, то собственно VirtualBox, распространяется под GNU GPL v2, которая не накладывает ограничений на использование. Если умудритесь только им обойтись - можно использовать.
А вот VirtualBox Extension Pack распространяется под лицензией Personal Use and Evaluation License, которая не допускает использования в коммерческих целях. И это на него покупается Enterprise License, которая ещё включает поддержку.

Разберитесь с приоритетом операторов.

Давайте-ка скобок добавлю, чтобы яснее стало, что в каком порядке выполняется:

('ic' + true) ? 'on' : ('off' + '.svg')

Ну и конечно писать подобные выражения в шаблоне - совсем не круто. Вынесите его в вычисляемое свойство или метод, например:

computed: {
  className() {
    return условие ? 'icon.svg' : 'icoff.svg';
  },
  ...

<p :class="className">

Числа из read() приходит в виде строк - последовательности ASCII кодов. Для 2 и 3 это будет 0x32 и 0x33 соответственно (я уже забыл, честно говоря, придут ли они вместе с "\n" или нет).
Короче, вы делите ASCII-коды.

Это очень хороший вопрос.
Ответ на него - никак не использовать.

Да, в mysqli действительно есть специальная функция, которая может сказать, какое количество строк вернул запрос SELECT.
Традиционно употребляется в двух случаях:

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

Первый вариант - это когда мы хотим узнать, вернул ли запрос хоть какие-то данные, или нет. Но на этот случай у нас есть сами данные. Зачем отдельно запрашивать их количество, если мы все равно будем эти данные получать в переменную, которую потом и можно будет использовать чтобы узнать, вернул ли запрос что-нибудь или нет.

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

Правильным решением этой задачи будет сделать запрос вида SELECT COUNT(*) FROM .... В этом случае БД сама внутри себя посчитает количество строк (очень быстро) и вернёт только одно число, которое не занимает оперативную память вообще.

Вот и получается, что функция mysqli_num_rows() является либо вредной, либо бесполезной

В данном случае надо сначала получить записи из БД

// БЕЗОПАСНО выполняем запрос
$stmt = $link->prepare("SELECT * FROM comments WHERE art_id = ?");
$stmt->bind_param("s", $note_id);
$stmt->execute();
// получаем данные
$result = $stmt->get_result();
$comments = $result->fetch_all(MYSQLI_ASSOC);
?>

А после этого уже их выводить

<?php if ($comments): ?>
    <?php foreach ($comments as $row): ?>
         <?=$row['comment']?><br>
    <?php endforeach ?>
<?php else: ?>
    Эту запись еще никто не комментировал
<?php endif ?>

Как видно, никакой mysqli_num_rows нам не понадобилось