Theming support

(All listed bullets are about adding CSS classes for theming support)

1- If a freelink is known to be internal (targets the same site, e.g. mysite.com) it should have a class style like flink-internal (the prefix might be "freelink" or "flink" for shorter or even just "link", "wikilink", whatever) while freelinks known to be external (targeting other website) it should have a class style flink-external

2- In addition, another class style with the shortname of the plugin should be also included. For instead, having a plugin targeting drupal.org projects could be themed different to other external links if there is a class style flink-drupal (which would be then class="flink-external flink-drupal" since it will be also an external link)

3- Moreover, supporting styles (like Mediawiki has) for missing/broken links or already existing ones would require to inspect the database to keep track whether internal links are satisfied or not. Style classes would be then like flink-missing vs flink-existing. Then an internal link could be themed in red if its missing/broken. Of course, this doesn't have to be supported directly by freelinking, it just requires the API to be able to be done by another module (see #621180: Building a Robust FL3 API).

There are more use cases, in every case what classes should be added would be other module's work, but the freelinking module should provide proper API to open doors to such implementations.
Maybe the only style class that should be already implemented into freelinking module would be the internal/external link discrimination.

We might then end up having a themed link to wikipedia decorated with that site's logo altogether a language flag, since some plugin might address styling accordingly to wikipedia's language subdomain in use in addition to other styles the link might get.
Also an internal link might be themed taking into account the targeted content type, decorating differently blog entries from project/issues/book pages/etc

Then, even a plugin or another module might be interested in adding CSS class styles to freelinks, but will need to know as much info as possible about what if being targeted:
- internal vs external
- plugin's shortname
- if it is a plugin addressing internal links it might also provide info about the targeted content-type, if it exsits already or not, etc
- if it is a plugin addressing external links it might be interested in providing extra info like target language, or even content-type if it knows what kind of CMS it is addressing.

In 3.x-dev, take a look at freelinking_freelink_alter(). I believe I committed that yesterday. Amongst other things, it makes sure every link has "freelink freelink-pluginname" amongst its CSS classes. This is also a good spot to do some link domain name analysis and add freelink-internal/freelink-external as the case may be.

Because it is merely freelinking's implementation of hook_freelink_alter(), other modules can also modify the links with a little insight into the link array structure. I believe that's a better fit for things like adding the domain name to the link's CSS classes. However, there might be some value in just pointing people to the Urlicon module.

I have recently begun work on the Search plugin and the Freelinking Node Create module. They will have the information necessary to realize if they were conjured by a plugin that failed to find an internal node, I will make a note to have them style their output accordingly.

Today committed theme_freelink() and theme_freelink_error() for further customizability.

Both the theme functions and hook_freelink_alter assume plugins provide a structured return value. If plugins return a string, it is currently passed straight back to the text without further processing. This supports sloppy code, but is intended to help developers new to Freelinking get their feet wet.

Internal/External CSS classes added. Current process analyzes the links generated by the plugins and identifies external domain names.

I cannot see a use case for a plugin to need the knowledge of internal vs. external links for itself, so I imagine this use case to be more for "meta" configurations and interactions. Specific use cases to frame the discussion would be helpful.

Similar to this concept, I had considered the value in adding something like:

In this way, plugin groupings might be configured in "sets". This seems interesting, but I'm not entirely sure if it is worth doing. I've only come up with use cases that simplify the UI and make it trivially easier to style a subset of plugins in a similar fashion.

Marking as Needs Review for purposes of Architectural discussion. All clear action items can be considered fixed.

Added to Freelinking settings: A checkbox to wrap all links in <span> tags with the same CSS classes as the link. This enables advanced CSS styling such as CSS-only insertion of URL icons.

While this was already achievable through theme customization globally, I wanted to enable individual Freelinking modules to supply their own stylesheet and icons without any tinkering necessary in the themes/ folder.

@#5 ++1

Upon further review, I dislike #5. The site administrator should not have to think about the particulars of HTML and styling requirements. I am now researching best practices for better plugin theme overriding.

The problem is overriding the theme function for a specific plugin, without overriding the theming of other plugins.

Right now considering a hook_freelink_theme_override(), but that seems like an awkward theme system hack. Any suggestions are more than welcome.