Download the PHP package dakataa/crud without Composer

CRUD Dashboard

Create fast and easy CRUD Dashboard. This package itself works as a REST API and can be used with ReactJS Package @dakataa/crud-react, or you can enable Twig version by adding additional package @dakataa/crud-twig.

How to Install

1. Setup Symfony Project.

2. Create Entity And Form Type

3. Add package to composer

   add routes without recipe in config/routes/annotation.yaml:

4. Allow controllers to inject services. Add this code to your services.yaml controllers are imported separately to make sure services can be injected

5. Create first controller. Standard way:

   If you want to customize the initial query, add a #[QueryResolver] attribute to your controller (or to a specific action method). It is resolved before the query is executed and receives the current CRUD action.

   resolver accepts:

   • the name of a method on the controller (resolved via getResolverContext(), i.e. $this by default),
   • an invokable class (SomeResolver::class, instantiated with new, must implement __invoke),
   • any other PHP callable (e.g. a static method array or Closure).

   Restrict the resolver to specific actions with the actions argument, e.g. #[QueryResolver('buildCustomQuery', actions: ['list', 'export'])]. Without it, the resolver applies to every action. You can also put #[QueryResolver] directly on an action method — a method-level attribute takes precedence over the class-level one for that action.

   with Make Command

Action Discovery

The /_crud/actions endpoint returns CRUD action metadata for frontend clients such as @dakataa/crud-react. The React client uses this metadata to build action URLs, labels, visibility rules, and permission-aware UI.

Action metadata can include permission information, but the frontend must treat it as discovery data only. Every action endpoint must still enforce access on the server side when the action is executed. Client-side AJAX checks are useful for hiding or disabling UI controls, but they are not a replacement for backend authorization.

Access Resolvers

Use #[AccessGrantedResolver] to customize permission checks for columns, additional fields, ACL entries, and actions. The resolver receives the request, permission, generated security subject, default authorization result, and CRUD service container. It must return the final boolean result:

Use #[ActionAccessGrantedResolver] for additional action-specific rules. Its resolver receives the request, action, entity object, result from the regular permission check, and CRUD service container:

The standard Symfony authorization result is calculated first. The class-level AccessGrantedResolver can then adjust the general permission result, after which ActionAccessGrantedResolver determines the final result for an action. ActionAccessGrantedResolver can be declared on the controller class or an action method, supports the optional actions filter, and gives a matching method-level resolver precedence over a class-level resolver. Returning anything other than a boolean causes an UnexpectedValueException.

Entity Resolver

Use #[EntityResolver] when an action must load its entity with custom lookup logic instead of the default repository identifier lookup. The attribute can be placed on the controller class or directly on an action method.

An entity resolver can be limited to specific actions with actions: [...]. For the current action, a matching method-level resolver takes priority; when there is none, the matching class-level resolver is used. Like the other resolver attributes, resolver accepts a controller method name, an invokable class, or another PHP callable. The callable receives Request and CrudServiceContainer and must return an instance of the configured entity class or null when the entity cannot be found.

Response Context Resolver

Use #[ResponseContextResolver] to add application-specific display data to a CRUD response without changing the built-in action workflow. The resolved data is added under the context key in both JSON responses and Twig template variables.

The resolver receives the request, current action, raw runtime context provided by the action, and the CRUD service container. It must return an array:

The resulting JSON contains:

The same values are available in Twig as context.helpText and context.isEdit.

The runtime context contains the original, non-normalized action data:

• list: items and pagination meta;
• view: object;
• add and edit: object and form.

Runtime context is available only to the resolver and is never included in the response automatically. Only the array returned by the resolver is exposed under the response's context key.

The attribute can also be placed directly on an action method:

#[ResponseContextResolver] is repeatable. Class-level resolvers run first, followed by method-level resolvers. Their results are combined with array_replace_recursive(), so a later resolver can override an earlier context value:

Like the other resolver attributes, resolver accepts a method name on the controller, an invokable class, or another PHP callable. A resolver that returns a value other than an array causes an UnexpectedValueException.

The resolver runs for CRUD actions that produce a standard JSON or template response, including list, view, add, and edit. Redirect and streamed actions such as delete and export do not produce response context.

Form Type Options Resolver

Use #[FormTypeOptionsResolver] to customize the options passed to the configured Symfony form type. The resolver receives the request, current action, current entity object, current options, and the CRUD service container, and must return the complete options array:

The attribute is repeatable and can be placed on the controller class or on an action method. Matching class-level resolvers run first, followed by matching method-level resolvers. Each resolver receives the options returned by the previous one, so later resolvers can add, replace, or remove options. As with the other resolver attributes, resolver accepts a controller method name, an invokable class, or another PHP callable. Returning a value other than an array causes an UnexpectedValueException.

