#2249 - Further metadata improvements
-
By Chris Graham
- Added
- 2 views
| Identifier | #2249 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | Further metadata improvements |
| Status | Completed |
| Tags |
Risk: Major rearchitecting (custom) Roadmap: v11 (custom) Type: Cross-cutting feature (custom) |
| Handling member | Chris Graham |
| Addon | core |
| Description | It would be good to merge parts of the set_extra_request_metadata function, _create_partial_node_structure method, and some code from content.php, into a cleaner "content object" model. This would be done via improving the existing content meta aware hooks.
Each content meta aware hook class would extend a new base class from content.php. For this, we'd need to guarantee anything loading these hooks has already called require_code('content') first. The new base class would have functionality currently distributed around... - string get_image_url(array $content_row) - string get_title(array $content_row, int $render_type) - string get_description(array $content_row, int $render_type) - array get_row(string $content_id) - array<array,object> get_parent_row_and_cma_ob(array $content_row) - Tempcode get_view_url(array $content_row) - Tempcode get_edit_url(array $content_row) - Tempcode get_add_url() - Tempcode get_archive_url() - string get_meta_description(array $content_row) - array get_meta_keywords(array $content_row) - (the existing run methods would be coded in as abstract, so the hooks must implement them) $render_type would be either RENDER_PLAIN, RENDER_COMCODE or RENDER_HTML. Most of these could be implemented in the base class, with only a few cases of them having to be overridden. Any of the static data currently passed in via set_extra_request_metadata should be renderable as a method of the hook, so that the page itself doesn't need to be the only way the metadata can be accessed. set_extra_request_metadata calls would therefore consist of empty arrays and only passed $content_type and $content_id, for any situation where a page directly maps to a content object (there are cases where it doesn't though, e.g. support tickets). Anything in the code currently handling the 'CALL:' title gathering encoding would have been replaced with a clean get_title call. The basic implementation for get_image() would be able to look for images in custom fields, so that we may more reliably always find images if they are somewhere. For override cases the image would be found via other means, e.g. the download hook would check for images attached to a download (which is currently what is done for the set_extra_request_metadata call). |
| Steps to reproduce | |
| Additional information | Improving the metadata system allows loads more opportunities. For example, we could automatically query out all content from the system and render Windows-style tiles for it. We could implement oembed-output support. |
| Related to | #3797 - Cleanup queries so can_arbitrary_groupby/remove_duplicate_rows |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
render_box($row)
render_tile($row)
get_hyperlink_details($row)
get_thumbnail_details($row) // Used for grid, mosaic, slider, carousel
render_columned_table($rows)
Once we have main_multi_content being able to render out different content interfaces, we can then look to see if a lot of the current catalogue and gallery code can be removed and main_multi_content used instead.
There may be other parts of Composr that can be vastly simplified to use the new hook functionality, e.g. the newsletter what's new hooks.
Also generally we should review what is using the CMA hooks and see if their use can be better abstracted to functionality from the CMA hook base class or functions in content.php. I don't like that lots of different parts of Composr right now are likely accessing CMA metadata manually and doing weird stuff - it should be more centralised.
Anything that relies on getting images or titles via metadata in CMA hooks should ideally be able to do so even if it requires querying the content row first (e.g. for catalogues). I think right now there are some cases where titles and images just won't be supported for particular content types.