rPman

Во первых, ты создаешь html а не excel, да офис умеет открывать такие файлы и даже не ругается, но если хочешь работать с документами напрямую, работай с .xlsx или .ods (open document стандарт поддерживается везде и всеми, это стандарт для документооборота, пользуйся лучше им) - это по факту архив с текстовыми xml документами

По факту, настрой кодировку, с которой ты будешь общаться с базой данных set_charset либо поменяй свою кодировку в php коде на ту же что выдает база данных (utf-8) и пропиши в твоем html в в заголовке

Вместо if в таких случаях используют switch case.

Альтернатива - определи map с ключом твои сравниваемые значения и значением делегат Func или экземпляр класса с виртуальным методом. Но что бы ты не делал, синтаксически это не добавит тебе простоты, а просто переместит в другое место определение кода и сравниваемое значение.

Есть еще препроцессор #if или даже собственный кодогенератор, иногда оно оправдано.

Городить что то сложнее switch нужно, когда логика, стоящая внутри кода около каждого из вариантов значения, может быть свернута в общий единый код или наоборот, он весь сводится к коротким инструкциям,красиво смотрящимся в виде анонимных функций, которые неплохо смотрятся в виде констант иннициализатора map

Не пользуйся крон, это худший способ запуска кода 'как можно чаще'.

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

Этот скрипт запускать, создав простейший сервис

В вопросе сказано 'автоподключение', это значит в коде нет желания писать где то connect или аналогичную ему строку иннициализации.

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

И вот тут возникает вопрос о месте хранения настроек. Если для всего проекта предполагается одна база данных с одним одномоментным подключением, то значит настройки должны храниться глобально (в подавляющем большинстве случаев это отдельный подключаемый файл config.php с инициализацией констант в define) либо в конфигурационном файле, десериализаторов которых пруд пруди, используй хоть .ini (parse_ini_file) хоть .json хоть что угодно.

Я пользовался разок определением констант в виде статичных мемберов класса, подключаемых прямо внутри определения класса с помощью include (синтаксически это красивее define и не требует городить громоздкие уникальные имена)

Так же возможна ситуация, когда вообще нет глобального объекта для работы с базой данных, точнее когда этот объект никто не удерживает кроме 'его самого', а доступ к нему организован через функцию, например:

function db()
{
  static $db=false;
  // до появления static у функций можно было хранить и запрашивать объект у самого класса статичным методом
  if(!$db) $db=new Database();
  return $db;
}

....

db()->query(...)

в этом случае подключение к базе будет сделано в момент первого доступа к ней, что иногда даже полезно

Все на так просто как кажется!

Первое, так как экономика у нас в мире все еще фиатная, то платежи в криптовалюте должны восприниматься просто как еще одна платежная система.

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

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

Поэтому - выбираешь биржу/банк, где у тебя будут храниться твои фиатные резервы, соответственно брать котировки нужно именно у этой биржи (а везде они разные). Брать нужно не тикер, а стакан depth (список bid/ask лимитных ордеров клиентов биржи) и из него вычислять, в зависимости от объема сделки! по какой цене исполнятся ордера на покупку вашей криптовалюты (bids), минус комиссия за сделку, получишь нужную цену. Это сделки - по маркету. Повторяю - в зависимости от объема сделки, стоимость криптовалюты - разная, чем выше объем тем больше спред между купи продай. Ты можешь разработать торговый алгоритм, который, изучая текущее поведение рынка, совершать сделки покупки и продажи не по маркету (так как сделки по маркету при крупных сделках - заметно дороже, да и при мелких по факту удваивает/утраивает комиссию совершения сделок) но создание надежного такого алгоритма уже вопрос на миллион (и если ты такой создашь, то ты уже сможешь зарабатывать как трейдер, извлекая доход из спреда и волатильности, зачем тебе тогда магазин?).

Так как держать весь свой депозит на бирже ты не захочешь (потому что биржи в криптоэкономике не регулируемые и могут совершать любой пиздец какой пожелают, например отжать у тебя депозиты, закрыть твои позиции по худшей цене, я не про маржинкол, задержать депозит или запретить внезапно лично тебе торговлю и прочее, по собственному желанию) то эти риски и к примеру затраты на регулярный вывод так же должны быть заложены в комиссию. Можно не использовать централизованные биржи, а пользоваться dex (например тот же uniswap или проекты с бесконечной ликвидностью как syntetix), это защитит тебя от произвола бирж но будет стоить заметно выше (комиссии выше на этих рынках, к примеру на эфире легко могут дойти до полутора тысяч баксов за сделку, правда такое редко происходит)

