Somehow, you think you are going to create a table with the different fields, but Drupal instead gets the fields as "elements" and totally ignore calling the function(s) that would generate a nice table and make things look right.

This has been reported several times by others, and I have no clue whether a setup is different or it would somehow depend on the theme in use. It has to work in Garland as that is the default theme everyone uses.

I'll be looking into it and post back once I have a patch.

I got the latest using the CVS command line:

cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout contributions/modules/addresses

and the code looks right. But let me know if that CVS command line was somehow wrong.

Thank you.
Alexis Wilke

CommentFileSizeAuthor
#3 addresses-fix-layout.6.4-1.x.patch510 bytesAlexisWilke
#2 addresses-missing-css.6.4-1.x.patch546 bytesAlexisWilke
Screenshot.png29.82 KBAlexisWilke

Comments

AlexisWilke’s picture

AlexisWilke commented

Okay... first thing here, the table is gone. Now you use the new scheme which is to use the form arrays as offered by Drupal which is neat.

And yet, it still is broken! I suspect that one of the modules I installed breaks the formatting in this way.

More later.
Thank you.

AlexisWilke’s picture

AlexisWilke commented
StatusFileSize
new addresses-missing-css.6.4-1.x.patch546 bytes

I noticed that you added an address.css file, but you do not include it in your init function. That means it won't be used.

I attach a patch for that purpose.

Thank you.

AlexisWilke’s picture

AlexisWilke commented
StatusFileSize
new addresses-fix-layout.6.4-1.x.patch510 bytes

Darn! I finally got it!

You moved different definitions to a new file which is good since you need that file only if the module is in use. So that's a good idea! But that also hid the culprit which I thought was what I needed to change, but since I could not find it in the module...

Anyway! There is a patch attached. The problem is the

you add around all your elements. You used container-inline and that means the form-item display parameter goes from block to inline. And that makes the form look all broken. Otherwise, your code looks really good. Very extensible! (and thus really hard to read... 8-) )

Just in case, there is the fix I made inline too:

// in sites/all/modules/addresses/addresses.settings.inc on line #328 as of 2008/09/19
function theme_addresses_elements($element) {
  return theme('form_element', $element, '<div class="addresses-form">'. $element['#children'] .'</div>');
}
AlexisWilke’s picture

AlexisWilke commented
Status: Active » Needs review

Marking this as a patch now.

brmassa’s picture

brmassa commented
Status: Needs review » Fixed

Alexis,

good. its now fixed on CVS.

regards,

massa

AlexisWilke’s picture

AlexisWilke commented

Actually, what I mention in #2 is done when needed, which is probably a good idea.

On the other hand, I would call the addresses.css something more specific if you want to keep the drupal_add_css() call specific only for the User Profile presentation.

So for instance, addresses.user-profile.css

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

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