the way plugins were conceived is odd, IMHO it should be revamped

-- there is no need for using global variable at all
-- plugins shouldn't be required to be include files residing inside freelinking's directory
---- plugins need to be provided and distributed through contributed modules
---- plugins should be implemented as a hook mechanisms
-- requiring plugins to handle a $matches argument resulting from a preg_match is lazy design
-- having a hook might help a future development of a module which brings UI to create/configurate new plugins through admin's backend

Comments

arhak’s picture

arhak commented

also there is a huge difference between handling internal vs external links
probably plugins or hooks should be provided separately for each case

Grayside’s picture

Grayside commented

I definitely agree about a hook. I have a number of ideas for plugins that would not be suitable for a default installation. In fact, some of the existing plugins are strange for many Drupal sites to include.

eafarris’s picture

eafarris commented
Priority: Critical » Normal
Status: Active » Postponed (maintainer needs more info)

There are five or six different issues here. Some I agree with, and some I do not.

Please create separate issues here for each of these ideas, so that their merits may be discussed individually.

And, while ideas are nice, ideas with code are much better.

Grayside’s picture

Grayside commented

Issue #612434: Freelinking 3 Plugins via Hooks bring hooks to Freelinking 3. I am now looking at simplifying some of Freelinking's hook_filter code, and in the process will check on $matches usage.

Grayside’s picture

Grayside commented
Status: Postponed (maintainer needs more info) » Closed (fixed)

Closing in favor of the broader discussion over in #613236: Freelinking 3 - Roadmap.