Hi,

I just realized (although I should have known when I was using $_SESSION :-)) that you cannot perform any search or filtering if you have cookies disabled in your browser. You alway get the full list of publications.

But it is possible to do every search and filtering using the URL. So I wonder if it wouldn't be better to drop the use of the $_SESSION variable completely and just redirect to the matching URL if search or filters are selected. Then everything works without cookies and users don't complain "The filters are broken...".

What do you think about this?

Comments

rjerome’s picture

rjerome CreditAttribution: rjerome commented

Yes, I agree, this has been part II of my biblio.page.inc refactoring exercise :-) (You may have notice biblio_show_results() is somewhat different now). If I remember correctly, you had proposed some semantics for this purpose a while back? Could you refresh my memory on this one?

Ron.

Frank Steiner’s picture

Frank Steiner CreditAttribution: Frank Steiner commented

Hmm, I'm not sure I know what you are talking about :-) We discussed a filter-related problem in http://drupal.org/node/331359 if that's what you mean. Actually, this problem would vanish also if SESSION was no longer used.

Did I get you right that you are in preparation of removing the use of the SESSION stuff? If that's right I wouldn't mind to care about the search related parts. Search would become a bit less efficient because I store the once found node list in SESSION, but this has drawbacks, too, so I wouldn't mind to drop this.

rjerome’s picture

rjerome CreditAttribution: rjerome commented

Maybe it wasn't you, I can't find it either, but if I recall it was a URL something like this... ?q=biblio&sort=author&order=asc&filter={year:2008 AND type:Journal} Note the filter portion.

Frank Steiner’s picture

Frank Steiner CreditAttribution: Frank Steiner commented

No, that wasn't me :-) But personally I'm very happy with the URL as is at the moment, i.e. /biblio/search/DNA/author/steiner/author/jerome

The other kind of URL is more google-like, but I don't see anything wrong with the existing URL style...

rjerome’s picture

rjerome CreditAttribution: rjerome commented

I guess the problem I see with the Drupal style is parsing and delimiting the components. For instance, what if you have multiple search terms? Do you do /biblio/search/x/search/y/search/z or /biblio/search/x/y/z and if so how do you know when you've come to the end of the search terms?

Frank Steiner’s picture

Frank Steiner CreditAttribution: Frank Steiner commented

For this special parameter where you can have only one instance (in contrast to all filter arguments) I would say the last search overrides all former searches. Actually, I'm not sure anyone wants to type this in. If we create the URL from the GUI, there will always only be one search term in the URL.

Don't get me wrong, I'm not opposing the goggle-style! I was just thinking that it could take a lot more work because you already *have* implemented the URL-style. So for a first approach one would just have to convert the SESSION contents into URL arguments to get rid of cookies. That should be quite straightforward.

sdrycroft’s picture

sdrycroft CreditAttribution: sdrycroft commented

I'd be keen to seen this implemented, as currently "Filter" does not work for anonymous users when the Boost module is enabled on a site. That could be described as being a compatibility issue between the two modules, but personally I think it would be beneficial if filtered results pages could be cached. Adding the filter to the URL would enable the Boost module to cache filtered results. Personally I'd prefer a URL scheme which doesn't use an additional GET argument, but instead tags on to the end of "q", especially as this would improve compatibility with the Boost module.

An additional URL scheme to consider could be like the one below, although this is just a thought (Note, standardising the order of the filter portion of the URL to be alphabetical would ensure that a user is served a cached page when it is available, as author:smith;year:2009 would not match year:2009;author:smith).

biblio/filter/author:jones;author:smith;year:2009?sort=author&order=asc
Aren Cambre’s picture

Aren Cambre CreditAttribution: Aren Cambre commented

Views does this already, so fulfilling #682044: Support fields (CCK) in D7 Bibliography Module would fix this.

sdrycroft’s picture

sdrycroft CreditAttribution: sdrycroft commented

@Aren - It would still be an issue for Drupal 6 though.

snufkin’s picture

snufkin CreditAttribution: snufkin commented
Version: 6.x-1.1 » 7.x-1.x-dev

The Drupal 7 version still implements a search page that relies on $_SESSION which breaks Varnish compatibility.

An alternative could be to rebuild these pages that use biblio_page() and biblio_profile_page() with Views and ship the default views with the module.

djbobbydrake’s picture

djbobbydrake CreditAttribution: djbobbydrake commented
Issue summary: View changes

Wondering if there are any plans to implement non-session-based search.