A global setting would be the worse API either, because no reusable code could omit the argument as they would not be able to rely on the default value (there is a reason why we deprecated relying on the old default instead of just changing it directly: it changes the behavior)
Currently, subsections of that tutorial are creating top-level entries in the sidebar table of contents:
Well, inlining the CSS parses the HTML and re-dumps it. So it might be affected by the missing charset.
it needs to be different only because you want to resolve things differently in the CLI and the webserver. In your case, it looks like you want the CLI to generate URLs relative to the project root rather than to the document root. If the dompdf library does not let you configure what is the document root for relative URLs, it is an issue of that library IMO.
And symfony won't automatically change the CLI to generate asset URLs based on the project root instead, because that would break lots of use cases. It would break all cases where you use the CLI to generate some HTML that is then sent elsewhere where URLs will be loaded from the webserver (sending emails from a worker for instance, or pre-generating HTML snippets for a cache).
Have you tried adding the
<meta charset="UTF-8"> in your
<head> to check whether it fixes it ? UTF-8 is not the default charset in HTML (for historical reasons).
Thus, not implementing the deprecated interfaces would be a BC break for code that typehint that interface (defeating the deprecation). I think you have an issue with your tooling reporting that deprecation. For instance, symfony/error-handler allows classes to implement deprecated interfaces without triggering a warning if they are in the same namespace. But here, it looks like there is a confusion between the actual class name and the class alias due to the class renamings done in Twig 1.x to add namespaces
This is an issue of dompdf then, not of Symfony. Not allowing you to configure what is the base for resolving relative URLs does not make sense to me.
To me, a better solution would be to configure your PDF generation to use the public folder as the document root for assets, so that you have the same config for the CLI and the webserver. Otherwise, things will become totally weird when your CLI needs to generate a URL that will be loaded through the webserver (when using a CLI script to send emails for instance).
- But this doesn't work for assets - you cannot use a full URL as
why ? the
src attribute of
<img> supports absolute URLs too