As an extension of field_formatter_settings (And I'm working on more) our client manager loves this one, and we've started using it on our base installs, so I've promoted it to full and would like to list it under the 'supported' modules if you agree.

https://drupal.org/project/field_formatter_filter

Basically it provides a concise way of running a cleanup to ensure 'safe' markup in node teasers - something that's always been a bit of a pain.
Over-thinking it and generalizing it led me to this solution - choose an input filter for longtext as part of the display settings, not leave it up to the editors to manage their input formats...

The thinking behind re-using 'input formats' rather than just a checkbox for 'strip tags' is that *some* markup is safe (links, bold, paragraphs) and some is not, so let's use the UI that core already provides for this.
This approach opened up some interesting new bonuses with text-formatting and view-modes - which I'm now starting work on next ...

Comments

chOP’s picture

chOP CreditAttribution: chOP commented

I note there are currently four issues in the issue queue for the Field Formatter Settings project requesting that a dependent, related or supported module be added or updated on the Module Description page.

  1. #1791756: New module: Image link to preset
  2. #2039113: Add Image Class to list of modules dependent on this
  3. #2073999: New module (Sandbox) : Field Formatter Order
  4. #2239479: Submitted for your approval: field_formatter_filter - new extension module

Surely there is a better way to get this list of dependent, supported or related modules updated than an issue queue request with the parent project.

Is there currently a way that a Module or Project can specify that it is supported by, dependent on, or a child of, another Module or Project?

If so, then that could be used instead to show the dependency or linkage. This would elminiate the need to request updates to the parent project's Description and move the responsibility for maintaining this relationship to the child projects.

dman’s picture

dman CreditAttribution: dman commented

[meta]
Two options, one requires new code built and added to d.o project module, and the other doesn't.

Option 1 introduces the idea of an 'is_extended_by' relation from parent to dependency, and can theoretically be calculated, and has been discussed in other meta-issues.

Option 2 is
- Just update the project page to link to a handbook documentation page like Feeds does where things can be freely wiki-fied. No more effort required.

There is still (I think) a significant advantage in putting these notifications into the project issue queue here, as it really allows the project maintainers and followers to see what's being done in the system, and identify new uses and possible synergy. Having these child projects pop up automatically or in the handbook does *not* alert the top maintainer.
Posting in issues here is as much a "here is what I'm doing with this, do you endorse it?" to the other developers as it is about letting users find it. It's not just a tedious change request, it's also a place for discussion on usage and expansion on ideas - eg #1860624: Merge Field Formatter Order sandbox with Field Multiple Limit became a discussion about a better way to do things with a good outcome.