Hey Carsten,
I have tested it further, and it seems that both the old and the new resource
provider api has the same bug. Correct me if i'm wrong that it's a bug, but the
following occurs:
- The resource provider gets deployed on a specific root (lets say
/content/my-site/a-page), either the
Roy Teeuwen wrote
> Hey Carsten,
>
> Thanks for the info! It seems by the way that the current implementation
> actually even breaks Slin when still using the old ResourceProvider api.
>
> When you have for example a api.ResourceProvider mounted on path /content, it
> will be added to the
Hey Carsten,
Thanks for the info! It seems by the way that the current implementation
actually even breaks Slin when still using the old ResourceProvider api.
When you have for example a api.ResourceProvider mounted on path /content, it
will be added to the excludedPaths of the ProviderContext
Hi,
to simplify the processing of providers we removed the explicit fallback
to a "higher" provider. However, your resource provider gets a context
which it can use to get a resource from a higher provider. So instead of
returning null you explicitely call the parent and return that result
from
Hey all,
We are currently upgrading our environment, and of course the new resource
provider SPI is now available. But it seems that our current resource provider
would not be able to be used in this new SPI, seeing as in the old one you
could dynamically look if the resource provider could
