05:14:00 <fresskom1_> Hmm, does css_styled_content still have to be installed when using fluidcontent? When uninstalling it, I can’t get any content elements to render.
05:30:37 <x3ro> Hmm, never mind me. This seems to have been caused by the wrong TypoScript includes being set in the root template /o\
05:37:12 <x3ro> NamelessCoder: Regarding https://github.com/FluidTYPO3/flux/pull/1126 – I’m doing some work with fluidcontent at the moment, and it seems like we’ll be switching to it for future projects. So I definitely have an interest in contributing :D I find that its documentation is much better than for most other TYPO3 related projects (kudos).
07:21:02 <Guest55270> Hello, I try to use <flux:form.option.translation> in a page layout. I added a field <flux:field.input name="settings.subtitle" label="Seiten-Untertitel" enabled="1" inherit="1" inheritEmpty="1" />, which works in standard page settings. There I can enter values in tab "Page configuration". But in language specific page settings, this tab is comple
07:33:54 <Guest55270> I installed compatibility6, but I still get the same behaviour.
09:07:24 <NamelessCoder> sounds good x3ro - looking forward to it, and thanks for the contributions so far!
09:37:35 <x3ro> NamelessCoder: I’d still like to start a discussion of how to best document flux in context of fluidcontent, though :D wouldn’t this best be done in a github issue?
09:38:28 <x3ro> Because I feel that right now it is somewhat lacking, I suppose due to the issue of keeping the Flux documentation clean of references to fluidcontent
09:41:45 <NamelessCoder> we can discuss it briefly here then follow up with a github issue - just to avoid having to cover more than necessary in the github issue
09:42:13 <NamelessCoder> it is indeed lacking and speaking of viewhelper docs it is lacking for the reason you describe
09:44:05 <NamelessCoder> I've been thinking about how to solve that one and the only sensible solution I can think of (until this point) is some sort of pingback tracking where we are able to link internal doc resources that link *TO* docs. So we can track that for example fluidcontent's docs about icons links to flux's icon viewhelper docs, but without having to include that information in flux itself (because there it will inevitably become outdated or wrong at some
09:44:05 <NamelessCoder> point, or we risk documenting dozens of extensions via flux)
09:45:01 <NamelessCoder> (that pattern would apply quite well to other viewhelpers too, if I'm not mistaken - tracking all doc places that link to a VH doc)
09:45:29 <NamelessCoder> challenges in that regard would be that we document every version and won't necessarily know if/how something applies to previous versions
09:45:33 <x3ro> That would be done in the typo3 that powers fluidtypo3.org?
09:46:09 <NamelessCoder> yes that would be part of the docs rendering, likely achieved with a custom template + VH for schemaker's FE plugin
09:46:50 <NamelessCoder> we could design a rule that says, for example, "VH links in docs are ALWAYS to 'master' version of any VH"
09:47:46 <NamelessCoder> so our docs only link to master VH refs but VH refs link back to that resource from every version of VH refs
09:49:36 <NamelessCoder> few things would need to happen for that to be a good approach... most importantly we'd need to add the VH doc links in various documentation that gets rendered on fluidtypo3.org. A plain "these viewhelpers are used in this example: <markdown-list>" would suffice, imho.
09:51:26 <NamelessCoder> there's more, actually... we could parse out example blocks when displayed in docs and parse as Fluid (not render, just parse) where possible, extracting viewhelpers that are used (see live fluid example on site for how that works) and listing those. But that doesn't have to be there for it to work initially
09:52:15 <x3ro> So, lets say I’m looking at the Flux\Form\Option\GroupViewHelper. That page would contain the list you’re speaking of, linking to where the GroupViewHelper is used in the fluidcontent docs?
09:52:24 <x3ro> Just to make sure I understand you correctly :D
09:52:33 <NamelessCoder> this makes the relationships between VH docs and other docs more human friendly, I think. But it doesn't really solve the other problem, that our current structure is a bit hard on the brain
09:53:08 <NamelessCoder> yep, exactly - when looking at any VH you would also get a list of all places in other docs where that VH is used (read: where there is a link to that VH)
09:54:50 <x3ro> I’m just trying to figure out where I would put those docs that link to Flux
09:55:09 <NamelessCoder> it's fine to document how Flux components work in each other extension, but the main docs should be in Flux. E.g. you can explain how "group" renders this and that type of field, but don't begin to list supported arguments and perspectives about how it renders as TCA - that's a job for Flux docs
09:56:41 <x3ro> Yeah, I think I get that. But lets take https://github.com/FluidTYPO3/flux/pull/1126 as an example. Lets say the mechanism that links references in the Flux docs is in place, and I would put the documentation from the PR in fluidcontent instead. Where would that be?
09:56:48 <NamelessCoder> my vision is a set of docs that explain exactly how Flux works in details - without using fluidcontent etc. as examples. It does make sense as a general library for integration even when you don't use any of the other exts and I think that fact tends to get missed.
09:56:51 <x3ro> that is, where in fluidcontent would I put the stuff I’ve written there? :D
09:57:25 <NamelessCoder> if that existed it would be pretty easy to write the fluidcontent/fluidpages docs because it would mostly be about explaining how those patterns apply in that extension
09:58:20 <NamelessCoder> re: your question, currently fluidcontent etc. has no viewhelpers which means you can't put it in viewhelper docs. The only place it can be put currently is in the "documentation" repository that gets rendered as a page tree on the site
09:59:25 <NamelessCoder> but that's not optimal and that's my point... this central documentation seems to be a pretty bad idea unless it's to write guides about how to use the framework as a whole. Individual guides should be in each extension's docs, probably. With relationships to Flux docs when there is a relation.
09:59:55 <NamelessCoder> we've had some efforts in that direction but it's a seriously tough job
10:00:36 <NamelessCoder> (gotta go in around 10 minutes, pre-warning :))
10:01:54 <x3ro> yeah, I guess its nothing that’ll be done in a day. I’ll give it some thought as well. one more question. you’ve mentioned schemaker, and I did get it running locally after some trouble w/ vhs versions. Is the stuff rendered at https://fluidtypo3.org/viewhelpers.html done by schemaker, or is that something else?
10:03:47 <NamelessCoder> we're only limited by PHP in this regard :)
10:05:26 <x3ro> I think I’ll take another look at schemaker and maybe play around a bit. I’ll also try to summarize this discussion in a GitHub issue. Would that go in Flux?
10:05:42 <NamelessCoder> to sum things up from my end, I'd aim for the following:
10:06:18 <NamelessCoder> 1 - independent Flux docs that can be read as a beginner (without requisite TCA knowledge) but with links to official resources to make it clear that Flux *IS* primarily a shell for TCA/TCEForms
10:06:56 <NamelessCoder> 2 - independent tutorial-style docs for each extension (fluidpages, fluidcontent etc.) to show how those work, without explaining Flux in detail - but linking to the Flux docs from step one
10:07:16 <NamelessCoder> 3 - manual or automatic extraction of "trackback" links from docs to VH refs
10:07:48 <NamelessCoder> 4 - refitting fluidtypo3.org docs section to reflect the divided docs - where now it's more of one big pile
10:08:14 <x3ro> Is the thing that renders the templating manual also in schemaker?
10:08:22 <NamelessCoder> I guess that's several weeks of work, depending on how fast one can type and how much one has ready in memory
10:08:37 <NamelessCoder> no, that's part of the fluidtypo3org extension (github repo)
10:08:40 <x3ro> yeah, but it doesn’t have to be one big “whoop"
10:08:51 <x3ro> step by step is also an option, I suppose
10:08:56 <NamelessCoder> definitely not and that's a good thing - each step can be done by its own
10:09:12 <NamelessCoder> but it won't be the golden solution until all is in place
10:10:05 <NamelessCoder> if that's something you want to tackle we'll support you every way we can. We've no budget this year :/
10:10:58 <x3ro> Yeah, I’ll check w/ my employer as well. I certainly wont get time to work on this full time, but lets see what can be done :)
10:11:24 <NamelessCoder> we also had InvisibleKind writing something (higher level tutorial style) that might be good as a replacement for the current big pile and then complemented by the individual ext tutorials
10:11:36 <NamelessCoder> it's along the lines of "how to use the framework, for beginners"
10:12:08 <x3ro> Well, the current templating manual is not bad, even though it could benefit from a little work
10:12:26 <NamelessCoder> fingers crossed you can get some time for this ;) if you do we can invite you into the team and you/co can use that as reference
10:12:45 <NamelessCoder> not much else we can offer except of course the knowledge ;)
10:31:00 <Guest|19175> Fatal error: Call to a member function resolvePrimaryConfigurationProvider() on a non-object in /kunden/123103_73765/rp-hosting/5007132/6007132/typo3cms/cm4all_live/public_html/typo3conf/ext/flux/Classes/Service/FluxService.php on line 363" with the newsest fluidcontent for 6.2.
15:58:20 <Guest|3161> hi, after updating fluid content i get a problem with this line: class Tx_CmagWebsite_Controller_ContentController extends Tx_Fluidcontent_Controller_AbstractContentController {