Mizutsune

Удалить символ только если ранее уже было два подобных

s = 'Камера:Разрешение фото и видео:фото: 3840х2160P; видео: 1920х1080P'
result = s.replace(/(?<=(?:.+?[:;]){2})(.+?)[:;]/g, '$1')
// Получим result:
    'Камера:Разрешение фото и видео:фото 3840х2160P видео 1920х1080P'

https://regex101.com/r/gWZ7Ap/1

Если вам надо заменить содержимое нескольких элементов с одинаковым классом, то и выбирать надо не один элемент, а несколько. Соответственно и замену надо производить циклом.

const today = String((new Date()).getDate()).padStart(2, '0');

const dayStartElements = document.querySelectorAll(".js-text");
dayStartElements.forEach((el) => { el.innerText = `${dd}` });

Думаю, такое вполне могло когда-то случиться, но ситуация в целом странная:
1. Deprecated объявляют уже после появления альтернативы
2. Deprecated обычно объявляют, что удалят в такой-то версии

Получается, если раздепрекейтить какой-то метод, то у тебя в будет два способа делать одно и тоже, и придётся официально поддерживать оба варианта. Зачем добровольно брать себе двойную работу?

Когда советуют, убедитесь, что у вас и у аудитории этого совета одна цель. Потому что "как можно скорее начать пользоваться фреймворками" - это если задача - как можно скорее начать шлёпать продукт и деньги получать. А если задача - научиться программировать, фреймворки тут не при чем.

я замечаю что гораздо лучше всё усваиваю когда делаю всё с нуля

Поверьте - так у всех.

Но вы обратили внимание, что в школе вам рассказывали про опыты Галилея, а не дали два шарика и не сказали - разберитесь какой из них падает быстрее?

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

Объем знаний слишком велик чтобы полсностью сгенерировать его самостоятельно. Best practice много и ко всем сразу сам не придешь. Чему-то учиться придется.
Поэтому наилучшая схема чуть-чуть повелосипедить. Изучить пару фреймворков. Попробовать опять повелосипедить. Изучить еще один, а там, может быть, присоединиться к разработке какого-то..

Мой собственный ответ после изучения темы и чтения иностранных коллег будет таким:

Технология была многообещающей и интересной на старте. Для ее поддержки гугл даже придумал отдельную спецификацию HTML Imports: https://w3c.github.io/webcomponents/spec/imports/i... (можете не ходить, там 404), что позволяло подключать однофайловые компоненты прямо в документ так:
<link rel="import" href="my-component.html">
Классно же да?

Но технология не приобрела популярности, возможно так как была слишком простой и понятной, а именно в это время на пик славы вышел npm, gulp и вот это всё. В моду входила непонятная магия, утрата контроля над кодом и всякие оптимизаторы позволявшие сделать для одного слайдера на главной страницы бандл в полтора, а иногда 2-3 Мб. кода, и всё это без всяких там jQuеry.
Ребята одумались и убрали спецификацию HTML Imports, предлагая разбивать компоненты на 3 отдельных файла - js, css и html с шаблоном. Причём js надо было подключать на странице, css тоже, а html должен был загружать по задумке создателей уже в само js. Такой подход позволял резко усложнить работу с web-components и сделать код снова неуправляемым, но было поздно - технология уже уступила позиции конкурентам.
Конечно это был сарказм, если кто-то не понял.

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

Короче технология по задумке хорошая, но на практике не применимая, поэтому широкого распространения и не получает.

Ключи объектов - это строки, если использовать нестроковое значение в качестве ключа, оно будет преобразовано в строку, дефолтное строковое представление объекта - это "[object Object]". Всё.

Хотите, чтобы объект реально был ключом - записывайте его в Map вместо простого объекта. Или научите свои объекты представлять себя в виде строки, переопределив у них метод toString (конечно, поступать так имеет смысл только в том случае, если вы можете гарантировать, что строковые представления будут уникальны).

Это всё просто ужасно. Начиная прямо с первой строчки, class Register extends Database
Делать отдельный класс для регистрации глупо. Если уж делать класс, то для манипуляции юзером в целом, а не одной только регистрации. Плюс, регистрация пользователя - это не база данных. И не должна наследовать классу Database.
По сути, вы хотите натянуть ООП на обычное процедурное программирование. Не надо этого делать, получится самолёт из соломы. Сделайте простую функцию.

Но это ещё цветочки. Остальных проблем тут выше крыши:

1. Никогда не используйте сокращённый синтаксис INSERT. Всегда надо явно перечислять поля. Это, скорее всего, и является причиной ошибки. Но даже если нет, то проблемы всё равно вылезут в будущем
   
2. Собственно сообщение об ошибке нам и надо получить от базы данных, чтобы понять в чем проблема. для этого к коду соединения с БД надо добавить строчку

   mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

   и после этого смотреть сообщение об ошибке
   
3. Самое главное - SQL инъекция. Какой смысл делать регистрацию вообще, если любой дурак узнает пароли всех остальных пользователей или сможет авторизоваться вообще без пароля? Запросы надо выполнять только через подготовленные выражения
   
4. И по поводу паролей. Пароли надо хранить в фаршированном виде, обработанными функцией password_hash()
   

<select id="event"></select>
<select id="dates"></select>

const events = [
  { name: '...', dates: [ ... ] },
  { name: '...', dates: [ ... ] },
  ...
];

const eventEl = document.querySelector('#event');
const datesEl = document.querySelector('#dates');

eventEl.innerHTML = events
  .map((n, i) => `<option value="${i}">${n.name}</option>`)
  .join('');

eventEl.addEventListener('change', function() {
  datesEl.innerHTML = events[this.value].dates
    .map(n => `<option>${n}</option>`)
    .join('');
});

eventEl.dispatchEvent(new Event('change'));

navigator.userAgent
Информацию о браузере - устройствe и тп

fetch('https://api.ipify.org/').then(
  r => r.text()
).then(console.log);

ip

Надо на сервере проверять данные.
И если у тебя всё время значение wazny.com, то зачем его вообще передавать? Если проверять, откуда прилетели данные, то смотри переменную $_SERVER['HTTP_REFERER']. Но, по идее, злоумышленник и это может подделать.

arr.reduce((acc, n) => (
  n = n.match(/(\w+) = (.*)/),
  n && (acc[n[1]] = n[2]),
  acc
), {})

Никак не обезопаситься. Всегда можно посмотреть, что за запрос уходит из браузера и симмитировать его с любыми нужными полями/заголовками/куками.
Данным, пришедшим от клиента, доверять нельзя никогда.

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