Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hi,
the DISTINCT was dropped from "SELECT DISTINCT" somewhere between -rc2 and -1.1 in
$query = db_rewrite_sql("SELECT n.*, b.*, bt.name as biblio_type_name FROM {node} n $joins WHERE $where_clause $limit $sortby");
This causes the same publications to show up several times in the list, because of the node_access entries, see http://drupal.org/node/332843
Is there any reason why this was dropped? E.g. performance issues? Could we get it back pleeeease? :-)
Comments
Comment #1
rjerome CreditAttribution: rjerome commentedOpps, that wasn't deliberate. It was causing an issue with the PostgreSQL implementation, but I had intended to put it back because I knew why it was there in the first place ;-)
I'm spending a lot of time these days trying to optimize the build_query and show_results functions these days, so I keep switching amongst various versions sometimes forget where I am :-0
To that end, what do you think of the attached image showing tabs for the sort links?
Comment #2
Frank Steiner CreditAttribution: Frank Steiner commentedLooks fine! Nice how all the non-biblio-entry stuff moves out of the way :-)
Talking about design, would you consider to put a div with a common class around every year or every letter ot every type? Like
This would allow to style every year into a collapsible fieldset where you could uncollapsed every year to see its papers.
This is off topic for here ;-) Just came into my mind whenI saw the png :-)
Comment #3
rjerome CreditAttribution: rjerome commentedThat's an interesting idea, I'll make it so.
Ron.
Comment #4
rjerome CreditAttribution: rjerome commentedOk, this is in the -dev version now. I put a new div wrapper called "biblio_category-section" around the data in each section and I've change the class name of the separator bar from "biblio-year" to "biblio-separator-bar". You might notice, I put the new wrapper under the bar, otherwise the bar would disappear when the section is collapsed.
Comment #5
Frank Steiner CreditAttribution: Frank Steiner commentedThis is pretty cool, thanks a lot!
Comment #6
rjerome CreditAttribution: rjerome commentedLet me know if you implement the collapsing sections, I would like to see it.
Ron.
Comment #7
Frank Steiner CreditAttribution: Frank Steiner commentedWhile trying this I'm having problems getting the sort tabs to show correctly. The biblio-header div needs a
class="clear-block"
to break the two float:left settings from the ul stuff. Otherwise the first separator bar and the sort links overlay each other. Adding the clear-block class solves this.Comment #8
rjerome CreditAttribution: rjerome commentedIs that related to collapsing the sections or just displaying the tabs in general? If you are referring to the general case, I haven't seen this problem on the systems I've tested.
Comment #9
Frank Steiner CreditAttribution: Frank Steiner commentedThis is a general problem, the moment I installed the new -dev this problem showed up. As far as I understand it can depend on surrounding divs. We use a style where the main page sections are ordered using floats, and then inner floats can do such things. I've learnin from w3schools etc. that in general every element that uses floating should be surrounded by some other element having a "clear:both" or, in Drupal, a "class='clear-block'".
About the fieldsets (maybe we should change the topic or use a different thread :-)) it is possible to do with a jquery function, but it is not as nice as I thought because you need to fetch the text from the separator-bar and put that into the legend etc.
I will set up a demo how it looks with fieldsets. And if you like that we could think about a different approach, e.g. a option in the biblio settings like "Use fieldsets for category sections". And if that's checked, biblio could just produce different code, i.e.
With such a code we just need to add collapse.js and the stuff automatically turns into fieldsets which can be styled (due to the classes in fieldset and legend) to anything you like. And everyone could decideif or if not to use fieldsets.
Give some time to set it up at our server.
Comment #10
Frank Steiner CreditAttribution: Frank Steiner commentedOk, take a look at http://naur.bio.ifi.lmu.de/publications (you can also see the problem with the floats there).
This is a quick hack, i.e. I added the fieldset code in biblio.pages.inc and instead of using a jquery function I took our body filter which converts fieldsets into collapsible ones. That's because it is much more efficient to use a filter instead of a jquery function because the server is usually faster than the jquery stuff on a client.
So this is just to show how it could look like. It's only implemented for sort-by-year. It should not be applied if the user did a search or has selected a filter I guess.
Don't wonder if you look at the code: I've made biblio.pages inc produce the code as listed above. But our filter turns all fieldsets into a different format without a legend but a preceding div an anchor with the same classes. That's due to styling issues with fieldsets and IE vs. Opera vs. FF. It's just not possible to have that grey background bar with all three browsers when styling a legend. But that's completely unrelated to the fieldsets in general. When adding collapse.js instead of using our filter, they would look like normal fieldsets (not very nice here, so I didn't use this :-))
Comment #11
rjerome CreditAttribution: rjerome commentedCool, I don't claim to be any kind of CSS wizard, so any input is greatly appreciated.
I can see some definite advantages to collapsing the category sections. You could basically do away with "paging" the results completely, you could jump directly to a section of interest.
I see some definite disadvantages to those tabs.. the colours are fixed in the image files so they don't automatically adjust to the theme colour scheme ;-( White on white is kind of hard to read. I guess those "square" ones (List, Filter) are completely CSS, but they are kind of ugly. I suppose if the background colour was transparent in the images then you could colour them with css, but then I guess there is still the problem of the curved corners. I'll have to rethink this one a bit.
Ron.
Comment #12
Frank Steiner CreditAttribution: Frank Steiner commentedI think that using graphics is always difficult to handle :'-( Even if you get the background done, curved tabs may look strange in a theme that is only using cornered tabs...
About the fieldsets let me know if you are interested in a first try for patch. I'm thinking of per-sort options, i.e. let the user chose if fieldsets should be generated for sort-by-year but not by-title etc. There should be an option to disable fieldsets when filters/search are active. And one to chose if fieldsets should be disabled for inline/profile views. Plus a keyword for biblio_db_search to active or deactivate them. I would take approach to generate fieldset-code and re-using collapse.js instead of using an additional similar jQuery function.
Doing all this carefully would take some time, so let me know if you are interested. Personally, I don't need all of this, I can use the current DIVs (as long as you mark the closing div the way you do now, otherwise my preg_match wouldn't be able to find the ending div anymore :-)), so I'm happy. But I wouldn't mind to create the patch for others.
Comment #13
rjerome CreditAttribution: rjerome commentedPoint taken, maybe the tabs are a bit to "theme" specific. I guess the other option would be to call them primary or secondary links and let the theme look after them, then they are sure to match, or just revert back to plain old text :-(
As for the field sets, I honestly don't know what kind of demand there is out there, so maybe just wait and see if anybody picks up on this thread before investing too much work in them.
Cheers,
Ron.
Comment #14
Frank Steiner CreditAttribution: Frank Steiner commentedOk!
Comment #15
Liam MorlandThis version is no longer maintained. If this issue is still relevant to the Drupal 7 version, please re-open and provide details.