I've had a reply from CC with a couple of screenshots. The cases of 'http' in the js files don't generate any issues, it is probably from your various updates to your site, reusing old code without realizing that it may include some 'http'.

I had actually come to the same conclusion myself, about the js files. I checked the buiding blocks I have on my sharing site, and they don't have any security issues. They have been built with various versions of RSD, RFF, RBB and SD as they have been launched.

Thank you Inger, That was it. Problem resolved. At first I went to the spot and missed the code because had to scroll to the rt to see it and I did not do that, then proceeded to look all over the place for it to no avail as in a couple of hours. Went back to logically following road map and found it then. Changed 3 to https then the problem was still there and was very disappointed. Went back and discovered had missed one the 4th one and changing that and the 12 pgs started registering secure. It is shaming as to how long this problem had existed. Now to start adding markup feedback says my site has absolutely no structured data markup. Guess i will now learn about that.

Maybe you need to go back to http instead of https where the structuring is concerned? Maybe Frank's guess was right about not changing those?

It was telling me had no markup structure before changing any of the http's. Perhaps the security problem was blocking the markup or blocking the browsers reading it. Anyway am not going to sacrifice security for markup will have both eventually. Will be adding it with the html editor was recommended for that purpose. I have not done a scan since fixing the security problem.

There seems to be a definitive answer at the last item here regarding the use of http://... or https://... for schema.org.

Frank

Thanks, Frank! I was also looking for something like that yesterday, without finding it. Looked in the wrong place, obviously...

The last ones that I switched that were connected to the background gradient image on 12 pgs. brought all 12 of the pages from being unsecured with error reports to being fully secure with no errors. Up until then I switched around 20 http's to https's. Later that night after fixing the 12 pgs the site went offline and was not seen on servers and I was under the impression that it was totally broken. I could go online to it with CC direct ftp, but could not open any pgs on any browsers. i ran security software and started trouble shooting. Then this morning the next day it was back online, magic just started working again. Leads me to believe that perhaps the CC server provider had troubles. I recently lost my homepaintersofjaxfla.com domain and have had to delete some properties and views. was lots of canononicles and now with the one domain not so many. Perhaps the going off line yesterday was to do with the google indexing. Then there is the possibility that I was hacked by an email yesterday from a disgruntled hacker that I had reported. Sometimes one does not exactly know what is going on or why things happen.

If you are using S-drive, it was off-line in the night to yesterday ('night' as in European time) because of some maintenance. I experienced it too, and asked about it.

Thank you for telling me this Inger has restored some of the confidence in my website maintaining abilities. Sometimes actually knowing what has happened makes a world of difference.

I have just crawled the off-line copy of my website using TextCrawler for http:// entries, and find the following are generated by SD4 itself:

schema.org entries
jquery.js and jquery.slim.js several entries
picturefill.js and picturefill.min.js several entries

I would be interested to know whether such entries really do affect the security of a website. I have looked at various online security tests for my website ( https://www.clparker.com ) and haven't found yet any that mention the above http:// entries as a security problem.

Frank