Exclude based on noindex or sitemap exclusion and hide UI

Have not tested but could https://www.drupal.org/project/conditional_fields → do this?

@smustgrave I don't think so. conditional_fields is mostly frontend (States API) related, isn't it?

Eh think I was getting crossed with another issue on this module.

As far as these processors go I’d be willing to host sub modules for the certain sitemap modules

Question instead of a processor would some alter hook adding states make more sense?

Okay so what do we think about this

We add the processors to the main module with a check like Search API Exclude Entity - Metatag

And that radio button is disabled if metatag isn't installed on the site.

Actually couldn't figure out how to check a module in the processor so moved to a sub-module

Thoughts?

Great work @smustgrave! I think a submodule makes even more sense.

Code looks good and is a perfect template to solve the following similar functionalities:
- Exclude based on XML Sitemap → exclusion of the entity
- Exclude based on Simple Sitemap → exclusion of the entity
- Exclude based on field value ✨ Exclude entity based on a field value Postponed: needs info

All solving different important use-cases and I think the code would be quite similar, so we're not far from there.
From my perspective, all these would serve well as separate submodules. So we have a wide range of typical exclusions afterwards.

I asked @Grevil to try and review this one, when he has the time.

PS: Might make sense to show the effect of this module somewhere in the UI (for all these modules). For example adding a description to the "noindex" checkbox field of the metatag setting, if this module is enabled, so the person who uses it, is aware of that. Same should happen for the other cases in #17. I guess these should also be separate tasks, perhaps under a parent task?

Created a meta for additional processors.

Also learned via slack that we don't need submodule but can use a hook or function to check if processor applies to this index.

@smustgrave I'd still say a module would be better, as it exposes the integration in the module list and shows that if you have module X + Y you can use this feature, which would need to be documented somewhere else instead.

So even if technically possible, I'd stay the submodules are the better choice! And they better decouple the modules transparently. But the maintainer decides, of course.

Can agree with that.

How do we feel about merging this one and do a beta release for 3.0.x branch? See if it gets people interested.

So want to get a 3.0.x beta release out for D11 and have it include least one of these additional exclude tickets so merged this one.

smustgrave → closed merge request !13

Automatically closed - issue fixed for 2 weeks with no activity.

@smustgrave could we maybe have a new release with this?

It should be in the beta2 release is it not working?

Thanks @smustgrave I'll check that, couldn't find it in the module list, sorry. Will report tomorrow!

@smustgrave my apologies! I had ^2 installed and didn't see it. Works great, sorry for the noise!