Support Forum
Hi,
Our website does not have a (pricy) SSL certificate so we just use http. Using https with our own certificate gave user warnings that the reliability was questionable, bla bla security etc.
Now the issue: after updating the forum to the latest version I noticed I couldn't use the 'edit' button, as well as the 'mark all as read' button and probably some more will be broken.
I've found that the POST call in the button's form referred to an HTTPS url. By changing this to HTTP with firebug I was able to get the Edit button working. Had to do the same to the submit button for it to work.
While digging a bit I found that the sp-control.php performs a string replace so that admins always get served with HTTPS in stead of HTTP.
example:
if (is_admin() && force_ssl_admin()) $site = str_replace('http://', "https://", $site);
Can I safely comment this out, or should I look for another solution?
Greetz,
Proph
our forum: http://www.lion-pack.nl/forum
Well, when we were using ssl/problem-with-post-edit-buttonttps we turned it on, but now we have the force ssl option commented out. Like so:
//define('FORCE_SSL_ADMIN', true);
...hhm, maybe not comment it out but turn true into 'false'?
The strange thing is. Now, after another member (also an admin by the way) of the forum has just posted a new reply to a topic, my buttons are working again and don't have the https uri's but regular http again...
This problem had been coming and going in previous updates as well. Every time I would mention my problem, someone else would say theirs was working just fine...and then suddenly so would mine. I found this rather odd because I cleared all browser caches and even removed all cookies.
So broken (https post url) --> other member/admin posts something --> working --> update/random period of time --> broken --> etc....
Probably found the issue and my 'fix' seems to have resolved it.
As I told in the opening post, we used to run SSL/problem-with-post-edit-buttonttps but stopped doing so. I now stumbled upon the option under Integration --> "update forum permalink". This permalink was still referring to https://foo..etc. We apparently forgot to update it when we reverted the switch to ssl. Updating the permalink fixed all the issues for me.
The fault may be on our end, but I don't understand why the user should update a permalink manually. You don't even have to manually fill in the link, an updated url is automatically fetched. Why can't the forum automatically check and update the permalink every so often? For instance every day together with other cron jobs it might do.
It will do it automatically if it can detect it. Depends what actions you took to make your change,. if they were programmatic through the WP UI then I suspect it would have been detected.
what is the point of running something every day that for 99.9% of users 99.9% of the time never changes? Any more that WP performs such checks on the permalink settings.
YELLOW
SWORDFISH
|
The point is, the change was made by disabling a WP plugin that enabled https. This was done through the WP dashboard UI. It seems this change was not detected. I can't remember manually updating the permalink when we enabled https. So it seems it did detect the http->https change, but not the other way round.
I understand the point about not checking something that under normal circumstances doesn't change that often/at all... I'm just trying to think of ways to prevent others from having to trouble-guess like I did, only to come to the conclusion you just had to press a simple button that calls an automated function. I was not actively searching for this option, because I never had to press it back when we enabled ssl. At first I therefore saw no logical connection between the broken forum buttons and disabling https.
Thanks for the time you're putting into this forum software and the support you're giving here.
p.s.: I'm aware we're using a Beta. That's also why I chose to share the problem/solution. Just trying to help improve it or at least document behaviour in less commonly encountered situations.
If I hadn't been so tired or hadn't been so late I would have gone in to more detail. And I don't know how much you know about how WP works.
WP works and communicates with plugins and themes through a system of filters and actions. These essentially act as sort of messaging system. Someone makes a blog post and it fires off 'messages' in the code. Any plugin that needs to know about this event will be listening for the message and can then take action if it needs to.
We come across a lot of plugins that will change the behaviour of core WP but don't bother to fire the message and if the message is not sent then any other plugin that needs to know about it wont hear it.
Having said that, there are some areas where Wp is quite deficient in supplying these filters and actions and, as it happens, changes to permalink structures is one of them. It was only one or two versions ago that the WP team actually built this in to the standard Wp permalink change code.
This process - if everything sticks to the few simple rules - is far superior than wasting cycles checking on a regular basis. But it does rely on sticking to the rules.
YELLOW
SWORDFISH
|
1 Guest(s)