alexalexes

Только не пытайтесь в базе хранить буквальное представление ежедневника как двумерной сетки из квадратиков - где пишут заметки на определенный день. Сетка ежедневника - это просто удобная форма вывода данных, но не способ их хранения.
Хранится это все будет, скорее всего линейно и банально списком заметок с заданными начальными и конечными интервалами:
Таблица заметок:
id - идентификатор заметки
begin_date - начало интервала
end_date - конец интервала
comment - заметка
Вот это минимум, что будет содержаться в базе данных в ее таблице.
А уже как будете получать данные этой таблицы и строить представление по дням, рисовать календарик - это уже не задача СУБД, а приложения, которое будет использовать эти данные.

Не привлекая JS, можно поместить все включенные галки в ассоциативный массив:
<input type="checkbox" name="tags[{{ tag }}]">
Если выбрать галку 1 и 3, то на стороне сервера можно перехватить такую структуру как ассоциативный массив:
{'tags' : { 'Тег1': 'On', 'Тег3': 'On'} }
PS: можно сделать неассоциативный массив:

<input type="checkbox" name="tags[]" value="{{ tag }}">

{'tags' : [ 'Тег1', 'Тег3'] }

Но это очень ресурсозатратно, поэтому я хочу создать отдельный серверный обработчик, занимающийся абсолютно всеми обращениями к сайту. Допустим, если сайт называется asd.com, то любое обращение через asd.com (asd.com/registration, asd.com/documents/users, asd.com и т.д.) должно проходить через этот скрипт. Сам скрипт, считывая url запрос, выдавал бы определенный нужный файл, а сама строка url при необходимости изменялась бы при помощи js (pushState и replaceState например)

Ну, вы уже описали технологию, берете любой популярный веб-сервер - php, node.js, python, asp net и реализовываете.

А каким образом вообще можно организовать сервером обработку url

Любой запрос, прежде чем попасть на выполнение в серверный скрипт попадает на обработку на http сервер.
Скорее всего, вы будете работать с apache или nginx. Ответ на этот вопрос кроется в искусстве конфигурирования файла htaccess или nginx.conf.
PS: После того, как http сервер перенаправит запрос согласно правилам конфиг. файла до нужной точки входа - тому файлу-скрипту, с которого начнется выполнение кода на сервере, сам скрипт точки входа может передать управление другому исполняемому файлу компоненту или просто подключать нужные скрипты, согласно параметрам url. Этот процесс называется роутингом, а координирующий скрипт - роутер.
Если вы поищите "Роутер или роутинг в <любимая среда разработки/фреймворк>" то найдете пример реализации.
Причем, роутинг можно реализовывать, как на стороне сервера (роутинг php/laravel/node.js), так и на стороне клиента (клиентские фрейворки, например vue).
Самый наколеночный вариант будет выглядеть так.
После того, как научитесь создавать многокомпонентное серверное приложение и связывать их, можете посмотреть, что такое Rest API, GraphQL, TreeQL.

1. Определяете список заголовков.
2. Определяете offsetTop у каждого заголовка.
3. Определяете scrollTop у прокручиваемого блока.
5. Определяете по offsetTop-ам i-ый и i+1 заголовок, где находится значение scrollTop.
6. Для стрелки вверх делаете scrollTo до i-ого заголовка.
7. Для стрелки вниз делаете scrollTo до i+1 заголовка.
8. Если i-ого или i+1 заголовка нет, то гасите кнопку.
9. На событии скроллинга нужно анализировать пункты 1-8, чтобы кнопки вовремя гасились.

Посмотрите функцию showCart. При каких условиях она рисует пустую корзину, такое состояние поставьте в cart.

function delGoods()
{
    cart = {}; // ... я поставил пустой объект, к примеру.
    saveCart();
    showCart();
}

Если сайт - это форум, то в некоторых форумных фреймоврках (например, IPBoard) предусмотрен вывод страницы списка зарегистрированных пользователей, которая доступна авторизованным пользователям с определенным уровнем прав или стажем (числу написанных сообщений и т.д.). Выводить такой список или нет и в каком объеме предоставлять контакты профиля решает администрация сайта и сами пользователи, если предусмотрены настройки в профиле.
Остальные способы доступа к списку пользователей сайта требует либо членства в администрации сайта, либо не легальны.

Не знаком с Битрикс.
Но для любой CMS должно быть доступно такое решение:
1) Создание роли контент-менеджера под определенный тип контента CMS (роль несет в себе необходимые ограничение к объектам CMS и FTP каталогу);
2) Создание аккаунта пользователя контент-менеджера, и закрепление его за ролью;

Среда выполнения JS в браузере изолирована от железа, поэтому тут нужна полноценная реализация клиент-серверного приложения.
Компьютер с COM-портом будет выступать в качестве веб-сервера.
На этом сервере необходимо реализовать серверный скрипт, который подключится к COM и будет осуществлять транзит по HTTP с клиентом - браузером.
А уже на стороне клиента API будет реализовано посредством JS, а получение данных - AJAX-ом.
Вот пример как сделать серверную часть на NodeJS.

https://habrahabr.ru/post/37686/
Тут для PHP, но для любого backend концепция от этого не поменяется.
1) Перенаправляем все ссылки для получения картинок на скрипт для проверки прав доступа.
2) Проверяем права доступа пользователя по сессионным данным;
3) Все ОК, сессия пользователя жива, файл существует, пользователь является владельцем файла или каким-то образом относится к нему (хотя бы для чтения) - передаем команду nginx серверу отдать файл из защищенного каталога.
4) Не ОК, отдаем пользователю 404.
3.1) Нет nginx ? Читаем файл серверным скриптом (лучше небольшими порциями, для экономии оперативной памяти сервера), отдаем пользователю данные с соответствующим mime-тайпом. На стороне клиента отданные данные прорисуются в img теге или в background-e DOM-элемента, не принципиально, каким образом прилетели бинарные ресурсы от сервера.