I can confirm that my PDFs are identical now with up to date dependencies once I removed the fill="none" from the <svg> root element. I'll subscribe to https://github.com/dompdf/php-svg-lib/pull/105 so I can test whether it fundamentally fixes it when merged.

Hi, First i want to thank's you for the work it's very usefull !

There is a way to change the background-color of an TR based on a condition ? Or maybe a way to put a template for an entier row ?

Thank's you

As the actual rendering is done by the clientside DataTables library we have no facilities for this. You can hook into the clientside events needed for this by taking the Promise returned from initDataTables and take it from there: https://datatables.net/forums/discussion/57940/sorting-breaks-rowrender#latest

The Twig columns do not use LIKE by default because, unlike the TextColumn, they are not inherently expected to be used to just show the field value but greatly enrich it with additional content or mutations. In general, LIKE would have more unexpected behavior in most use cases. You can just override the operator default for a single column.

Having said that, we did document on purpose that, for most cases, rendering a ton of Twig templates per row for many rows can quickly become sluggish at least, and far better performance is achieved for most simple cases, like creating hyperlinks, by hooking into the render of a TextColumn.

So yes, the solution from https://github.com/omines/datatables-bundle/issues/290#issuecomment-1427484088 is what we actually use ourselves. If you inject the RouterInterface into your table type you can make it a oneliner even:

'render' => fn ($value, Entity $entity=> sprintf('<a href="%s">%s</a>', $this->router->generate('entity.show', ['id' => $entity->getId()]), $value),

Thanks @theofidry 😄

For those wondering - now you can upgrade to phpunit 10 but let's just say the current symfony/phpunit-bridge should have a conflict with phpunit 10 as it is completely broken hehe.

Would be great to merge this, currently only blocker on PHPunit 10 install in all my projects.

I'm using the export using the event listener and that works really well. There are a few columns I would like to be able to opt out of an export. I don't see a way to remove those columns. Any ideas?

You can modify the type definition based on whether you are in an export as the DatatableState object exposes an isExport() function.

Does someone else have problem with opcache preloading? Php 8.1.13 (with https://symfony.com/doc/current/performance.html#configure-opcache-for-maximum-performance)

`{"message":"Uncaught PHP Exception TypeError: "Omines\DataTablesBundle\Adapter\Doctrine\ORMAdapter::normalizeProcessor(): Return value must be of type

Omines\DataTablesBundle\Adapter\Doctrine\ORM\QueryBuilderProcessorInterface, Omines\DataTablesBundle\Adapter\Doctrine\ORM\QueryBuilderProcessorInterface@anonymous

returned" at /var/www/oops/builds/20230103-134422/vendor/omines/datatables-bundle/src/Adapter/Doctrine/ORMAdapter.php line 319","context":{"exception":{"class":"TypeError","message":"Omines\DataTablesBundle\Adapter\Doctrine\ORMAdapter::normalizeProcessor(): Return value must be of type Omines\DataTablesBundle\Adapter\Doctrine\ORM\QueryBuilderProcessorInterface, Omines\DataTablesBundle\Adapter\Doctrine\ORM\QueryBuilderProcessorInterface@anonymous returned","code":0,"file":"/var/www/oops/builds/20230103-134422/vendor/omines/datatables-bundle/src/Adapter/Doctrine/ORMAdapter.php:319"}},`

This seems to be an issue with opcache. The error states that an anonymous implementation of QueryBuilderProcessorInterface is not a valid implementation of QueryBuilderProcessorInterface, which is nonsensical. However, I can imagine anonymous classes are tricky to preload as they only exist at runtime, and they have spawned a bunch of problems:

https://github.com/php/php-src/issues/10131 https://bugs.php.net/bug.php?id=79349 https://www.drupal.org/project/drupal/issues/3258987

As this is not something we can fix in the bundle I'm closing the issue.

Specifically those 3 things will break right away once you start to actually use SQL features out of ORM context :)

-- Fresh hell for any kind of pagination, filtering or sorting
SELECT name, sum(amount) FROM user u JOIN order o GROUP BY name;

I'm closing the PR as we agree there is no sufficiently generic implementation that warrants distributing it with the bundle.

Added an adapter that lets you use a basic 'query' to create a datatable.

Usage example:

        use Doctrine\DBAL\Connection;

       ...

        $table = $this->dataTableFactory->create()
            ->createAdapter(QueryBuilderAdapter::class, [
                'queryBuilder' => $this->connection->createQueryBuilder()
                    ->select('*')
                    ->from('someTable')
            ])->...

Limitations:

• Support for column search has not been implemented. Global search, sorting etc. is working properly.

Update README.md

I added an example to my previous comment on how the ArrayAdapter would probably already suffice for the legacy use case.

Thank you for the modifications. I reviewed and discussed this PR with co-author @shades684 and regrettably in your PR we see the exact same problems occur that made us not implement a DBAL Adapter in the first place - your count implementation will break with any kind of SQL construct more complex than a straight query (which breaks the prime reason for sometimes preferring DBAL over ORM), similar for the searching functions which will break on int or date fields etc. etc.

In general we feel it is unlikely that a good generic DBAL adapter can be implemented which will be sufficiently abstracted to distribute with the bundle, as you will in general always be hardcoding towards a specific use case. And for that it is trivial to implement an adapter at the project level.

We think in general it's a better idea that we improve the bundled ArrayAdapter some day, as it provides a most-of-the-way implementation for easily feeding with a SQL result.

Thanks @bsweeney, I'll try to validate that fix and report in that issue.

As this issue is still high on the list when Googling for 'how to prohibit accidentally committing dump statements` - there is an awesome PHPStan plugin that allows you to define forbidden functions and constructs, and is out of the box default configured to do exactly what we want here: https://github.com/ekino/phpstan-banned-code

composer require --dev ekino/phpstan-banned-code