There seems to be an error in the javascript:

Fout: $(this).parent(".homebox-column-wrapper").attr("style") is undefined
Bronbestand: http://dev.##.nl/sites/all/modules/homebox/homebox.js?x
Regel: 83

Seems to be already an issue with this but that is getting to cluttered. I will try to look in to this, but can not guarantee a fix.

Comments

brianV’s picture

Thank you for opening the new issue *as asked by the module maintainer*.

brianV’s picture

Priority: Critical » Normal

Can you attach an export of you homebox?

My suspicion is that your column widths aren't properly defined, which is causing them not to print, creating the above JS failure.

Also downgrading priority as this works correctly on a stock Drupal site and my test sites.

Michsk’s picture

Priority: Normal » Critical

i have not defined widths, is that crucial? If so then that is a strange restriction since we then can not use css to alter the width.

Michsk’s picture

The settings page states that it is a optional feature:
Optionally set custom widths for each available region

defining widths does fix this, but this should be an option and not necessary.

brianV’s picture

Version: 6.x-3.0-beta5 » 6.x-3.x-dev
Status: Active » Needs review
StatusFileSize
new536 bytes

lasac:

I agree - that's not how it should work.

The expected behavior is that if width isn't defined, then it should default to (100/num_regions)% width for each column.

The attached patch should implement that - can you please test it?

brianV’s picture

Title: attr("style") is undefined » Widths aren't printed in TPL if custom column widths are not set in homebox config.
Michsk’s picture

Title: Widths aren't printed in TPL if custom column widths are not set in homebox config. » attr("style") is undefined

No does not fix it.

Another issue is that we can not use decimals. But since we don't use pixels but percentage then decimals should work. 33.3% should be a valid width.

brianV’s picture

Title: attr("style") is undefined » Widths aren't printed in TPL if custom column widths are not set in homebox config.
StatusFileSize
new588 bytes

Looks like we cross posted.

Try this patch for the default case where no custom column widths are entered.

brianV’s picture

lasac: I've created a new issue for decimals in column widths at #1300758: Custom column widths don't accept / preserve non-integer widths.. I've included a patch in that issue; I would appreciate it if you wouldn't mind testing it.

Michsk’s picture

Status: Needs review » Reviewed & tested by the community

latest patch fixes this.

rbosscher’s picture

#8 Fixed it for me too

slybud’s picture

Patch in #8 also made my day and solved the issue : +1 for it

foxtrotcharlie’s picture

Patch in #8 works for me too. Thanks @brianV

drumm’s picture

The original request should be fixed by #955072: Make Homebox only equalize heights of columns within the same row., which avoids the problem by using classes instead of inline styles.

It looks like part or all of BrianV's fix was committed, http://drupalcode.org/project/homebox.git/commit/1dbf189. I found this to be a problem so far with Drupal.org's upgrade to D7. We want the homebox columns to match our grid system; in D6, the theme fully handled it with css applied for homebox's classes. At the moment in D7, the inline styles are also applied. Having both is messing up the layout and the theme can't override inline styles with CSS alone. I'll look a bit more into:

  • Override homebox.tpl.php in our theme to remove the styles, which would mean we have to maintain a copy of that too
  • A way to use the widths when needed, and avoid inline styles when not needed
  • Revert the automatic widths
  • Live with the automatic widths and set them appropriately
drumm’s picture

Status: Reviewed & tested by the community » Fixed

I went with "A way to use the widths when needed, and avoid inline styles when not needed." If widths aren't specified at all, the space is still divided up evenly. If zero is specified for an individual width, the inline style is omitted.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.