hedera

Sorry, I’d forgotten this was still open. It turned out that the appearance of the https://www.youradexchange.com/ad/display.php?r=32796 was because my Chrome browser was infected with Superfish adware. I didn’t write down the removal process but I found it easily enough by Googling “Superfish”. D’oh.

In my accidentally published post, which I set to Private so no one would see it till I was done, the Status line in the Meta box is not editable. It says “Privately published” with no dropdown. I then changed status to “public” – which made the Status line editable. I’m now back in Draft mode and the “Save Draft” button is there. Knocking head against wall. Thank you.

You’re quite right, it isn’t a bug – as so often, it’s user error. I simply didn’t realize that, once I’d actually published a post (even if I didn’t mean to), the “Save Draft” would go away… I don’t suppose there’s any way to “unpublish” something? Although so far I can work on it in “private” mode, so no one can see it till I’m done. If I had a brain, I’d be dangerous.

I beg to differ with you.

I have exactly 7 plugins installed and active normally: Akismet, HTML Import 2 (no longer needed), NextGEN Gallery by Photocrati, TinyMCE Advanced, TwentyTen: No Max Editor Width (probably not needed if I can stay with the Photocrati theme I was using), WP Social Bookmarking Light, and WPtouch Mobile Plugin. I deactivated one at a time with the Photocrati theme I was using in place, to no effect. I then changed my theme to TwentyFifteen and deactivated ALL the plugins at once. I still have only 2 buttons in my post edit session: Update (which was Publish before I accidentally hit it) and Preview. I still can’t save a draft.

You may prefer building posts in Notepad, but I don’t. I’ve been blogging directly in WordPress since 2006 and never had this trouble with the editor. I call it a bug.

This turned out to be a Superfish infestation in my Chrome browser; I got rid of it with help from the Malwarebytes forum. Not a WordPress issue at all.

The adware link only appeared on the site pages – all the site pages – when your plugin was active. Deactivating the plugin made the adware link go away from all pages. When the plugin was active, logging into the administrative panel caused new windows to pop up with adware in them, some of it flagged as malware, as I said. Deactivating the plugin made them stop.

If something only happens when plugin A is installed and active, and deactivating plugin A makes it go away, I say plugin A is the cause.

OK, I thought it might be associated with FAQ-You but I couldn’t be sure. I’ll talk to my colleagues about a replacement; we have a lot of FAQs, unfortunately. Can you recommend an alternative?

You can see this for yourself. The test home page is https://lifering.org/sitetest. The results I describe should work on any public site page to a non-logged in user, which is what I’m concerned about.

In Chrome the address bar shows a nice green padlock, just like the one on my Bank of America online banking page.

In FireFox it has a gray padlock, and a little gray shield, which if you click on says, Firefox has blocked content that isn’t secure.

I see this when not logged in in either browser.

When I log in to the admin interface, the Chrome display doesn’t change. The shield goes away in Firefox when I display the dashboard but the padlock remains gray. It stays when I’m logged in, as long as I’m on a public page.

I’ve found and eliminated the Superfish link – it was in one of my Chrome extensions. But I cannot find where that a.vimeocdn.com link is being called (see my last post), and I’ve actually used Windows Grep to search all 3 of the wp-* directories for the string, in both .php, .css, and .js files. I think it’s part of WordPress’ video handling tools. Anyone ever dealt with this?

I did try that, actually; but as I said, we have a working plugin (Restrict Content Pro) which kept us from opening any of the admin pages under HTTPS, even though we could log in that way. Oddly enough, the plugin doesn’t interfere when I have the entire site set to load HTTPS, and that’s probably the way we’ll go.

I have a green padlock on every page in Chrome, but FireFox still shows the “blocking content” shield. I have FireBug installed, and its console shows no “blocked content” errors, but it still shows the message.

I ran VelvetBlue and still had an orange triangle, so I looked in the F12 error list and had 5 errors, 3 of which were local widgets displaying images. I recreated them in an https environment and the padlock turned green, even though the console still shows two “non-https” links:

https://a.vimeocdn.com/js/froogaloop2.min.js?25f83-1376905454

https://www.superfish.com/ws/sf_main.jsp?dlsource=qomciru&userId=uTe6OtZMGYb8goIvyBsCZR&CTID=SF

I have no idea where these are or how to fix them, but I suspect I’ll have to if I want people to use FireFox ??

And you’re quite right about 123FlashChat. I have instructions from them on how to run the chat room under https. That’s next, then I’ll tackle vimeocdn.com and superfish.com. I really appreciate the help you’ve given me – thank you!

One question about the VelvetBlue plugin. What version of WordPress do you run it with? We are up to date at WordPress 3.9.2, but when I look at the VelvetBlue plugin, it says it’s only compatible up to WP 3.8.3. Are you running it with WP 3.9.2?

Thanks for the suggestions, I’ll look into the VelvetBlue plugin. And I have access to a duplicate test copy of my site. I was coming to the same conclusion about the WordPress HTTPS plugin. I still really don’t want to have to go through all 100 pages one at a time…

My testing has revealed, though, that my .htaccess file will have to have a conditional statement in it to exclude one whole page. We run a heavily used chat room (hosted by 123FlashChat for us); when the chat room page is https, the flash app doesn’t even try to load. We’ll probably have to go to the vendor and see if we can get new code for it; but I’m pretty sure we’ll have to exclude it from a general system https. Sigh. I just learned this yesterday and have yet to research how to do this.

Actually, the problem wasn’t W3TC. It was another plugin, Restrict Content Pro, which takes over the login process and redirects it in its own format.

I’m now working on a different effort, to secure the entire site with HTTPS; and I find that just changing the siteurl and home fields to use HTTPS instead of HTTP does MOST of it. I’m still trying to work out the stuff not covered by “MOST of it.”

I’ll see when I can fit this in, but deactivating ALL the plugins (we have 29 active) has a major impact on our production site and I have at this point no identical backup site to try this on. I’m trying to build one and will test this there when I get it up. I may try deactivating just W3TC and see if that works; I’m not totally convinced we need it anyhow.