Support » Plugin: Easy Footnotes » Some proposals for a better flexibility/usability

  • As announced, here some proposals for a better flexibility/usability:

    Optional hrule

    Add on option (e.g. checkbox) to add a <hr /> element before the heading. I think this is not uncommon for footnotes.

    Choice of heading type

    It would be nice if we could choose the heading type (h6, h5, h4, etc.) for the footnotes. For example, I prefer a h6 here, to make it fit with my other “footer” elements (as described in the other thread). This is not crucial since it can be addressed via CSS, too. However it would make things easier for users that don’t want to add custom CSS.

    Heading (label) language issue

    Problem: I have English posts and I have German posts, but I can only set one footnotes heading text for all. I think it is clear that is very ugly to have an English “Footnotes” heading in a German post, or, even worse, the other way round.

    I know, this applies only to the minority of users with a bi/multilingual blog (but when it does apply it is a show-stopper).

    At first I worked around this problem by leaving the “Easy Footnotes Label” field empty and applying a CSS with a language selector, like this:

    .easy-footnote-title h4:lang(de):before {
    	content: "Fußnoten";

    While this seems to work fine, it is a bit too hacky for my taste. So I tried another solution, directly in the plugin code:

    if ($useLabel === true) {
    	$langAttr = apply_filters( language_attributes );
    	if (strpos($langAttr, 'lang="de') !== false) {
    		$efLabel = 'Fußnoten';

    (Please forgive me if this is an amateurish approach, I’m still a WP-php newb). Well, this seems to work equally fine, is less hacky than the CSS solution and could be implemented relatively easily in the plugin (I think):

    • You would add an array with the, let’s say, 15 most common language codes and their assiociated efLabel strings.
    • On the UI side you would add a checkbox “Set label according to page language”. If the option is selected the plugin would execute a language_attributes query (similar to above but with the predefined language keys from the array) and apply the correct label (heading).

    Thoughts on potential caveats:

    • It’s impossible to predefine “all” languages and you don’t have the linguistic knowledge to do so: Just add additional languages (or corrected localizations) on user demand.
    • The user has not set the correct page main language at all (or not correctly through language_attributes): This is a major problem on user-side and can’t be addressed by Easy Footnotes. Anyway, even if the page language isn’t set properly the user won’t suffer any drawbacks either, just the traditional, “monolingual” footnotes heading.

    If you’re bothered about too many check boxes you could even implement this as a completely silent functionality. (I.e. always querying against language_attributes.)

    Why am I making such a lot of proposals?

    Well, your footnotes plugin is definitively the best one I’ve found and it comes pretty close to what I had planned to set up (= hack together) myself. So, of course, I would prefer to see the (few) missing features implemented “natively” in the plugin instead of having to modify it after each update by hand.


Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Author Jason Yingling


    Thanks for all the great feedback! I’ll definitely try to work some of this into coming releases. If you’ve got more suggestions I’d love to hear them.

    Side note: I’m still working on setting up a shortcode to place the notes in a template as well.

    Side note: I’m still working on setting up a shortcode to place the notes in a template as well.

    That’s great news to hear.

    However I have to admit that, since the placement problems with the jetpack elements are solved, I’m currently no longer using my placenotes shortcode. (I’ve also reduced the number of my custom next-post links.)

    But in any case, an optional placenotes will greatly augment the flexibility of EF and make it usable for every kind of page structure.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘Some proposals for a better flexibility/usability’ is closed to new replies.