Unique Links by Page [#621180]

In #613236: Freelinking 3 - Roadmap, I list a few bullet items that were on my mind one day. One appears as so:

5. Plugins may opt-in for distinct links in a page to be added to the node links. (Useful?)

Use Case: Create a block that shows each unique "wanted page" that results from freelinking_nodetitle failing to find a valid node.

In examining this (and implementing part of it in freelinking.module), the node links do not make sense. This is definitely a case for a block.

Assuming this should be part of Freelinking itself, I am looking at caching the array of unique links. This makes sense to me as the links are regenerated as the cache_filter gets reset. Is this a database cheat, or a logical destination for this data?

The idea here is to avoid needing to implement a cron job that checks the markup and then uses further regular expressions to re-extract the links. However, if the real value in a feature like this is to capture all links, then such a scraper would be necessary.

Comments

Comment #1

arhak commented 2 November 2009 at 23:28

IMHO this might perfectly go in another module having the required hook being provided by freelinking

I agree eafarris about leaving freelinking without DB, but hooks should be provided instead for other modules be able to provide such functionalities.

Comment #2

Grayside commented 13 November 2009 at 06:13

Title:	Building a Robust FL3 API	» Unique Links by Page
Issue tags:	-FL3UX

This is a rolling post covering the kinds of end-goals the FL3 API needs to keep in mind. In some cases, it may make more sense for the functionality to be provided by a specialized link indexer.

Unique Links: Listings of links, especially unique "Wanted Pages". Users could always type <a href="add/node/story">, possibly with further arguments. Those would be ignored by a Freelinking Plus type of system.
Cache Clearing: hook_nodeapi() to check the titles/etc of new content. If it matches the wanted pages in the database, those linking nodes are cache-cleared and index-wiped. Predominantly for Freelinking.
Statistics: View showing link count to certain domains/etc. (View eh? Views handling of links?)
Missing/Broken Links: Listings of every link that needs to be repaired around the site. Broken links seem redundant to the Linkchecker module. Missing links (which should be rendered as error messages) do not currently reach freelink_alter, but could be scraped via unique styling (class="freelink-error").
Canonical Origin of Links: Many feature requests relate to the values of the linking node. Supplying a source path or specific values from one may be worthwhile, if some means can be found to uniquely identify links so they may be associated with the database.
User Interface: Override and create Freelinking plugins through a graphical interface. Perhaps using Chaos Tools.

Comment #3

arhak commented 3 November 2009 at 01:29

Issue tags:

+FL3UX

existing pages, wanted, missing/broken, and so on.. might have theming support as well
#621586: Theming support

Comment #4

Grayside commented 5 November 2009 at 22:02

Title:

Unique Links by Page

» Building a Robust FL3 API

One of the key features desired for #314860: i18n: language (locale) not taken into account for finding title depends on the language settings of the linking/source node. Unfortunately, because text from a node has no idea where it comes from, and can be seen in a number of different pages, the language cannot be definitively found.

It is probably beyond the capacity of the FL3 API to provide (and probably the Input Filter system in general), but a grand database-driven Freelinking enhancement module should consider how it might track canonical origin values for individual links.