View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
232 | Composr | core | public | 2010-12-18 08:40 | 2010-12-21 02:23 |
Reporter | Guest | Assigned To | Chris Graham | ||
Priority | normal | Severity | minor | ||
Status | resolved | Resolution | fixed | ||
Summary | 232: EXTRA_HEAD doesn't seem to be usable from blocks | ||||
Description | The "EXTRA_HEAD" functionality, for including arbitrary tempcode in a page's head tag dynamically, doesn't seem to be putting anything there when called from a block. I'm trying this on a fresh Composr 5.0.3 with a few extra files from an addon I'm making. I've stripped down the block to try and rule out bugs on my part, and have found that it doesn't even work in the following skeletal block (comments removed to save space): <?php class Block_flattr_site_button { function info() { require_lang('flattr'); $info=array(); $info['author']='Chris Warburton'; $info['organisation']='ocProducts'; $info['hacked_by']=NULL; $info['hack_version']=NULL; $info['version']=1; $info['locked']=false; $info['parameters']=array('style'); return $info; } function run($map) { // This is the documented way global $EXTRA_HEAD; if (is_null($EXTRA_HEAD)) $EXTRA_HEAD = new Tempcode(); $EXTRA_HEAD->attach(do_template('FLATTR_HEAD_JS')); $EXTRA_HEAD->attach(make_string_tempcode('fooooooooooooooooooooooo')); // I've found this way to work fine in modules too if (!array_key_exists('EXTRA_HEAD',$GLOBALS) || is_null($GLOBALS['EXTRA_HEAD'])) { $GLOBALS['EXTRA_HEAD'] = new Tempcode(); } $GLOBALS['EXTRA_HEAD']->attach(do_template('FLATTR_HEAD_JS')); $GLOBALS['EXTRA_HEAD']->attach('fooooooo'); return make_string_tempcode('bar'); } } Here "bar" shows up, indicating that the block is appearing correctly. Also, using "var_dump($GLOBALS['EXTRA_HEAD'])" fills the source with tempcode which looks right (it contains the right strings, although I couldn't say if the structure is right). Here "FLATTR_HEAD_JS" is the Javascript required for showing Flattr buttons, but neither it or the "foooo" strings appear in the <head>. Since simple strings don't work I don't think it's a problem with my template (which is just some tempcode comments followed by a <script> tag with CDATA inside) | ||||
Steps To Reproduce | 1) Insert into a block code which dumps values into the $GLOBALS['EXTRA_HEAD'] tempcode (after initialising it if required) 2) Add this block to a page (I tried with the start page of the site zone in an otherwise default 5.0.3 installation) 3) The <head> tag will not contain anything which was given to $GLOBALS['EXTRA_HEAD'] | ||||
Tags | No tags attached. | ||||
Attach Tags | |||||
Time estimation (hours) | |||||
Sponsorship open | |||||
|
Thinking about this a little more, using EXTRA_HEAD directly in a block isn't such a good idea since there may be lots of the same block on a page. I've fiddled with my code to use require_javascript instead, although I think this bug is still valid for those who do need access to the head. |
|
Preprocessing now happens before the header's Tempcode generation. For most cases there was no issue, but EXTRA_HEAD was passed in as a parameter rather than referenced later as a symbol, so got bound early. |