Михаил Ливач

Исходя из этих строчек

$this->load->model('extension/ajaxfilterdiskov');
$res = $this->model_ajax_filter_diskov->getDisklist($query);

и текста ошибки, можно сказать что ваша модель не загрузилась.Либо вы "нарушили схему" =)
Возможно нужно так:
$this->model_ajaxfilterdiskov

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

learn.javascript.ru

if (event.keyCode === 9) {
  if (event.shiftKey) {
      $('.prev').trigger('click');
      console.log('shift + tab was pressed');
  } else {
      $('.next').trigger('click');
      console.log('tab only was pressed');
  }
}

(?<=>)\+\sещё(?=\s\d+<)

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

Если используете функцию mail, то должны сами озаботиться соблюдением всех стандартов. В частности, все заголовки, в том числе и тема письма, должны быть закодированы согласно RFC 2047. В заголовках допускаются только символы из ASCII-128.

$subject = '=?UTF-8?B?' . base64_encode($pagetitle) . '?=';

А лучше используйте PHPMailer, он сам приведёт всё в нормальный вид.

Типа такого?

В вашем случае это называется просто "удалить элемент". Это умеет любой блокировщик рекламы типа uBlock Origin, AdBlock и прочие. Там есть специальный инструмент "пипетка" - им выбираешь элемент и далее удалением этого элемента будет заниматься уже сам блокировщик полностью автоматически. Кроме того, можно вручную указать селектор нужного элемента.

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

Зависит от сайта и изменений.

• Изменения только в коде и в базе ни чего не изменялось? Тогда вообще стоило бы их через git накатывать.
  
• Изменения как в коде так и в базе:
  
  • Если на сайте не было за это время изменений, то может прокатить развёртывание бекапа.
    
  • Если же сайт активно использовался: создавались заказы, редактировались товары, сделки в Б24 и т.д, то такой вариант не уместен так как будет потеря данных. В таких случаях нужно использовать миграции. Есть много разных вариантов написания миграций, но общая суть в том, что изменения в БД фиксируются в виде скриптов, которые выполняются в момент деплоя. Один из способов управлять миграциями- это модуль sprint.migration.
    
  
  
  
  

Про хром ты заблуждаешься, другие браузеры это тоже поддерживают, гугли "google one tap"

Потому что так исторически сложилось.
1. Очень многие механизмы раньше (а какие-то и сейчас) работают только со свойствами, но не с полями.
А если они и умеют работать с полями - часто по-умолчанию они с полями не работают.
(Это относится ко всяким сериализаторам, ORM, и другим штукам, которые работают с объектами через рефлексию, создают прокси)

2. Даже если ты делаешь автосвойство - ты всё равно можешь делать с ним всё то же самое, что и с обычным свойством: вынести его в интерфейс, сделать виртуальным и переопределить в наследниках, а потом обратиться к нему не на конкретном типе, а на интерфейсе. Это может быть очень полезно, а иногда и необходимо в некоторых случаях

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

По сути всё.
Сказки про инкапсуляцию оставим для учебников, так как если мы делаем какую-то тупую DTO-шку, то никакой пользы от обращения через свойства мы не получим.

Накладных расходов у свойств по сути нет, так как JIT их заинлайнит.
А раз никаких минусов нет - зачем включать мозг и думать "а понадобится ли мне по какой-то причине тут свойство или можно обойтись полем"? А потом ещё огребать, если ошибся (даже если это редкий случай)
Единообразие тут скорее благо.

Те же рекорды (record, record struct) вообще не позволяют тебе объявить поля и при этом скрывают многословность свойств.

к примеру, не сделать этот int отрицательным

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

но вот смысл автоматических свойств я так и не могу осознать, хоть убейте

Смысл автосвойств - чтобы не писать руками { get {return x;} set {x = value;}}.
А смысл свойств вообще - чтобы можно было вынести в интерфейс, переопределить, итд.

А ещё у свойства я могу не писать set или вместо set написать init и required, чего я не смогу сделать в классе с полями.
Да, у поля можно написать readonly и получить по сути то же самое, но тогда его надо будет обязательно через конструктор инициализировать.

Потому что на смартфоне не может быть чисто логически события mouseover. Тут только ставить обработчик события click на какой-нибудь элемент. Есть еще события касания, с помощью которых можно имплементировать свайп (но в вашем случае это навряд ли нужно), здесь подробнее написано.