The problem: If the user quickly enters a title that is unique, there is no need for him or her to see an empty block or fieldset or whatever "warning" about duplicate content. Alternatively, it might be nice to have a different description when the content is unique and previously wasn't.

This might be implemented by expanding Description to be three fields:
- Initial Description (Description upon entry. Maybe be empty or <default> to indicate use following description.)
- Related Content Found (Description when matches > 0. Defaults to today's description, perhaps in a red/warning CSS class.)
- No Related Content Found / Title is Unique (Description when matches = 0. Defaults to "Success: your title is unique.", perhaps in a green/success CSS class.

I think this would "punish" the user less than the current implementation, at the cost of some complexity. This would require changing the AHAH involved, I assume.

Alternatively, this could all be moved to a theme function.

Comments

coltrane’s picture

coltrane
he/him
commented

I see the value in this. I may get to looking into this more sometime in the next week.

danchadwick’s picture

danchadwick commented

coltrane - I am including this in an upcoming patch on this issue:
http://drupal.org/node/942632#comment-3600046

coltrane’s picture

coltrane
he/him
commented

DanChadwick, it's easiest to review functionally separate patches. Is this feature necessary in a patch to #942632: Monster issue ?

danchadwick’s picture

danchadwick commented

I've added quite a bit of functionality. At this point, the module meets my needs. Because of changes in the interaction between the server and jQuery, it seemed unreasonable to separate the functions.

Rolled into 942632 "Limit responses" is the following functionality related to this issue:

  1. The uniqueness in-line fieldset starts out collapsed. The prompt hidden within it is the prompt specified in the UI. The block of course has the same text and is visible (no fieldset).
  2. Upon page load, an initial search is triggered, if there is a long enough text (>= three characters). This also fixes the duplicate-results bug with preview-the-search and support edit node (as opposed to add node).
  3. During matching, the responses are limited in number to the value set in the UI. Responses beyond that are indicated with "... and more" following the ul ("replace" searches only"). This text (like "Searching ...") is currently not configurable or translatable. Not implemented for solr. Drupal search is limited to 10 by core (and validated by the uniqueness settings UI).
  4. If the search on a non-blank title yields no results, the prompt is replaced by "Success! No duplicates found." The "Success!" may be styled via CSS. This text too is not configurable or translatable (currently).
  5. For "replace" type searches, the "Searching" is moved to the bottom to avoid flickering the content up-and-down while searching.

I also implemented limiting the search to a content type (node and drupal searches only; no solr), as well as omitting the current node from the results (no solr). To a certain extent, this could be considered part of the "Flexible URL" issue as it only really comes up with edit.

It seems that these issue interact. I can create separate patches for Flexible URLS and Limit Responses, but this issue is rolled into them.

I have not addressed separate configuration settings for separate content types, but I probably will soon. That should be able to be a separate patch, but one contingent upon application of series of patches before it.

bforchhammer’s picture

bforchhammer commented

Nice, these changes sound good! However I prefer separate patches as well because I think it helps to keep the codebase clean and avoid inadvertent changes in the process... Sorry for the extra work this will cause but I think it's worth doing.

# The uniqueness in-line fieldset starts out collapsed. The prompt hidden within it is the prompt specified in the UI. The block of course has the same text and is visible (no fieldset).

Not sure I agree with your use case; I think I want my users to see the fieldset all the time, uncollapsed. So this will probably need a configuration option.

# Upon page load, an initial search is triggered, if there is a long enough text (>= three characters). This also fixes the duplicate-results bug with preview-the-search and support edit node (as opposed to add node).

Duplicate-results bug? What's the issue exactly? How do I reproduce it? (Shouts for a separate issue!); An initial search on page load sounds like a good solution though.

# During matching, the responses are limited in number to the value set in the UI. Responses beyond that are indicated with "... and more" following the ul ("replace" searches only"). This text (like "Searching ...") is currently not configurable or translatable. Not implemented for solr. Drupal search is limited to 10 by core (and validated by the uniqueness settings UI).

Needs to be implemented for Solr, definitely needs configuration option and translation support. Same issue for other parts; another reason to make separate issues would be so this doesn't hold back other features/parts of your patch. That 10 search result limit with Drupal needs a note next to the respective configuration value (and/or in the documentation); (assuming we can't change it).

I also implemented limiting the search to a content type (node and drupal searches only; no solr) [...] I have not addressed separate configuration settings for separate content types, but I probably will soon.

See #899480: Limit search to same content type if you haven't already.

[...] as well as omitting the current node from the results (no solr)

Haven't thought of that, definitely required for "node edit forms".

danchadwick’s picture

danchadwick commented
Status: Active » Postponed

Please see patch and release notes at Limit number of responses. I reply to post #4 there.

bforchhammer’s picture

bforchhammer commented
Status: Postponed » Active

#942632 has been closed, so work should continue in this issue now...

bforchhammer’s picture

bforchhammer commented
Status: Active » Closed (won't fix)

I'm closing this issue because 6.x is not seeing much activity anymore, and 7.x already contains functionality suggested above.