08:21:49 <vizArt> hi: ISSUE: BackendConfigurationManager on CLI Scripts (https://github.com/FluidTYPO3/flux/issues/668) is still broken in version 7.1.2
08:22:30 <vizArt> the fork from akii (https://github.com/Akii/flux/commit/391c02093f0aafa5e919d729429e010b4acba76c#diff-27bf5883578afaf149e9b26735ad57df) works.
08:32:05 <vizArt> I noticed this first time nov.2014 ... https://fluidtypo3.org/community/irc-logs.html?tx_fluidtypo3org_content[date]=20141119&cHash=1addc7ada531144b667e5745b9be95be#09:56:30
08:32:31 <vizArt> but today i remebered after my sheduler wont work after update
08:39:10 <Akii> NamelessCoder: somehow a change that was merged is unmerged
08:39:20 <Akii> that one https://github.com/FluidTYPO3/flux/pull/706
08:39:24 <NamelessCoder> Akii recently I removed some methods from Flux's ConfigurationManager because they were behaving exactly like the inherited methods would behave
08:39:51 <Akii> vizArt reports something is broken :D
08:42:23 <vizArt> still present ... and a big problem
08:43:39 <NamelessCoder> vizArt 7.2 is right around the corner but if you can, please confirm whether that happens with the development branch. We wouldn't want to release a new version with that one still hanging around.
08:48:53 <vizArt> ok, thanks for the info ... i have modded the v.7.1.2, so it works for now
10:29:10 <fger> hi guys, im experimenting with TYPO3 6.2.10 and composer-based install of core/extensions...
10:30:05 <fger> installing typo3-ter/news works like expected - copy of the extension files in typo3conf/ext/news and the composer librarie under Packages/Libraries...
10:30:46 <fger> but when installing / requiring e.g. fluidtypo3/fluidpages the Extension Manage shows 2 installed extensions
10:31:05 <fger> one fluidpages and the other named LibrariesFluidtypo3Fluidpages
10:32:00 <fger> looks like the new composer-autoload-mechanism hooks in and both extension file locations get registered in the PackageStates.php ... can anyone confirm ?
11:10:37 <fger> small other question: Does anyone know, if the copy/paste bug of inline-fal-related images, that lets also flux:field.inline.fal (latest flux dev) relations fail, is solved in TYPO3 6.2.10 ?
11:12:58 <NamelessCoder> fger haven't tested that one - if you do, please report here ;)
11:49:14 <Arrluk> Hi. I want to create an anchor menu (fluid content object) of all content elements of the current page. How can this be done? How can i access the content of other fluid based content objects of the current page…its all stored as XML inside the record.
11:54:44 <NamelessCoder> Arrluk see v:content.get/flux:content.get + flux:form.data
11:55:02 <NamelessCoder> flux:content.get if the content you want to list is child content of another element
11:55:11 <NamelessCoder> v:content.get if it is page-level content
11:55:47 <NamelessCoder> flux:form.data to extract the content's Flux options if you need them. The standard record attributes are available as plain array.
12:05:56 <Arrluk> But i cannot loop with v:content.get?!
12:06:48 <pedda> Arrluk you know about the sitemap ce which is capable of anchor list ?
12:07:55 <pedda> a fluid content element is always wrapped by a div.csc-default div by default and prepended by an anchor
12:08:42 <pedda> it shouldn'T make any difference if those ce's are fce's or default ce's anyway, so in my opinion you could use the sitemap ce
12:09:48 <pedda> if the menu you want, is not planned to reside somewhere fixed in your page layout
12:22:21 <Arrluk> The section index output was empty so i tried to build another fluid based CE..almost all content elements are based on fluid in this case.
12:25:04 <pedda> as this is a core feature, it doesn't matter how your content elements are implemented (DCE, fluidcontent, templavoila, whatever)
12:25:20 <Arrluk> But i can try to use another viewhelper to get all elements of the page where i can loop through…then try flux:form.data. basically i didn´t know how to access the xml
12:25:36 <pedda> each content element is wrapped by a div and prepended with an anchor as long as you didn't move some TypoScript around to avoid this
12:26:33 <pedda> if i would have been requested with your task i would kne, that each content element has it's own marker like c123 where 123 is the content element's uid
12:26:49 <pedda> i would have placed a sitemap ce in my "sidebar" or whatever
12:28:50 <Arrluk> In this case it was requested to do this with fluid….i know about the section index but its more like "optional" way
12:29:11 <pedda> nearly anything is optional in typo3
12:29:20 <pedda> there are a lot ways to achieve a goal
12:30:07 <Arrluk> I know…It´s an alternative way im looking for…Thanks anyway!
12:30:29 <pedda> okay if i get you right, the task now is: create a fluid content element which renders a list/list-group (bs3) which contains links to all content elements
12:31:08 <pedda> i would use the page.uid and select all content elements whose pid is = page.uid
12:31:51 <pedda> and render links to #c<ce.uid> as many times as i have matches returned in my fce file
12:31:54 <Arrluk> I did this…just didnt know how to acess the flexform data as i wrote earlier
12:32:43 <pedda> aaah .. now i get it.. you need to access the flexform, because you use your own title field instead of the content element's default Header field
12:33:06 <Arrluk> I used v:content.render before as this provides a way to iterate through the elements
13:32:29 <benjamin_654> hi, i can remember that there was a change for default icon filenames & location the last few days - but i dont find the commit.. has someone a link at hand?
14:54:09 <JustAPoring> Ugh... I'm dealing with an issue where a an element with a flux grid column can be cut & pasted into itself, which leads to happy little errors.
14:54:21 <JustAPoring> I'm running an older version in this project, does anyone know if this was ever fixed? :(
15:03:25 <benjamin_654> JustAPoring: i just tried it with current development branch -> This bug is still there (->Fatal error: Maximum function nesting level of '5000' reached, aborting!)
15:04:01 <JustAPoring> benjamin_654: Thanks for testing! That sucks. I'll open an Issue in that case. Would this be related to flux or fluidcontent?
15:06:00 <benjamin_654> Now my backend is gone ): …..
15:06:46 <JustAPoring> benjamin_654: You can edit the 'content area of parent' of that element through the list view... But I haven't found a way to get rid of this element without direct DB acces yet
15:07:42 <benjamin_654> JustAPoring: thx, but i have a script that pulls the live db into dev .. so its not a big deal ..
15:09:22 <JustAPoring> benjamin_654: I wish I had a way to have a beuser get rid of tho.... the customer of this project managed to kill ~5 pages already.
15:17:09 <benjamin_654> JustAPoring: you can try the blacklist feature (if its already available in your version)
15:18:23 <JustAPoring> benjamin_654: Any idea roughly when that was implemented? We're using 3.1.2 in this project - according to emconf.
15:18:57 <JustAPoring> Hm.. it looks like we're quite up to date for fluidcontent actually.
15:19:29 <JustAPoring> benjamin_654: This sounds great! I'll check it out.
15:39:36 <JustAPoring> benjamin_654: It didn't work, sadly. That one only hooks into the wizard, and doesn't do anything about copy/pasting blacklisted objects.
15:42:26 <benjamin_654> Outdoorsman: looks good to me
15:42:39 <Outdoorsman> I'm not really sure what Tx_Fluid_ViewHelpers_Widget_PaginateViewHelper.templateRootPath does or where to find documentation???
15:43:46 <Outdoorsman> The full thing is... plugin.tx_fluidbootstraptheme.view.widget.Tx_Fluid_ViewHelpers_Widget_PaginateViewHelper.templateRootPath
15:44:15 <benjamin_654> Outdoorsman: it overrides the templateRootPath for the Paginate Widget - if you dont use it, you dont need it..
15:44:58 <Outdoorsman> Okay, so it could accept templateRootPaths.10, templateRootPaths.20. Thanks... that's what I needed to know.
15:45:50 <JustAPoring> Outdoorsman: Correct me if I'm wrong, but you don't really need to use templateRootPaths unless you actually require for there to be that fallback mechanism that comes with it...
15:46:05 <JustAPoring> Since that widget is a single template file I don't see how you would ever need to use the fallback mechanism for that one.
15:46:41 <JustAPoring> Are people actively suggesting to never use templateRootPath and always use templateRootPaths?
15:47:01 <Outdoorsman> Maybe that's true. But by nature fluidbootstraptheme will have a provider extension overriding it 99% of the time.
15:47:12 <NamelessCoder> yes we are JustAPoring, because the singular naming is deprecated
15:47:29 <JustAPoring> NamelessCoder: Oh, when was that deprecated? Some 7.x version?
15:47:58 <JustAPoring> So they immediately deprecated the singular? :O I didn't know that.
15:48:03 <NamelessCoder> currently gets used as fallback but support won't be eternal
15:49:29 <JustAPoring> This might cause even more confusion for look-alikes which don't support the plural variant... But I suppose that's gonna work out eventually.
15:51:21 <Outdoorsman> Thanks for the comment NamelessCoder. JustAPoring, to override the fluidbootstrap theme in my provider extension I have to do "plugin.tx_fluidbootstraptheme.view >" and then recreate it from scratch with the templateRootPaths.10 and .20 to override it properly.
15:52:06 <Outdoorsman> That another reason it seems nice to have it overlay ready.
15:52:26 <Outdoorsman> Or whatever terminolgy I should be using.
15:53:29 <JustAPoring> Yeah... but I've seen some extensions which sometimes used view.templateRootPath for standalone templates ... that is what I assumed would cause confusion once the acutual view.templateRootPath is removed.
15:54:31 <NamelessCoder> I initially submitted a patch for the core which suggested the use of the "overlays." array to define *additional* template paths that would be checked before the fallback path
15:54:53 <NamelessCoder> this patch was rejected and replaced later by the one that is used now, that introduced templateRootPaths (plurals)
15:55:32 <NamelessCoder> the reason for doing that is that apparently, that methodology fits better with the configuration pragma of Flow, which is to grab Yaml files from packages and each package completely replaces any others it overrides
15:55:51 <NamelessCoder> now, the problem came "how to support the legacy path name and the plurals at the same time".
15:56:05 <NamelessCoder> (which wouldn't have been a problem at all, had they chosen my patch, but I digress)
15:56:16 <JustAPoring> Do you know if there is an easy way to replicate the functionality of templateRootPaths for StandaloneViews?
15:56:23 <NamelessCoder> the decision was made initially that if defined, templateRootPath would be the ONLY path checked
15:56:48 <NamelessCoder> so in 6.2 you couldn't properly use these for overlays without first removing the existing view configuration
15:56:56 <Outdoorsman> I like the templateRootPaths.x option much better, it was a good move!
15:57:11 <NamelessCoder> and this is where the whole problem began - so, Anja made efforts to fix this, letting templateRootPath work as *fallback* rather than *override*
15:57:48 <NamelessCoder> anywho: now, the templateRootPath works as fallback but is still considered just as much legacy as it was in 6.2
15:57:59 <NamelessCoder> it's probably going away in 7.2 LTS, mind you!
15:58:12 <NamelessCoder> alright, so, now the situation STILL is that we're using arrays to define these paths
15:58:27 <NamelessCoder> and those arrays are, because of the very similar naming, bound to be confused.
15:58:36 <NamelessCoder> one value is an array, the other is a string.
15:58:37 <benjamin_654> Ah .. i begin to understand a problem i had with that overriding templateRootPath ..
15:58:54 <NamelessCoder> this is why https://github.com/FluidTYPO3/flux/blob/development/Classes/View/TemplatePaths.php exists
15:59:36 <NamelessCoder> it *forces* every path usage in Flux (but not the core itself) to go through a proper object that sorts all this crap out and hides away the underlying configuration, replacing it with methods that *always* and *only* return path arrays.
15:59:53 <NamelessCoder> this class supports ALL the current naming conventions: singular, plural, overlays.
16:00:18 <NamelessCoder> but the core hasn't adopted anything like this and it still passes the arrays in raw to the template views (including the standaloneview, JustAPoring)
16:00:39 <NamelessCoder> internally the core's view STILL has methods to getTemplateRootPath which are no longer used by the core.
16:00:50 <NamelessCoder> they may however still be used by extensions that implement custom views
16:01:13 <NamelessCoder> and that's the problem: the core's views' methods that return a templateRootPath will return a reset($this->templateRootPaths)
16:01:40 <NamelessCoder> because the singular method is deprecated and no longer used, that is safe for almost all cases - but not all
16:02:11 <NamelessCoder> you can immediately see how that causes severe issues if someone were to configure a plugin to use the plurals but the developer only implemented the singular
16:02:58 <NamelessCoder> initially Flux only supported the singular naming + overlays (internally added, same as in EXT:view). It did this because 4.x and 6.2 both had to be supported (and there was no TemplatePaths object back then)
16:03:18 <NamelessCoder> this is still true about the TER version. It simply doesn't support the plural paths - they're ignored.
16:03:48 <NamelessCoder> however, in the development branch, all paths handling is pushed through TemplatePaths and homogenised. There's no more Q if some naming is supported - they all are.
16:04:31 <NamelessCoder> but even so, there is no way to guard against people using the deprecated methods on the view they instantiate manually. And if they do, back comes the problem that only a single path is supported
16:05:00 <NamelessCoder> plenty extensions have been adapting to this new naming in recent months; Flux is just a bit behind because of the LTS support requirement
16:05:25 <NamelessCoder> so that's the story and the full story behind paths in fluid
16:05:50 <NamelessCoder> and how that relates to Flux, what works and doesn't and why, and when you can expect it to change
16:07:17 <JustAPoring> NamelessCoder this sounds like a huge headache.
16:07:32 <NamelessCoder> JustAPoring tell me about it. A lesser man would have cried.
16:08:18 <NamelessCoder> JustAPoring so to answer your Q about the plural paths support for standalone views: Use FluidTYPO3\Flux\View\TemplatePaths, feed it your existing paths array in the constructor and use the getters afterwards to get paths and resolve templates.
16:09:21 <JustAPoring> NamelessCoder: thanks for your work. ;) I will do the next time I'm in that situation.
16:10:42 <benjamin_654> i often feel like the core has the “not invented here”-syndrom .. i still thing extbase could have used symfony/doctrine components ..
16:10:58 <NamelessCoder> ah, there's my old hobby horse
16:14:36 <NamelessCoder> to people coming from for example Drupal I can tell you TS is crazy flexible
16:15:10 <NamelessCoder> it also has its strong points vs. fluid (but mostly because TYPO3 invented the "integrator" job)
16:15:30 <Outdoorsman> Thanks for the history NamelessCoder... I almost feel like I just got to watch a movie, my emotions going up and down, agreeing then disagreeing, you have a bright future ahead :)
16:15:46 <JustAPoring> Flexibility isn't everything if basic templating tasks are a chore
16:16:47 <JustAPoring> I should read this channel more often. :D
16:16:51 <NamelessCoder> heh yeah Outdoorsman you win some, lose some - and you *definitely* have to pick your battles. To me, that paths thing wasn't one I wanted to fight
16:17:43 <Outdoorsman> Understood. Some people have real work to do once in a while too :)
16:19:54 <Outdoorsman> JustAPoring... I am really enjoying the templating options that the whole FluidTYPO3 ecosystem has opened up but at the same time, I'm findinig that it still takes me quite a bit longer to go from design to production than it did with Templavoila (don't throw anything at me).
16:21:02 <Outdoorsman> For a small web developer like myself, it comes down to how long does it take. If it takes longer, I have to charge more and it makes it harder to complete with my competition.
16:21:27 <NamelessCoder> Outdoorsman it's just a matter of training like everything else. In time you figure out the solutions that solve your exact problems - and they do tend to be the same problems over and over
16:21:27 <JustAPoring> I'm in the luxurious situation that I've never had to develop with templavoila from scratch, only maintain some, so I can't really comment on that
16:23:03 <Outdoorsman> No matter what someone says, there was power in that point and click method that Templavoila used. I created a custom template, point/click, and bam it worked. I wish there was a dummy way to do the same thing in FluidTYPO3 that would also allow for customization.
16:23:35 <NamelessCoder> the things I could do if my only job was FluidTYPO3...
16:23:58 <NamelessCoder> it's been two years now since I thought out the way to do that, Outdoorsman - but it's a 3-4 month job, minimum.
16:24:03 <Outdoorsman> It's my pie in the sky, I know. But turnaround time is huge.
16:24:12 <JustAPoring> Hell, in still quite new with TYPO3 considering all, with roughly 3 years under my belt now
16:25:33 <Outdoorsman> well NamelessCoder, if you really really think that it's a good solution that would help reduce the barrier to entry, it just may be worth talking to some big investers like AOE or whoever and it could become the new gold standard.
16:27:01 <Outdoorsman> Not trying to convince you to do something that may not fully be adopted though. It might be something to make a public project from the beginning with a clear goal, milestone, teamwork and everything.
16:27:47 <Outdoorsman> Many minds working toward a common goal should give it much bigger adoption as well as a potentially better solution.
16:28:56 <NamelessCoder> currently there's no agency support (money-wise) behind. It's been, what, 5 years or so without any mention of putting serious money in it.
16:29:36 <NamelessCoder> not that I complain, I'd still be doing this without it. But that's the main reason why some of the features don't go beyond thinking stage.
16:31:23 <Outdoorsman> Seems I get laughed out of town whenever I bring up this topic so thanks for at least entertaining it. I really don't think I'm imagining when I say this could bring TYPO3 to a much broader audience and would also benefit the programmers as well so there's less chance for error and faster time to market.
16:31:34 <NamelessCoder> also, FT3 doesn't want to become gridelements. No offence to their strategy, I just don't agree with it.
16:32:01 <NamelessCoder> Outdoorsman have you tried EXT:site, the pseudo-distribution for FT3?
16:32:32 <NamelessCoder> it's not point-and-click templating but it does all the heavy lifting and makes a folder mount in file list where you can edit your first two templates
16:32:57 <Outdoorsman> Hmmmm... thanks for the tip.
16:33:04 <NamelessCoder> that's the best compromise so far in regards to entry barrier
16:35:32 <JustAPoring> No offense, but IMHO the state of the documentation is the largest entry barrier ( in case nothing much changed the last couple of months )
16:35:42 <Outdoorsman> site... very interesting... that's a unique way of handling things.
16:36:27 <JustAPoring> I know all too well that writing documentation is a time consuming task
16:36:43 <NamelessCoder> JustAPoring we get almost zero contributions for documentation
16:37:04 <Outdoorsman> JustAPoring: This has been a good section for me to get acquainted with, https://fluidtypo3.org/viewhelpers/flux/development.html
16:37:13 <NamelessCoder> trying to arrange updates for Flux 7.2 launch currently
16:39:51 <JustAPoring> I know the ref but often - especially for flux which IMHO is not very self explanatory - knowing a viewhelper and its attributes are one step of the way.
16:40:27 <NamelessCoder> it's based on TCA - 'nuff said ;)
16:41:58 <JustAPoring> When I stated with FT3 the doc had huge holes. Is that still the case? (On phone right now or I'd check)
16:42:30 <NamelessCoder> 10-15% of the pages are still missing (the more advanced parts)
16:43:00 <JustAPoring> Sadly those are probably very important parts...
16:43:58 <JustAPoring> But is sad to hear there are so few doc contributions
16:44:21 <JustAPoring> Not that I've made any myself to be frank
16:44:54 <JustAPoring> I am very much part of the problem
16:46:53 <NamelessCoder> well, if you know some magic trick that solves this problem don't wait to tell me ;)
16:47:22 <NamelessCoder> at this point, contributing is as easy as clicking a button and writing Markdown which everyone can learn in a few minutes
16:47:37 <NamelessCoder> not sure how to improve that, short of paying people to write
16:55:37 <Outdoorsman> JustAPoring... I'm sure NamelessCoder wouldn't mind you sending a donation to help out with his time if you can't do it. I've done that a little becuase i know it takes a lot of free time. I try to give back when I can.
16:56:20 <Outdoorsman> There are also some quite active folk on the vhs team too
17:04:35 <NamelessCoder> donations are of course appreciated :)
17:15:05 <JustAPoring> Well I can't really offer any donations - but contributions might be possible ;-)
18:15:24 <Arrluk> i read that its currently not possible to use FAL elements inside flux.objects…is there any workaround for that. maybe to create a fluid container element where the single elements are stored….i need multiple elements for a slideshow (not a fixed number of row)
18:17:00 <Arrluk> I get the error "Wrong configuration in table a7c727320c"