[MOOSE-336] PHP Controller Classes for Blocks

[GeoffDusome]

What does this do/fix?

This pull request introduces a significant architectural refactor to the block controller system, moving dynamic block data handling to dedicated PHP controller classes. This change lays the foundation for a more object-oriented, MVC-style approach, making block logic more modular, maintainable, and testable. The update also includes new abstract controller classes, several new block controller implementations, trait refactoring, and related codebase clean-up. Additionally, there are targeted CSS improvements for card components.

Core architecture and controller refactor:

• Introduced Abstract_Block_Controller and Abstract_Card_Controller base classes to encapsulate shared block logic and attributes, promoting code reuse and OOP principles. [1] [2]
• Migrated block-specific logic into new controller classes for blocks such as Icon Card, Image Card, Image Overlay Card, Masthead Search, Post Card, Related Posts, Search Card, and Terms Block, each encapsulating their own data and behaviors. [1] [2] [3] [4] [5] [6] [7] [8]
• Refactored traits (Post_Data, Primary_Term) for use within the new controller classes, and moved their locations/namespaces accordingly. [1] [2]

Codebase organization and clean-up:

• Renamed and reorganized files to align with the new controller structure and namespaces, including moving Abstract_Controller and traits to a new Abstracts and Traits directory, and updating references throughout the codebase. [1] [2] [3]
• Removed direct usage of traits from post type and taxonomy classes that no longer require them due to the new controller architecture. [1] [2]

CSS and visual improvements:

• Added new PCSS mixins for card hover/focus states and updated card styles to use these mixins, improving visual feedback and code maintainability. [1] [2] [3]

Changelog and documentation:

• Updated the CHANGELOG.md to reflect the new OOP/MVC approach for dynamic blocks and other recent changes.

These changes set the stage for more scalable and maintainable block development going forward, and provide a clear separation of concerns between data handling and presentation.

QA

Links to relevant issues

• Link to Issue

[MlKilderkin]

All good. Just some suggestions and comments

[dpellenwood]

This is really solid, Geoff.

A couple thoughts/points for conversation on the controller approach:

• I'd like to prose that we a a card abstract class is created to house all the "default" card controller logic. Then the individual card types can use and extend that default with any unique or specific implementations.
• We've been here before. SquareOne has a very similar structure fort all its components. One of the most difficult aspects to working on a Sq1 project was that you had to jump back & forth between the core plugin and core theme to build or edit components. I'd like to propose that we move these controllers into the same folder as the render (and other files) . I could see the abstract (note above) living in the core plugin and the implementations living in the theme blocks folders.

Let me know what you think about the above.

[GeoffDusome]

I'd like to prose that we a a card abstract class is created to house all the "default" card controller logic. Then the individual card types can use and extend that default with any unique or specific implementations.

Makes sense to me - I'd like to get some help with this though. I've reached out to Caleb to ask if he has any time to chat through this and will discuss mapping this out.

We've been here before. SquareOne has a very similar structure fort all its components. One of the most difficult aspects to working on a Sq1 project was that you had to jump back & forth between the core plugin and core theme to build or edit components. I'd like to propose that we move these controllers into the same folder as the render (and other files) . I could see the abstract (note above) living in the core plugin and the implementations living in the theme blocks folders.

This is fair and valid. Will consider for final implementation.

[GeoffDusome]

@dpellenwood @MlKilderkin I've overhauled this whole thing to be more inline with DRY programming & what Dave suggested as far as abstract classes. With the help of @crstauf, we decided to make the post data used in the Post & Search cards a Trait so that it can be used elsewhere if necessary. Say, like the Fellow Header block on NHC where it's not a card but still might require post data.

This feels a lot better to me and should allow us to spin up new blocks slightly faster.

Let me know your thoughts!

[GeoffDusome]

cc @Vinsanity - adding you as a reviewer here as well just in case you have any opinions.

[GeoffDusome]

🗒️ Noting that this change & the hover change below it are due to weird rendering where odd numbered em values could be rendered at different heights, causing some elements to have a smaller underline than others.

[GeoffDusome]

🗒️ The post cards in the Moose design system in Figma now have an excerpt and it looked like the cards in the code in Moose hadn't been updated to match, so I did that as part of these updates and styled it here.