Markus Klein
Markus Klein
Maybe I got something wrong, but TYPO3 definitely extracts @var stuff with the AnnotationReader https://github.com/TYPO3/typo3/blob/master/typo3/sysext/extbase/Classes/Reflection/ClassSchema.php#L220
Thanks for your information. I'm unfortunately not deep enough into these details. Afaik the TYPO3 implementation uses `@var` for data type detection of model's properties. So somehow things are parsed,...
Thanks for bringing this on my table again. I took another look and realized that TYPO3 actually uses the `Symfony\Component\PropertyInfo\Extractor\PhpDocExtractor` to retrieve the type information via PHPdoc. So closing this...
Seems like related to #99 and #18.
The expanders returned, when I adjusted my inky configuration to ``` .pipe(inky({ cheerio: { xmlMode: true } })) ```
I can only second the previous post. We also use other non-standard tags within the templates and those are converted from self-closing to empty tags. In our case the custom...
As noted in #99 I could solve this issue with setting this configuration: ``` .pipe(inky({ cheerio: { xmlMode: true, lowerCaseAttributeNames: false } })) ```
TYPO3 specific bug report: https://forge.typo3.org/issues/86862
> there's not much we can do about this special case RegEx should be designed for failure. This seems to be a classic back-tracking explosion inside PCRE. I honestly have...
Some thoughts about this: First place, the given example doesn't seem to be of real nature but rather a theoretical thing. (Why would you escape a static number?) Second, I...