i see there is a block available on the d6 version but not the d7 version. I was just wondering whether it left the scope or would be considered for inclusion. In that case i could make a patch from my sandbox

https://drupal.org/project/1991012/git-instructions

Comments

Letharion’s picture

Letharion commented

The reason there is not already a block available is because normal blocks cause problem like this one: http://drupal.org/node/1566092

I wouldn't be immediately against having a block, but I would prefer the problem was solved in a a more flexible way, such as with a View. Patches are welcome, but in this particular case I'm not interested in solving the problem myself. If you do write a patch, please try to make the block a separate sub-module.

Something I would definitely like to have is a Ctools Pane, as that would open up essentially unlimited configuration possibilities. I haven't taken the time to write this yet though.

discipolo’s picture

discipolo commented

as i see it a custom view is only needed for a contextual block (that displays the button with a different link depending on where it shows). i would deem a configurable block to be sufficient, meant for sitewide use. i will try to turn my sandbox into a patch as independend submodule. i will also look into ctools panes.

Letharion’s picture

Letharion commented

I believe there (at least) two separate use cases for a block.

The first use-case is what you describe, and what the block in D6 did, it was contextual. It would take the node currently being displayed, and base it's button on it. However, this has two, or more, problems. One is what came up in #1566092: Block flatter button not displayed. What if you want do display the button on the front page, which doesn't have a node context? Or several? Or, what happens if you have flattr buttons on any combination of nodes, comments and terms, and you display these together, how would the button behave? Blocks simply don't provide the flexibility to solve this neatly.

The other use-case is to let the block be static. Configure it with one-off parameters, and place it done. Except quite soon someone will want to have two separate of these blocks. So one should implement 2 blocks. Or perhaps 3? How many will be "enough"? Again, blocks are not flexible enough to meaningfully solve this.

The above problems is why I would prefer there not be any blocks at all (at least until D8), it will be a hack no matter the solution. Ctools Panes, while more complex to configure, solve all the above neatly.

discipolo’s picture

discipolo commented

ctools panes looks like it shouldnt be too hard. from what you are saying it almost sounds like a beans or boxes integration actually, although that might be too much. so the ctools pane would take care of both the contextual and the static configured block requirements?

discipolo’s picture

discipolo commented

here is a basic module creating a ctools pane .... this should work if added to the flattrmodule
http://drupal.org/sandbox/discipolo/1999150
only ctools panes are rather worthless if not using panels right? so i am thinking about creating a boxes/bean integration module similar to what i found http://drupal.org/project/openlayers_blocks which http://drupal.org/project/bean_panels could turn into panes, and maybe i will throw in a views content pane for good measure
since i have a project which distinctly requires just one flattr this site block i am trying to turn https://drupal.org/sandbox/discipolo/1991012 into a full project https://drupal.org/node/2067023#comment-7767575

kscheirer’s picture

kscheirer
Primary language English
Location Vallejo
commented

The other use-case is to let the block be static. Configure it with one-off parameters, and place it done. Except quite soon someone will want to have two separate of these blocks. So one should implement 2 blocks. Or perhaps 3? How many will be "enough"? Again, blocks are not flexible enough to meaningfully solve this.

This is a slippery-slope argument with no basis. You don't have 1 block yet, so I doubt anyone has asked for 2 or more. If they ever do, let them know that only 1 is provided due to the limitations of blocks. Perhaps someone will be inspired to write ctools or bean integration. Providing Flattr's current implementation plus 1 block looks like an improvement to me.

discipolo’s picture

discipolo commented
Status: Active » Needs review

i kept thinking about your comment that one block wouldnt be enough and agree that multiple would be better.
when reviewing the project application for https://drupal.org/sandbox/jasonrichardsmith/2009844 i was impressed by the way it handles the multiblock issue and have adapted the code to work with flattrblock.

it would be great if you could look at it and tell me what you think.
i could try to create a patch for flattr that implements flattr_block as a submodule