The "core" classes relationship to each other is fairly complex. It is therefor important to understand this relationship before you try to instantiate any of these classes. All core classes are part of the Doorkeeper CMS, and are used for showing, editing, and creating content such as articles or videos. They should generally not be used outside of a core_selector context.
If you only see core_* filenames in the core directory. Good. I will probably have finished much of the work already!
As of the writing of this (26. September 2019), I am still in the process of re-thinking the application logic, with the aim of relying on dependency injection for all classes. The content classes in core are some of the last classes for me to re-write.
When I am done, it will be much easier to maintain the Doorkeeper code, and add new features to the CMS.
Currently, I think the best way forward will be to have each "feature" or "page" handled by a separate class. By this I mean all "article" pages must be handled by the "core_articles" class, and so on.
Note. Currently, all core_ files are new, and might not be fully working / implemented!
- I need a class or switch to dynamically feed the requested feature to the "core_selector" class, which will then attempt to call the correct method for the request. I.e. "show_comments"
- I want to get rid of the "$this->leader" property, since it is very confusing, and hard to remember what it refers to. Maybe I should simply rename it? Currently it simply makes the content classes object available in the content_switch class.
- Get rid of the $this->page_selector object in content.php, and never instantiate classes inside of classes (except for factories)
- Rethink the location of the content classes. The "core" directory is probably not the best place.
- Make content classes use dependency injection instead of confusing class extends
- Consider how to organize / potentially split the content classes into multiple classes.