sulu | Core framework that implements functionality | Content Management System library

If you need to write queries to PHPCR you should use the jackalope abstraction and its query builder so you can write normal SQL 2 queries and jackalope will convert them based on your adapter into the correct SQL query.

If you are interested how jackalope is converting SQL 2 query into SQL queries have a look at its QOMWalker implementation:

https://github.com/jackalope/jackalope-doctrine-dbal/blob/master/src/Jackalope/Transport/DoctrineDBAL/Query/QOMWalker.php

Did you create the sulu project using the create-project command like in the docs. Then you should be under dev environment. Check that by go into your local .env.local and check if there it is set to APP_ENV=dev so changes will automatically be detected and no cache clear is required. This is for development only!!!

If you are on a prod server make sure the clear all cache. This includes admin and website cache:

This is not possible you only have access to the raw form data. For a single selection the gatekeeper value contains only the id of the selected element. Not any data of the element behind this element.

All data you have access to it, you see in save (POST/PUT) request of the form.

The only thing which is possible would be using resource_store_properties_to_request to filter the result of your data_selection by the gatekeeper id, this requires that your data api need to keep the gatekeeper parameter in mind to filter by it:

Thanks a lot for the detailed description! Unfortunately, I am afraid that it is not possible to implement what you are trying to do while using the built-in autocomplete component at the moment.

The resource_store_properties_to_request param reads the values from the data of the form that renders the autocomplete component. If you are creating a new DataGroup entity, the data of the form is empty (because there is now existing data for a new entity) and therefore the resource_store_properties_to_request param is not able to read a dataSetId value.

I am sorry to say, but I think you would need to implement a custom autocomplete field-type that reads the dataSetId value from the current url to achieve the desired functionality. If you are interested in doing this, I would recommend to have a look at the basic field-type example in the sulu-demo repository.

As you have already noticed, the properties in the list configuration are used only for displaying the list in the administration interface. The list configuration is separated from the global search functionality.

The search functionality of the administration interface is implemented by the SuluSearchBundle. It builds upon another bundle called the MassiveSearchBundle. If you want to integrate your custom entity with the global search functionality, you need to do two things:

1. Configure the MassiveSearchBundle to index the data of your custom entity. The MassiveSearchBundle documentation should explain how to do this.
2. Register the index in the SuluSearchBundle to make it searchable via the administration interface. This step is described in the Sulu documentation.

You can use the TagManager service (id: sulu_tag.tag_manager or Sulu\Bundle\TagBundle\Tag\TagManagerInterface):

Best way is to take a look at existing sulu entities with tags e.g. Account or Contact.

The property can be implemented like this:

There are basically three things to do:

1. You have to add a new Translation entity for your custom entity. So if you have an Event entity, you need an additional EventTranslation entity. See https://github.com/sulu/sulu-workshop/tree/master/src/Entity

2. You need to tell Sulu, that your custom entity is translatable by adding the available locales to the view in your AppAdmin class, see https://github.com/sulu/sulu-workshop/blob/master/src/Admin/EventAdmin.php#L74

3. You need to adjust your custom entity's admin controller (it will receive a locale request parameter now) to persist the localized properties to the CustomEntityTranslation instead of the CustomEntity iself, see https://github.com/sulu/sulu-workshop/blob/master/src/Controller/Admin/EventController.php

So as conclusion, Sulu is only responsible for showing the locale switcher in the upper right corner and appending the current selected locale as locale parameter to your api calls. Everything else is completely up to you, you have to implement that like in a normal symfony application

Yes you are right, this is for the filtering by types. These types are e.g. the template-keys for pages and the title is for the translation in the admin ui.

The selected types can be used in your CustomDataProvider with the Sulu/Component/Content/SmartContent/QueryBuilder to filter the items by a specific type.

The DataProviderRepositoryTrait uses the type-filtering on the these lines. You can also overwrite the appendTypeRelation method, if the alias is not correct for your custom entity.

But if you don't need filtering by types, you can just ignore it.