All urls constructed for XMLHttpRequest use are derived from core WordPress functions that provide the scheme in use as it knows it. If this is not happening then something is missing in the WP configuration.

The only things we know of that may not automatically covert over to https when the website does is firstly any urls embedded in old posts when the site was http. And – calls to gravatar.com – the latter of which is currently under investigation for changing as appropriate.

As to trawling through your records and changing old urls then you really have two options. Assuming we are simply talking about forum topic/post content here then it would be possible to create a simple Wp style filter that would change each http top https prior to display. This is simple to do, has a small performance hot of course and does not actually change any data.

The only sensible alternative would be to export your forum post data to a SQL dump file. Use a decent text editor to perform a search and replace and then import it back into the database. That makes a permanent change nut you just have to ensure your forum is in maintenance mode for the duration. This kind of operation could be done in under 5 minutes if you are all prepared and ready to go.

Hi,

I can’t see what could be wrong, wordpress is currently setup to https so I’m not sure why it’s not working… could you clarify what needs to be set in order to make https work?

I thought of the SQL method but was hoping there was an easier and faster way.

Cheers

as to admin, we basically, we get the schema (http or https) from wp…  we use their functions…

I assume you do:  https://codex.wordpress.org/Administration_Over_SSL

and set the wp config options as wp details?

if this is front end, on wp – settings – general, are the blog and wp urls defined with https in them?  and then if on forum – integration – page and permalink, does the forum url have https in it? 

I dont know of any way to change urls that exist in the db from http to https short of changing via mysql db queries…

Hi Mr Papa,

Yes, WP-Config has the appropriate details and so does WordPress via the SQL/General section of WordPress.

The problems still exist, I’ve even got my host to try and do the forcing https via apache init.d scripts and the same exact problem exists.

I’ve just tried on a 100% updated version of wordpress & plugins and the same thing again 🙁

Would it be possible for one of you guys to take a look? either via Teamviewer (or similar program, would help me see the problem too!) or I can give FTP and WordPress access.

Cheers

several things are confusing here… its been about 3 months since I last ran through a complete ssl test (got new computer and now dont have ssl configured again) but all worked… unfortunately, its always been a royal pain to get working locally… but perhaps a task for this weekend…

and we have many users using ssl not reporting any issue… 

not saying you arent having a problem or something might not be afoot, but kind of hard to pinpoint when affecting single user…

is the only thing not working the auto update stuff?  leave aside urls in post content – we cannot really do much about that – nor should we attempt to alter a user’s content…  but want to make sure the only thing you see a problem with ssl is the auto update – allows us to focus a bit more narrowly…

and btw, FF 28 is ancient so this wouldnt be something new and just cropping up…

ah, thinking a bit more about auto update…  did this site use to be non https before?  if so, that might explain it…

the auto update ajax (XMLHttpRequest) urls are stored in the database… so if you were running non https before, they might still have simple http urls instead of https…

can you look in your database?  look at the sfmeta table…  for any row with a meta type of autoupdate… are the ajax update ulrs (in the meta value column) there using http?  if so, should be able to update the db and getting it  working…  be careful, those are serialized arrays so you cannot just change the string, you also have to change the string length… if you dont know how to do that, post the values here and we can help…

would  also explain why my ssl tests wouldnt find it.. would have been ssl since day one – not changed…

Hi Papa,

Yes previously it was running http not https, and you’re right in the sfmeta table under the meta_type of “autoupdate” the value is:

a:2:{i:0;s:13:"spjUserUpdate";i:1;s:58:"http://www.website.com/index.php?sp_ahah=autoupdate";}

It’s found in 4 different autoupdate variabless, do I only need to change these 4 or are there more in other tables?

EDIT: 
Here are the exact strings: (changed website name, but it’s still same amount of characters)

