Past issues: #951160: add the dopl module?
Related project:

Currently it is possible to link to project issues using the #951160: add the dopl module? format. Many support answers include linking to Drupal projects and documentation pages, which is tedious to type out every time.

Since dopl already exists, do we use its functionality at first, and then try to expand to other node types through the issue queue? Or another project entirely?


  • Decide functionality for initial launch
  • Choose module or develop functionality
    • Code review
    • Tests


realityloop’s picture

Requested co-maintainership:

Also updated code on support site to enable linking to node/[nid] on d.o as well.
example (would link to this node):

davidhernandez’s picture

Cool. Long term we'd like to be able to pull the node title and use that in the link text. Will this be feasible?

realityloop’s picture

Request was granted.. will look into title for node links

realityloop’s picture

Status: Active » Needs review

Live now in dopl
-Module list, moved to Input filters
-Added support for linking to nodes by node id (880940.node), also supports direct linking to comments (880940#comment-4329472.node)

davidhernandez’s picture

Looking over the code now. This will do NNNNN.node, NNNNN#comment-NNNNN.node, views.module, garland.theme, spanish.translation, etc? And for issues [#NNNNN]? Issues are handle by the other filter though, correct? Does everything require [#]?

realityloop’s picture

Issues are just node id's, this will handle them too, just implemented differently I guess. This allows you to link directly to a comment which I doubt any other filter does.

realityloop’s picture

Did some updates today.. change from using .node to .do and .gdo to link to groups

davidhernandez’s picture

Status: Needs review » Reviewed & tested by the community

I did some limited testing. Seems to work fine.

‎dopl.project -> project link filter‎
‎fusion.theme -> Fusion‎
‎ar.translation -> Arabic Translation‎
‎hyperlocalnews.installprofile -> Hyperlocal News‎
‎ -> Print view not using custom css or module css‎
‎140949.gdo -> Building Drupal projects on Git‎
‎ -> Filter to make linking to nodes faster/easier‎
‎ -> view/revert/delete revisions per content type‎ project link filter
Arabic Translation
Hyperlocal News
Print view not using custom css or module css
Building Drupal projects on Git
Filter to make linking to nodes faster/easier
view/revert/delete revisions per content type

Since theme is separated as {name}.theme, should modules be separated too? .project currently works for themes and modules, so maybe just get rid of .theme?

I think the only other thing missing is .user. Brian and I discussed this briefly, and we agree it would be difficult because of spaces in user names. I don't think we can expect anyone to know a users id number. I'll mark this issue as reviewed, and create a separate issue for .user, and file it under wish list.

Fidelix’s picture

I know a lot has already been done.
But did you guys take a look at project/freelinking? It's an awesome project, really.

davidhernandez’s picture

I did look at freelinking. It is awesome for some things, but dopl does exactly what we want, so probably no need to look for an alternative. Also, freelinking doesn't (in my limited testing) seem to handle linking to off site content as easily. (We are going to be linking almost exclusively to off site content.) You have to write out the full address. Dopl's format is quick and easy, and designed specifically for content.

I haven't poured over the code, but I'm initial impression is that dopl would perform better for what we want, which is always a major consideration. Even dopl will still need to be more thoroughly tested. A support website could get a huge amount of traffic, so if no link filter performs well the feature will have to be removed.

mradcliffe’s picture

freelinking is the current go to solution for Wiki-like linking. Although, I also agree that dopl makes sense in the context of links.

Fidelix’s picture

freelinking is very good for internal and external linking too.

dopl does not seem as extensible as freelinking, and for d.o links, freelinking does that out of the box, and you can customize the syntax in which the data will be entered.

Anyway, I believe this issue is very important, as it will influence UX and performance, and that a lot of testing should be done. If I can help in some way, let me know.

davidhernandez’s picture

Can you write out the syntax for linking to d.o pages using freelinking, like I did above? I wasn't aware of support specific to d.o pages. Do you write just like you would any external link? When I used freelinking, my understanding of the syntax was [[Node Title]] for internal, or [[]] for external URLs. I just want to make sure we are comparing apples to apples before passing judgement. Also, do you know if it caches the results? That is important for performance. We can't have it searching through node titles every time.

Fidelix’s picture

I will try talking to grayside to get a perspective about caching and other performance concerns in freelinking if we agree it is indeed viable.

But no, the syntax is not the same as you made above.
It can be chosen like:



Of course, if one of those plugins are set as default, no specification is required:
eg. If donid is set as default:

A bit of information about caching can be found here:

Filter code is only processed once every 24 hours, or whenever the cache is cleared for that node.

But I found a bit of text in the README that is confusing me:

* There is no database table in FL3. Previous versions of Freelinking
use a table to keep track of freelinks and their targets.

And then:

* There is no option for nodetitle to failover to search in
the event the user does not have permission to create a new node. Filter caching
prevents FL3 from running such logic for each individual user. Nodetitle may
failover to search, or to createnode in the event that the Freelinking Prepopulate
module is enabled.

How is he caching stuff if not in the database? This needs to be investigated.

I'm sorry if this is being delayed too much. If you feel dopl is extensible enough for future modifications, feel free to move ahead.

davidhernandez’s picture

Caching doesn't require a module to create its own tables. It will use Drupal cache tables.

Dopl is indeed easy for us to modify, and geared specifically for this type of use, as Brian (realityloop) has taken over maintaining the module.

In any case, I don't think we need to be locked in to any solution. I would say, however, that is issue is somewhat low priority. We can revisit it later, when we have a working system up. There shouldn't be any reason why we can't change what we use, if we decide to. We'll just have to decide before we have something live, because syntax might change. (Thought we could probably script a change.)

Fidelix’s picture

Agreed. Then while we have something at hand which currently works, and is future proof, lets stick with it.

Anyway, is there some way I can help with tests or development? I want to help this project happen.