08:14:05 <trezndzetter> last week you saved me from giving up on the deployment
08:14:31 <trezndzetter> now I am happily trying out and developing the first templates
08:14:57 <trezndzetter> I wonder how you guys get rid of cache
08:15:22 <trezndzetter> If I change my translationsfile it doesn't appear immediatly
08:15:36 <trezndzetter> and not after flushing all caches.
08:15:36 <NamelessCoder> mikemm you can safely ignore that version constraint but you may need to explicitly install VHS then fluidcontent_core and ignore the warning.
08:16:16 <NamelessCoder> trezndzetter use development context for TYPO3 and the "clear system cache" cache clear method
10:05:37 <jmverges> NamelessCoder, did you see the issue that I raised? https://github.com/FluidTYPO3/fluidcontent_core/issues/132
10:05:48 <NamelessCoder> jmverges yes, I will get to that when I have time
10:06:13 <pedda> tsob tells me there is a plugin.tx_fluidpages.siteRootInheritance property available
10:06:23 <jmverges> ok, so, do you think that is a issue or is working for you?
10:06:40 <pedda> but not at the moment if a page is created in list mode
10:06:53 <pedda> i can coppy a page within the page tree though
10:07:07 <NamelessCoder> pedda the difference from before to now is that the Flux ConfigurationManager is expected to be registered as implementation. It works the same way as the standard ConfigurationManager except it supports additional ways of determining the page UID
10:10:09 <NamelessCoder> https://github.com/FluidTYPO3/flux/blob/development/Classes/Configuration/BackendConfigurationManager.php#L114 should be called and should return the right page UID
10:11:56 <NamelessCoder> this is purely a matter of resolving the TS that applies to the currently edited page UID - it should be quite simple
10:17:43 <pedda> if i debug the whole configurationManager->getConfiguration(…) i get some output where plugin. is not empty but fluidpages is missing
10:18:37 <pedda> i can see felogin, flux, formhandler and tt_address, lets say .. all those "i include my own piece of ts config on load" extensions
10:19:42 <pedda> as mentioned earlier.. because of basic.autoload em setting i would expect fluidpages to get listed among these
10:20:48 <NamelessCoder> that's fine in that location: the typoscript at that point is only responsible for controlling your overrides of inheritance behavior for the template selector field
10:21:50 <NamelessCoder> https://github.com/FluidTYPO3/fluidpages/blob/development/Classes/Service/PageService.php#L155 is used to resolve available selections
10:22:02 <NamelessCoder> (it also uses the overridden ConfigurationManager)
10:23:23 <NamelessCoder> https://github.com/FluidTYPO3/fluidpages/blob/development/Classes/Service/ConfigurationService.php#L73 is where the TS-related part happens: fluidpages reads all registered provider keys and resolves the view configuration (either what is set in TS or it uses fallbacks with default paths) and stores the path configurations for each provider extension key
10:24:00 <pedda> but as $typoScript['plugin.']['tx_fluidpages.' ] i'm talking about line 112 and 113 of PageLayoutSelector (just to make sure) where in line 113 removeDotsFromTS is utilized on a null value because line 112'S var is lacking of plugin.ty_fluzidpages
10:24:03 <NamelessCoder> pedda I assume you also have seen https://github.com/FluidTYPO3/fluidpages/commit/b5fd17bd69315589ea77a77202fc5eb0255cf0f1
10:24:43 <NamelessCoder> yes pedda - that's expected. The TS option is not documented and may be removed and fluidpages itself does not define the TS in plugin.tx_fluidpages
10:25:10 <NamelessCoder> but it is NOT that location that is responsible for storing your actual template paths - that has to reside in plugin.tx_yourext.view
10:26:36 <NamelessCoder> what works now: registering a provider extension key + controller name "Page" and having valid template files in that location. The TS defining view paths for your provider extension is optional now - and you can use any of the supported ways of setting the paths
10:27:03 <NamelessCoder> let me just throw some more links at you... ^^
10:27:44 <pedda> always good to know about those, as the most information about breaking changes can be taken from commits only regarding ft3 tools imo
10:27:49 <NamelessCoder> pedda you already have the links that removed the legacy bit and I've shown you the places where we now rely on the new ConfigurationManager to resolve our TS.
10:28:21 <NamelessCoder> pedda then comes, once merge, https://github.com/FluidTYPO3/flux/pull/758 - which will enable the use of any supported structure for defining templateRootPath, templateRootPaths, overlays.xyz.templateRootPath etc.
10:29:29 <NamelessCoder> currently to resolve the view configuration we call this method: https://github.com/FluidTYPO3/flux/blob/development/Classes/Service/FluxService.php#L288 which checks if TS is set and if not, uses the method right above it to generate defaults
10:29:51 <pedda> as i was able to create pages until yesterday, and i didn't update/upgrade flux by now
10:29:56 <NamelessCoder> the method there should be 100% safe from any errors that is NOT caused by incorrectly setting the TS (which I assume you are doing correctly)
10:30:22 <pedda> i enabled some overlay by the help of View.. this is the only thing i did in the last 24 hours related to template paths
10:31:19 <NamelessCoder> you should consider EXT:view deprecated; flux either has or is soon getting native support for the ways the core defines multiple root paths
10:31:37 <drlimbo> we used this way to include an icon: icon="{v:extension.path.resources(path: 'Icons/icon-twitter.png')}" - but icon="" is depreceated, so we should use options="{icon: 'Icons/Content/Example.gif', ...
10:31:42 <NamelessCoder> and I very much would appreciate if you find the time to test the pull request(s) flux#758 ;)
10:31:52 <drlimbo> is there a way to use the v:extension.path.resources with the options="{icon: way?
10:34:02 <NamelessCoder> drlimbo see https://github.com/FluidTYPO3/flux/blob/development/Classes/ViewHelpers/Form/Option/IconViewHelper.php (not yet published to docs). Usage: <flux:form.option.icon value="{v:extension.path...}" />
10:35:34 <NamelessCoder> it's easier to use than <flux:form options="{icon: '{v:extension...}'}"> but has the same effect - and you don't have to escape single quotes inside the options array values
10:36:04 <drlimbo> thanks NamelessCoder, so <flux:form.option.icon should be used inside <flux:form, right?
10:37:22 <xaver> icon should work without any option /Resources/Public/Icons/{Content,Page}/id.(png,gif...)
10:37:56 <NamelessCoder> drlimbo true, what xaver said. You may want to check out the automatic icon-by-convention resolving
10:38:23 <NamelessCoder> place your icon at the expected location and Flux uses it automatically, no need for the flux:form.option at all and better performance.
10:38:37 <drlimbo> if i add the <flux:form.option.icon viewhelper, it crashes the "Tab-Layout" -> https://www.evernote.com/shard/s8/sh/b816c4ee-f9c1-4d60-b2c3-b486a1fde994/a51b7e56c46ddbddcb9ff5e73d36afd1/deep/0/ogbase--TYPO3-CMS-6.2.9-.png
10:39:04 <NamelessCoder> drlimbo then you don't have the most recent code and much of what has been suggested will not work
11:02:21 <drlimbo> i can't find a way to re-enable the messages (i changed debug to 1 or 2 in extension settings of flux)
11:02:45 <xaver> drlimbo: or take a look here https://github.com/bootstraptheme-for-typo3/fluidbootstraptheme/blob/development/Resources/Private/Templates/Content/Carousel.html
13:58:18 <pedda> i can solve my issue only if i revert fluidpages right before 28ac27f
13:58:48 <pedda> i tried to follow your explanation, which was a bit too much for me, but anyway
14:01:28 <pedda> as far as i can understand what happens on the mentioned lines 112 and 113 in PageLayoutSelector, there is no way to perform GeneralUtility::removeDotsFromTS($typoScript['plugin.']['tx_fluidpages.']) successfully if $typoScript['plugin.']['tx_fluidpages.'] is null
14:03:11 <pedda> i can'T explain why it is null, as i would expect the ts path to exist due to the em setting of EXT:fluidpages called basic.autoload
16:49:12 <jousch> Are there any plans to support dynamically precompile sass,less files combined with the assets viewhelpers?
17:31:53 <NamelessCoder> hey jousch - the plan is to have an extension that's dedicated to assets and uses assetic or similar as engine, but nobody seems to want to do it :)
18:28:17 <jousch> Thanks NamelessCoder, the question came up at the t3board15
18:33:20 <NamelessCoder> people ask it now and then :)