Form Submit Resolvers

Use #[FormSubmitResolver] and #[FormSuccessResolver] to run custom logic for a valid submitted form without coupling that logic to Doctrine persistence.

For a valid form, the lifecycle is:

1. All matching FormSubmitResolver callbacks run.
2. If the controller has an #[Entity], the form data is persisted and flushed.
3. All matching FormSuccessResolver callbacks run.
4. The success message and optional redirect response are created.

For an invalid form neither resolver is called. An exception from a resolver interrupts the remaining lifecycle and is not converted into a successful form response.

Both resolvers receive the request, current action, submitted form, and CRUD service container:

Resolver callbacks should return void; any returned value is ignored. The attributes are repeatable and can be placed on the controller class or directly on an action method. Matching class-level resolvers run first, followed by matching method-level resolvers. Within each level, resolvers run in declaration order. Use the optional actions argument to limit a resolver to specific CRUD actions.

Forms Without an Entity

An #[EntityType] can be used without an #[Entity]. In that case the valid form is not passed to Doctrine, but both resolver phases still run. This is useful for contact forms, imports, commands, searches, and forms backed by an array or DTO:

When no custom success message is configured, entity forms use Item was saved successfully, while forms without an entity use Form submitted successfully.

Migrating From Form Save Hooks

The former beforeFormSave() and afterFormSave() controller hooks have been removed. Replace overrides as follows:

• beforeFormSave() → #[FormSubmitResolver]
• afterFormSave() → #[FormSuccessResolver]

Additional Data Fields

Use #[Fields] to include data in the result without displaying it as a column. List plain field names, or use a field name as a key with its options array as the value. The optional roles, permission, and useFlatKey arguments apply to every field in that declaration:

Each field becomes a Column with visible: false, searchable: false, and sortable: false. The keyed arrays are passed directly to Column's options; they do not configure its other arguments. Multiple roles are evaluated with OR semantics. When both roles and permission are present, both checks must pass. Use an explicit Column for searchable fields or other column configuration.

Fields is repeatable, allowing fields with different access rules or flat-key behavior to be placed in separate declarations. It follows the same class/method scope as Column: method-level declarations apply when that method declares its own Entity; otherwise class-level declarations are used. It also adds fields to columns configured through Entity(columns: [...]). An explicit column takes precedence over a matching field, without merging options. Declaring the same field in more than one Fields entry raises a configuration error.

Column Value Resolver

For each column, compileEntityData() resolves the displayed value using the following priority chain, stopping at the first one that applies:

1. #[ColumnValueResolver] — if present and applicable to the column, its return value is used as-is (including null or false).
2. Column getter — if the column declares an explicit getter option, get{Getter}() is called on the entity.
3. Query-selected field — if the query added an extra selected field under the column's alias (e.g. via addSelect('... AS someAlias')), that value is used.
4. Property fallback — otherwise get{Field}(), has{Field}(), or is{Field}() is tried on the entity in that order.

By default (steps 2-4), you don't need to do anything — columns resolve themselves from the entity. Use #[ColumnValueResolver] when a column's value needs custom logic (formatting, computed values, cross-entity lookups, etc.):

Just like #[QueryResolver], resolver accepts a method name on the controller, an invokable class, or any PHP callable, and can be scoped with fields: [...] (instead of actions) to only run for specific column fields:

It can also be placed on an action method to only apply to that action, falling back to the class-level resolver otherwise.

Once a value is resolved (by any of the four steps above), it goes through normalization before being sent to the client: Collections are joined into a comma-separated string, DateTimeInterface values are formatted (dateFormat column option, default ATOM), BackedEnums are reduced to their scalar value, and remaining arrays/objects are JSON-encoded unless the column is marked raw. Finally, if the column declares an enum map, the resolved value is looked up in it for display.

Column Visibility Resolver

Use #[ColumnVisibilityResolver] to include or exclude columns according to the current request. The resolver receives the request, the current column, and the CRUD service container, and must return a boolean. Returning false removes a regular column from the response metadata and row data, as well as from the generated filters, sorting, and query column selection. Entity identifiers may still be included internally because CRUD actions require them.

The optional fields argument limits the resolver to the specified column fields. Without it, the resolver is called for every column. The attribute can be placed on the controller class or directly on an action method. A matching method-level resolver takes precedence over a class-level resolver.

As with the other resolver attributes, resolver accepts a controller method name, an invokable class, or another PHP callable. Returning anything other than a boolean causes an UnexpectedValueException.

How to extend templates

Map URL parameter to entity column

How to ...