By creed on

Hello all

Writing a module for drupal installation of mine (first one actually.) and works fine except for one odd thing. I'm having the module's block function load an image and display it with text being super imposed. Normally Id' just set the div containing the area that it would be displayed as the background image, but within the module the background item for css doesn't find the file. No errors in drupals report or anything. However an img src tag with the exact same path works nicely (but doesnt' show the superimposed text). All the css is returned as well (the variables aren't but that was next on the agenda to be removed. if they are replaced with just text it loads that fine.

Have tried the ode in question without it being in a module and it works as expected so I'm thinking that for whatever reason it's not like background? Have tried every path type, background and background-image, Kind of at a loss for what this isn't working. here's the code itself within the modules contents function.

      	$data = '';
		$data .= '<div id="homepic" style="background:url(/sites/www.example.com/files/banner_images/homepic.jpg) no-repeat;">';
			$data .= '<div class="message">';
					$data .= '<h4 id="site-name"><a href="'.$base_path.'" title="'.t('Home').'">'.$site_name.'</a></h4>';
					$data .= '<p id="site-slogan">'.$site_slogan.'</p>';
			$data .= '</div>';
		$data .= '</div>';	
		return $data;

Anyone ever ran into something like this at all? Also if anyone happens to know how to make the paths dynamic with drupal, I'd like ot hear back as well.

⋅ Categories: Drupal 6.x

Comments

dman’s picture

dman commented

Assuming that code is exactly what you are using (and not some edited version) there doesn't seem to be anything visually wrong with it. I take it you have also looked at the view-source it pumped out.
And you say there is no error logged - such as the 404 that would be caused by the wrong path. This would normally be an easy clue.
So, beyond checking that your HTML and CSS is valid (use the w3c tool) I'm not sure what to suggest.

The way you are constructing the data (raw html, rather than theme) is not great, but should still work.

You may want file_create_url() to make your generated links portable

 $data .= '<div id="homepic" style="background:url(' . file_create_url('banner_images/homepic.jpg') .') no-repeat;">';

But there is probably something else missing here. Probably something we can't see from your description of the issue.

.dan. is the New Zealand Drupal Developer working on Government Web Standards

creed’s picture

creed commented

That I have. It shows that the link is showing in the html right where it should be.

Tried the function you mentioned but no luck. For using theme instead of raw html how do you mean? Any way to do it better I'm all ears.

Well I'll try to describe how I think things are working.

When you load the main page, I have created a custom region in page.tpl.php as so:

		<div id="banner_image"><?php echo $banner_image ?></div>

the CSS for this div is the following:

#banner_image {width:900px; height:250px; margin:5px 0 10px 0;}

now in that $banner_image, I have the module set to display there in the admin->blocks section in the administrator panel. It then loads the following:


function example_block($op = 'list', $delta = 0, $edit = array()) {
  // The $op parameter determines what piece of information is being requested.
  switch ($op) {
    case 'list':
      // If $op is "list", we just need to return a list of block descriptions.
      // This is used to provide a list of possible blocks to the administrator,
      // end users will not see these descriptions.
      // A block can provide default settings. In this case we'll enable the 
      // block and make it visible only on the 'node/*' pages. 
      
      $blocks[0] = array(
        'info'       => t('Example: empty block'),
        'status'     => TRUE,
        'weight'     => 0,
        'visibility' => 1,
        'pages'      => 'node/*',
      );

      return $blocks;
    case 'configure':
      // If $op is "configure", we need to provide the administrator with a
      // configuration form. The $delta parameter tells us which block is being
      // configured. In this example, we'll allow the administrator to customize
      // the text of the first block.
      
      $form = array();
      if ($delta == 0) {
        // All we need to provide is a text field, Drupal will take care of
        // the other block configuration options and the save button.
        $form['example_string'] = array(
          '#type' => 'textfield',
          '#title' => t('Block contents'),
          '#size' => 60,
          '#description' => t('This string will appear in the example block.'),
          '#default_value' => variable_get('example_string',  t('Some example content.')),
        );
      }
      return $form;
    case 'save':
      // If $op is "save", we need to save settings from the configuration form.
      // Since the first block is the only one that allows configuration, we
      // need to check $delta to make sure we only save it.
      if ($delta == 0) {
        // Have Drupal save the string to the database.
        variable_set('example_string', $edit['example_string']);
      }
      return;
    case 'view': default:
      // If $op is "view", then we need to generate the block for display
      // purposes. The $delta parameter tells us which block is being requested.
      switch ($delta) {
        case 0:
          // The subject is displayed at the top of the block. Note that it
          // should be passed through t() for translation.
          // The content of the block is typically generated by calling a custom
          // function.
          $block['subject'] = t('Title of block #1');
          $block['content'] = example_contents(1);
          break;
        case 1:
          $block['subject'] = t('Title of block #2');
          $block['content'] = example_contents(2);
          break;
      }
      return $block;
  }
}

function example_contents($which_block) {
  switch ($which_block) {
    case 1:
      // Modules would typically perform some database queries to fetch the
      // content for their blocks. Here, we'll just use the variable set in the
      // block configuration or, if none has set, a default value.
      	$data = '';
		$data .= '<div id="homepic" style="background:url('.file_create_url('banner_images/homepic.jpg').') no-repeat;">';
			$data .= '<div class="message">';
					$data .= '<h4 id="site-name">SSSS<a href="'.$base_path.'" title="'.t('Home').'">AAAA'.$site_name.'</a></h4>';
					$data .= '<p id="site-slogan">DDDD'.$site_slogan.'</p>';
			$data .= '</div>';
		$data .= '</div>';	
		return $data;
  }
}

From my understanding, it grabs the block function, with $o set to view. It them loads the contents function, takes that data, and throws it on the screen. Outside of missing something within the creation of the module itself (and that is entirely possible...this is my first one), I'm not seeing it being a module issue?

dman’s picture

dman commented

All the module looks just fine.
If you were publishing or developing it further for distribution, then the rendering part would be pulled out into a theme_example_contents() function ... which would do pretty much what you are already doing... so that's no big deal at all right now.

I can only suspect a typo, an incorrect filename or capitalization or maybe server permissions (all of which would leave you with a 404).
You said that an image with exactly the same path worked, but the background didn't. ..
so 

 $data .= '<img src="'. file_create_url('banner_images/homepic.jpg'). '" />';

works fine?

It's unlikely that your CSS is therefore over-riding it with something like

.message {background-color:white;}

but I'm out of guesses.

.dan. is the New Zealand Drupal Developer working on Government Web Standards