and how do you set the https?  all the proper wp config options set?

by chance was this post you want to edit made pre ssl?  such that its base url was already set up without https?

nvm…. think my question is a red herring…

from the users running full ssl, we have not had either issue reported…  and since we use standard wp functions for getting the schema, seems odd…   so some research will be required… and a built complex since at this time, I dont have an ssl test bed that works anymore…

Hm, I set the https basically by manually navigating to the site (typing https:// … into the url bar) or coming out of the (SSL-secured) admin area like that.

As for the herring, no, optional ssl was already in effect before I installed this plugin. I do suspect if basic wordpress were to be set to enforce SSL for everyone then it’d work just fine, but that is undesirable in this situation.

To be precise: WordPress Address and Site Address are both set to http://, so regular users do not stumble over the self-signed certificate. Everyone who is willing to put up with that (eg, staff) can navigate the site via https and all links (except some forum button links) follow suite.

This does work best if every plugin and theme uses relative links ( /path/to/content) instead of absolute links (http://sitename.net/path/to/content).

well, several problems there…

first, wp determines the schema (http or https) and plugins (such as simple press), use the wp built in functions for determining that…

what is the point of having ssl and non ssl??  if you support ssl, why not force the users to use it? 

anyways, as a plugin for wp, we are just using standard wp stuff…  for example, proper ssl set up:  https://make.wordpress.org/support/user-manual/web-publishing/problem-with-post-edit-buttonttps-for-wordpress/ (note the specific bad practice of supporting http and https)… 

second, relative urls is a bad idea in WordPress as well since they explicitly do not support them and favor absolute urls… see:  https://make.wordpress.org/core/problem-with-post-edit-buttonandbook/design-decisions/#absolute-versus-relative-urls

Mr Papa said

well, several problems there…

first, wp determines the schema (http or https) and plugins (such as simple press), use the wp built in functions for determining that…

what is the point of having ssl and non ssl??  if you support ssl, why not force the users to use it? 

anyways, as a plugin for wp, we are just using standard wp stuff…  for example, proper ssl set up:  https://make.wordpress.org/support/user-manual/web-publishing/problem-with-post-edit-buttonttps-for-wordpress/ (note the specific bad practice of supporting http and https)… 

second, relative urls is a bad idea in WordPress as well since they explicitly do not support them and favor absolute urls… see:  https://make.wordpress.org/core/problem-with-post-edit-buttonandbook/design-decisions/#absolute-versus-relative-urls

1. …because of the reasons I have mentioned before? So staff can use SSL. Everyone else can chose to use it as well, if they want to put up with the self-signed certificate.

2. I do note that they give no reason for this supposed bad practice. >_>

3. Given that link, even WordPress itself seems to favour relative URLs if they were to do a do-over, so that doesn’t seem very convincing at all. (Not to mention the arguments being rather weak.)

Mind you, this is not a big issue, it’s just kinda odd to see these buttons behave differently from everything else.

2  ssl is about security… if you allow non https when https is there, you have no added security…  the guys you trust the most (staff), use ssl..  everyone else uses non unless they want to use ssl?  no security benefit there…  trust me, not trying to tell you your business – just dont understand the use case or concept…

3  understand… like it or not, as part of wp ecosystem, we have to live within its boundaries…  there are certainly things I would like to see different…

when I get an ssl site back up, can try to see if anything that can be learned here…  but its a fringe set up (no offense intended)…