debplatt

@ristoniinemets, Thanks. I’m puzzled as to how I an image by that name was added to my media library, but it sounds like I can safely delete it.

Regards,
Deb

I am not blocking access to wp-admin with my .htaccess.

I can use the built-in web developer’s console of my browser to see which JQuery is loading. According to my console, both my development and production sites are loading this version of JQuery into my browser:

JQMIGRATE: Migrate is installed, version 1.4.0 | jquery-migrate.min.js:2

Is this the version that you were expecting?

In passing I’ll note that my sites both use the following plugin to email the user messages created by Quick Contact Form: WP Mail SMTP. This has worked nicely with your plugin for previous versions, and still appears to work with 6.11 on our development machine. I have it configured to use SMTP with the SMTP host being smtp.gmail.com

I checked permissions on both our development and productions sites. In both sites (running on Linux) the permissions for wp-admin are set to 755 with the owner being my personal login account. When I checked my wp-config.php file, there was one difference between the two sites. The development site (where 6.11 works) has define('DISALLOW_FILE_EDIT',false);, while the production site (where 6.10.2 works, but 6.11 produces a server error message) has define('DISALLOW_FILE_EDIT',true);. I couldn’t see why this would make any difference to the Quick Contact Form plugin, but just to rule this out I set the constant to false on the production machine. Sadly, this did not eliminate the problem.

Since the 6.11 update produces an error message, I rolled back the plugin to the 6.10.2 version which seems to serve us well. If there is some data that I can get from the site with the updated plugin, I would be happy to do so during a low volume time for our site. Just say what information needs to be checked.

I mention in passing that when I run the 6.10.2 version, the form content fills the content area for my web page as would be expected. However, when I run the 6.11 version (even on the development site where no error messages are produced), the width has narrowed to be 280px wide. Inspecting quick form element (6.11 version), I found the following information using the console.

• The value “device-width;” for key “width” is invalid, and has been ignored.
• The value “1.0;” for key “initial-scale” was truncated to its numeric prefix.
• The value “1.0;” for key “maximum-scale” was truncated to its numeric prefix.
• The value “0;” for key “user-scalable” was truncated to its numeric prefix.
• Error parsing a meta element’s content: ‘;’ is not a valid key-value pair separator. Please use ‘,’ instead.

All the above information was attributed to index-13, which was: <meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;">

With respect to your plugin the console also told me: Failed to load resource: the server responded with a status of 404 (Not Found) This was with respect to https://192.168.1.7/wp-content/plugins/quick-contact-form/images/failure.png Failed to load resource: the server responded with a status of 404 (Not Found) So it could be I was supposed to see some sort of image indicating that there was some sort of error, but since the image wasn’t found, it wasn’t presented.

Using the terminal I looked into the directory quick-contact-form. It has no subdirectory images. When I looked to see what images were local to the quick-contact-form directory, there were only three GIFs, screenshots one, two, and three. There is a subdirectory assets which is empty.

Our production site runs on a virtual machine hosted by Linode. We also have a development site which runs on a virtual machine on a computer in our home. Both versions of our site use the same theme, plugins, etc. When I tried upgrading from 6.10.2 to 6.11, quick contact form worked as expected on the development machine, but it displays the server error message described by others on the production machine.

Since we control the virtual machine that’s hosted by Linode, I don’t think the problems is due to the ISP caching our website. Any other changes that we make to the site take effect in real time.

Since we are using the same theme on both our production and development sites, I also don’t see how the theme can be to blame. I would think the same thing would be true of the plugins that we are using since they are installed on both sites.

keesiemeijer, I really appreciate the PHP snippet that I can add to our functions.php. We are actually using a child theme of the Apprise theme now, and I will follow your advice by adding this to our child theme. Once again, thanks so much for your help!

wpfan1000, thanks for trying to get a lead for me. I had spent a long time googling for answers before posting to the WordPress Forum. I wish WordPress would simply list the criteria that have to be met for the Customizer to work. Then I could check to see if I were meeting those criteria.

Ipstenu, I have configured wp-config.php so that I use https for logging in and also for whenever I am doing administrative work. To test whether this is the source of my difficulties, I changed wp-config.php to read as follows:

define('FORCE_SSL_LOGIN', false);
define('FORCE_SSL_ADMIN', false);

Although I was now using http instead of https, when I tried to use the Customizer to display a live preview, it still didn’t work (just an eternal loading symbol).

wpfan1000, I am not a theme developer. I am just a regular user. And my problem is not specific to a theme. I am unable to get the live preview to render any content for any theme, including any of the themes that are supplied by WordPress (Twenty Fifteen, Twenty Fourteen, etc.). I can set theme options using the customizer, but I do not get a preview, so I am unable to know how my choices are affecting the look of my site until I save my settings and look at the live site.

keesiemeijer, if a page existed with comments before the 4.3 upgrade, it continues to exist and people can add comments just as they did previously. However, I was having problems when I added a new page (I did this on our test site, not our production site). However, after your most recent comment, I did go back and check my screen options, and you were right, I had checked the checkbox next to “Comments” thinking that I was enabling comments, but I should have enabled “Discussion” instead. When I did this I could see that the new page was now open to comments. Although I would like to be able to enable comments globally for our pages, this will work for us. I appreciate your patience and your help.

keesiemeijer, when I check the Discussion checkbox on an individual page, all that does is bring up a button that says “Add comment”. If I click the “Add comment” button, it allows me to add a comment, but none of my readers can respond or add comments on their own. To me the whole point of comments was to engage the visitor, not just let me do a “P.S.” to my own post.

leejosepho, I do have Administrator permissions. When I go to Settings > Discussion, here are the headings available for me to configure:

• Default article settings
• Other comment settings
• E-mail me whenever
• Before a comment appears
• Comment Moderation
• Comment Blacklist

I don’t see any setting in any of the above groups that would allow me to set comments on by default for the pages at my site.

@alexisglenn, I was delighted to hear that you resolved your issue. As it turns out I am accessing my site by logging on directly using a terminal, and not via cPanel. And my installation directory just had an index.php file without there being any index.html. So I am still out of luck. But as I said, I’m glad that other people are successfully resolving this issue. But as for me, I’m still stumped.

Because I have been using a theme which allows users to configure it using its own pages, I haven’t been using the theme customizer at all, so I don’t know if it ever worked previously. Because WordPress is going to require theme developers to use the customizer, I thought I should try it out on some new themes on a copy of our site that sits on a development machine. When I did so, the live preview behaved as described by AllieSackett: a loading symbol would forever spin.

Here’s what I have tried so far without luck:

• Disabling all plugins
• Remvoing the entire plugins directory as described by alc000 above
• Switching to a different web browser that has no installed extensions
• Changing the wp-theme (and its subdirectories), so their group membership is “www-data” and changing the group permissions for those directories to read, write, and execute
• Modifying wp-config.php by changing define('DISALLOW_FILE_EDIT',true); to be false.
• Changing my .htaccess file to allow access to wp-config.php
• Since I used svn to install WordPress core at my site, and continue to use it to update the core installation, I tried using svn again to reinstall the core; it said I was at the current revision. So I tried going back to a previous revision (4.1) updated the database, then switched back to the current revision (4.2.2) and updated the WordPress database again. I now had a fresh install of the WordPress core. Without enabling any plugins, I tested the live preview.

Nothing worked. I mention in passing that at one point in time I tried wp-super-cache, but it was disabled and its directory was removed long ago.