Александр Талалаев

Не морочьте себе голову берите из проверенных решений, например у Bootstrap так :

// Extra small devices (portrait phones, less than 576px)
// No media query for `xs` since this is the default in Bootstrap

// Small devices (landscape phones, 576px and up)
@media (min-width: 576px) { ... }

// Medium devices (tablets, 768px and up)
@media (min-width: 768px) { ... }

// Large devices (desktops, 992px and up)
@media (min-width: 992px) { ... }

// Extra large devices (large desktops, 1200px and up)
@media (min-width: 1200px) { ... }

Или в обратном порядке (указанный размер либо меньше):

// Extra small devices (portrait phones, less than 576px)
@media (max-width: 575.98px) { ... }

// Small devices (landscape phones, less than 768px)
@media (max-width: 767.98px) { ... }

// Medium devices (tablets, less than 992px)
@media (max-width: 991.98px) { ... }

// Large devices (desktops, less than 1200px)
@media (max-width: 1199.98px) { ... }

// Extra large devices (large desktops)
// No media query since the extra-large breakpoint has no upper bound on its width

Перво наперво настойчиво рекомендую сообщить об этом заказчику, саму верстку выполнить в полном объеме согласно принятому описанию заказа, а далее предложить варианты заказчику. Либо вы заканчиваете полностью просто верстку статичных html для последующей интеграцией специалиста по bitrix в саму систему, либо вы сами берете на себя эти доработки но с условиями расширения времени заказа (и может быть оплаты).
Вашей вины в том что заказчик полностью не описал задачу нет, но и самого заказчика конечно же полностью в этом винить нельзя и будет по честному для заказчика как можно быстрее ему сообщить о проблеме и наиболее легкие пути выхода для всех сторон.
Если там человек адекватный, он оценит честность и думает пойдет вас на встречу если вы аргументировано обоснуете иные сроки или иные условия выполнения заказа.
Ну и в крайнем случае можно закрыть заказ по согласовыванию сторон, если же он подаст жалобу, то у вас тоже есть право жаловаться на условия ТЗ, в которых не было раскрыта истинная сложность задания.
И еще раз повторю, я настоятельно рекомендую быть прежде всего честным с заказчиком, а не стараться сделать то что у вас очень может быть не получится и таким образом неожиданно для заказчика сорвать сроки/качество продукта. Поэтому лучше как можно раньше предупредить, чтобы человек тоже скорректировал свои планы и оценил вашу честность.

Http-редирект реализуется так:
window.location.replace("https://ya.ru");
Поэтому пиши все свои обработчики, проверки и тп, а затем перенаправляй на нужно тебе страницу.

Я вам советую завести на git и хостить(можно к примеру gitlab у них есть бесплатные приватные репозитории ), а можно и не хостить. А сами заметки/блог вести в Markdown. Markdown имеет простейший и удобный синтаксис + есть огромное количество бесплатных редакторов.
Таким образом вы получите портируемую, слабо от чего-либо зависящую систему удобных заметок с историей изменений добавлений.

Ответ на основе обновленных данных
Где-то в модели Product (обновил добавил проверку)

protected $appends = ['prev_product_json'];

 public function getPrevProductJsonAttribute()
	{	    
	    $product = Product::where('id', '<', $this->id)->first() ?? Product::where('id', '>', $this->id)->first();
	    return isset($product) ?  $product->toJson() : NULL;
	}

Ну и после этого где нужно:

$product = Product::find(2);
dd($product->prev_product_json);

PS только сразу подумайте, возможно вам нужно прошерстить поля и создать список полей которые не стоит выводить в json , тогда в моделе делаем protected $hidden = ['field_name'];

Например так
echo number_format('7.220094E-8', 15, '.', '');

github это круто, но смотреть/изучать его никто не будет. Поэтому не важно что туда выкладывать, просто покажи что умеешь им пользоваться, знаешь имеешь понятие о git в целом.
А так лучше показывай готовый живые сайты или собранные тобой клевые штуки на https://codepen.io/ .
ну а в целом, главное для джуна это умение и ЖЕЛАНИЕ учиться. Именно эти параметры важны человеку который тебе будет курировать или вести после найма.

Чаще всего проблема в том что не заданы параметры width и height у viewport
viewBox="0 0 500 200" width='500px' height='200px'
Не обязательно в пикселях, и в целом это не ограничивает дальнейшее масштабирование svg через css или как-то иначе, но позволяет многим браузерам правильно подсчитать размеры изображения.

Разу у вас все сверстано, то разумнее всего задать дивам что перекрывают кнопку свойство pointer-events в значение none.
pointer-events: none;
Таким образом бразуер будет игнорировать события мыши для этих элементов.

У вас будет очень пагубный путь, не советую даже так начинать.
Возьмите хотя бы эту книгу (которая тоже не идеал) и пройдетесь по ней, там как раз хороши путь к тому чтобы написать свой роутер с учетом автозагрузок PSR-4 (в целом глава 6 о MVC).
А вообще читаем это: https://github.com/getjump/ru-php-the-right-way
Исходники вот этого: https://github.com/klein/klein.php
И исходники вот этого: https://github.com/slimphp/Slim

На СЕО это положительно скажется, но прежде всего легче будет людям, так как более понятный, тн человекопонятный URL.
Но только по фильтрам лучше не сокращать, а выводить все.
Ну те в вашем случае:
metro1 - na-dom - Это один параметр разные значение
site.ru/catalog/category1/metro1 - категория и метро
site.ru/catalog/category10/metro1/male - категория, метро и женский пол
site.ru/catalog/category10/metro1/any/ - категория, метро, любой пол
site.ru/catalog/category10/na-dom/male/- категория, выезд на дом, женский
site.ru/catalog/?sort_reviews=ASC&sort_price=DESC - просто сортировка по отзывам и цене, сортировки все же лучше делать отдельно, через классический GET. , его же любым выше можешь добавлять
По факту все эти урлы - GET запросы, просто они прячутся под url.

Route::get('/catalog/{category_name?}/{tip_vyezda?}/{sex?}/', 'FrontController@showCatalog')->name('show.Catalog');

/*Где то в FrontController*/

public function showCatalog() {
$category_name = request()->category_name;
//и тд, обработчик проверки и прочее
}