04:09:10 <benjamin_654> Opk: nice! I did not know about this fork. Will have a look at it.
11:18:03 <drlimbo> HI NamelessCoder, i just updated to VHS 2.3.0 (from 2.2.0) but now the "v:page.header.meta" fails and the documentation wasn't updated
11:18:10 <drlimbo> PHP Warning: Missing argument 2 for FluidTYPO3\Vhs\ViewHelpers\Page\Header\MetaViewHelper::renderTag()
11:23:19 <NamelessCoder> please check out development and try again
11:24:16 <NamelessCoder> and as far as possible please don't forget to give the development branch a try - every error like this you catch before we release is an error we don't end up releasing ;)
11:24:43 <NamelessCoder> (as in: give it a try *regularly*) ;)
11:28:39 <NamelessCoder> oh yeah - and we ask for a lot of patience in the docs updating. It's not yet automated so there are some manual actions involved, plus very long cache life.
11:28:55 <NamelessCoder> it *will* get better, trust me ;)
11:29:06 <drlimbo> oh, with your latest commit it works well NamelessCoder
14:04:07 <Outdoorsman> NamelessCoder, should I submit a new bug for what we found yesterday? Which extension should the typoscript order of precedence issue be reported in?
14:15:30 <NamelessCoder> no need, I'll be fixing that momentarily ;)
17:39:37 <Outdoorsman> NamelessCoder: Currently the first typoscript line is the one that is written last regardless of the 10 or 20... shouldn't it be the last line that overwrite the first one?
17:46:35 <NamelessCoder> it should be using the one with lowest priority last
18:19:56 <Outdoorsman> NamelessCoder: Not arguing, but it seems it should be the other way around. For example in typoscript if I enter page.includeCSS.file1=fileadmin/local.css and then on the next line enter page.includeCSS.file1=fileadmin/local2.css, local2.css is the one that's used.
18:21:25 <Outdoorsman> The last one overwrites the first one.
18:25:44 <NamelessCoder> yes, that's true for standard typoscript. There, the order of lines is all important. But when you configure objects that use those numeric indices, the rules change. Most (but not all!) of those objects will internally sort the sub-objects/values according to that numeric index
18:25:57 <NamelessCoder> page.includeCSS is *not* among those that sort
18:28:48 <Outdoorsman> Okay... I'll take your word for that one then.
18:29:15 <Outdoorsman> More feedback... ss for the templateRootPaths.10, the numbers at the end don't make any difference yet, just the line item order in.
18:29:38 <NamelessCoder> rule of thumb is: if the indices are truly numeric and only numeric is supported, the array is sorted. That goes for most COA, USER etc. objects you see in TS
18:30:47 <NamelessCoder> for templateRootPaths etc. in a Flux context those arrays should now be sorted, assuming all the caches are nuked and you pulled Flux very recently
18:31:34 <Outdoorsman> I *just* pulled it and cleared cache. I didn't do a full rm -rf typo3temp/* though... I'll try that in case something is hanging on.
18:35:27 <Outdoorsman> I just hard flushed cache and the numbers are not being sorted yet.
18:38:46 <NamelessCoder> yeah I think you're right... it does sort, but in the wrong order
18:45:42 <NamelessCoder> now this should match how the core's View classes expect to receive the paths
18:46:14 <NamelessCoder> it internally just uses the order it is given - and Flux is now giving it the right order. I actually thought the core reversed it internally but it seems it doesn't.