Теперь самое грустное, либо цены у тебя будут плавающими (ежесекундно изменяющиеся) либо твой магазин должен выступать буфером, фиксируя на какое то время цены на товары, рискуя резкими колебаниями цены, например добавляя свою комиссию на этот счет (ее придется считать самому, к примеру вычисляя из текущей волатильности на рынке криптовалют). Ведь помимо исключения прыгающих цен в прайслисте, есть еще время, с момента, когда клиент уже запустил процедуру оплаты и получил адрес для перевода криптовалюты + сумму, и до того момента как сеть биткоин подтвердит этот перевод, и это время может исчисляться часами (клиент тоже может тормозить).

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

Так же возможно использование инструментов маржинальной торговли, т.е. вместо спотовой биржи и продажи криптовалюты, можно на момент, пока совершается сделка по продаже товара, держать короткую позицию (продажа) на нужную сумму, с плечом, держа в залоге меньшую сумму чем нужны сделке, но рискуя этой суммой, если рынок криптовалют начнет движение 'не в ту сторону' (рост цены).

p.s. замени криптовалюту а любую валюту, и получишь все то же самое но для международных торгов. Просто фиатные валюты менее подвержены волатильности (хотя во время экономического кризиса могут становиться похожими на горки в криптовалютах) а значит риски, которые несет магазин, минимальные... и заморачиваться с подобными схемами, особенно мелкой рознице, нет никакого резона.

Если фрейм на том же домене что и создавшее его окно, то получив элемент штатно getElemenById а затем получай его document вот так:

var frameDocument = myFrame.contentDocument || myFrame.contentWindow.document

Так же можно получить доступ к фрейму (точнее его winodow) если задать ему атрибут name с помощью:
window.frames["имя фрейма"]
и уже от полученного получить document

Имея доступ к document, можно уже запрашивать любые элементы на странице и править их

p.s. там много исторических наслоений от разных браузеров, советую протестировать выбранный способ, в т.ч. на мобильных

p.p.s. если фрейм чужой, то доступа вы к нему иметь не можете (под вопросом домены третьего уровня, это вопрос исследования, мало ли как браузеры это реализуют), так как иначе это будет страшнейшая дыра и доступ злоумышленника к вашим личным кабинетам на сайтах.

Полный доступ к содержимому фреймов имеют браузерные плагины, или к примеру твой собственный браузер на базе готовых компонент

Проверь, может в самом коде php стоят команды типа ini_set('memory_limit', '128M');

То есть если пользователь запросит пароль в 13:59 у него будет не 30 секунд на ввод а всего одна секунда. Как с этим можно бороться?

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

Что именно убрать? слишком большой код?, заверни в функцию с передачей имени переменной в аргументах:

function cache($name,$callback)
{
	static $cache = [];

	if(isset($cache[$name])) return $cache[$name];
	return $cache[$name] = $callback();
}

var_dump(cache('graph',fn()=>DB::getRecords()));

и ошибки получения данных разрули, и инвалидацию (тогда к cache нужен доступ из разных методов, а значит лучше оформить в виде класса, или если процедурно, добавить управляющий параметр в функцию)

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

Мы тут можем только гадать, если это HTTP Authorization Basic то у тебя должны быть логин и пароль, эту авторизацию поддерживают все основные библиотеки, на php все пользуются curl, первый же пример из гугла

Делать авторизацию само собой нужно на сервере, иначе если делать на клиенте, то секретный логин/пароль (или ключ) станут доступны всем пользователям. Т.е. с клиента должен идти запрос в твоем формате, а сервер уже формирует правильный, получает ответ и возвращает клиенту.

Используй семафоры, там есть инструменты по отсылке сообщений между процессами машины, на linux всегда включена, на windows сборках к к сожалению нет

Иначе реализуй на основе сокетов, тогда будет пофиг на какой машине в кластере работает процесс

Если переменная нужна в каждом запросе в течении некоторого времени и небольшая по размеру, то можно сохранить в сессионных куках setCookies а в php $_COOKIE[имя]

Когда то, там где это было не критично, бакэенд я делал в виде примитивной прослойки для базы данных и хранения sql запросов, т.е. клиент в запросе выдавал идентификатор запроса и список его параметров именованным массивом, а сервер возвращал табличку как есть, код на php чуть ли не десяток строчек плюс список sql запросов. Если запросов за раз бывает много, ввести возможность отправки их пакетом....

Немного сложнее с запросами на модификацию, сами запросы не сложные но нужно будет как то описывать ограничения, что можно к примеру удалять или править а что нет, в общем под задачу, но точно так же как и с запросом данных на чтение, бакэнд выступает исключительно простой прослойкой к вызовам методов sql драйвера (понятно что до вызовов по методам доходить не стоит, т.е. к примеру после вставки записей insert можно тут же вызвать lastInsertId и вернуть его в ответе, а так же проверить на ошибки и собрать подробности (запихнуть в лог и выдать клиенту)

websocket

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