View Issue Details

IDProjectCategoryView StatusLast Update
0002249Composrcorepublic2020-02-27 21:41
ReporterChris GrahamAssigned ToChris Graham 
Severityfeature 
Status resolvedResolutionfixed 
Product Version 
Fixed in Version 
Summary0002249: Further metadata improvements
DescriptionIt 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 InformationImproving 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.
TagsRisk: Major rearchitecting, Roadmap: v11, Type: Cross-cutting feature
Attach Tags
Time estimation (hours)20
Sponsorship open

Relationships

related to 0003797 resolvedChris Graham Cleanup queries so can_arbitrary_groupby/remove_duplicate_rows 
related to 0000948 non-assigned oEmbed support (output) 
related to 0003354 assignedChris Graham Tile-based activity feed 

Activities

Chris Graham

2020-02-12 03:06

administrator   ~0006389

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.

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.

Chris Graham

2020-02-27 21:41

administrator   ~0006446

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.

Issue History

Date Modified Username Field Change
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