First of all, Michelle, I'm always impressed by everything you do. Thank you.

I just took a look at the latest alpha4 and I've found something very minor, but it's confusing. I'm using the Silver Bells style.

When displaying any of the views under the tabs such as "Active topics" (/forum/active, /forum/new, /forum/unanswered), the forum table (class="forum-table forum-table-topics view-table") is 100% the width of my content area, as I would expect. However, when I view the simple url for the forum itself (/forum/129), the table is not the full width of my content area.

I'm using firebug to look at the CSS and expected to find a difference that would be easy to report, but instead I'm seeing an extra table with class="sticky-header" with a fixed width. That doesn't appear to be in the original HTML of the page, so I'm thinking perhaps that is added to the DOM with javascript??? Anyway, when using the url such as /forum/129, the explicitly specified width of the "sticky-header" table is more narrow. When using the urls such as /forum/active, the width is much greater.

So something about the calculation of the "sticky-header" table width is different depending on whether I view /forum/129 vs. /forum/active. It's certainly not critical, but could be an indication of another problem.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Michelle’s picture

Title: sticky-header width not the same for forum table & topic list » Sticky-header width different for different tables
Project: Advanced Forum » Views (for Drupal 7)
Version: 6.x-2.0-alpha4 » 6.x-2.x-dev
Component: Styles » Miscellaneous
Category: bug » support

I have no idea how Views calculates that, sorry. I barely know any javascript so me digging into the code isn't likely to be useful. I'm going to send this one over to the Views queue in hopes that someone over there can shed some light on this.

If there's something AF can do to affect this, feel free to toss it back. All AF is doing is turning sticky headers on, though, so I don't know anything that could be done from my end.

Michelle

carteriii’s picture

Version: 6.x-2.x-dev » 6.x-2.12
Component: Miscellaneous » Code
Category: support » bug

Michelle, are you at least seeing the same behavior that I am, that the table is not full with when using /forum/xxx vs. /forum/active? If you're not seeing that, then it might indicate that I have something else going on.

merlinofchaos’s picture