a:2:{i:0;s:16:”spjwatchesupdate”;i:1;s:81:”http://www.abcdefabcdefab.com/index.php?sp_ahah=watches-manage&target=watches”;}

a:2:{i:0;s:13:”spjsubsupdate”;i:1;s:75:”http://www.abcdefabcdefab.com/index.php?sp_ahah=subs-manage&target=subs”;}

a:2:{i:0;s:11:”spjpmupdate”;i:1;s:74:”http://www.abcdefabcdefab.com/index.php?sp_ahah=pm-manage&target=inbox”;}

a:2:{i:0;s:13:”spjUserUpdate”;i:1;s:58:”http://www.abcdefabcdefab.com/index.php?sp_ahah=autoupdate”;}

I’d appreciate some help (not sure what you mean with serialized) :S

Why is the forum software stripping out my code tags… it looks right then I press submit/save and it removes it!

To get things corrected as far as AutoUpdate goes then you could edit these database entries directly if you feel able. The problem is that these are held in what php calls a serialised array. So there are two edits to be made for each one in the sfmeta table.

If you look at that row entry above, just before the url there is the number 58. This has to be set to the number of characters in the following text string. I know you have replaced the real url here because the text in your post is only 50 characters long You will find the real one in your database is 58.

So – quite simply – if you change that to https then you will need to change that value to 59. Failure to do so will cause errors. This is why complex edits on serialised array data is fraught with danger. But this one is not complex.

So yes – you only change those 4 sfmeta entries.

As to the other 4 then it really depends on where they are. As Steve pointed out above, if they are in the post content then should they be changed? It is really up to you.

Meanwhile we will have a conversation here about this as we do need to try and avoid this happening (the sfmeta table) in the future of course.

Yellow Swordfish said
To get things corrected as far as AutoUpdate goes then you could edit these database entries directly if you feel able. The problem is that these are held in what php calls a serialised array. So there are two edits to be made for each one in the sfmeta table.

If you look at that row entry above, just before the url there is the number 58. This has to be set to the number of characters in the following text string. I know you have replaced the real url here because the text in your post is only 50 characters long You will find the real one in your database is 58.

So – quite simply – if you change that to https then you will need to change that value to 59. Failure to do so will cause errors. This is why complex edits on serialised array data is fraught with danger. But this one is not complex.

So yes – you only change those 4 sfmeta entries.

As to the other 4 then it really depends on where they are. As Steve pointed out above, if they are in the post content then should they be changed? It is really up to you.

Meanwhile we will have a conversation here about this as we do need to try and avoid this happening (the sfmeta table) in the future of course.

Hi,

Ok, I’ve solved that issue and the auto-update is working now 😀

Now for the second problem where I can’t link any external images, the actual sql source of the post with the image shows a correct:

<img alt=”” src=”http://www.somewebsite.com/wp-content/uploads/picture.jpg” width=”250″ height=”400″ />

If I disable https on my site then the link works, now if I switch https on… it shows:

 because it’s somehow trying to load it as https (the site in question doesn’t have ssl certificate)

If I inspect element it shows:
<img src=”//www.somewebsite.com/wp-content/uploads/picture.jpg” width=”250″ class=”sfimagebaseline” alt=””>

It’s turning them into cdn style links… // before the www???

I will double check and talk to colleagues but we do not make any such changes to the urls of external links and images. Are you sure you do not have anything else installed – any other WP plugin – that might be making these changes? Anything to do with the way in which you went https for example? Don’t forget we are talking about any plugin that might try and change text on WP post/page content,

Yellow Swordfish said
I will double check and talk to colleagues but we do not make any such changes to the urls of external links and images. Are you sure you do not have anything else installed – any other WP plugin – that might be making these changes? Anything to do with the way in which you went https for example? Don’t forget we are talking about any plugin that might try and change text on WP post/page content,

I found the problem, thanks to your advice 😛

It was my “CloudFlare” plugin, it had a rewrite rule converting everything to https, some things incorrectly some things correctly -_-

That’s frustrating! Glad you got to the bottom of it..

back to your code tags… proper way is to paste the code into content, select (highlight) the code, then use the code button to mark as code (it looks like a piece of paper with {} on it)…

thanks for confirming you switched to https in mid stream…  think I have an idea on how to handle such a change…

Mr Papa said
back to your code tags… proper way is to paste the code into content, highlight the code, then use the code button to mark as code (it looks like a piece of paper with {} on it)…

thanks for confirming you switched to https in mid stream…  think I have an idea on how to handle such a change…

That’s exactly how I was doing the code tags, try and edit my post and put the code tags around it… they vanish every time.

Ike said
That’s frustrating! Glad you got to the bottom of it..

 Yeah it was, thankfully it wasn’t something majorly wrong just a few variables wrong due to switching mid-way and silly CloudFlare plugin ruining the other part 🙂