Classy is a framework for building WordPress themes, based on Blade template engine

Появилась идея сделать небольшой рефакторинг. Идея частично обсуждалась с @konstantp.

В текущей реализации папка models находится внутри app/classes, что на мой взгляд не очень удобно. Я предлагаю перенести модели сразу в app. При этом, в папке classes реализовать дефолтную модель WordPress Post Type, которую будут расширять все модели из app/models. Саму же папку classes переименовать в core. На выходе мы получаем изолированный core от кастомной функциональности, что дает также возможность его обновлять внутри проекта.

Что думаешь @LehaMotovilov ?

Есть смысл добавить namespace Classy; Тогда можно будет убрать методы:

$this->define_constants();
$this->include_core_files();
$this->include_models();

Ну и шаг вперед к best practices. Что думаете?

При динамическом определении констант в методе Classy->define_constants(), моя IDE PhpStorm не понимает что вообще происходит и при каждом обращении к именовоной константе, например к THEME_PATH выдает warning "Undefined constant" и соответственно не работает goto definition.

Может быть есть смысл оставить более прямой вариант без враппера Classy->define()? Что думаешь по этому поводу?

Очень не хватает возможностей @php, @continue(), $loop... Полагаю, связано с тем, что поддержка разработки Classy закончилась до появления этих директив в Blade))) Можно ли лелеять надежду на обновление?) Или если совсем нет времени, укажите в каком направлении двигаться, чтобы обновить его самостоятельно.

classy/app/classes/appearance.php registers theme locations:

register_nav_menus(array(
'header-menu' => __( 'Header Menu', Classy::textdomain() ),
'footer-menu' => __( 'Footer Menu', Classy::textdomain() ),
));

However classy/app/classes/menu.php doesn't support wp_nav_menu function and theme locations and to add a menu into scope you have to pass its ID.

Initially get_content method returned content with applied the_content filter only if $post_content property is empty. Now it applies the_content filter in any case. It fixes shortcodes execution.

I added scripts to composer.json so it is easier to run phpcs and phpmd.

Now you don't need to know the details of the command, you just run composer cs and composer md.

I also added type so that Composer installer will recognize the package as a theme.

Fixes issue with a page that has classy template and is set as FrontPage in General->Reading settings. Initially it was ignored and custom template couldn't be found.

Обновил инициализацию ClassyUser. Там была ошибка в методе импорта. Добавил в PHP CS правила для комментариев в коде. Так же пофиксил все ошибки которые нашли phpMD phpCS в классе ClassyUser.

Так же я не совсем понял суть метода verify_id() добавил туда todo. Как я понял пользоваться нужно вот так?

$some_user = new ClassyUser( 1 );

Тогда veryfy_id толжен вернуть WP_Error? Если все так, могу написать валидацию юзера по id.

Сегодня решил посмотреть класс Comment. Если не смотреть на get/set методы то его функционал в основном заключается в формировании структуры комментариев parent->child. Так же в текущей реализации класс Comment не поддерживает вложеность больше одного уровня.

Я предлагаю в данном случае использовать родной WordPress API для отображения комментов. Убрать логику формирования структуры parent->child из Comment и добавить метод classy_comments для обработки вывода. В общем сделать Comment больше как Helper а не как wrapper для WP_Comment.

Вариант вывода комментариев: views/layouts/comments.blade.php

<h4>{{ get_comments_number_text(); }}</h4>
{{ wp_list_comments( [ 'callback' => [ '\Classy\Comment', 'render_comments' ] ] ); }}

Что думаешь?

У нас небольшая проблема. Вот все варианты как можно использовать класс ClassyUser.

$user = new ClassyUser( 1 ); // User by ID - Ok.
$user_2 = new ClassyUser(); // Must be current user?
$user_3 = new ClassyUser( 234 ); // User not exist.

Первый вариант в принципе понятен. Но с вторым и третим вариантами есть проблема. Во втором случае если пользователь не залогинен мы получаем пустой обьект ClassyUser так же как и в третьем варианте если юзера с таким ID не существует.

object(ClassyUser)[469]
  public 'ID' => int 234
  public 'link' => null
  public 'user_login' => null
  public 'name' => string 'Anonymous' (length=9)
  public 'user_nicename' => null
  public 'user_email' => null
  public 'display_name' => null
  private 'object' => boolean false

Получается что конструктор класа ClassyUser должен кидать Exception что юзер не найден. Что не сильно удобно так как все варианты использования класа нужно будет оборачивать в try catch.