We'll need an update hook to enable this on existing sites.

Looks like a lot of this is copied from core, yea? Maybe it would be worth including a comment here to that effect, so future devs can refer back to the core code if updates are necessary etc (in plan and log contexts too).

This needs to be changed from an annotation to an attribute.

Needs an enforced dependency so that it gets removed whenfarm_ui_context is uninstalled.

We'll need to figure out how to do this without an explicit dependency on Gin. We maintain the ability for downstream users to develop/use their own theme by encapsulating all Gin-specific stuff infarm_ui_theme.

Perhapsfarm_ui_theme could install this block, and depend onfarm_ui_context? 🤔

Then it would be the responsibility of downstream users with custom themes to add the block themselves, but at least all the other functionality of contexts would exist.

I'd like to understand this a bit more. It doesn't look like the core issue is getting much action recently, but I only skimmed it.

I see this commit is marked asTEMP: ... - what is the path forward here?

Hmm yeah, afraid I don't remember if this change was enough to display the contextual info load on the "logs" tab for any given asset, or if this change also needs the core path... My hunch is that this change is enough but the comment is confusing.. but I should test.

I think this comment is a good summary of the issue:https://www.drupal.org/project/drupal/issues/2528166#comment-14855963 but yea, doesn't look like that will merge anytime soon because it could cause some breaking change (existing code that expects theasset parameter to only be an ID will fail if this is changed to start returning an entity object)

Tho there is also a larger question if we even want the asset's contextual information available on these pages? I see how this could be an issue if the contextual info UI takes up excessive space on the page but I hope that we can make the contextual information UI minimal enough so that there is little to no reason to ever not include on any "asset page"... otherwise we might as well isolate contextual information to a dedicated page and try to show it in other places... but IMO the ability to bubble up contextual info into more places/pages is the driving factor of this PR 😅

Anyways - adding this additionalasset route parameter to thisview.farm_log.page_asset route definition makes it possible for theContextProvider/AssetRouteContext class to provide the asset into the route's context on these pages without having to know the specific details about thisview.farm_log.page_asset route specifically. This is all important because the route context is used by theFarmContextBlock itself. When rendering an instance of theFarmContextBlock on a given entity page, assetl/log/etc, it means this context will be mapped directly from the route context.BUT the block's context can also be set manually, allowing for the ability to potentially render one or moreFarmContextBlock on demand for one or more entities in a given context (eg: maybe when interacting with the asset timeline?)

Thanks I think I understand a bit better now.

Tho there is also a larger question if we even want the asset's contextual information available on these pages?

Personally, I think the MVP only requires showing the contextual information on/asset/%. If it simplifies this PR to just do that as a first step, and then make next step decisions in follow-ups, I would be OK with that.

This is probably fine as-is, but we should confirm that this doesn't break on plans that do NOT include the defaultasset orlog reference fields. It's possible for downstream plan types to omit those if they want to take their own approach (or useplan_record entities).

(I thought thecrop andgrazing plan modules both did that, but it seems that they are still inheriting theasset andlog fields. That's a separate issue... those should be removed since they are not used by those plan types. I'll make note to follow up on that separately...)

Ah interesting. As long as there is one plan bundle that has aplan.asset field I do not think this would cause an issue - but yes, if there were no plan bundles that had thisplan.asset field, I can see how this might break. IIRCloadByProperties builds a simple entity API query behind the scenes which I do seem to remember failing when specified fields do not exist...