ahcj

Thank you — I will look forward to it.

Respectfully, I don’t think you understand the context of this problem for production site administrators.

1. The PHP project itself has EOLed 5.3.3, however distros continue to support it with backported security and bug patches of their own.

2. PHP 5.3.3 (with backported security and bug patches) remains the default in CentOS 6.9, which is supported until 2020. More recent versions are not available via their repositories. Hosts would have to upgrade PHP outside of the CentOS packages and assume the maintenance burden from then on.

3. About 50% of sites running PHP as of August 2017 are at versions less than 5.5:
https://w3techs.com/technologies/details/pl-php/5/all
https://w3techs.com/technologies/details/pl-php/all/all

4. Updating PHP is not like simply updating my Web browser. Real-world production hosts like mine are filled with various work by various developers over at least several years. Bumping PHP further than a maintenance release would almost certainly mean unnecessarily breaking things that are hard to find, probably tricky to fix and written by people I’ve never met who are long gone.

I think it might be reasonable to assume that the language features you’ve used that require PHP 5.5+ were not actually necessary for you to develop this plugin.

I hope you will consider making this plugin available to a greater number of real-world users by removing dependency on those language features. If for whatever reason that’s not an option for you, then I don’t think it should be considered a general release version (anything at or above 1.0) until PHP versions 5.5 and higher become much more widely used.

Is there a reason this isn’t the default? Is there some kind of “gotcha” that I need to look out for if I enable this?

One of the selling points I’ve seen for this plugin is sensible out-of-box defaults. But if we’re all (or at least many of us) now doing https everywhere all the time, this setting pretty much defeats the plugin, doesn’t it?

This directly violates the plugin developer guidelines. See #11:

“In general, things like banner or text link advertising should not be anywhere in a plugin, including on its settings screen.”

https://developer.www.ads-software.com/plugins/wordpress-org/detailed-plugin-guidelines/

I’ve seen WordPress heads make an allowance on a plugin’s own settings page (grudgingly), but definitely disallow doing it on the main Dashboard, as you do here.

(For others’ reference: You might not see the Dashboard banner because it appears only once after installation.)

Campbell Hoffman:

“Yes I’m still supporting it – there is a security problem with the plugin. Right now I’m fixing it, and pending review the plugin will be back in the plugin directory.”

This was eight months ago. At the very least those of us using this plugin need to know what’s going on.

What is the security problem? Should we stop using this plugin or be vigilant about a particular kind of exploit? Is anyone really still supporting WordPress Form Manager?

If it’s been abandoned, please say so. If you need funding to continue development, please ask.

I’m not eager to set aside huge amounts of developer time to convert everything we’ve built on top of this plugin to investigate and convert to something else.

I have determined that there are two (and only two) ways I can make this bug happen in Safari/Mavericks or Safari/iOS: Either check “Add workaround for Safari hyphenation bug” or apply this CSS rule to my small-caps text:
-webkit-font-feature-settings: "liga" 0;

Applying the *other* CSS rule to my small-caps text does not produce the bug:
-webkit-font-variant-ligatures: no-common-ligatures;

But does this mean that if I leave the Safari workaround option unchecked, and I want to keep ligatures for the rest of the page, then I am leaving open the possibility that the ligature bug will appear for some people, on certain configurations of Safari?

On the other hand if I’m not seeing a ligature bug anywhere else with the font I’m using, then I really don’t have a need for that workaround to begin with?

I’m not having luck with this, unfortunately:
https://ghoiren.net/2016/01/hello-world/

I suppose I’d be happy to leave that workaround unchecked, but I don’t know what the consequences might be.

Unchecking “Enable hyphenation” had no effect.

However, unchecking “Add workaround for Safari hyphenation bug” *did* eliminate the spacing. I went back and forth a few times to be sure.

(For what it’s worth: I’m accustomed to waiting for months to get a response on other WordPress forums, and would have been happy to wait here. Your active support of this plugin is very much appreciated.)

I’ve added before-and-after screenshots of iOS:
https://ghoiren.net/2016/01/hello-world/

iOS version 8.4.1, with whatever is the current version of Safari.

My Mac is OS X 10.9.5, with Safari 9.0.3.

This happens only when wp-typography is active, doesn’t when it isn’t.

I’ve also cranked up my Mac to test Safari there, and it is the same. So I was incorrect in thinking it was particular to iOS.

Here is an example:
https://ghoiren.net/2016/01/hello-world/

(Noted for the benefit of others…)

In functions.php or wherever is appropriate for you, include:

add_filter('simple_local_avatars_dynamic_resize', false);

With deep respect for the value of this plugin and the work that goes into it, I’d like to suggest that when the alternative is so destructive to previous functionality the default here should have been false.