This feature request is #6 on Dries' Drupal 6 wishes at http://drupal.org/node/141043

Thought to proceed with it, and have a patch attached.. It affects path_overview() function; a search keyword argument has been added, which when set, returns URL aliases matching the same(using LIKE). Please review..

CommentFileSizeAuthor
#20 drupal6-feature-path_alias_search_5.patch2.52 KBGurpartap Singh
#19 drupal6-feature-path_alias_search_4.patch2.76 KBGurpartap Singh
#12 drupal6-feature-path_alias_search_3.patch5.52 KBGurpartap Singh
#10 drupal6-feature-path_alias_search_2.patch4.43 KBGurpartap Singh
#7 drupal6-feature-path_alias_search_1.patch4.53 KBGurpartap Singh
#4 drupal6-feature-path_alias_search_0.patch4.16 KBGurpartap Singh
drupal6-feature-path_alias_search.patch4 KBGurpartap Singh

Comments

chx’s picture

chx commented

I believe http://drupal.org/node/106094 solves this better, that issue needed a JS plugin now it's done, I will ask Steve McKenzie to revisit the issue.

boris mann’s picture

boris mann commented

chx, this seems nice and simple and I think we want this for the overview (see webchick comment on why yes, we still do want to be able to look at all paths).

heine’s picture

heine commented
Status: Needs review » Needs work 
+  if ($search_key) {
+    $sql = "SELECT * FROM {url_alias} WHERE dst LIKE '". $search_key ."'";

Please see http://drupal.org/node/101496 .

Gurpartap Singh’s picture

Gurpartap Singh commented
Status: Needs work » Needs review
StatusFileSize
new drupal6-feature-path_alias_search_0.patch4.16 KB

Also changed line endings to LF(unix).

ChrisKennedy’s picture

ChrisKennedy commented

This looks pretty good. I think two changes would make it a lot more usable:

1. Autocomplete support
2. Remove manual wildcards and just do it automatically in the background (e.g. put % at the beginning/end, and replace spaces with %). Maybe see how Steven's menu scout patch/module does searching and indexing too.

dries’s picture

dries commented

I agree about the wildcard support -- let's do that automatically like we do elsewhere in Drupal.

... Search aliases by keyword ...

I think the 'by keyword' is redundant. Maybe make that 'Search URL aliases'.

I'd rename $search_key to $key.

Another suggestion is that I might vote against a new tab. On all the Drupal sites I administer, the search form would be the primary navigation tool to administer URL aliases. In other words, I'd _always_ go to the search page. Therefore, I wouldn't mind to see the form in a fieldset above the path alias table.

Plus, in my mind, it is not actually a "search" but a "filter". I think people "search" for data, but "filter" a specific list of things. Personally I think most people's mental model will be that of a filter. All other filters in Drupal are shown above the overview tables.

Not sure what the others thing of this, but I'd love to see the filter/search functionality on the main path alias table.

Thoughts?

PS: thanks for taking on this task! Much appreciated.

Gurpartap Singh’s picture

Gurpartap Singh commented
StatusFileSize
new drupal6-feature-path_alias_search_1.patch4.53 KB

New in this patch:

  • Added field autocomplete.
  • Adds wildcard(%) around keywords. Spaces are replaced by the same.
  • Changed instances of "Search" to "Filter", wherever appropiate.
  • Form now lies above the URL aliases overview, as a non-collapsible fieldset(defaults).
  • Moved validation check to hook_validate() implementation.

More which can be done:

  • Replace _ by \_. i.e. add escape character to the single character wildcard(_). Because user might be searching for aliases with underscore in them, but when it acts as wildcard, it might present unwanted items in list. Should this be done?
  • Make the overview listing a form with checkboxes.
  • Allow bulk operations(e.g. delete, what else..?) on selected aliases.
  • Even add editing interface, i.e. show textfields with values (instead of just text), and allow editing/saving(in bulk). This could be bit complicated as a system path can have multiple aliases. Or use jQuery and save instantly?
  • But these last two should go into a separate patch?
chx’s picture

chx commented

Improve path alias administration. On a site with hundreds or thousands of path aliases, it becomes impossible to find the path alias that you want to edit.

That's right...

Add a search form to the path alias administration screen.

... but this is not. I had a solution which would have let you reuse every existing navigation method including search. I can't even fathom a valid use case for path alias searches. But, feel free to disregard me, I have other stuff to do, this is just my view on this, and I won't comment on this or any other path issue in this release cycle.

heine’s picture

heine commented

I beg to differ.

One is trying to filter url aliases, not get as many results as possible. Autowildcarding beginning and end conflicts with such a goal. One can make a case for auto wildcarding the end, but I'd rather not have to manage 10 million aliases (I'm exaggerating) where each and every search is on %keyword%.

Also http://head.localhost/?q= + autocomplete wildcarding is excellent. However, when one is looking for http://head.localhost/?q=test one doesn't expect a search on http://head.localhost/?q=%test.

$key = '%'. implode('%', explode(' ', $key)) .'%';

