ThunderCat

Давайте я возьму вас за ручку, и погуглю с ложечки.

Вот я беру вашу ошибку, "No connection could be made because the target machine actively refused it" копирую в гуголь (если не понимаю по-английски, то добавляю слово "ошибка"), и оно мне человеческим голосом говорит,

Ошибка «No connection could be made because the target machine actively refused it» означает, что сервер, к которому вы пытаетесь подключиться, либо не запущен, либо недоступен, либо не слушает соединение на указанном порту. Чаще всего эта проблема связана с тем, что целевой сервер не запущен или неправильно настроен, но также может указывать на переполненный резерв сервера или проблемы с брандмауэром.

Что конкретно вам непонятно в этом объяснении?

Добавляю к запросу слово openserver и получаю

Ошибка «No connection could be made because the target machine actively refused it» при работе с Open Server означает, что сервер не запущен или недоступен, или же неправильно указан порт. Чтобы исправить это, нужно запустить Open Server из папки установки и убедиться, что серверные компоненты работают, или проверить правильность адреса и порта в настройках приложения, которое пытается подключиться.

Что конкретно непонятно в этой инструкции?

(а потом поколение снежинок удивляется, почему к ним такое отношение. сейчас уже даже по ссылкам ходить не надо, умная железка уж и разжёвывает, и в рот кладёт - а они всё "моя твоя не понимаю"!)

Blade в этом плане сложен - он "компилируется" в настоящий php и кэшируется, поэтому реальный стек сложно сопоставить с исходником.

Поэтому надо писать в нём минимум логики, а всю работу производить в контроллере. В шаблоне у вас не должно быть никаких $_GET и уж конечно никаких

$cats=$site->qa("select * from categories where catid=0  order by name asc");

Тогда они будут простыми и ошибку будет сложнее совершить и гораздо легче найти. А если она случится в контроллере, то там уже трейс будет нормальный.
Использовать нормальный фреймворк, но при этом писать в нём код так, как будто на дворе до сих пор PHP 5.2 - это странно.

ORDER BY date DESC 
LIMIT 2

Получите последнюю и предпоследнюю записи.

Я просто вставляю order by date (поле даты) и забираю последнюю строчку.

Глупо.

Используй ORDER BY date DESC - и тогда можно, во-первых, брать первую строку, а не мотать вниз до последней, во-вторых, нужная "предыдущая" строка при обратной сортировке будет "следующая" - ну то есть вторая.

PS. Дата - ненадёжный критерий сортировки. За один день комп могут сдать на склад и выдать другому товарищу - и будешь ты гадать, какая из двух записей актуальная, а какая для неё предыдущая. Я уж не говорю о вводах и корректировках "задним числом".

У вас файл создан под Уиндоуз, в которой в качестве разделителя строк используется последовательность \r\n
Разбивая по \n, вы в конце каждой строки оставляете висеть символ \r, и в итоге при сравнении совпадает только последний элемент файла, после которого нет перевода строки

Для чтения файлов в РНР есть специальная функция. Которая понимает любые переводы строк, и умеет их автоматически удалять.

$array = file(JPATH_SITE.'/list.txt', FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES);

И всё сразу начнёт находиться.

Чтобы ограничить количество выводимых страниц требуется знание арифметики в пределах начальной школы.
Чтобы вместо 1 и $num_pages использовать заранее рассчитанные значения, укладывающиеся в определённый интервал. Например 10 страниц.
То есть надо всего лишь определить начальную и конечную цифры, которые подставлять в for вместо 1 и $num_pages.
Например, если мы хотим выводить только 10 страниц, а текущую выводить посередине то для получения первой цифры надо отнять от текущей 4. Затем к ней надо прибавить 9 - так мы получим второе число.
При этом, разумеется, надо проверить, чтобы первое не было меньше 1, а последнее - больше $num_pages.
А дальше просто подставить их в for. Вот и всё.

Почему «пропали» коммиты?

