Embed block tokens

Subscribing to this crazy-ass wackiness! Looking to use block tokens to embed blocks, views, etc directly into node content using the token filter module. Might take a stab at a revised patch if I get to it.

hey, just wondering whats happened to this?

Is it a module or not?

Thanks

+1 is better than a follow in this instance

I was looking for just this solution. It doesn't look like this ever made it into Token or Token Filter. Anyone know?

Is it in any of the dev modules?

This needs to also run _block_get_renderable_array() after running _block_render_blocks().

Why is that?

Oooooh, for titles and contextual links and goodies...this is rather sick...trying some stuff to get that in

And let's see if this does it

Quick change so that the list of tokens includes user created blocks

Never mind that last patch, late evening haze (was working in the wrong local token folder)

jpstrikesback: Does this sudden flurry of activity mean a patch against the current version might be forthcoming?

Dave Reid: If the patch is good, is there a chance of this being rolled into dev?

Nitrospectide: that one in #12 is against the latest dev, give it a shot, seems to work well

jpstrikesback: What I'm most interested in right now is the user created blocks. It looks like your #14 includes that.

Actually #12 does it fine, I just didn't see the results in the token list until a few cache clears later. #14 is a dud :)

The patch in #12 is working for me.

@Dave Reid : Any thoughts on #12?

#12: 776952-token-blocks-D7-12.patch queued for re-testing.

+++ b/token.tokens.incundefined
@@ -17,6 +17,21 @@ function token_token_info_alter(&$info) {
+    'description' => t('Use the blocks in your site as tokens. CRAZY!'),

I think we can lose the excitement, as great as this functionality is the description doesn't need it.

+++ b/token.tokens.incundefined
@@ -913,6 +928,35 @@ function token_tokens($type, $tokens, array $data = array(), array $options = ar
+      $blocks[] = block_load($module, $delta);

This, along with other code, puts an unnecessary dependency on the Block module. I'll take a swing at removing this dependency as 9 times out of 10 I will have the Block module disabled as Context works better.

While maybe not the best solution, this is the quickest, basically I wrapped the Blocks token code with a conditional that checks if the Block module is enabled or if not if it can include the block.module file, given that the Block module is always going to be present (unless someone patches core) it will work.

Otherwise, the solution requires a lot more code to be written to reproduce the functionality of the block module (as Context has done) which is less than ideal.

Ok, so I'm sure the changes I made shouldn't have caused the tests to fail, I tested it locally and the tests don't seem to work so well either... but failing in things that had absolutely no relevance to the changes I made.

However, I did fail in my local testing, due to what I was testing the token with I failed to notice I was getting a cached result, so it looked like everything was working perfectly with the Block module turned off but it turned out not to be the case.

I've updated the patch with just a simple condition to check for the Block module, so for the moment the functionality will require the Block module, but I will look at changing that as I think this could be extremely awesome, but I think the dependency on the Block module is completely unnecessary.

Ok, this time for sure, this patch adds the ability to use Block tokens with or without the Block module, it's a mix of the existing code and the approach taken by the Context block reaction code, tests all passed locally and manual testing worked a charm.

Included is an interdiff from the patch at #12.

It's worth taking into account, the first part of the interdiff, the invocation of _block_rehash(), is something that's needed regardless of making this functionality work without the Block module, if you where to disable and uninstall the Block module and then re-enable and then proceed to try to process any block tokens without going to the Block configuration page then the block_load() function won't have enough information and cause the current functionality to fail.

I think #27 is in fact better than #28. The trick in #28 while being optimized, duplicates code, makes it unnecessarily difficult to understand, maintain or update.

@jcisio,

#28 doesn't duplicate code, it adds some additional code based on other concepts, not duplicated code, so that anyone who's not using the Blocks module can still have the blocks rendered via Token, which I believe is very important.

If you think the changes I made are difficult to understand I'd be happy to document them a little better:

+    $theme_key = variable_get('theme_default', 'garland');
+    module_load_include('module', 'block', 'block');
+    if (module_exists('block')) {
+      _block_rehash($theme_key);
+    }
+

Most of this needs to be in regardless of making the code work without the Block module, because if the Block module is only just installed and the Block page hasn't been visited then the block_load() won't work properly without _block_rehash() having been run first.

-      $blocks[] = block_load($module, $delta);
+      if (module_exists('block')) {
+        $block = block_load($module, $delta);
+      }
+      else {
+        $block = new stdClass;
+        $block->module = $module;
+        $block->delta = $delta;
+        $block->title = '';
+      }
+      $blocks[] = $block;

This is pretty straight forward, if the block module is active then the $block data is pulled from block_load(), otherwise we just stub the $block data manually.

+          if (!module_exists('block') && isset($build["{$module}_{$delta}"]['#theme_wrappers'])) {
+            foreach ($build["{$module}_{$delta}"]['#theme_wrappers'] as $key => $value) {
+              if ($value == 'block') {
+                unset($build["{$module}_{$delta}"]['#theme_wrappers'][$key]);
+              }
+            }
+          }

If the Block module isn't enabled and the prepared block element has 'block' as a theme wrapper we remove it otherwise the render process will fail.

I don't think that's all that difficult to understand or maintain, but I'm open to alternatives, however I'm not so open to restricting this functionality to only being available for use when the Block module is present, especially when it was so simple to make it work without it.

path #28 looks cool :)

Patch #28 working.

Patch #28 working for me as well. Very useful, thanks!

#28 working nicely; ready to apply to the dev version!

So what do you advise an interested user or Bad behavior who's also faceing to do? Wait for a new Bad Behavior dev version? Or wait for a new D7 core update?

Thank you

ive been using this for about 5-6 months now without any issues that i can detect why its not in the current dev version did any one find a problem with it ?

Working good for me, ready for include patch in dev release?

It would be good if this could be merged into master finally after 4 years.

Bump; this is RTBC for over 2 years. Please.

Agreed. Thanks for looking into merging this...

A cool addition to this would be tokens like

$module:$delta:subject
$module:$delta:content

To add just parts of the block.

I'd be happy to create follow up tickets though instead of adding to this patch if that is preferred.

I'm guessing since this isn't yet merged into 7 there's no activity on getting this same functionality ready in 8? If there's work being done on an 8.x version (I can't find any), I'd love to help out.

Anybody using statuses module? I want to show embedded status update when user shares other user's update. Currently, statuses module allows to use replacement tokens to be used from admin ui and by default, it has @name and @message, which is replaced by the username and status update text of the shared update. Instead of text, I want to show embedded status update. I have tried replacing @message with @status and @message_formatted and @status_themed, but nothing working. I have uploaded the statuses.token.inc file.

The 7 year old patch in #28 still applied cleanly. The 7.x branch definitely needs some love.