Usability: Add project issue URL filter

I strongly support this. You see everywhere in the issue queue links to related issues, yes, they are converted to clickable links, but the link with the node number does not say nothing about the status of the other issue. It is very confusing.

Seems that the developers does not have time to use the current format #12345: How do I log in as admin?, so consider improving the URL filter for both, usability and readability of the issue tracking.

Have you tested this patch at all? I haven't, and I wonder if the final output will be right, considering that the text in question will be going through the URL filter and then the project_issue issue nid filter (in that order, I believe). It seems that the <a> tags might get put in twice, and mess up the final output.

Also, I'm not sure that this is really a good idea in the first place. What about sites that use different paths than node/nid#comment-cid, assuming that's possible? In addition, will your regex work with sites that have Drupal installed in a directory called node (this probably isn't likely to happen, but you never know)?

Yes, I was thinking mainly in the drupal.org issue tracking system. Anyway, can get the URL and obtain the normal path of the path it represents ?

I fail to see the usability problem here. What's so hard about just selecting the nid and pasting that? In my browser, I go up to the URL bar, mouse over the nid, double click, and that's it. The issue where this format was added (#89673: GHOP #53: add input filter to convert #12345 into an issue link) was very long and complicated, since it was hard to get even the current behavior working properly (and it's still got some edge cases it doesn't fully handle). I'm not really psyched about trying to alter it much just because some developers haven't figured out how to only select a nid and not a full URL.

Seems that the developers does not have time to use the current format

Uhhh... ? Do you have any evidence to support that claim? I don't have any hard proof myself, but I'd bet $20 the problem is not that they "don't have time", the problem is most people don't know about this since they didn't hear about it when we announced it and never bothered to read the fine print on the "Filtered HTML" input format help text.

I don't have any hard proof myself, but I'd bet $20 the problem is not that they "don't have time", the problem is most people don't know about this since they didn't hear about it when we announced it and never bothered to read the fine print on the "Filtered HTML" input format help text.

I agree that this is probably the reason in most cases.

The one advantage I see for doing something like what's in the patch is that links to other issues that were created/posted before the issue nid link filter existed would then also be converted to show the issue nid, title, and status (on mouse over of the link), and that would be nice.

However, as the mentor to the GHOP student who created this filter in the first place, there were quite a few problems with getting it to work right, and I would hesitate to go messing with something that works well.

If we did this, I do feel that doing it in the drupal.org module would be preferred to doing it in project_issue, but others may disagree. In any case, as dww pointed out this would need to be thoroughly tested by someone locally using the drupal.org installation profile, and then tested on project.drupal.org before being deployed.

<honesty>
I don't think I actually knew that double clicking just the nid in the URL would select just that part of the URL. I usually either copied the whole thing and deleted the rest, or manually selected the nid by click-dragging over it.
</honesty>

I'd love this - I often forget that [#http://drupal.org/node/304808] doesn't work and have to go in and edit my followups, which is annoying (I'd also support that syntax if it's easier than processing just straight urls - saves a click or two compared to selecting or deleting the rest of the URL.

There's an existing issue for the core url filter processing generated URLs, but it's long and ugly.

Compare the workflows:

Proposed:
1. ctrl+l (command+l if you prefer)
2. ctrl+c
3. [# ctrl+v ]

Current:
1. Pick up mouse
2a. Focus it over just the nid and doubleclick (note that this doesn't work in Firefox, which is the most common browser on drupal.org, nor in Opera)
2b. Click, move mouse to beginning of nid, release click
3. ctrl+c
4. [# ctrl+v]

Current for keyboarders:
1. ctrl+l
2. end OR right-arrow
3. shift+ctrl+left-arrow
4. ctrl+c
5. [# ctrl+v ]

In other words...+1 on the concept.

2a. Focus it over just the nid and doubleclick (note that this doesn't work in Firefox, which is the most common browser on drupal.org, nor in Opera)

It works for me in FF2 and FF3 on Windows and Mac.

The problem is most people don't know about this since they didn't hear about it when we announced it and never bothered to read the fine print on the "Filtered HTML" input format help text.

That's true, but I don't think this is the generality. You often see on the queue posts from well known developers where they just paste the full URL, even knowing that the filter exists. So, let's consider an improvement to the current filter or adding a new one to convert regular URLs if they point to project issues.

Proposed:
1. ctrl+l (command+l if you prefer)
2. ctrl+c
3. [# ctrl+v ]

Isn't the proposal that you can just paste the link to an issue and it will convert? I thought that the people mentioning [#http://drupal.org/node/304808] were simply referring to the mistake that's often made... wouldn't filtering the direct link be simpler if possible?

Great idea, by the way!

TEST: http://drupal.org/node/304808
#304808-9: Usability: Add project issue URL filter

@sun: If you wanted to work on a patch for project_issue that supported raw URLs, noticed if they were on the local site, looked up the nid, saw if it was an issue, and if so, converted to the same format as the existing filter, I'd be happy to review and test it, and if it's not terribly insane, commit it. For extra credit, if the link anchor includes a comment number (e.g. http://drupal.org/node/304808#comment-1022088) that should get converted into #304808-5: Usability: Add project issue URL filter (like we do now when you write #304808-5: Usability: Add project issue URL filter to refer to a specific comment within the issue). I'm just concerned that making this really work right is going to be a bit of a nightmare, which is why I'm reluctant to work on it myself. But, if you feel strongly, I promise to work with you to try to get the code in committable shape and deployed...

Looking forward to this! Thanks ahead of time to sun.

+

Here's my initial effort at this. Did not want to use lots of regex.

Moving this to project_issue since it can be re-usable not just on drupal.org.

Thanks for moving this forward!

A) Looks like this is still only allowing [#http://drupal.org/node/304808] style references, not just http://drupal.org/node/304808 -- is that intended?

B) At first glance, this seemed like a bug:

     case 'process':
       $regex = '(?:(?<!\w)\[#\d+(?:-\d+)?(@)?\](?!\w))|<pre>.*?<\/pre>|<code>.*?<\/code>|<a(?:[^>"\']|"[^"]*"|\'[^\']*\')*>.*?<\/a>';
       $text = preg_replace_callback("/$regex/", 'project_issue_link_filter_callback', $text);
+      $text = preg_replace_callback('/(?:(?<!\w)\[#(.*)](?!\w))/', 'project_issue_link_abs_filter_callback', $text);
       return $text;

It'd be helpful to add a code comment here explaining that we're not actually clobbering $text with the 2nd line, we're only touching it if the first one didn't find anything with just [#nid] and we do find something via [#url].

C) There's an awful lot of duplicated code between project_issue_link_abs_filter_callback() and project_issue_link_filter_callback() :( It'd be nicer to refactor those into a shared helper that actually renders the junk once we have a nid and cid, and then each function can just be responsible for processing the text based on the regexp that matched to find the nid (and cid) we're dealing with.

Sub'ing. And, related: #1096318: Make d.o automatic links (e.g. [#12345]) work for all nodes

7.x now?

Would this work for change records, projects, doc page, users?

I think this will not help with api #870074: Add a filter to link to api.drupal.org or g.d.o links.