gregscott

I’m missing something. I see the normal list of plugins. When I click “Troubleshoot” on the Health Check plugin, I see this text at the top of the window:

*************
Health Check — Troubleshooting Mode
Your site is currently in Troubleshooting Mode. This has no effect on your site visitors, they will continue to view your site as usual, but for you it will look as if you had just installed WordPress for the first time.

Here you can enable individual plugins or themes, helping you to find out what might be causing strange behaviors on your site. Do note that any changes you make to settings will be kept when you disable Troubleshooting Mode.

Notices
Plugin actions, such as activating and deactivating, are not available while in Troubleshooting Mode.
****************

And then there’s a button that says “Disable Troubleshooting Mode.” And that’s it.

Did I install the wrong plugin? Its full title is “Health Check and Troubleshooting” but the WordPress community. When I view details, I see it’s at version 1.26.

Found the problem. It was a typo in /etc/wordpress/wp-config.php.

/* Disable all file change, as RPM base installation are read-only */
/* define(‘DISALLOW_FILE_MODS’, true); */
define(‘DISALLOW_FILE_MODS’, true);

Should have been:

/* Disable all file change, as RPM base installation are read-only */
/* define(‘DISALLOW_FILE_MODS’, true); */
define(‘DISALLOW_FILE_MODS’, false);

I forgot to change “true” to “false” last night. I always keep the original setting commented out as my own audit trail of changes.

Fedora packages WordPress with “true” because WordPress keeps its content in /usr/share/wordpress but the Linux standard says /usr/share is supposed to be read only. So Fedora sets the config file accordingly out of the box.

– Greg Scott

I cheat with my stuff – I have 2 websites and each has its own virtual machine. If I did this in any kind of bulk, it wouldn’t scale, but I don’t have to solve any problems around shared hosting this way. I wonder how some of the other shared hosting sites do it?

OK, so it’s a modified version of Apache. Modified from what original version? If it’s modified from version 2.4 then try the suggestion from AngelaNorton.

Will your server admin let you look at the file named error_log when you test that captcha? That might also give some clues.

Or… Maybe just try formatting your .htaccess file per AngelaNorton’s suggestion and see what happens.

– Greg

Woops – try it now. I had a hardware problem on one of my virtualization hosts and had to shut down a bunch of VMs. And I shut down my bullseyebreach.com VM by mistake. Sometimes I am a dork. Should be up and running now.

I’m not using any hotlinking prevention services I know of. The closest that comes to mind is a plugin named Redirection that gives me info about 404s and lets me set up 301 redirections.

– Greg

Bummer – ain’t nuthin’ simple in this world. That Jetpack plugin messed up my book cover image. I noticed the image didn’t show up on my home page and I looked into why – viewing the HTML source, this is where it’s supposed to get my image:

src="http://www.bullseyebreach.com/wp-content/uploads/2015/02/bullseyefinal-200x300.jpg"

But with the plugin activated, it tries to get the image from a big long URL starting with http://io.wp.com… And, of course, I have no clue where that lives and I never put anything there. Maybe that plugin thinks it’s making cached copies there, I don’t know. After deactivating Jet Pack, my image displays just fine.

Bummer – I was hoping it would just work.

– Greg

I did read “The Cuckoo’s Egg.” Great book – my copy’s gotta still be around here someplace. There was also another one – I forget the title – about Robert Tappan Morris and the first Internet worm. Was that the book with 3 different stories named, “Cyberpunk?” Oh yes – and “Takedown,” by (I could never spell his Japanese name) about the sysadmin who nabbed Kevin Mitnick. All great books.

And yeah, especially given the subject matter of “Bullseye Breach,” it occurred to me this attack might be not be random. I know the bad guys usually catch a wide net, but this website went live about 3 weeks ago and it didn’t take the bad guys long to find it. And the book is not about a breakin on a no frills machine. That no-frills machine sitting in a dusty corner of an upstate New York HVAC contractor was just one link in a chain reaching from Russia to Bullseye Stores in the Midwest USA.

Watching that log for a while, it was a well oiled attack. I have the whole thing sitting in access_log and I’ll bet there were a few dozen IP Addresses in the attack, each individual one hitting me only once in a while. So none of the compromised computers would notice anything wrong, but cumulatively, it looked like a tidal wave for a while. Literally from all over the world. Scary.

I’d better gear up.

– Greg

For vigorwebsolutions – just now saw this – thanks for the kind words!

For spaycanjil11 –
Just taking a stab in the dark – in the non-working one, what do the permissions look like on the file,
http://www.toledohomesinspectionshousesinspectors.com/wp-content/uploads/wpcf7_captcha/664484767.png

Do you have a way to do a tail -f on your httpd error_log and watch it in one window as you open the Contact page? That’s what led me to my clues.

– Greg Scott