Slava Rozhnev

Сосед может банально микроволновкой пользоваться, а у вас Wi-Fi может глючить. Такое бывает.
Или у него свой Wi-Fi, который работает на том же канале и может быть банальный конфликт. Для возможного исключения последнего в роутере поменяйте канал передачи на какой-нибудь другой. А еще лучше на телефон установите какой ни будь Wi-Fi Analyzer и посмотрите, какие каналы больше заняты и выберите какой-нибудь более свободный.

Как комментарий ко всем ответам:
Надо различать объект функции и вызов результата вычисления функции.
Объект - это f
Вызов результата - это f()
На этом и основан фокус.
f() превращается в a
a() превращается в b
b() превращается в print("nested function")
Оно печатает строку.

Не могу удалить foreign table из postgres запросом

Посмотреть в pg_blocking_pids, кто мешает. Сделать с этими соединениями что-нибудь (pg_terminate_backend, например)

Если делать элементарный запрос SELECT * FROM fwd_orders LIMIT 500, то все исполняется за 600ms . А если в этот запрос добавить любой ORDER BY, то выполнение запроса идет 10 и более минут (в таблице более 20млн. строк). Почему так происходит? И как можно ускорить работу?

Посмотреть explain (verbose) на предмет того, что считается локально, а что прокидывается на удалённую базу.
В частности, уточнить у используемого расширения oracle fdw, реализован ли там push-down для order by. По описанию похоже что нет такого и потому вся таблица вычитывается и сортируется локально.

1) никак, да и незачем. файлы жс уже находятся на клиенте, так что все что вы можете - обфусцировать код, но кому надо и так разберется, а кому не надо пофиг в любом виде. Относительно пхп файлов - иx и так никто не увидит с клиента, они исполняются на сервере, и клиенту доходит только результат выполнения скрипта.
2) Никак. Если у вас передаются через запросы какие-либо данные которые не должен видеть пользователь, значит что-то пошло не так.
3) По вкусу, безопасность это никак не гарантирует.
4) Странный вопрос, суть которого вообще не ясна.
5) Выдает с головой полное непонимание что и как устроено и что за что отвечает.
6) Куки не страшные, опасаться не стоит, еще не зарегистрировано ни одного случая нападения куки на человека. Пишите туда данные необходимые для работы приложения. Обычно пароль или другую секретную информацию записывать туда не рекомендуется.

может кто-то пользуется какими-то лайфхаками)

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

1. Сначала определяемся с требованиями к этому http-серверу, и чем не устраивают существующие решения
2. Выбираем из какого-нибудь компилируемого, более-менее производительного языка, с поддержкой асинхронности и удобной работой с сетью:
Erlang, C#, Go, Rust

В таблице transactions хранить тип транзакции и её id (то есть у вас должно получиться как минимум три колонки id, transaction_type (символьный или цифровой код, как больше нравится), transaction_id). Остальные колонки в зависимости от поставленной задачи. Далее, в зависимости от типа транзакции, делать соответствующий join.

SELECT client
FROM ( SELECT DISTINCT client
       FROM Dep
     UNION ALL
       SELECT client_id
       FROM Contact ) total
GROUP BY 1
HAVING COUNT(*) = 1

Или же я вообще пишу глупость

В целом да. Но

вся эта логика прекрасно будет в index.php лежать?

- это гораздо большая глупость.
Ну то есть лежать-то будет, но к MVC уже никакого отношения не будет иметь.

По пунктам

Юзер не должен принимать в конструкторе логин и пароль.
Вот сейчас эта страница отображает мне двух юзеров помимо меня. Их обоих надо создавать с логином и паролем, серьёзно?

Что такое AuthPage вообще непонятно. Модель, контроллер? По базе проверяет модель, куки пишет контроллер. А здесь какой-то кадавр.

Перед тем как писать авторизацию "в стиле MVC", надо сначала разобраться, что такое модель, что такое контроллер, и что такое вью.

Модель - это вся логика приложения.
Контроллер - это интерфейс для общения модели с браузером. Делает всё, связанное с обработкой НТТР запросов.
Вью - отображение.

Как правильно.

Соответственно в модели должен быть класс User с методом auth(), который принимает логин и пароль и возвращает инстанс класса Юзер.
В конторе делается экшен: отдельный метод, который
- проверяет, если был запрос методом ПОСТ, то берет из него логин и пароль,
- валидирует их, если валидация не прошла, то создает ошибку, которую надо показать юзеру
- если прошла, то вызывает метод auth() модели User, передавая в него логин и пароль
- если совпали, то пишет в сессию ид юзера, и делает редирект куда-нибудь
- если не совпали, то создает ошибку, которую надо показать юзеру
- вызывает вью с формой для логина и пароля

Для регистрации делается еще один экшен, который
- проверяет, если был запрос методом ПОСТ, то берет из него данные для регистрации,
- валидирует их, если валидация не прошла, то создает ошибку, которую надо показать юзеру
- если прошла, то то заполняет класс User данными и выполняет метод save() и делает редирект куда-нибудь
- вызывает вью с формой для регистрации

Для личного кабинета делается третий экшен, который берет из сессии ид юзера, обращается к методу read() модели User и через View показывает личный кабинет

Варианты реализации

Самый простой вариант реализации контроллера - это папочка с отдельными файлами-экшенами. Ничего плохого в такой архитектуре нет, этот этап надо пройти, если раньше так не делали.

То есть папка user в которой есть, скажем, файл index.php который является экшеном личного кабинета.
Он проверяет юзера в сессии, и если нету, то перекидывает на auth.php
в auth.php есть форма и ссылочка на register.php
Все три файла инклюдят в себя файл user.php из папки model, в котором есть функции auth(), register() и profile()

Но в более классическом варианта к трем буквам MVC добавляется ещё одна - R, роутер. Специальный сервис, который разбирает адресную строку, и видя, например, что к сайту обратились по адресу /user/register, создаёт экземпляр класса UserController и вызывает его метод register()

<img src="/img/image.jpg" > этого достаточно для работы на любом домене с любой схемой.
если же реально нужно иметь домен в ссылке, то программно вычислять.

также есть тег base.

в общем все зависит от потребности.