huge amount of space under slider

In an attempt to further check any installation problems I set up a new testing domain online at http://d7dev.junglecreative.com and installed with the standard installation profile.

I then uploaded the latest snapshot from the repository, currently only on the 7.x-1.x-dev branch (http://drupalcode.org/project/Flux-Slider.git/snapshot/e400f5b6c83c0a5e1...) and enabled that module.
edit:this has now been superseded by the 7.x-1.4 release

As I didn't yet have the Libraries API installed it would not let me enable the module, which is the desired action at this point.

I then navigated to the Libraries API page and used the 'install from URL' function to add the latest 7.x-2.0 version from http://ftp.drupal.org/files/projects/libraries-7.x-2.0.tar.gz

I imagine at this point the majority of users will enable the Flux-Slider and Libraries-API modules at the same time, by my reckoning that is when an error is most likely to occur rather than enabling the Libraries API first and then the slider.

At this point there is already a block available for use within admin/structure/block titled Flux Slider and the system status report at /admin/reports/status is showing a requirements error as the Flux-Slider library is not installed;

<tr class="error">
  <td class="status-icon"><div title="Error"><span class="element-invisible">Error</span></div></td>
  <td class="status-title">Flux Slider JavaScript Library</td>
  <td class="status-value">Not Installed, please see the README.txt for instructions on installing the library</td>
</tr>

Next test was to place the Flux Slider block within the templates 'highlighted' block placement area and refresh the front page. This results in a requirements error again being displayed instead of the block stating that the Flux Library is not installed;

<div id="messages">
  <div class="section clearfix">
    <div class="messages error">
      <h2 class="element-invisible">Error message</h2>
      The Flux Slider library is not installed, consult the modules README.txt for instructions.
    </div>
  </div>
</div>

All of this behaviour is by design and the error messages are being displayed as they should.

The next step was to navigate to the Flux Slider admin panel pages at admin/structure/flux-slider and admin/structure/flux-slider/options. Both pages loaded without any problems or errors being displayed. I then saved the details for each admin page and again viewed the front page and the system status pages which were both still displaying the requirements error message.

Next I FTP'd into the server and created the directory sites/all/libraries and sites/all/libraries/flux-slider and then transferred a copy of the Flux Library into the sites/all/libraries/flux-slider directory.

Next step was to refresh the system status report page at /admin/reports/status at which stage it was displaying a success message that the Flux Library was found on the server in the required location;

<tr class="ok">
  <td class="status-icon"><div title="OK"><span class="element-invisible">OK</span></div></td>
  <td class="status-title">Flux Slider JavaScript Library</td>
  <td class="status-value">Installed</td>
</tr>

I then refreshed the sites front page (which already had the Flux-Slider block in place but was showing the requirements error) and the slider block appeared and started running its automated transitions, which is the default setting.

I then refreshed the Flux Slider admin pages and changed all the settings and re-saved the forms, no errors reported and settings took hold fine and changed the front page block.

Caveats from this exercise:

Upon install the settings autoplay value is not reported in the admin form although it was set in the database; this will be rectified in the next commit.

RE: CSS height bug
The HTML <div> element with a class name of '.fluxslider' that is created by the Flux Library was for some reason appending an extra 0 (zero) to the DOM injected height element, so when set to 200px height in the admin panel it would set it as 2000px which would push the content way down that sat beneath the slider.

if that element has an additional forced style rule applied as such;

.fluxslider {
  height: 200px !important;
}

then that seems to take care of the overflow problem but that is not my desired solution as we really shouldn't be forcing the style rules with an !important tag as it really isn't the best solution.

Digging a little deeper into the sites database, in particular the {variable} table we come across the database entry for the height attribute which is displayed as ('trans_height', 's:3:"200";') which is showing me that the correct value is being stored in the database, so where is it getting transferred up to 2000 ?

The only place within the module where the height attribute is received from the database and then used to build out the module is within the flux_slider.module file, specifically the function flux_slider_block_view(). Here it is pulled from the database using $img_height = variable_get('trans_height');

It is then added to the theme(image) function using;

foreach ($images as $img_path) {
  $image = theme('image', array(
    'path' => $img_path,
    'alt' => $img_alt,
    'title' => $captions[$caption_count],
    'width' => $img_width,
    'height' => $img_height,
    'attributes' => $attributes,
 ));

- but I don't see that the problem is starting from there as they are the HTML attribute values added to the IMG elements.

The height attribute is then passed to the JavaScript files within a settings array as such;

$flux_settings = array(
  'flux_autoplay' => variable_get('trans_autoplay'),
  'flux_transition' => variable_get('trans_type'),
  'flux_delay' => variable_get('trans_delay'),
  'flux_pagination' => variable_get('trans_pagination'),
  'flux_controls' => variable_get('trans_controls'),
  'flux_captions' => variable_get('trans_captions'),
  'flux_width' => variable_get('trans_width'),
  'flux_height' => variable_get('trans_height'),
);

and is then passed to the script as shown;

drupal_add_js(array('flux_slider' => $flux_settings), 'setting');
drupal_add_js($js_path, $flux_settings);

All of this, to the best of my knowledge is the correct methods for dealing with such techniques and through debugging it seems like the correct value is being passed along, to this point at least.

Next, time to check over the JavaScript file flux_slider.js that deals with building the function to pass to the Flux library.

Within the main script object Drupal.behaviors.fluxSlider it only has 2 references to the height attribute. The first time when it is retrieved from the settings array as thus;
var flux_height = Drupal.settings.flux_slider.flux_height;

To check this value I placed some console log outputs into the code, first at the start of the function to check it before the assignment;

console.log('height 1: '+Drupal.settings.flux_slider.flux_height); 

.. and then after the assignment I placed another call to ;

console.log('height 2: '+flux_height);

Both of these console outputs reported back the correct value as set in the slider admin panel.

I even attempted to check the value after it had already been passed to the initialization function as thus;

var myFlux = new flux.slider('#slider', {
          autoplay: flux_autoplay_bool,
          transitions: [flux_transition],
          delay: flux_delay,
          pagination: flux_pagination_bool,
          controls: flux_controls_bool,
          captions: flux_captions_bool,
          width: flux_width,
          height: flux_height,
        });

Again, this echoed back the correct value that the slider height was set to within the admin panel.

The only area that could possibly be doing it is within the Flux Library itself although when using the Library as a standalone script this condition doesn't rear its head. It could be related to its use within Drupal in which case it would be a clash with core in some way, this would need further in-depth research.

I have attempted to trace the height value through the Flux Library but haven't found anywhere that it deviates from the setting, I will possibly get in touch with the scripts author and see if he can shed any light on the problem.

In the meantime, I have been trying to override the height attribute that is set on the div.fluxslider element ;

<div class="fluxslider" style="width: 960px; height: 3500px;">

(this should be a height of 350px !)

..alas but to no avail so I have resorted to manipulating its container the div#slider element where I have programmatically coded in the height that is passed from the database along with an overflow:hidden style rule, as thus;

jQuery("div#slider").css({
  "height":flux_height,
  "overflow":"hidden"
});

yeah it may be a bit dirty but it does the trick and may only be a short term fix until i can get to the real root of the problem.

The current 7.x-1.4 release contains the updated code base, let me know if you have any problems with it.