Posted by mohanjith on March 12, 2008 at 8:30pm
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | search.module |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
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.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| node.module.patch | 3.58 KB | Idle | FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch node.module_68.patch. | View details | Re-test |
Comments
#1
Attaching a revised version of the patch that is relative to the main drupal folder.
#2
created-evaluator looks specific to your site. Can you make that a generic Drupal term?
#3
-1 to module_exists('js_calendar') as well.
#4
created-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,
+ );
#5
This still needs a reroll minus the js_calendar code.
#6
#7
I'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.
#8
Alright, 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.
#9
Makes it a little nicer to have the autocomplete feature available for usernames if the user have
access user profilespermission.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.
#10
Maybe it's necessary another revision for Drupal 5.10.
The last part of patch doesn't match node.module:
@@ -1978,6 +2030,15 @@if (isset($form_state['values']['language']) && is_array($form_state['values']['language'])) {
$keys = search_query_insert($keys, 'language', implode(',', array_filter($form_state['values']['language'])));
}
+ if (isset($form_state['values']['author']) && $form_state['values']['author'] != '') {
+ $keys = search_query_insert($keys, 'author', $form_state['values']['author']);
+ }
+ if (isset($form_state['values']['created-comparator']) && $form_state['values']['created-comparator'] != '') {
+ $keys = search_query_insert($keys, 'created-comparator', $form_state['values']['created-comparator']);
+ }
+ if (isset($form_state['values']['created-date']) && $form_state['values']['created-date'] != '' && strtotime($form_state['values']['created-date']) !== FALSE) {
+ $keys = search_query_insert($keys, 'created-date', strtotime($form_state['values']['created-date']));
+ }
if ($form_state['values']['or'] != '') {
if (preg_match_all('/ ("[^"]+"|[^" ]+)/i', ' ' . $form_state['values']['or'], $matches)) {
$keys .= ' ' . implode(' OR ', $matches[1]);
#11
This patch isn't for Drupal 5.x, it's for 7.x, as all feature requests currently should be.
#12
#13
Why was this set to "won't fix"? Looks like a useful addition to node.module to me!
#14
The last submitted patch failed testing.
#15
#16
node.module.patch queued for re-testing.
#17
Feature 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.
#18
Why move to search.module? I thought the code to be patched to achieve this resides in node.module...?
#19
That 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. :)
#20
@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. =)
#21
greg.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 add to that discussion if you are interested.
#22
Sorry, 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... ;-)
#23
Another issue that has a partial patch for this (which I've just closed as a duplicate): #155254: Search Content by Author