Ate Up With Motor

Okay, thanks. I will give that a shot.

Thanks again for your help. I really appreciate your excellent support for this theme.

Great, I will give that a shot.

If I add a modified /includes/editor-style.css, do I need to copy all of the unmodified contents of the existing file or can I add a new one to the child theme containing just the altered line?

Do I need to copy the rest of the includes folder or can I just copy that one?

Thanks!

Oh, going along with that, I’m not sure how I can remove the wp_enqueue_style function that is loading the Google API fonts in the first place. I see it in the Frontier functions.php file, but I don’t know how to disable it from the child theme.

Thanks again!

Unfortunately, I don’t really know how to do that, at least not in a way that would be useful to you. (I could find the references in the code to wp-content and change that to the actual folder name, but I don’t have the technical skills to come up with a patch that would automatically insert the correct directory.) I’m not a programmer…

Email notifications have started again of their own accord, so whatever the issue is doesn’t appear to be related. Never mind.

Okay, that did it. Thanks for the suggestion — that obviously hadn’t occurred to me!

I’ll give that a shot. WP-Super-Cache is running in preload mode, which is a lot faster, but may be hanging on to what was otherwise a temporary glitch.

Those pages/posts don’t seem to be having that error when I view them while logged in, which supports the idea that it’s a cache problem. (WP-Super-Cache is set to not cache for known users.) I cleared the cache and am having it restart the preloading; let’s see if that does the trick.

Costin,

I’m sorry, I don’t have debug logging enabled. I looked through the most recent error logs and didn’t see anything related (the host only keeps them for a few days, so that isn’t necessarily revealing).

As an experiment, I tried deactivating and completely deleting the plugin, then reinstalling and reactivating a fresh copy from WordPress. That appears to have done the trick; I re-enabled all the settings and all the alerts are now green.

Any alert that regards a function performed by the plugin itself: “WordPress version is displayed in links for all users”; “Core update notifications are displayed to all users”; “The check for PHP and database error reporting is disabled”; and so on.

Essentially, all the options controlled by the plugin settings are red or yellow and the alert dates have not updated in over a week. All of these settings are enabled in the Settings page and have been for days now.

Cron jobs for other functions, such as backups, are being performed on schedule, so it puzzles me that the alert checks are not.

How long should I expect it to take for the alerts to refresh? It’s been days and they haven’t updated.

Hmm — the problem now seems to have resolved itself. I have no idea…

Okay, it appears what happened was that when the data was imported, the parameters and indices of the term_relationships and term_taxonomy tables were not set properly, so neither of those tables had an index. I fixed that — with considerable difficulty — and that solved all of these problems. Apparently the tables not being indexed left WordPress unclear on what to do with them.

For some reason I don’t understand, I wasn’t able to assign the indices for those tables from phpMyAdmin: If I tried to set the primary key, I’d get an error warning me that I had duplicate keys, but if I tried to drop the primary key, I got an error that it didn’t exist!

Fortunately, I was able to go back to the other installation, copy the term_relationships and term_taxonomy tables, import them into the database, and update them (fortunately, I’d only added one or two things since the import). I renamed those two existing tables and gave the imported tables their names (effectively replacing the existing tables with the imported ones), and that solved the problem.

I think there’s something more basic (and pretty serious) going on. If I create a new category, I can’t add posts to it (if I try to check the box for that category from the edit window, it unchecks as soon as I hit Update) and I can’t delete it without going into the table and dropping that row. If I try to delete the category from the Categories menu, it flashes red and disappears, but if I refresh or if I navigate elsewhere and then go back, the category is still there (and still in the table).

I tried deactivating all plugins and switching to the unmodified Twenty Thirteen theme and trying again to assign a post to a new category or delete a category. Same result: I can create the category, but I can’t assign posts to it and can’t delete it.

I’m not sure what else I can try.

Here’s another curious fact. I tried to add a new category with Model Histories as a parent and then assign one of the posts in the affected categories to that new subcategory. WordPress would not let me assign it to the newly created category. I could click the checkbox for it and hit Update, but as soon as I did, the checkbox disappeared and the category information was not saved. I found I could remove and add back one of the existing subcategories, but not a newly created one.