Главная ошибка — использование --amend во время rebase.
Команда git commit --amend не создает новый коммит, а перезаписывает предыдущий.

Когда вы время интерактивного rebase на каждом шаге делаете --amend, вы по сути всё время заменяете один и тот же коммит. Остальные коммиты, которые Git должен был «применить» в процессе ребейза, просто исчезают, потому что их заменили.

Как делать правильно?

Во время rebase -i вместо amend нужно:

git add <файлы> #  главное проиндексировать правки файлов
git rebase --continue # тут гит уже сам сделает git commit --no-edit

Вручную делать git commit перед continue имеет смысл только если вы хотите поменять ещё и сообщение коммита.

Как восстановить утерянные коммиты

Git не удаляет коммиты сразу. Они остаются в репозитории и доступны в reflog — журнале ссылок.

Их можно найти так: git reflog

Затем восстановить ветку: git reset --hard <хеш_из_reflog>

Вывод

Это не баг Git, а ожидаемое поведение. Просто rebase + amend — взрывоопасная смесь, особенно если не до конца понимать, что происходит.

Неделя начинается с понедельника и идентифицируется своим порядковым номером в году. Первой календарной неделей года считают первую неделю, содержащую первый четверг текущего года. Последней календарной неделей календарного года считают неделю, которая предшествует первой календарной неделе следующего года. ISO 8601.
Соответственно, 2024-12-29 - воскресенье, последний день последней, 52-й недели года.
2024-12-30 - понедельник, входящий в неделю, где четвергом является 2025-01-02, то есть в первую неделю 2025 года.

location ~ ^/phpmyadmin/(.+\.php)$ {
    root /usr/share/phpmyadmin;

Путь к файлу формируется путём простого добавления URI к значению директивы root.

URI = /phpmyadmin/index.php
root = /usr/share/phpmyadmin

В итоге nginx будет искать файл /usr/share/phpmyadmin/phpmyadmin/index.php

Если в root убрать лишний /phpmyadmin.

location ~ ^/phpmyadmin/(.+\.php)$ {
    root /usr/share;

nginx будет искать файл /usr/share/phpmyadmin/index.php

Стоит использовать те фреймворки, которые вы знаете, а то будет мало пользы

Коротко - потому что IEEE 754

Выполняет он математические операции правильно, но некоторые числа компьютер просто не способен представить со 100% точностью, тк для них нужно было бы бесконечное количество памяти.

Точно также, как мы не можем записать все цифры числа 1/3 в десятичной системе, точно также и компьютер иногда не может записать все цифры в двоичной.

Если ты работаешь с деньгами, то тогда используй то, что делают все банки - представляй суммы денег не как дробные числа, а как целые. Например место 1.5 рублей записывай как 150 копеек. Запятую добавишь при выводе человеку.
btw тут в комментах пишут, что для денег тоже есть паттерн по-лучше конкретно для php.

Если при делении у тебя получилось дробное количество копеек - округляй так, как велит закон.

Если ты делаешь какие-то математические вычисления - возможно тебе нужны рациональные числа.
Не знаю, что обычно для этого в пхп используют, но нагуглил https://github.com/webgriffe/rational
https://github.com/markrogoyski/math-php

Но в случае с целыми числами ты всё равно можешь упереться в ограничение на максимальное число, а в случае с рациональными числами ты получишь очень сильную просадку в производительности.

Если тебе критически важна скорость, а точность - не так важна, то оставайся на IEEE754 и просто округляй то N значимых цифр (обычно больше 5 цифр мало кому нужно)

Потому что типом данных double нет возможности представить число 0.58. Поэтому компьютер берёт наиболее близкое к 0.58 число, которое double может выразить.

Если вам нужны точные вычисления, то следует воспользоваться специальными функциями:

$format = bcdiv("580000000", "1000000000", 2); // "0.58"

var_dump(bcmul($format, "100")); // string(2) "58"

Существует даже специальный сайт, рассказывающий о данной особенности математики чисел с плавающей запятой: https://0.30000000000000004.com/