IRC logs

20150312

Logs from channel #fedext on freenode - our official support channel.

IRC log range: 20150312*

20150312

  • 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:23:47 <Akii> that should be merged
  • 08:24:06 <vizArt> and this since a long time ... will this fork be merged, or is there another fix planned. This issue exists for severel month
  • 08:24:47 <vizArt> ah ... ok
  • 08:24:54 <vizArt> thanks for answering
  • 08:25:26 <Akii> at least I think I've created a PR
  • 08:25:37 <Akii> and I don't remember not getting one merged thus far
  • 08:26:06 <Akii> https://github.com/FluidTYPO3/flux/pull/706
  • 08:26:45 <Akii> NamelessCoder: *ping* ^^
  • 08:26:59 <vizArt> *ping* lol
  • 08:27:14 <vizArt> thanks ... this fix is realy important
  • 08:27:22 <Akii> yes it is
  • 08:27:27 <Akii> but it also should be merged :D
  • 08:27:43 <vizArt> yes it should
  • 08:27:49 <Akii> you're already pretty far with this bug.. normally you spend some days until you realize it's flux ^^
  • 08:28:06 <Akii> (faster if debugger is available and used)
  • 08:28:16 <vizArt> debugger in use :D
  • 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:33:03 <Akii> indeed, never made to master
  • 08:33:18 <vizArt> I realy thought that it was already fixed
  • 08:33:19 <Akii> very strange
  • 08:33:42 <Akii> it somehow unmerged itself ^^
  • 08:33:49 <Akii> bjo3rn: maybe you're here :D
  • 08:34:22 <vizArt> lol
  • 08:38:18 <NamelessCoder> sup Akii?
  • 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:39:59 <NamelessCoder> hmm...
  • 08:40:37 <Akii> how old is 7.1.2? ^^
  • 08:40:37 <NamelessCoder> has this been confirmed on 7.2? I've not seen that problem for a long, long time.
  • 08:40:48 <NamelessCoder> ~5-6 months I think
  • 08:40:54 <Akii> hmm
  • 08:40:59 <Akii> vizArt: how about updating? ^^
  • 08:41:47 <NamelessCoder> btw that there feature I just pushed is pretty damn sneaky ;)
  • 08:41:55 <vizArt> No confirmed on TYPO3 6.2.x
  • 08:42:01 <vizArt> with Flux 7.1.2
  • 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
  • 08:49:10 <vizArt> looking forward to 7.2 ;-)
  • 08:49:22 <Akii> loool
  • 08:49:47 <Akii> that's what you get ;)
  • 08:49:51 <Akii> create a PR next time
  • 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 ?
  • 10:33:13 <mrboe> @fger this works for me
  • 10:33:14 <mrboe> http://pastebin.com/pTSgHvBD
  • 10:34:36 <mrboe> the only problem is because i use lightwerk repo the symlinks of t3 would not be created
  • 10:35:05 <mrboe> but thats ok for me
  • 10:36:12 <fger> hi, ok - i did it via phpStorm and composer.typo3.org repo ... then adding dependencies to the fluidtypo3 extensions
  • 10:36:52 <fger> I deleted the fluidTYPO3 dependencies and re-added ... now there aren't any Packages/Libraries/fluidtypo3/fluidpage etc. files
  • 10:36:57 <fger> dunno why they were created
  • 10:37:17 <fger> do you have them in your system ? root-dir/Packages/Libraries/fluidtypo3/... ?
  • 10:37:29 <mrboe> no
  • 10:37:51 <fger> ok, maybe just temporary files that couldnt be deleted in one install or sth...
  • 10:37:56 <fger> thx 4 info anywa
  • 10:37:57 <fger> y
  • 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:13:28 <fger> ok ;) ackn :)
  • 11:18:30 <NamelessCoder> thx ;)
  • 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:03 <pedda> typo3 standard content element
  • 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:27:28 <pedda> and set it to: section index
  • 12:27:47 <pedda> this would render some ul > li whith ancor links to listed CE's
  • 12:28:45 <pedda> marker -> anchor
  • 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:30:55 <Arrluk> Yes
  • 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
  • 12:33:22 <Arrluk> "get" does not
  • 12:33:42 <Arrluk> YES!!
  • 12:33:44 <pedda> what do you need the flexform parsing for ?
  • 12:33:52 <pedda> that's why you also got an empty section index menu, because you're not using the header field
  • 12:33:53 <pedda> ;)
  • 12:34:04 <Arrluk> !! :)
  • 12:34:15 <pedda> and the special menu ce is rendering "empty li's"
  • 12:34:35 <Arrluk> an empty list…exactly
  • 12:34:44 <pedda> we'Re getting closer to this ;)
  • 12:34:45 <pedda> well
  • 12:35:08 <pedda> if you have your own title field within your flux fields definition you definetly need to parse that one
  • 12:35:10 <pedda> ^^
  • 12:35:30 <Arrluk> that´s what i´ll try next ;)
  • 12:35:59 <pedda> in your next project take into account which pro's come with using the core's Header field
  • 12:36:29 <pedda> i stick to Header fields in most of my projects
  • 12:36:39 <pedda> as a lot of functionality is based on these
  • 12:36:45 <pedda> core functionality
  • 12:36:56 <Arrluk> i´m just "extending"…did not built the basic site
  • 12:37:15 <pedda> ah well .. in that case you have no choice ^^
  • 12:37:21 <Arrluk> thats why i have to deal with it
  • 12:37:50 <Arrluk> again, thank u for your time
  • 12:38:18 <pedda> nvm
  • 12:38:27 <pedda> that's why we hang around here ^^
  • 12:38:47 <Arrluk> ^^
  • 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:04:39 <benjamin_654> JustAPoring: Yes
  • 15:05:12 <JustAPoring> benjamin_654: Haha. I mean - is it related to flux OR fluidcontent? In which repo should I post the issue? :P
  • 15:05:25 <benjamin_654> JustAPoring: fluidcontent
  • 15:05:31 <JustAPoring> benjamin_654: Thanks. Will do.
  • 15:05:40 <benjamin_654> JustAPoring: thx
  • 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:30 <benjamin_654> JustAPoring: https://github.com/FluidTYPO3/fluidcontent/commit/5d63b574fa84564896c4dd3b198523508d21f9d4
  • 15:18:40 <JustAPoring> oops, that was fluidpages.
  • 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:39:40 <JustAPoring> Thanks either way.
  • 15:39:54 <Outdoorsman> Can this... Tx_Fluid_ViewHelpers_Widget_PaginateViewHelper.templateRootPath
  • 15:40:11 <Outdoorsman> also be written... Tx_Fluid_ViewHelpers_Widget_PaginateViewHelper.templateRootPath.10
  • 15:40:22 <Outdoorsman> Oops I meant, Tx_Fluid_ViewHelpers_Widget_PaginateViewHelper.templateRootPaths.10
  • 15:41:02 <Outdoorsman> I'm trying to update an extension to use the latest recommended typoscript.
  • 15:41:40 <Outdoorsman> For example I've already updated... plugin.tx_fluidbootstraptheme.view.templateRootPath
  • 15:41:45 <Outdoorsman> to this... plugin.tx_fluidbootstraptheme.view.templateRootPaths.10
  • 15:41:51 <Outdoorsman> which is correct.
  • 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:36 <NamelessCoder> 6.2
  • 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:05 <NamelessCoder> the full story is this:
  • 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:32 <NamelessCoder> coming to that
  • 15:56:40 <JustAPoring> kk
  • 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:29 <NamelessCoder> Outdoorsman semantically better, compatibilty-wise worse.
  • 15:57:38 <JustAPoring> NamelessCoder: I agree
  • 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:18 <NamelessCoder> part 2 of the story:
  • 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:32 <NamelessCoder> yw
  • 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:12:04 <NamelessCoder> it is quite true though
  • 16:13:11 <JustAPoring> Small steps. 7.x looks like at least some people get it
  • 16:13:34 <benjamin_654> ..but still - fluid & extbase are soo mutch better than pi & ts ..
  • 16:13:52 <JustAPoring> Haha. What isn't tho
  • 16:14:09 <benjamin_654> pibase extensions / typoscript
  • 16:14:20 <JustAPoring> ... :)
  • 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:15 <JustAPoring> +1 on that
  • 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:18 <Outdoorsman> Don't know about it.
  • 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:40:38 <JustAPoring> :)
  • 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 ;-)
  • 17:46:28 <NamelessCoder> also very appreciated ;)
  • 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"