Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
It makes sense to be able to search by author and the creation date for a site with many nodes. This patch will add the ability to search by the author and creation date.
We need to consider if and how this should be supported for content types that have their date and author hidden. See #70722: Search results should respect the content type's "Display author and date information." option
Comment | File | Size | Author |
---|---|---|---|
#9 | search_author_date_0.patch | 3.87 KB | Susurrus |
#8 | search_author_date.patch | 3.72 KB | Susurrus |
#7 | search_author_date.patch | 3.72 KB | Susurrus |
#1 | search-date-author-233476-1.patch | 3.59 KB | floretan |
node.module.patch | 3.58 KB | mohanjith | |
Comments
Comment #1
floretan CreditAttribution: floretan commentedAttaching a revised version of the patch that is relative to the main drupal folder.
Comment #2
robertDouglass CreditAttribution: robertDouglass commentedcreated-evaluator looks specific to your site. Can you make that a generic Drupal term?
Comment #3
robertDouglass CreditAttribution: robertDouglass commented-1 to module_exists('js_calendar') as well.
Comment #4
tbartels CreditAttribution: tbartels commentedcreated-evaluator is the name of the form-field for the comparison selector, not site-specific
+ $form['advanced']['created']['created-evaluator'] = array(
+ '#type' => 'select',
+ '#title' => t('Created date comparison'),
+ '#options' => array('' => '---', '<' => 'Before', '=' => 'On', '>' => 'After'),
+ '#multiple' => FALSE,
+ );
Comment #5
Susurrus CreditAttribution: Susurrus commentedThis still needs a reroll minus the js_calendar code.
Comment #6
Susurrus CreditAttribution: Susurrus commentedComment #7
Susurrus CreditAttribution: Susurrus commentedI've rerolled to remove the js_calendar part, renamed created-evaluator to created-comparator, and added the searching code for 'author', which was missing.
Still not really a fan of the organization, but I think fixing that would be for a follow-up patch.
Comment #8
Susurrus CreditAttribution: Susurrus commentedAlright, a few tabs in that patch. Here's a new one without tabs.
There should really be a check for all submitted patches through coder.module to confirm that the coding standards were adhered to. Would probably speed up development time.
Comment #9
Susurrus CreditAttribution: Susurrus commentedMakes it a little nicer to have the autocomplete feature available for usernames if the user have
access user profiles
permission.I would think it'd be easier if the FAPI for textfield could check the menu system for appropriate permissions before attaching autocomplete URLs than having to do the check this way.
Comment #10
Alex72RM CreditAttribution: Alex72RM commentedMaybe it's necessary another revision for Drupal 5.10.
The last part of patch doesn't match node.module:
Comment #11
Susurrus CreditAttribution: Susurrus commentedThis patch isn't for Drupal 5.x, it's for 7.x, as all feature requests currently should be.
Comment #12
Alex72RM CreditAttribution: Alex72RM commentedComment #13
greg.harveyWhy was this set to "won't fix"? Looks like a useful addition to node.module to me!
Comment #15
narovi CreditAttribution: narovi commentedComment #16
petchiappan CreditAttribution: petchiappan commentednode.module.patch queued for re-testing.
Comment #17
jhodgdonFeature requests at this point are too late for Drupal 7, and much too late for Drupal 6, sorry! Moving to consideration for Drupal 8, and into the search module queue.
Comment #18
greg.harveyWhy move to search.module? I thought the code to be patched to achieve this resides in node.module...?
Comment #19
jhodgdonThat is true, but it is search related code and a search feature request. And I am hoping in Drupal 8 that all of the search related code will be in search.module or sub-modues and not in node.module any more. :)
Comment #20
greg.harvey@jhodgdon: You're right to bump this to D8, but you're way off with the way Drupal works. Let me explain:
The code we're looking at here will *never* be a part of search.module, because this code is in a hook - it's by design that Drupal allows modules to expose "hooks" to other modules so they can, in turn, manipulate their behaviour. The search module does this by providing a hook called hook_search() so other modules can write their own search interfaces.
A bit more on hooks here: http://api.drupal.org/api/group/hooks - it says allows modules to interact with core, but it's more than that - the hooks system allows modules to interact with other modules, period, whether core or otherwise - but I digress... You get the idea - API code is central to one module but the code to *manipulate* that API is distributed to modules, ones which invoke the original module's hooks.
This issue is looking at the hook_search() implementation for node.module - node_search(). This will always be a node.module issue, because what you're looking at is node.module manipulating the API provided by search.module, so it is incorrect to mark it up as a search.module issue.
Because of this, a lot, if not most "search-related code" will always be distributed to other modules, by design, and search.module is just an API for searching the Drupal database.
Putting back to the correct queue, hope that clears it up for you. =)
Comment #21
jhodgdongreg.harvey: I know perfectly well how hooks in Drupal work. Please check out people's background before assuming they are inexperienced.
That said, this is a search feature request, whether or not the code will go into the node module. No one who is maintaining the node module issue queue is going to address this, and it will be addressed in Drupal 8 by the maintainer of the search module (me). So if you don't mind, I would like to leave it in the search issue queue, even though the code might end up in the node module.
By the way, we are hoping for Drupal 8 to make a module called search_nodes.module (or something to that effect), pulling out the search hooks from node.module. Please check out #237748: Decouple core search module implementations from node and user module (and turn search/node and search/user to views). and add to that discussion if you are interested.
Comment #22
greg.harveySorry, it was hard to judge your experience from your post.
Interesting, re: search_nodes.module. I understand now why you're marking it as a search.module, but without the back story it was totally counter-intuitive to mark up a patch for node.module as a search.module patch. I'm sure you understand... ;-)
Comment #23
jhodgdonAnother issue that has a partial patch for this (which I've just closed as a duplicate): #155254: Search Content by Author
Comment #24
klonosI think we should postpone this on #2083717: Convert Search Results to Views (or close it as a duplicate or even make the other issue a META and this one one of its sub-issues).
Comment #25
ianthomas_ukAdded reference to #70722: Search results should respect the content type's "Display author and date information." option
Comment #26
jhodgdonSince 8.0.x-beta1 has been released, our policy at this point is No feature requests until 8.1.x. See #2350615: [policy, no patch] What changes can be accepted during the Drupal 8 beta phase?. Sorry, it's just too late for 8.0.x at this point, so even if we had a viable patch, the core committers would not commit it.