i have created a panel , when i click on view tab , my other blocks like User Login and navigation moves down bottom of the page , but when i click edit in Panes , it shows beside panel page , which is correct , i am using addari theme , it was working perfect all of sudden i am facing this problem.

CommentFileSizeAuthor
#4 messedup.png85.72 KBJauzsi
#4 looksfine.png87.55 KBJauzsi
actual_defect.PNG103.47 KBarjunkr
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

merlinofchaos’s picture

Can you try this in another theme? If it works in normal themes but not in your theme then it is probably your theme's fault.

merlinofchaos’s picture

Status: Active » Postponed (maintainer needs more info)
esmerel’s picture

Status: Postponed (maintainer needs more info) » Closed (fixed)

No updates for more than 30 days.

Jauzsi’s picture

Title: Allignment problem » Addari theme sidebar alignment problem
Project: Panels » Addari
Version: 6.x-3.0-beta2 » 6.x-2.1
Component: Miscellaneous » Code
Assigned: Unassigned » Jauzsi
Status: Closed (fixed) » Active
Issue tags: +addari alignment problem right panel sidebar
FileSize
87.55 KB
85.72 KB

Hi All,

I'm having the same problem with Addari theme. (Using Drupal 6.20, Addari theme 6.x-2.1, Views module 6.x-2.12)
I couldn't find solution for this issue, so I reopened this topic, hoping if somebody could help...
I don't see this problem on all my site's pages, only on wich are built by views. These pages have 'typeteaser' and 'node sticky' classed DIV containers, while others wich are fine don't have these containers. So I think these would be the problem.
But I'm really not good in Drupal development, so I don't know how to verify my theory, and how to solve it.
Could someone please help...?

UPDATE: This issue is present in Google Chrome, Internet Explorer and Opera Browser. The page looks fine in Firefox. So another guess: the problem could be CSS implementation incompatibility? Still have no ide what to look for in the code...

Joel MMCC’s picture

Wow, it’s been almost ½ a decade since this issue was created, and well over ¼ of a decade since @Jauzsi moved it to the Addari theme queue and updated and re-opened it!

I, too, am having the same issues. Using what Jauzsi noted, I noticed something else. The #sidearea div is rendered in the wrong place when a page involving a View is displayed in the main content area, regardless of whether the page is actually a View “Page” Display (complete with its own path), or a View “Block” Display set to display in the Content Bottom (and perhaps Content Top and maybe others as well) Region(s)!

Using the Developer Tools of Google Chrome (right-click in the background of the side area and select “Inspect element”), and collapsing HTML DOM-tree code blocks as desired to compactify the listing down to what we really need to focus on, we see this on a properly-rendered (non-Views) page:

▼ <div id="mast">
  ▶ <div id="primary_menu_bar">…</div>
  ▼ <div id="postarea">
    ▶ <div id="postareainner">…</div>
    ⋮
  ▼ <div id="sidearea">
    ▶ <div id="sidebars" class="clear-block">…</div>
       <!--sidebars-->
     </div>
     <br style="clear: both;">
   </div>

Note that the entire #sidearea div (and the float-clearing br that immediately follows it) is rendered as a sibling of #postarea (and immediately after it), and as a direct child of #mast. This is the way it’s supposed to be.


But watch what happens if a View exists in the Content area (perhaps anywhere in #mast):
▼ <div id="mast">
  ▶ <div id="primary_menu_bar">…</div>
  ▼ <div id="postarea">
    ▶ <div id="postareainner">…</div>
    ▼ <div id="sidearea">
      ▶ <div id="sidebars" class="clear-block">…</div>
         <!--sidebars-->
       </div>
       <br style="clear: both;">
    </div>

Note that the entire #sidearea div (and the float-clearing br that immediately follows it) is now rendered as a direct child of #postarea, and as a sibling of #postareainner (and immediately after it) — and thus as a grandchild descendant of #mast!

I still don’t know what causes this (which .tpl.php or other .php file would be involved and exactly how it’s faulty), but at least now we know what the actual rendering glitch is.

Interestingly enough, you can simply drag the whole #sidearea div in the “Elements” tab of the Google Chrome Developer Tools window and move it to its correct place, and the sidebars will pop into their correct position! Move the float-clearing br tag as well, and the white background will now appear in its correct place, filling in the background behind the entire #mast div area! This proves that this HTML-rendering-order glitch is indeed the cause of the visual glitch.

Now all we need to do is figure out what’s causing this rendering-order mispositioning and how to patch it to fix it.

Joel MMCC’s picture

Priority: Normal » Major
Issue summary: View changes

Updating to Major Priority since this breaks substantial theme functionality. This happens in recent versions of Firefox as well, now, so there is no major browser that renders such pages as they should appear.

I suspect that the actual underlying problem may be failure to emit a key “</div>” somewhere in the rendering of Views. Either the browser or normal Drupal processing detects the missing tag and attempts to compensate and inserts it, but in the wrong place when in the content (#mast?) area.

The Mini-Calendar in a Block in the sidebar appears to render correctly, yet it, too, is generated by Views (albeit as a Table instead of Unformatted), as does the Upcoming Events (also from the Calendar Module, also displayed as a View in a sidebar Block).

Joel MMCC’s picture

Priority: Major » Normal

Update:

This happens with some other Themes as well (notably a custom one for Groupanizer called “Gracenote”), and so may not be a bug in this particular theme after all. It may be in the underlying theme engine if both are based on the same one, or it may even be in Views itself. I leave it to @Jauzsi to move this issue to another Project should s/he see fit.

Workaround:

This only appears to happen with Views using the “Unformatted” Style. Set the Style to “Grid” instead, with “1” Column. This gives the same visual effect as “Unformatted,” but unfortunately uses a Table (with one column in this case) instead of DIVs to separate the rows. Thus it’s a kludge that could adversely affect accessibility and SEO, but for whatever reason it does prevent the erroneous placement of the #sidearea (and its BR) and so does work.

Since there is a viable workaround, I’m resetting this to “Normal” Priority.