Павел

Извините, если отвечу резко: зачем Вы плодите сущности? Во всех ОС есть встроенные средства для снятия скриншота. Довольно часто мне рассказывают, что встроенные средства неудобны, но что может быть удобнее отдельной кнопки на стандартной клавиатуре? Нажимаете кнопку print screen и скриншот уже в буфере обмена. Я не знаю Ваши обычные задачи, если надо скрин кому-то отправить-открываете предназначенные для этого сервисы(например) и жмёте ctrl+v. Если надо сохранить локально-открываете графический редактор(paint, paint.net, фотошоп, наконец) и жмёте тот-же ctrl+v. Ещё я слышал, что это долго, открывать пейнт, на что можно возразить, что его можно повесить на горячую клавишу и выходит, что сделать скриншот, и сохранить его можно нажав 4 сочетания клавиш, не используя мыши. Вряд-ли какая-то другая программа позволит сделать это сильно быстрей. А вот занимать место на диске и вносить слабо прогнозируемые изменения в реестр она точно будет.

Переносите элементы .items-left, а проверяете количество .items-right. Думали, что класс сам собой заменится? Нет, так не будет.

Ну судя по всему с адресом у вас все отлично,
Если адрес присвоенный роутеру вы видите на 2ip.ru значит все должно работать.
Может у вас двойной NAT в локальной сети?
Сколько у вас роутеров, где пытаетесь настроить DDNS.
И для чего вам DDNS - по адресу зайти пробовали?

.red {
  background: red;
}

$('.table').on('change', function(e) {
  const $tr = $(e.target).closest('tr');
  const ajaxdata = $tr.find('.ajaxdata').val();
  const subcat = $tr.find('.subcat').val();

  $tr.toggleClass('red', ajaxdata === 'none' && subcat === 'none');
}).find('tr').change();

// или

const table = document.querySelector('table');

table.addEventListener('change', e => {
  const tr = e.target.closest('tr');
  const ajaxdata = tr.querySelector('.ajaxdata').value;
  const subcat = tr.querySelector('.subcat').value;

  tr.classList.toggle('red', ajaxdata === 'none' && subcat === 'none');
})

table.querySelectorAll('tr').forEach(n => {
  n.dispatchEvent(new Event('change', { bubbles: true }));
});

const result = tags.filter(n => active.some(m => m.name === n.name));

или

const result = tags.filter(function(n) {
  return this.has(n.name);
}, new Set(active.map(n => n.name)));

или

const tagsObj = tags.reduce((acc, n) => (acc[n.name] = n, acc), {});
const result = active.reduce((acc, n) => ((n = tagsObj[n.name]) && acc.push(n), acc), []);

В adblock добавьте. В нём можно указать путь до DOM блокируемого содержимого в настройках

вот твоя ошибка
if (empty($mes) or empty($mesname))

Сетевые принтеры расшарить, и установить на ближайших к принтерам компьютерах, как принтер по умолчанию.

USB принтеры можно подключить к самым дальним компьютерам, откуда далеко бегать до сетевых принтеров, или купить принт-серверы, и использовать как сетевые принтеры.

USB принтеры так же можно расшарить для всех, но при выключенной host-машине принтер станет недоступен.

Snappy Driver Installer, как мне кажется

Зайдите по скрину в этот раздел меню и добавьте свой action
На скрине уже добавлен

https://learn.javascript.ru/events-change

<input type="text" id="login"> 
<script>
  var input = document.getElementById("login")
  var data = {
    "login":"",
    "password":""
  }
  input.oninput = function() {
    data.login = input.value;
  };
</script>

Заставить всех использовать LF и забыть об этой проблеме. PHPStorm достаточно умён, что бы и на винде понимать такой формат.

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

const data = $('table tr')
  .get()
  .map(tr => $('input', tr).get().map(n => $(n).val()))
  .filter(row => row[row.length - 1])
  .map(row => `(${row.map(n => `'${n}'`).join(', ')})`);

или

