As discussed with @Prokyonn teaser and link content type are a bit differently. But we said that we will go with a LinkLoader and TeaserLoader and so a special "link" and "teaser" resource, that way we don't require a lot of changes for teaser provider and link providers and can keep them currently as they are. But all teasers and links should be loaded via one query per type that way.

@Prokyonn for the PropertyResolvers inside bundle I would remove the Resolver namespace think PropertyResolver is enough. For ContentBundle it make sense to have that namespace for implementation I would skip it. What do you think?

-Sulu\Bundle\ContactBundle\Infrastructure\Sulu\Content\PropertyResolver\Resolver\AccountSelectionPropertyResolver
+Sulu\Bundle\ContactBundle\Infrastructure\Sulu\Content\PropertyResolver\AccountSelectionPropertyResolver

@Prokyonn for the PropertyResolvers inside bundle I would remove the Resolver namespace think PropertyResolver is enough. For ContentBundle it make sense to have that namespace for implementation I would skip it. What do you think?

-Sulu\Bundle\ContactBundle\Infrastructure\Sulu\Content\PropertyResolver\Resolver\AccountSelectionPropertyResolver
+Sulu\Bundle\ContactBundle\Infrastructure\Sulu\Content\PropertyResolver\AccountSelectionPropertyResolver

Yes that totally makes sense 👍

Just as a random thought. Could you also design the system so that it is easy to profile and debug these functions simmilar to the DocumentManager/DebugEventDispatcher?

@mamazu as now all are service tags it is straight forward over the debug:container now:

• Get All property resolvers: bin/console debug:container --tag sulu_content.property_resolver
• Get All resource loaders: bin/console debug:container --tag sulu_content.resource_loader

As discussed we will target the 3.0 for the new resolver and merge other bundles into that branch for easier maintainance, but that will be its own Pull requests.

Moved TODO list into own issue: #7672