View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002249||Composr||core||public||2016-03-03 17:09||2020-02-27 21:41|
|Reporter||Chris Graham||Assigned To||Chris Graham|
|Fixed in Version|
|Summary||0002249: Further metadata improvements|
|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).
|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.|
|Tags||Risk: Major rearchitecting, Roadmap: v11, Type: Cross-cutting feature|
|Time estimation (hours)||20|
I am thinking about how we can more consistently render out different content interfaces uniformly through the main_multi_content block, so that we can significantly cut down on the number of blocks we have while allowing anything to display in any way. We can do that through adding some new render_* methods to the CMA hooks.
get_thumbnail_details($row) // Used for grid, mosaic, slider, carousel
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.
||This is now implemented, although the fine details have diverged a bit. I didn't implement get_parent_row_and_cma_ob/get_meta_description/get_meta_keywords because there was no need, and we want to minimise our code weight overhead given this is very core functionality.|
|2016-12-08 00:44||Chris Graham||Tag Attached: Type: Cross-cutting feature|
|2017-04-08 16:19||Chris Graham||Tag Attached: Risk: Major rearchitecting|
|2017-11-06 10:02||Chris Graham||Relationship added||related to 0003354|
|2019-06-27 18:03||Chris Graham||Tag Attached: Roadmap: v11|
|2020-02-12 03:06||Chris Graham||Note Added: 0006389|
|2020-02-12 03:06||Chris Graham||Relationship added||related to 0003797|
|2020-02-27 21:41||Chris Graham||Assigned To||=> Chris Graham|
|2020-02-27 21:41||Chris Graham||Status||non-assigned => resolved|
|2020-02-27 21:41||Chris Graham||Resolution||open => fixed|
|2020-02-27 21:41||Chris Graham||Note Added: 0006446|