Антон Р.

Потому что переменная $v содержит в себе еще один массив.

<?php
$arr = [
    [6, 1, 13, 7],
    [56, 23, 12, 78],
    [43, 288, 78, 6],
    [77, 12, 65, 83],
];
foreach ($arr as $item) {
	foreach ($item as $value) {
		echo "{$value}\t";
	}
	echo "\n";
}
?>

Я видел битрикс внутри, видел вордпресс. Это совершенно 2 разных подхода к написанию кода.

В битриксе все хаотично, html, js, php, css — все вперемешку, качество кода на уровне мелениума.
В вордпресс все намного лучше, но могло быть и лучше: там очень много функционального программирования, хотя сейчас приоритет отдается ООП.

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

Потому что он не исполняется.
На сервере на настроен РНР

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

Вам просто должно быть интересно.

код свой покажи

Знаю ООП

это ты так думаешь)

Изучаю PHP рекомендуют читать чужой код.

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

Сойдёт, но лучше раскидать сразу на отдельные блоки (даже без ООП) - вы хоть будете видеть что есть Модели, Вьюшки, Контроллеры и роутинг:

<?php

function response($view, $model) {include $view;include $model;}

$models = array(
    'default' => '../model/model_default.php',
    'some' => '../model/model_1.php'
);

$views = array(
    'default' =>  '../view/view_default.php',
    'some' => '../view/view_1.php'
);

function controller($page) {
    GLOBAL $models, $views;
    switch ($page) {
        case 'firstPage':
            response($models['some'], $views['some']);
            break;
        case 'contacts':
            response($models['default'], $views['some']);
            break;
        case 'default':
            response($models['default'], $views['default']);
            break;
    }
}

function router(){
    if (isset($_GET['value']) && $_GET['value'] == 1) {
        controller('firstPage');
    } else {
        controller('default');
    }
}

router();

В PHP сообществе вообще не развиты вопросы проектирования и архитектуры. Большинство лепит, что придумает. PHP изначально родился для примитивных homepage, вобрал в себя всю несерьезность, низкий порог входа и как следствие довольно слабое комьюнити, что часто становится объектом для шуток.

Искать ответы на вопросы проектирования и архитектуры нужно в Java. Например там почти каждый с самых азов слышал о де факто ставшей стандартом слоистой архитектуре, она же layered architecture, она же n-tier architecture и видел изображение похожее на это

Из которой нужно понять, что всю программу можно разделить на несколько слоев и зависимость между слоями должна быть направлена сверху вниз, но не наоборот. Таким образом, например фреймворк может быть инкапсулирован в presentation слой и в любой момент безболезненно заменен на другой, так как другие слои ничего о нем не знают. Вся бизнес-логика инкапсулирована в domain слой в виде plain old java object, который не зависит вообще не от чего, а также предоставляет интерфейсы (репозиториев например) для инфраструктурного слоя и только в этом слое фактически и будет тот самый настоящий ООП, который все так упорно пытаются найти. Никакого стороннего кода в бизнес-логике нет, а соответственно весь сторонний код можно в любой момент поменять, не трогая бизнес-логику вообще.

Для этого нужно открыть какую-нибудь книгу, где за руку проведут с нуля до конкретного приложения построенного с использованием этой архитектуры. Например Implementing domain-driven design, хоть эта книга и о DDD, но я уже говорил, что слоистая архитектура это де факто. С опытом, будет понятно, что в более простых приложениях количество слоев можно уменьшить, понимая на какой компромисс придется пойти, что иногда можно объединить domain и часть infrastructure и получить всем известный шаблон Active Record или вообще выбросить эти слои и получить шаблон transaction script, когда для решения просто не требуется что-то более сложное. Придет понимание, как можно начать с transaction script и в итоге постепенно катиться в сторону domain layer, через active record или не через active record если это когда-нибудь понадобится и тому подобное. Cтанет понятно, зачем, как и когда использовать патерны о которых написал Мартин Фаулер в своей книге Patterns of Enterprise Application Architecture.

Полученные знания можно применить к любому языку. В том числе и PHP. Будет хорошо, если уровень этого сообщества хоть чуть-чуть будет подтягиваться к уровню Java, вместо того чтобы бомбить пятиуровневые ифы создавая такую цикломатическую сложность, что все метрики кода горят ярче красного.

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

Оба автозагрузчика грузят только те классы, которые присутствуют (объявлены new) в этом php-файле:

// Определяем место где лежат файлы классов, которые будем загружать
define('DIR',  __DIR__);
define('APP',  DIR.'/app');

// Устаревший вариант
function __autoload($class) {
    include APP. '/'. $class . '.php';
}
 
// Актуальный вариант с безымянной функцией
spl_autoload_register(function ($class) {
    include APP. '/' . $class . '.php';
});
 
$obj1  = new MyClass1();
$obj1->displayVar();

В вашем примере
namespace something\base;
use something\models\Login;
вы определяете пространство имён и говорите его использовать словом use