IRC logs

20150727

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

IRC log range: 20150727*

20150727

  • 10:28:41 <mneuhaus> ahoy!
  • 10:29:02 <jmverges> hi mneuhaus
  • 10:29:33 <mneuhaus> am i right to assume, flux/fluidcontent isn't working yet with 7.3.1? ^^
  • 10:30:21 <jmverges> well you can give it a try
  • 10:30:30 <mneuhaus> i did ^^
  • 10:30:35 <jmverges> I'm on master doing stuff and they are working
  • 10:30:43 <mneuhaus> $hookObject must implement interface TYPO3\CMS\Core\Database\TableConfigurationPostProcessingHookInterface
  • 10:30:45 <jmverges> did you download github sources or extensions?
  • 10:31:06 <mneuhaus> initially from ter, but updated to git
  • 10:31:17 <jmverges> is implemented that interface
  • 10:31:43 <mneuhaus> i'll try again, dev oder master branch?
  • 10:31:45 <jmverges> I got that issue also, I don't know what is wrong because the interface is implemented
  • 10:31:54 <jmverges> development branch
  • 10:33:30 <mneuhaus> ok, then, *pulling up sleeves* lets find out what fails here :)
  • 10:39:24 <drlimbo> hi there, does someone already find a good solution for dynamic image rendering (size based on viewport)
  • 10:40:17 <mneuhaus> drlimbo: you mean through an ajax call?
  • 10:41:25 <mneuhaus> afaik you can't get information about the viewport through pure php means. only javascript can read detailed info like that. you could maybe "guess" based on the screen resolution i think there was a way to read that info using php
  • 10:42:07 <mneuhaus> scratch that, even screen resolution isn't accessable without js
  • 10:46:05 <mneuhaus> for me it seems not flux itself is the issue but the Compatibility6 ext
  • 10:46:34 <mneuhaus> yep that was the cause
  • 10:48:31 <drlimbo> mh yes mneuhaus didn't thought about the technique already =P
  • 10:48:51 <drlimbo> but it must be some js to determine the viewport
  • 10:51:15 <drlimbo> maybe some JS looping trough images and add a ?viewport=1024 parameter? and f:image or something uses this width?
  • 10:51:20 <NamelessCoder> hehe stand back. Marc has pulled up his sleeves, bugs will be squashed! ^^
  • 10:51:34 <drlimbo> i thought about using multiple <img> Tags and show the correct size with CSS
  • 10:52:12 <drlimbo> maybe NamelessCoder has a good idea?
  • 10:53:22 <NamelessCoder> sorry, don't really do FE work
  • 10:54:26 <drlimbo> no problem
  • 10:54:26 <mneuhaus> hehe ^^
  • 10:54:56 <mneuhaus> sorry, claus, the already fell down again, was just the compatibility6 ext screwing with me :)
  • 10:55:30 <NamelessCoder> oh, well, in that case: phew. But damn.
  • 10:55:32 <mneuhaus> drlimbo: what you're looking for is essentially something like this: https://github.com/scottjehl/picturefill
  • 10:56:53 <drlimbo> yess mneuhaus - and if there is a viewhelper for this, it would be awesome =P
  • 10:57:10 <jmverges> so mneuhaus the interface was about compatibily6 ?
  • 10:57:18 <mneuhaus> yep, fals alarm, sorry
  • 10:57:20 <drlimbo> but it can be done with multiple img.url
  • 10:57:50 <mneuhaus> didn't expect for a shipped sysext to screw up like that, and flux was the only other candidate about that interface :)
  • 10:58:14 <mneuhaus> drlimbo: a viewhelper almost seems like overkill, a simple partial would be quick and easy, no?
  • 10:58:29 <jmverges> drlimbo you could create a extension
  • 10:58:41 <jmverges> if you do, please share it
  • 10:59:13 <jmverges> I like the viewhelper idea
  • 10:59:17 <drlimbo> yes i also thought about jmverges
  • 10:59:45 <drlimbo> don't know if a have enough know-how for that, just created / edited some basic viewhelpers until now
  • 11:00:12 <jmverges> well take a look to the contribution guide first of all: https://fluidtypo3.org/documentation/contributing/contribution-guide.html
  • 11:01:28 <mneuhaus> <foo:img.picturefill src="foo.png" sizes="{xs: '200x300', sm: '400x500', md: '500x600', lg: '1000x1200'" />
  • 11:01:30 <mneuhaus> ? ^^
  • 11:01:43 <jmverges> mneuhaus picturefill is a crossbrowser thing for modern browsers stuff?
  • 11:01:46 <NamelessCoder> not a bad idea marc
  • 11:02:29 <mneuhaus> should be an easy quick, just an extension of the regular image viewhelper that calls its parent with the splitted sizes
  • 11:02:34 <NamelessCoder> yep
  • 11:03:05 <NamelessCoder> sizes="{xs: {0: 120, 1: 180}, sm: {0: 300, 1: 480}}" could also be allowed
  • 11:03:14 <mneuhaus> yep
  • 11:03:21 <NamelessCoder> would make it easier to pass each dimension as variable perhaps even calculated ones based on ratio
  • 11:03:32 <mneuhaus> although writing that seems quite messy
  • 11:03:37 <NamelessCoder> sizes="{xs: 100, sm: 300}"
  • 11:03:48 <mneuhaus> though might make sense because it might come from variables
  • 11:03:56 <NamelessCoder> just setting the width and assuming ratio conservation
  • 11:04:06 <mneuhaus> yep
  • 11:04:11 <NamelessCoder> oh it should support all of those :) and just detect what is what
  • 11:04:24 <mneuhaus> maybe i'll toy around later ;)
  • 11:04:27 <NamelessCoder> ;)
  • 11:04:40 <mneuhaus> god i love viewhelpers
  • 11:04:42 <drlimbo> that would be awesome mneuhaus
  • 11:05:03 <drlimbo> and sure im willing to test your viewhelper and give you feedback
  • 11:05:17 <mneuhaus> they are such an awesome way to have flexible yet simple and clean templates
  • 11:05:55 <mneuhaus> i managed to "bolt on" a custom filter + date selector onto a custom list layout for news without much hassle
  • 11:06:32 <mneuhaus> question would be how exactly the resulting html should look like
  • 11:07:58 <NamelessCoder> make it a tagbasedviewhelper
  • 11:08:17 <NamelessCoder> and maybe allow setting the name of the attribute in the tag that will store all size URIs
  • 11:08:28 <NamelessCoder> that should be pretty damn compatible with JS libs too
  • 11:09:54 <mneuhaus> in general i guess it should follow the proposed standard:
  • 11:09:55 <mneuhaus> <picture>
  • 11:09:55 <mneuhaus> <source srcset="examples/images/extralarge.jpg" media="(min-width: 1000px)">
  • 11:09:55 <mneuhaus> <source srcset="examples/images/art-large.jpg" media="(min-width: 800px)">
  • 11:09:55 <mneuhaus> <img srcset="examples/images/art-medium.jpg" alt="…">
  • 11:09:56 <mneuhaus> </picture>
  • 11:10:49 <mneuhaus> but i'll have to read up a little bit about the current picturefill state of things :)
  • 11:11:14 <jmverges> mneuhaus: that is w3c standard ?
  • 11:11:26 <mneuhaus> proposed one, yes
  • 11:11:47 <NamelessCoder> proposed usually means likely to become standard
  • 11:11:55 <mneuhaus> yep
  • 11:12:28 <mneuhaus> yet, from proposed to "standard" takes usually somehere around 0.5-10 years :D
  • 11:12:47 <NamelessCoder> hehe yeah like html5 ^^
  • 11:12:53 <mneuhaus> exactly :)
  • 11:13:47 <mneuhaus> well, doesn't look to bad currently:
  • 11:13:47 <mneuhaus> http://caniuse.com/#search=picture%20element
  • 11:14:01 <mneuhaus> basically ie + safari missing
  • 11:14:07 <mneuhaus> screw opera mini
  • 11:14:30 <NamelessCoder> yeah IE/safari biggest issues there
  • 11:14:52 <mneuhaus> that's what polyfills are for :)
  • 11:15:40 <mneuhaus> http://caniuse.com/#search=srcs is an alternative method
  • 11:15:55 <mneuhaus> looking even better than picture element
  • 11:16:21 <jmverges> yeah, you could use it
  • 11:17:50 <mneuhaus> well, gottarun for now :)
  • 11:18:06 <mneuhaus> i'll take a stab at it in a few hours
  • 13:00:05 <xaver> mneuhaus: different standards exist - i think we should support it if one standard are implemented everywhere.
  • 13:01:01 <xaver> if ie and safari starting same thing, firefox and chrome would maybe follow to have a standard
  • 13:03:46 <mneuhaus> i'd shoot for bot proposed ones picture element + srcset
  • 13:03:57 <mneuhaus> with a switch to choose which one