Questions and suggestions

hey GermanKiwi

Thank you so much for taking the time to check out my plugin and for the great feedback and questions, I really appreciate it.

I’ve really tried to build something that makes using icon fonts easy, and I’m not a fan of the shortcode myself – unless its the last resort, but for something like this I think its absolutely necessary to see them in the editor.

With regards to your questions, I absolutely plan to stay up to date with Font Awesome and the other icon font families I’ll include over time, but as you pointed out, it will take a little time when these come out. With regards to the plugins page, I will absolutely add a settings link to the plugins page to make it easier to find. On the last point though I’m not sure I agree 100%, I think if there is mor request for this I can move it, but WordPress’ default function for adding a plugin menu specifically adds it to the plugins drop down, I’m not absolutely set on this, but will give it some thought and do some more reading around ‘best practices etc’.

Thanks again, I hope you enjoy using the plugin. and if you’d be so kind as to leave a rating I’ll be forever grateful.

Warmest Regards

Paul

Hi Paul, thanks for your quick reply! I’m looking forward to seeing how this plugin will develop in the future.

Regarding the options page, I’m almost 100% sure that the default location for this is underneath the Settings menu. ?? That is where almost every other plugin puts its own options page, with the exception of a few plugins that put their options page at the top level (eg. for a custom post type).

I also did a bit of quick searching and learned that a plugin’s options page should be generated by using the “add_options_page” function, and according to https://codex.www.ads-software.com/Function_Reference/add_options_page this function places it underneath the Settings menu.

Additionally I found https://ottopress.com/2009/wordpress-settings-api-tutorial/ which is a tutorial about the WordPress Settings API – and this tutorial shows the same function (add_options_page) which creates the options page underneath the Settings menu.

The same function is also mentioned in the example code at https://codex.www.ads-software.com/Creating_Options_Pages.

I’m not a plugin coder myself but I hope these links will be helpful to figure this out! ??

Cheers!

Hey GermanKiwi

thanks for that, I have seen those, where there is some conflicting information for me around best practices is the following

https://codex.www.ads-software.com/Function_Reference/add_plugins_page

My current choices about where to put this comes from :

1. there is a function specifically for plugin options pages
2. Menu’s under settings should (will) only be available to administrators, where I feel this is more of a content issue and should be accessible to a manager, who may often not be the admin (reserved for devs in many instances).

I’ll continue reading about it and see what the community at large say is best practice.

thanks for all the input, and I’m excited about where this plugin goes as well ??

My understanding is that the “add_plugins_page” you mention above, is simply describing how to use that function – it’s not saying that it’s the recommended or “best practice” place to put the options page. But the other pages I mentioned which describe the “add_options_page” function, *do* seem to be saying that that function is the recommended best-practice.

I’ve also found https://github.com/tommcfarlin/WordPress-Plugin-Boilerplate/issues/60 which states the same thing.

Regarding your 2nd point about the settings only being available to administrators – I think this is a good thing! ?? In fact none of the settings pages of my other plugins can be accessed by non-administrators – that’s very normal and definitely desired. Only the admin should be able to access plugin settings. I believe this is also a best-practice, which is why WordPress does not let non-admins view the Settings page or its sub-pages.

For myself, I would not want non-admins being able to change the font settings of your plugin. The chosen font family is a design issue, closely related to the theme. Only the developer (myself, the admin) should be able to change the font family that is used on my website. I use Font Awesome fonts all over my website, in buttons and navigation and links to Facebook etc. If a non-admin were to change the font family to Genericons, it would be a disaster for me – significant parts of my website would break or look weird! Only the developer should be able to change this.

The Editors (who are responsible for content) do need to be able to insert fonts into the body of a post or page, but they can do that already via the Visual Editor, thanks to your nice new menu there. They don’t need to access the plugin settings page at all.

That’s why I think it’s correct for the plugin options page to be located under Settings and only be accessible to the admin, just like 99% of other plugin options pages already are. ??

Anyway, that’s my opinion about it, and I hope you’re able to find some good info when you continue reading. Maybe you can ask the WP core devs for their guidelines?

Cheers!

BTW, I have another (unrelated) question for you:

I noticed in the “wpvi-fa4.css” file which your plugin uses, that there is an extra entry in there which does not appear in the original CSS file from the Font Awesome project. As follows:

i.fa[class*="fa-"] {
    width:1em;
    height:1em;
    text-align:center;
}

I was just curious what this does and why you’ve included it?

Best practice recommendations are that plugin option pages should be placed in the Settings menu of the admin area. If some users wish editors to be able to access the options page, then they should be able to do this by using a role management plugin – such as https://www.ads-software.com/extend/plugins/user-role-editor/

this is just a little helper css class that assists in evening out the display of the icons giving them uniform proportion in relationship to the font size, and avoiding some little display gremlins I found when initially setting this up. This shouldn’t negatively impact your experience of using font awesome compared to outside WP at all.

thanks esmi,

is there a codex link or some documentation expressing that which you’re referencing, I’d greatly appreciate the link.

Cheers ??

Paul

From what I recall, this came up in a discussion a while back but I can’t locate it now. The closest I could find is https://codex.www.ads-software.com/Adding_Administration_Menus

Thanks for the explanation! I’ve just taken a closer look at what your helper class actually does, and played around with turning it off and on to see how it affects my own site. Unfortunately it has a negative effect on the design of my site. What I can see is that it turns the Font Awesome (“FA”) font characters into fixed-width characters (like the Courier font) – rather than the proportional-width characters they’re supposed to be (like Arial, Times Roman etc). This means that when I have a FA font followed by some text, if the FA character is narrow there will be a much larger gap between the FA character and the following text – which looks unsightly to me.

In my case I have three widgets in my site’s footer area, each with its own H4 title. To the left of each title is an FA font character symbolising the title. I’ve given the FA character a padding of 20px to separate it from the title text following it, and I want there to be only 20px between the FA character and the text – nothing more – so that they all look the same as each other. But with your helper class, this adds additional space between the narrower FA characters and the following text, and it doesn’t look good. (I hope my description makes sense!)

Likewise with the ‘height’ element you’re using – this changes the height of some of my rows, which I don’t want.

My view is that there is a reason this kind of class is not included in the official Font Awesome CSS file – the designers clearly haven’t intended it to be used that way. They intend it to be used as a proportional-width font. So I would much prefer if this helper class could be left out. I think that if a developer wants to make the fonts fixed-width (and fixed-height and centered), then he can easily add his own custom CSS to his own theme’s CSS file – that would be a more appropriate solution than having this forced on all of us. ??

Another reason to stick with the official FA CSS file is that it makes things a lot easier for when developers switch to your plugin from some other FA plugin (or maybe they were using the BootstrapCDN solution from https://fontawesome.io/get-started/ but they want to switch to your plugin) – it is best then if their migration is seamless due to not being any chances to the CSS they are already used to, and have already designed their site around.

I know it’s just a small thing, but now I’ve had the chance to see how it changes the layout of my icons, I’m really not keen to see it there. I think as a matter of principle, design “overrides” like this should be left to each individual designer to make on their own individual sites.

??

please add separate forum topics for different concerns, I’ll look at this as I continue to develop this plugin.

Yeah you’re right, I should really have posted this as a separate topic – sorry about that. Thanks for considering it!