http://www.php.net/str_replace ?

if ($form_values['filter'] == '') {

It would be better if the user could empty the textfield and click filter again, thereby returning to the full overview.

I believe one should be able to filter on the system path (eg node/1 ) as well.

Note that I think this patch doesn't exclude any additional, per page, interface.

Gurpartap Singh’s picture

Gurpartap Singh commented
StatusFileSize
new drupal6-feature-path_alias_search_2.patch4.43 KB

If the wildcard is not fixed to ends, it would try to search only for the exact url alias. Maybe the list should be sorted by most matching aliases.

And spaces now remain intact. * can be used as a wildcard(should add help text) in the field e.g. about*company can result about-our-company, aboutcompany,, etc. It is similar to user_search(): $keys = preg_replace('!\*+!', '%', $keys);

dries’s picture

dries commented

I'd stick with the auto-wildcards for now. I would, however, remove the 'http://'-prefix text. It's confusing because it makes you believe you are looking for an exact match. (If we drop the wildcards, then the prefix makes sense. If we want wildcards, drop the prefix-text.)

Elsewhere in the code we use strtr to translate certain characters. Not sure, but it might be faster. I think it would be slightly more consistent.

The text 'Filter by keywords' doesn't mean much. Maybe change that to 'Filter by alias' (because technically, you could also filter by the source path).

I think this patch is almost ready! Good job. :)

Gurpartap Singh’s picture

Gurpartap Singh commented
StatusFileSize
new drupal6-feature-path_alias_search_3.patch5.52 KB

We have wildcard at starting and at end, but spaces are not replaced by wildcards, rather user has the option to use * wildcard anywhere in between the keywords. And the prefix url was removed.

path.module no where uses strtr or any other way to translate strings except urldecode when saving the alias. And don't think we need to use urldecode here because user is expected to enter a decoded keyword(i.e. / and not %2F) and hence it makes no difference when searching.

Changed the fieldset title to "Filter aliases". and added "The aliases can be filtered by keywords. Use '*' as a wildcard." after the help text shown above the overview page.

Further after this patch, would like to take up with some of the implementation which chx proposed in his patch. Like the active alias and single form editing for all aliases per system url. Have talked to chx and he's good with it :). Also considering to make the overview page have text fields with update/save button. But this all would go into another issue after this one has been committed.

Stefan Nagtegaal’s picture

Stefan Nagtegaal commented

It would be nicer if the autocomplete feature returns two lines for each $match it found, first line would be the alias and the second - right underneath - daisplays the node title.

What is a 'wildcard'? ;-)

dries’s picture

dries commented
Status: Needs review » Fixed

I committed a modified version of this patch. Thanks! :)

chx’s picture

chx commented
Status: Fixed » Active

And there we are , a pointless form to a pointless admin screen committed without any debate. Anyone read my comment? Anyone pointed out a use case when you remember a part of a path -- which does not pertain to another search? The usual case is that aliases are generated from node titles and user names. Now, you can search in something which usually comes from a mungled version of both.

/me waves with his hands frantically trying to get attention.

chx’s picture

chx commented

To elaborate more: this admin screen is pointless because there is still no meaningful mass operation that's doable by hand if you have a couple hundred thousand aliases.

And, what if your aliases are not generated? Hm, then how you ended up with so many that they need filtering??

chx’s picture

chx commented
Status: Active » Fixed

Ah well. This is a waste of my time. I will not use the still useless path alias screen and roll my interface as a contrib. Not a biggie. Move on.

Gurpartap Singh’s picture

Gurpartap Singh commented
Status: Fixed » Needs work

From the changes Dries made to the patch, one thing was missed. If the user puts slashes in filter field(which is probably a big chance with path filtering), it would only pick up the first part before the first slash. And there already lied function to fetch them all. So here's a patch using it. Also, removed the fieldset from the filter form. Now it's more like other filter forms, like on watchdog, etc. Or do you want to make the watchdog form have fieldset too? :P

Gurpartap Singh’s picture

Gurpartap Singh commented
Status: Needs work » Needs review
StatusFileSize
new drupal6-feature-path_alias_search_4.patch2.76 KB

Also, return 'path/to/somewhere'; was not working for some reason, so anyhow, it's changed to return drupal_goto(....); in this patch. Also, path_admin_filter_get_keys() has argument for the key position, because it'll be used for another upcoming patch to path module.

Gurpartap Singh’s picture

Gurpartap Singh commented
StatusFileSize
new drupal6-feature-path_alias_search_5.patch2.52 KB

Removed path_admin_filter_get_keys(), as all the arguments passed can be imploded and used, resulting the same. Thanks chx!

Gurpartap Singh’s picture

Gurpartap Singh commented

Have got more for path.module, but this patch is lagging them for now... (It's to have active alias; single screen to edit aliases for a system path per language, etc.).

Gurpartap Singh’s picture

Gurpartap Singh commented
Status: Needs review » Fixed

ok the active alias patch at http://drupal.org/node/147143 includes these changes. So marking back to fixed.

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)