00:43:08 <cedricziel> it's impossible atm to distinguish the references for each object
00:44:00 <cedricziel> your issue would be solved by simply saving the form before adding a file reference
00:45:06 <cedricziel> normally, you'd add a displayCond to prevent displaying it
01:16:34 <Guest|3982> Hi, just upgraded from 6.1.11 to 6.2.5 and now the install tool fails with "Fatal error: Uncaught exception 'UnexpectedValueException' with message 'The package "fluidcontent" depends on "uploadflux.git" which is not present in the system."
01:18:14 <NamelessCoder> Guest|3982 sounds like something went wrong in the packagestates file
01:19:08 <Guest|3982> So, manually deinstalling fluidcontent should help?
01:19:31 <NamelessCoder> I think reinstalling any ext (for example using the nice CLI command) should solve that
01:19:48 <NamelessCoder> using EM might not work because of that error - or EM might already have uninstalled the exts for you
01:19:56 <NamelessCoder> 6.2 EM is a lot more clever than 6.1
01:20:41 <Guest|3982> I'll try it via CLI as I'm not able to access any part of the backend.
01:24:43 <Guest|3982> Had to remove all flux and fluid* exts from the local configuration, but now the backend is up again. Thanks!
12:17:00 <ndee> hi there, we upgraded from 6.1 to 6.2 and also updated flux to 7.2, fluidcontent 4.1.0, etc. When I edit a nested element, I see the following: http://glui.me/?i=qn8acxwqqir6h84/2014-10-03_at_12.12.png/ somehow, the ColPos from flux doesn't get added
14:51:55 <ndee> when I edit a CE of type plugin, I get the message Flux Debug: No content template found in "tt_content:1765". What exactly can't be found? Why would this show up in a CE of type plugin?
16:04:21 <NamelessCoder> danilobuerger not quite sure, but most likely just missing a registration somewhere which is compatible with the DataProvider for be_layout
16:04:54 <danilobuerger> bjo3rn i saw, well the merge i used works on both 6.1 and 6.2 but is deprecated... it would be best to use the code from the assetservice and move it to a utility so every class can use it
16:05:49 <NamelessCoder> yep to avoid deprecation log spam we need a condition around that array merging, a utility makes sense. Can be dropped when 6.1 is dropped
16:06:13 <bjo3rn> danilobuerger same goes imho for some of the menu service methods
16:06:19 <danilobuerger> bjo3rn you want to tackle that? i am more interested in looking into the 18181 thing
16:26:11 <NamelessCoder> wiwi|15259 if it is not secret and you want to save me a bit of time, please zip and email your extension to me (my email is in every class file of Flux but don't paste it here ;))
16:28:06 <danilobuerger> NamelessCoder 18181 invalid bug is occuring since https://github.com/FluidTYPO3/fluidpages/commit/28da1127239a00b7fafb87a6317d4930ac3d5e63 on 6.2
16:33:21 <NamelessCoder> wiwi|15259 I'll admit this is where it gets a little bit ideological, but: field.group was dropped for a reason. It's the one completely un-normalizable and un-replicatable field there is. All the functionality is still possible through field.file and field.relation - and if you do intend to use field.relation for such relations, you really should be using a proper MM table with a column and index for foreign table name as well as foreign key
16:35:34 <NamelessCoder> that being said: you can quite easily recreate the component if your current project requires it for backwards compatibility. This would require 1) replicating the flux:field.select ViewHelper and changing the created field type to a custom class name, which is created by 2) replicating the FluidTYPO3\Flux\Form\Field\Select field to your own namespace and changing the type of field it generates.
16:36:29 <NamelessCoder> sorry about the inconvenience for this one. We did this in preparation of true relation-based settings storage in which it wouldn't be possible to properly support this field in all its variations
16:37:33 <wiwi|15259> i need to select contents (pages, db, news), without relation between them, that why i ask question :)
16:37:52 <NamelessCoder> could you use two selection fields for that?
16:37:58 <wiwi|15259> will try to create my own component
16:38:14 <NamelessCoder> it's a very narrow use case, requiring mixing pages+content in the same list ;)
16:38:38 <NamelessCoder> you *could* utilize the section+object with two types of objects
16:38:52 <NamelessCoder> slightly more cumbersome for the editor user but it would work just the same
16:39:14 <NamelessCoder> this would also allow you to mix in stuff like custom headers, dividers etc.
16:40:31 <wiwi|15259> fact is i can have anytype of object (link, news, pages, video, image and more)
16:40:58 <wiwi|15259> will make my custom component :)
16:48:45 <NamelessCoder> I see what's going on now
16:49:07 <NamelessCoder> you got your own Provider which is being used, but it lacks the property $extensionKey which you should set to your extension key
16:51:35 <NamelessCoder> ah, you didn't register it. Maybe you don't intend to use it?
16:52:54 <NamelessCoder> still looking for possible causes in Flux
16:55:03 <NamelessCoder> are you using fluidcontent_core in your site wiwi|15259 ?
17:01:49 <NamelessCoder> oh crap. bjo3rn I just found another array merge overrule issue in Flux's AbstractProvider
17:02:23 <danilobuerger> NamelessCoder are you sure 18181 invalid can be fixed with another data provider? looking at the code in BackendLayoutView it seems unlikely
17:02:24 <bjo3rn> can it be replaced by the utility method?
17:04:03 <NamelessCoder> well there's no interdependency between flux and vhs :/
17:04:39 <bjo3rn> yes, that explains the 'oh crap'
17:04:53 <NamelessCoder> danilobuerger I'm far from sure but I'd expect it to be parsed from the "data" property on BackendLayout which the DataProvider returns
17:05:54 <danilobuerger> well yes, but then the data would have to include that column in some row for it to get into __items
17:06:55 <NamelessCoder> I think you can get around that by setting colCount = 0 even though it contains one column - but I really don't remember the internals at this point
17:10:45 <NamelessCoder> already gone from master, iirc
17:11:19 <bjo3rn> so leave it as is and change it when it's time?
17:11:41 <danilobuerger> NamelessCoder not increasing the row count seems to work.. any reason you want that in another data provider? before 6.1 its also in fluidpages
17:13:43 <NamelessCoder> wiwi|15259 found the problem. You can pull flux from git in a few minutes or give it a few days, a TER release should be coming soon
17:18:46 <NamelessCoder> this commit should solve it:
17:23:09 <danilobuerger> NamelessCoder not increasing the row count seems to work.. any reason you want that in another data provider? before 6.1 its also in fluidpages
17:23:46 <NamelessCoder> the DataProvider allows us to deliver this extra value from Flux which it should be, but without preventing Fluidpages from also providing its values.
17:24:18 <NamelessCoder> the reason for putting it in fluidpages in the first place was that any overriding class had to deliver *all* possible values, no merging possible
17:25:57 <NamelessCoder> e.g. itemsProcFunc has single setting which gets overridden by each extension that adds it, which is now changed to DataProvider that has multiple possible providers instead of overriding the "procFunc"
17:32:57 <danilobuerger> Oh well, didnt see your text until now... the PR is in fluidpages, feel free to move it into Flux, need to move on to other things
17:35:16 <NamelessCoder> I'll do some choppy/paste ;)
17:37:48 <NamelessCoder> btw danilo did you see; we now automatically upload new TER releases when merges to master occur?