mark_me

document.getElementsByTagName('*').length

Потому что date.getMonth внутри использует this, который с вашей магией теряется.
Вот так будет работать: magic(date.getMonth.bind(date));

В cron не получится задать это условие одной строчкой, проще запускать каждый день, а в скрипте проверять, четный день года или нечетный.

Один тариф - один сайт

"А в ответ - ничего" - в мире linux является симптомом выполненной успешно команды.

а у вас права для выполнения chmod есть? или вы рут?

В случае использования Cloudflare не так сильно имеет значение, где находится ваш сервер. Он будет выдавать ваш сайт и другие ресурсы наиболее близко к пользователю. Достигается это благодаря сети CDN-серверов по всему миру. Полный список вот тут: https://www.cloudflarestatus.com/

При выборе сервера ориентируйтесь на его конфигурацию, стоимость, надежность компании, датацентра, а также на общую развитость интернет-инфраструктуры в стране, ведь данные еще должны быстро передаваться между вашим сервером и Cloudflare. Если нужен именно выделенный сервер, то обратите внимание на Hetzner. Если достаточно мощного облака, то DigitalOcean и Vultr.

Да, это так называемый "Letterboxing", направленный против фингерпринтинга. Выключить можно в about:config установив значение параметра privacy.resistFingerprinting.letterboxing в False

Может поле message.date будет хранить еще и DATE?

Быстрое решение:

SELECT * FROM messages
INNER JOIN users ON messages.receiver = users.id
WHERE users.id = 1
ORDER BY messages.id DESC

вроде как-то так, если правильно понимаю

SELECT m.*, u.* FROM messages m
  INNER JOIN users u ON m.receiver = u.id
  INNER JOIN (
    SELECT receiver, sender, max(date) as date
      FROM messages
      GROUP BY receiver, sender
  ) m2 ON m.receiver = m2.receiver
      AND m.sender = m2.sender
      AND m.date = m2.date
  WHERE u.id = 1
  ORDER BY m.date DESC

но не понятно зачем джойнится users на ресейвера, может все-таки на сендера? ведь в диалоге должны отображаться имена отправителей??

SELECT m.*, u.* FROM messages m
  INNER JOIN users u ON m.sender = u.id
  INNER JOIN (
    SELECT receiver, sender, max(date) as date
      FROM messages
      GROUP BY receiver, sender
  ) m2 ON m.receiver = m2.receiver
      AND m.sender = m2.sender
      AND m.date = m2.date
  WHERE m.receiver = 1
  ORDER BY m.date DESC

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

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

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

inner join table_name as table_1 on table_1. ...
inner join table_name as table_2 on table_2. ...

Так добавьте умножение на ref

SELECT ref, COUNT(ref)*ref as 'ref' FROM `users` WHERE status > 0 GROUP BY ref

Вообще вопрос странный. Если не так понял, приведите пример, что хотите получить.

индексы на обе таблицы на login , потом играться с составным индексом login + date или просто date

Бестолковая затея. Если в плане защиты, как говорят ответы выше. Сделайте заглушку на хост по-умолчанию. Все, кто не прописан на хосте веб-сервера попадут на заглушку.
Для роутинга вроде так и делается.