const data = Array.prototype.reduce.call(
  document.querySelector('table').rows,
  (acc, { cells, lastElementChild: last }) => (
    last.lastElementChild.value && acc.push(`(${Array
      .from(cells, n => `'${n.lastElementChild.value}'`)
      .join(', ')})`
    ),
    acc
  ),
  []
);

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

Полноценный CI/CD поднимать не вижу смысла ввиду размеров

вы ж все равно собираетесь какие-то скрипты мутить и чото выдумывать,
какая разница это будут крон скрипты на сервере или джоба в дженкинсе? по-скорости написания - одно и тоже будет. так что по-моему размер тут не имеет значение
единственное что имеет значение - насколько явно у вас описан процесс(алгоритм) билда/разворачивания приложений
с этой точки зрения мое видение примерно такое:

1) git не есть инструмент для развертывания по, git лишь для версионирования кода
и по-идее результатом вашей работы должен быть не код в гитхабе, а какой-то вменяемый артефакт, готовый к деплою (docker-image, pip пакет, npm пакет, deb пакет, jar, war, zip в крайнем случае, и тд и тп). Если производить артефакты то вопрос с тегами отпадет сам собой - у вас будет артефакт какой-то версии и все
сервер не должен знать ни про какие гиты и ни про какие-то теги в нем
Здесь я бы рекомендовал паковать все в докер-имеджи хотя бы только потому, что сервер в итоге не будет знать ничего о зависимостях приложения, нужных библиотеках, ниочем вообще, вам нужно установить только докер
Огромное преимущество использование докера - в Dockerfile вы вынуждены волей/неволей описать точно и явно все шаги требуемые для установки приложения. И что самое замечательное - это все будет храниться в том же репозитории, под контролем гит - шикарно.
Артефакты желательно хранить в каком-то артефактории,
но если реально все просто - то можно хранить несколько последних версий прямо на сервере в какой-нибудь папочке

2) как только вы получили артефакт - его можно деплоить
неплохо было б знать особенности вашего проекта, но грубо говоря допустим что достаточно его зааплоадить на сервер, положить в нужное место
опять же с этим дженкинс справится на ура и займет у вас это все дело 10 минут . Если вы опишете логику в Jenkinsfile вы выиграете еще раз потому что процесс развертывания(алгоритм) будет описан опять же ЯВНО. И будет тоже под контролем гита. (Jenkins должен знать только в каком репозитарии и в каком месте ему искать Jenkinsfile)
Если же вы будете крутить какой-то спрятанный cron скрипт на сервере - о нем никому ничего не будет известно. Поверьте уже через короткое время все это дело начнет усложнятся, что-то забудется, что-то измениться и это все вместе больно ударит вас по яйцам.

В чем еще преимущество такого подхода: если вам нужно сделать roll-back на предыдущую версию вам не нужно собирать проект заново выкачивая все с гита, ведь у вас есть предыдущие артефакты, ролбек в таком случае вообще не проблема - просто указываем предыдущую версию артефакта и деплоим еще раз и все

3) Env Variables
когда приложение стартует - считывает все что ему нужно из переменных окружения
деплой джоба может каждый раз эти переменные устанавливать перед тем как деплоить - это было бы тоже круто потому что вы сделали бы это знание так же явным

Итого имеем
- логика сборки проекта описана в Dockerfile и находится под гитом
- логика деплоя находится в Jenkinsfile и находится под гитом, и что самое главное является кодом (Jenkinsfile пишем на груви, для простых вещей вам понадобиться 30 минут изучения и все)
- на сервере мы ничего не устанавливали совершенно кроме самого докера
- мы храним несколько версий нашего приложения на всякий случай и можем быстро откатиться не прибегая к гиту вообще
- сервер не знает ничего о гитах
- на сервере нет НИКАКОЙ дополнительной логики по разворачиванию вашего приложения
- имея все это очень легко добавлять другие сервера для деплоя - что нам нужно - грубо говоря указать другой айпи и набор env variables к нему ( если они конечно отличаются)