Растишка

- Представление о MVC имею. Раньше писал пару проектов на CodeIgniter, но на нём на мой взгляд мало что есть из коробки, и много времени уходит на разработку.

С тех пор изобрели Composer, при должном желании прикручивается он и к CI в том числе :)

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

На русском - CodeIgniter, на не русском - Laravel, Symfony и другие.

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

Composer - решает 99% проблем, практически в любом фреймворке.

- Возможность работы с различными БД из коробки

Пока фреймворков без этой штуки не видел, но есть... Вы не поверите, Composer, что бы сменить/поставить "другой" ORM, если Вам "текущий" чем-то не подошел.

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

То о чем Вы говорите, это: Varnish, Nginx+SSI и т.д. кэширование "из коробки" есть в Symfony (т.к. если его отключить, страницы может генерироваться феерически долго)

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

По моему, любой современный фреймворк, если уже даже "Битрикс" небеизвестный до этого до этого дошел... некоторые фреймворки вообще скоро будут требовать PHP7, а не только "поддерживать".

- Проект будет ориентировочно крутиться на nginx+php5-fpm. Думаю практически все фреймворки смогут работать в этой среде, но вдруг...

Я пока таких "вдруг" не встречал. Если у админа голова и руки на месте - то никаких "вдруг" быть не должно. А вообще, у PHP версии 5.х, есть как минимум 3 основных "ветки", это <5.3, >=5.3 или 5.4+ и т.д., ещё кое-какие отличия были в 5.5 и 5.6, но не такие "разительные", подробности можно почитать в истории версий PHP. По этому, нужно конкретнее указывать версию, например, Laravel требует 5.6+

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

Это не возможность фреймворка - а навык программиста/админа.

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

1. Yii2
2. CMS + готовые модули CMS
3. Вы не забыли, что есть... composer?!

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

Большое спасибо за время уделенное прочтению моего вопроса, и огромное спасибо за Ваши ответы.

Не за что! Кнопка "Мне нравиться" - сразу под сообщением :D

1. Можно
2. ХЗ
3. Чоу, круть.

Как вариант, так:

data: {
    ...
    visibility: 'cpu' //активная вкладка по дефолту
},
methods: {
    golist: function(val) {
        this.visibility = val;
        ...
    }
}

<li><a href="#" v-on:click="golist('cpu')" :class="{ active: visibility == 'cpu' }">Процессоры</i></a></li>
<li><a href="#" v-on:click="golist('gpu')" :class="{ active: visibility == 'gpu' }">Видеокарты</i></a></li>
<li><a href="#" v-on:click="golist('games')" :class="{ active: visibility == 'games' }">Игры</a></li>

Вот, например, надо сделать простейшую фотогалерею.

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

$image= new Image(); //создаем пустой объект имаж, чтобы иметь его настройки(таблица, поля...)
$gallery = new Collection ($image); //создаем новую коллекцию объектов типа имаж, пока пустую.
$gallery->getCollectionByField(array("galleryid"=>"64")); // инициализируем из базы, используя
// ид галереи, теперь в гэлери одной строчкой мы загрузили все картинки в свойство (например),
// $gallery->collection  и можем к ним обращаться как к элементам массива, и в свойстве
// $gallery->collection[1] будет объект типа $image. Как вариант реализации.

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

Что касается статики - как говорится в любом нормальном источнике - статики нужно избегать по максимуму, на это есть несколько причин:
- статика загружает оперативку, т.е. статические объекты создаются всегда, не зависимо от необходимости их использования
- статика плохо поддается тестированию, не всегда, но часто, т.к. глобальная область видимости приносит проблемы пересечения зон ответственности методов, часто это нарушает SOLID, особенно если тыкать статику везде. Почитайте, посмотрите как должен выглядеть нормальный код в объектах - вам понравится.

ps:
ваш код - почему бы не писать так:

$post=BLOG::getPost($айди_поста);
// меняем 
$post = new Post($айди_поста);

echo $post['content'];
// меняем 
echo $post->content; // не обязательно так, может вот так:
echo $post->getContent(); // тогда при выводе можно будет сделать какую-то предварительную обработку, 
//заменить тэги, еще что-то...

$comments=BLOG::getComments($айди_поста);
// меняем
$comments = new Comments($post);
echo $comments->getTree(); // хотя тут скорее всего от вьюшки зависит, я бы тут возвращал не 
// строку, а массив для итератора, это правильнее для разделения на мвц, мухи отдельно - 
// котлеты отдельно, в смысле код и хтмл.

Код кладем в базу как есть, меньше читаем про загадочный код который может "повредить базу", больше про PDO и prepared statement. Все косяки могут всплыть только при выводе, если там будет какой-то кривой код - вся хрень произойдет на клиентсайде.

Чаще этот блок известен всем как просто слайдер (реже там статическая картинка с текстом или без или даже видео). Если сверху не было бы явно отделённого меню и весь верх представлял собой единый блок с красочной иллюстрацией и элементами навигации, то подобный верх страницы может называться hero header, а само изображение hero image (ничего общего с заголовком в примере).

UPD Статья с примерами