Status: Active » Closed (won't fix)

Views doesn't provide any CSS for sticky headers that I'm aware of. That's going to be entirely managed by your theme.

'sticky-header' is an option that can be turned on when displaying tables. It's actually on by default, most of the time. In Views it must be explicitly turned on. Some tables explicitly turn it off.

Whatever is providing the fixed with to 'sticky-header' is probably the culprit. YOu may need to change or override that in your theme.

carteriii’s picture

Status: Closed (won't fix) » Active

I agree it's not in the CSS. The width is being explicitly added to the sticky-header table declaration. For example, here is the HTML that I'm seeing with Firebug:

<table class="sticky-header" style="position: fixed; top: 0px; width: 638.75px; left: 10px; visibility: hidden;">

So I'm assuming it's the javascript which is creating the stick-header that is putting that 638.75px in there. Is that javascript just grabbing the current width of the table? My issue is that the width value comes up different in two situations that seem like it ought to be the same, and I haven't figured out where/what javascript is setting that value.

merlinofchaos’s picture

Status: Active » Closed (won't fix)

Sorry, I can't help you there, sticky headers are a core feature.

If it's from a view, you can turn them off in the table style settings.

carteriii’s picture

Project: Views (for Drupal 7) » Advanced Forum
Version: 6.x-2.12 » 6.x-2.0-alpha4
Status: Closed (won't fix) » Active

OK, this *is* related to advanced forum, so I'm moving this back to that project where we started. The sticky-header just added a layer of abstraction that made it difficult to track down.

Michelle, I found the issue. In short, the "Last Post" column does not have the same class on it in the advanced_forum_topic_list view as it does in the other advanced forum views (e.g. advanced_forum_active_topics). This is because the advanced_forum_topic_list uses "Node: Last comment time" to define the "Last Post" column; however, the other views use the "Node: Updated/commented date" to define the "Last Post" column.

Line 168 of advanced_forum.naked.structure.css has the following CSS that is not applied to the view "advanced_forum_topic_list":

.forum-table-topics td.views-field-last-updated {
  width: 30%;
}

Note that this will not apply when the column is defined as "Node: Last comment time". Consequently the column is not stretched, and the table does not consume the full width of the content area.

I believe the "fix" is to change the views to use the same "Last Post" column definition. Alternatively additional CSS could be added to style the other column definition, but I think it's more proper that both column definitions be the same or we may later find some other unexpected consequence.

Michelle’s picture

Title: Sticky-header width different for different tables » Last post for Active Topics should be last comment time/author
Version: 6.x-2.0-alpha4 » 6.x-2.x-dev

Hmm... Active Topics _was_ changed at one point. I don't know how it got reverted. Only the "New and updated" view should be using the updated time. And that I've been thinking about changing if I can figure out how to write a filter for just new, not updated.

Michelle

carteriii’s picture

Version: 6.x-2.x-dev » 6.x-2.0-alpha4

Perhaps I'm seeing this since I've had advanced_forum installed for quite some time, so I'm running off an old definition of a view???

Michelle’s picture

Version: 6.x-2.0-alpha4 » 6.x-2.x-dev

No, I haven't fixed it yet. Had an exhausting day and crashed soon after I wrote that response. Not likely to get it fixed tonight.

Michelle

mcdruid’s picture

Patch attached which changes advanced_forum_topic_list's 'Last post' field to "Node: Updated/commented date" rather than "Node: Last comment time", as per carteriii's comment #6 above.

Anyone able to test and confirm this fixes the issue?

mcdruid’s picture

This patch also updates the Forum topic list style, so that the Last comment author and Last post fields remain grouped in one (sortable) column.

mcdruid’s picture

Status: Needs review » Fixed

Committed to 6.x-2.x - thanks for your help carteriii.

Status: Fixed » Closed (fixed)

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

Henke001’s picture

Ah, so I see, this must be the problem for me. How it works now might be fine in some cases, but say that you delete a new comment from an old topic, that topic will still be updated and still on top of the topic list. Like the other day I had a spambot spamming 100 or so of the oldest topics of my 10 year old forum, I removed the spam posts but still the main post is marked as updated and is now on top of the topic list, pushing all relevant topics down a few pages.

mcdruid’s picture

Assigned: Unassigned » mcdruid
Status: Closed (fixed) » Needs work

Hmm... Active Topics _was_ changed at one point. I don't know how it got reverted. Only the "New and updated" view should be using the updated time. And that I've been thinking about changing if I can figure out how to write a filter for just new, not updated.

...hmm - did I get the wrong end of the stick here? I'll have a look at reverting the change to the view (so that it returns to using last comment time), and fix the original CSS / class issue.

Michelle’s picture

They should be using the last comment time because using last updated is confusing for end users. In a forum, most users only care when there is a new post, not when someone made an edit, especially since Drupal really doesn't make clear what was edited without additional modules.

The "New and Updated" view uses the last updated time because it makes sense there.

mcdruid’s picture

Status: Needs work » Needs review
FileSize
2.5 KB

I believe this patch should reverse the change I mistakenly made to the view (i.e. change the last post field back to using last comment time instead of last updated), and should also fix the CSS issue that carteriii was originally concerned with.

This should apply to beta1 or the current dev release - I'd appreciate someone else testing this before I commit it to 6.x-2.x-dev, but if nobody does, I'll go ahead and commit it next time I spend some time on AF.

mcdruid’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

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

dillix’s picture

Version: 6.x-2.x-dev » 7.x-2.x-dev
Assigned: mcdruid » Unassigned
Status: Closed (fixed) » Active

I think this patch also should be ported into 7.x-2.x-dev branch. As I can see in includes/views/advanced_forum_topic_list.view code for Updated/commented date, starting from line 359:

/* Field: Content: Updated/commented date */
$handler->display->display_options['fields']['last_updated']['id'] = 'last_updated';
$handler->display->display_options['fields']['last_updated']['table'] = 'node_comment_statistics';
$handler->display->display_options['fields']['last_updated']['field'] = 'last_updated';
$handler->display->display_options['fields']['last_updated']['label'] = 'Last post';
$handler->display->display_options['fields']['last_updated']['alter']['alter_text'] = 0;
$handler->display->display_options['fields']['last_updated']['alter']['make_link'] = 0;
$handler->display->display_options['fields']['last_updated']['alter']['word_boundary'] = 1;
$handler->display->display_options['fields']['last_updated']['alter']['ellipsis'] = 1;
$handler->display->display_options['fields']['last_updated']['alter']['strip_tags'] = 0;
$handler->display->display_options['fields']['last_updated']['alter']['trim'] = 0;
$handler->display->display_options['fields']['last_updated']['alter']['html'] = 0;
$handler->display->display_options['fields']['last_updated']['hide_empty'] = 0;
$handler->display->display_options['fields']['last_updated']['empty_zero'] = 0;
A-snowboard’s picture

Issue summary: View changes

+1 dillix