DavisDaddy

Thanks. I’m glad we had this little chat ?? Your observation about the
incomplete theme was dead on. I conjecture that something in the
semi-automatic updating process saw our non-standard files in the
“twentyfourteen” theme directory and just aborted the process. (Non-standard
meaning that, in addition to regular backups of everything, I like to keep a
local backup handy, such as “page.php.20150425”, meaning that that is the
version of “page.php” that existed before I did the edits on 25 April, etc.)

I downloaded WP 4.2 “by hand” and copied the files from
“…/themes/twentyfourteen” into our existing “twentyfourteen” directory, and
shazam! All of the old, familiar files are there.

This alone would have effectively solved our immediate problem, but I also
implemented your suggestions about having “page.php” and “style.css” in the
child theme. (Actually, “style.css” was already there, but it didn’t contain
the relevant edits.)

Our site now appears to be (a) completely updated and (b) working with an
entirely standard, unedited “twentyfourteen” theme.

Thanks again. Very awesome indeed.

I’ve done some more digging, and I find messages like:

thumbnail”;O:8:”WP_Error”:2:{s:6:”errors”;a:1:{s:15:”image_no_editor”;a:1:{i:0;s:28:”No editor could be selected.

in the wp_options table for the option with name:

wp_cycle_images

I’m guessing that there was a change in the PHP and/or MySQL configuration on the server that caused the GD library to disappear.

I’ve added some packages to the server, and it now appears that GD support is enabled. Now I’m looking for advice as to how to purge the record of the offending images. I suppose I could just remove the entire wp_cycle_images option (using MySQL), but I’m afraid that I’ll REALLY break something if I do that. I don’t mind re-uploading the images, if that’s all that’s required.

Any suggestions?

Thanks.

Thanks. This is very helpful. I think I have this working now. Here’s the actual command I used:

if ( post_password_required() ) {
echo get_the_password_form();
} else {
// regular template code goes here
…
}

Yep, so far as I can tell, this is exactly my set-up. The behavior I see is as follows. If I create a password-protected page with a default template, WordPress prompts for a password when I visit the page.

When I use a custom template, as I’m doing here, WordPress does NOT prompt for a password, unless I include some additional code in the template file (as per my original post).

Furthermore, even if I DO get prompted for the password (by virtue of the additional code), my query loop runs, irrespective of my password response. I.e., I see all the posts, regardless of what I type for the password.

I think that to prevent that, I need to check for the use of the correct password before I allow the query loop to run. That was ostensibly the purpose of the second “if” statement in the original post.

But the second condition in the second “if” is always false in all the experiments I’ve tried.

Without the second “if”, I always see all the posts, regardless of the password I type. With the second “if”, I never see any of the posts.

If you have a custom template that is behaving differently from this, I’d be pleased to learn the details.

Thanks. That IS what I’m doing, or trying to do. The page is password protected. It has a custom template. I get the prompt for password. But what do I do with it?

IIUC,the first “if” statement is supposed to check if the page is password protected in the first place and to prompt for the pw, if so, assuming that there isn’t already a cookie containing the pw.

The second “if” statement, again IIUC, is to prevent the script from going into the query loop unless the password is correct.

So far as I can tell, the first condition in the second “if” does evaluate to true, but the second condition is always false. Hence, I never get to see any of the posts.

So, to summarize, I go to the password-protected page and type what appears to be the correct password, but I’m unable to detect that it’s correct, and therefore I never enter the query loop.

BTW, I should have mentioned that this is WP 3.5.1 on ubuntu 12.04

Thanks to Mark and Seacoast for their useful suggestions. I think the custom
Page Template is going to work. I do have (at least) one follow-up question.

The MySQL connect/select/query functions require me to supply the hostname,
username, password, and database name. For all of these I just replicated the
information that’s already in wp-config.php. This isn’t a big deal, as it’s
not likely that this information will change frequently (maybe never).

OTOH, replicating data like this is ugly, and it DOES open the door for an
inconsistency down the road.

Is there any simple way to pull this information into my PHP script? Ideally,
this would be something like:

$dbName = wp_get_db_name();
etc.

Failing that, I guess one could do some kind of regular-expression search of
wp-config.php, looking for DB_NAME, DB_USER, etc.

Any suggestions? Thanks.

— Mike

Hi, Mario. Thanks for the follow-up. I haven’t reduced the Image Dimension
at all, but I like your suggestion to look in the database at the wp_options
variable. (The MySQL aspect of WP is a mixed blessing, IMHO.)

— Mike

Thanks. That’s the information I was looking for.

— Mike