Hi there, I’ve developed a site using v9 and express objects extensively. It’s a historical society. In all three cases, I use the Express Object List to give the visitor options to click any record to read more. The URLs are all fine but my issue is that the detail pages are not indexed in the site search engine.
An example URL that I would like to appear in the site search :https://www.nanaimoarchives.ca/transcripts-and-recordings/historical-audio-recordings/view-recording/view_express_entity/12
Any way to make that happen? Yes, I realize that I can manually create all the pages and install the express detail block and link them up … but that’s a ton of work. There are hundreds of records. Any ideas?
Hi @fridayphoto ,
This is a good point, probably something Express should support in the future. I definitely recommend making an issue for it as a Feature Request here because I think a lot would benefit from it and I’m sure it would get some traction.
In the meantime, I think your best bet would be a custom search that searched the appropriate express object and then figured out its frontend detail page and linked to it.
That is the kind of problem this issue is aimed at resolving. Please add your thoughts.
opened 12:21PM - 30 Dec 22 UTC
Type:Enhancement
Status:Proposal
Enhancement:Level Of Effort:3
Enhancement:Quality Of Life:1
### Description
At present, each kind of searchable entity has its own search… index. There is a search index for pages/collections, a search index for files, a search index for users, a search index for calendar events, search indexes for express objects, and probably more that I have missed.
Whilst there are differences in the structure of these search indexes, there is also considerable overlap in structure and data held.
One of the growing areas of CMS functionality is aggregation of disparate data, so we can have things like boards showing an overview across pages and calendar events.
The proposal here is that all search indexes could be replaced with a single consolidated search index. The primary advantage of this single index will be to facilitate front end and dashboard functionality that aggregates different kinds of entities.
A secondary advantage will be a reduction in not-quite duplicated code. The various search populating and data list classes will benefit from greater common functionality.
A further advantage will be the ease with which further kinds of listed and searchable entities can be incorporated into the index, and hence incorporated into the aggregated usage of that index.
There will be obvious consequences for code that populates the search indexes and to existing classes that use the search indexes. With that in mind, this could be implemented as a phased update across core minor versions.
- v9.N - The new consolidated index is added to exist in parallel with existing disparate search indexes.
- v9.(N+1) - Existing disparate search indexes are marked as deprecated, allowing time for code using the search indexes to be updated to use the consolidated search index. New functionality utilizing the consolidated index advertises the benefits.
- v9.(N+2) - Full switch over. Deprecated disparate search index tables and any remaining deprecated code removed.
For implementation, the columns in this consolidated search index could be a combination of:
- Map equivalent columns together from the current search index tables. (Could this translate directly into the summary fields of boards?)
- A superset of the remaining columns from the current search index tables
- A column to identify the kind of entity indexed.
This would leave a single sparsely populated table of all search data, where any entry provided some common data and a subset of further data relevant to the type of entity indexed.This sparse population may also identify scope for improving the searchability of some kinds of entity, along the lines of "What do we use for the description column for XXX? It doesn't have one? Why not?"