Assistance Needed with Bloomreach Performance Issues and Taxonomy Management

Experience Manager (PaaS/OnPrem)
1

I am currently working on resolving a performance issue within our Bloomreach website. The issue pertains to a filterable search results page, which I am transitioning to a faceted, paginated format. This transition is progressing well, but there are specific requirements from the old page that I need to understand how to incorporate into the new setup.

1. Taxonomy Items with Additional Attributes: Is it possible for a taxonomy item to have additional attributes? For instance, we have a taxonomy item named “In Production” that needs to have a colour value of green. It looks like this:

image
image1171×557 24.2 KB

Currently, documents are tagged with one or more taxonomies and cross-referenced with an internal document containing a large YAML block. This cross-referencing process is a performance concern I would like to eliminate by storing this data directly on the taxonomy item itself.

So far I have managed to understand that I need to add a CND akin to:

[hippotaxonomy:category]
  orderable
  - hippotaxonomy:key (string) mandatory
  + hippotaxonomy:categoryinfos (hippotaxonomy:categoryinfos)
  + * (hippotaxonomy:category) = hippotaxonomy:category
  - hst:color (string) multiple

However this has only shown up in the console.

image

I need it to display here for CMS users too:

image
image1822×930 73.5 KB

2. Facets Built from Taxonomies: Can facets be built solely from taxonomies and sub-taxonomies? Presently, filters on the pre-faceted version are derived from the cross-reference document. I am looking to streamline this by using only taxonomies and sub-taxonomies.

This is what it looks like now and will need to continue to look like after. As you can see it has top-level taxonomies and sub-taxonomies (not different document attributes).

image
image390×907 17.4 KB

3. Scoping EssentialsContentComponent to a Page Request: Is there a method to scope an EssentialsContentComponent to a page request? Specifically, I want to implement the subclasses’ methods in a way that limits processing needs when called from multiple FTL files.

Any insights or suggestions you can provide on these issues would be greatly appreciated.

Thank you for your assistance.

2

Hi Geoffrey,

You’re not yet on version 15.3.0, are you? From that version, the node definition of a category has

[hippotaxonomy:category] > nt:base orderable
- * (string)
- * (string) multiple

which would give you flexibility. Another direction would be to add a custom mixin type on the categories with any property you like. But I’m not sure how that will go in editing and publishing.

Regarding that, to customize the front-end, this requires reconfiguring the class “org.onehippo.taxonomy.plugin.TaxonomyEditorPlugin” at “/hippo:namespaces/hippotaxonomy/taxonomy/editor:templates/default/root/plugin.class” and Wicket coding.

Facets are built using data on document instances so as long as the data is there, it’s possible, because the chosen taxonomy values are saved on document instances.

Not sure what you mean by the scoping question. FTL files do not talk to components, they talk to beans that components have put on the request for them.

Hope this helps!
Jeroen

3

Additionally, maybe easier than the Wicket coding is to hook into the service at
/hippo:configuration/hippo:frontend/cms/cms-services/classificationDaoService so you can save extra information on the document instance at editing (save) time. This may require a mapping/cross reference document but at least it’s not used at site render time.

4

This would seem to fulfil the need we have Taxonomy Plugin Category Detail View/Editor Customization - Bloomreach Experience Manager (PaaS/Self-Hosted) - The Fast and Flexible Headless CMS however the link to the taxonomy-demo project is not working.

Do you have another example link? Or know where that demo was moved to?

5

Hmm seems you’ve found a page that is on 13 and quite outdated… I’ll check it.

The taxonomy demo project was replaced by an Essentials feature, but then that got removed by itself due to lack of maintenance… Code has moved to GitHub, see

Don’t think it has AdditionalFieldCustomTaxonomyEditorPlugin though, but it does extend TaxonomyEditorPlugin (in docs) so that’s indeed the Wicket part.

CHeers, Jeroen