efikim

+1

Its gone back to working correctly without me changing anything, so I’ll leave it as it is for now, especially as I’m planning to change the hosting shortly.
Thanks for your help

further checking – I already have the ‘use CF-CONNECTING-IP header’ selected in the Wordfence configuration, so surely shouldn’t need the Cloudflare plugin.

Thanks Damon,

I think it was working ‘correctly’ earlier (the site has been using both cloudflare and WordFence for a considerable time) and I don’t recall making any changes to the site’s cloudflare settings that might have changed anything. In fact over a period of about fifteen minutes about half of the failed attempted logins were given as cloudflare named ips, and half were recorded as purely numeric Ip addresses
Additionaly, the CloudFlare WordPress plugin isn’t marked as compatible with WordPress 4.0 or up.

Awaiting comment from Wordfence support.

Thanks for having a look at the problem, and the helpful explanation. I’ll try to find another way to build what I want – your comments are helpful in pointing another way to look at the requirement. (I was trying to duplicate the approach I took with another, much simpler, CMS that’s no longer supported.)
Thanks for your help! ??

if you mean a meta keywords tag, that stopped having any relevance for SEO several years ago, as it was widely abused.

not according to this support request for Genesis Simple Edits, which was the first I looked at …

any change on this yet?

Your first problem is getting an image to link to a page. As far as I know this is not directly supported by NextGen – I’ve looked because I need this for a new site I’m working on.

The only solution I found was a hack to the the NextGen code, which would have to be re-applied every time you upgraded the plugin … currently a far too frequent occurence!

Then you’d just have to manually create the extra pages to hold a normal gallery.

The instructions are at holondesign.com/nextgen-by-photocrati-gallery-thumbnails-go-to-pages.

I’m considering using the wordpress media gallery (which has a plugin to manage linking images to pages) and jetpack extensions instead on the new site.

have you saved the new draft after editting the page? – if I remember rightly, it checks the saved draft or published page/post, not the one in your browser

xml files are invisible in browsers unless they have a valid stylesheet. Since google can read it, its not actually the sitemap file itself that has a problem, but the stylesheet (or the xml file has something wrong in the bit that names the stylesheet).

Thats still an error, but not one that most would worry too much about (or even notice). If you still want to see the stylesheet, use the browser’s ‘view page source’ function (on the right click menu in Windows versions of firefox).

as tdiaz has commented, the beta testing was poorly managed.

Normal practice for well organised beta tests is two or three betas, followed by one to three Release Candidates. No-one familiar with beta testing puts anything before the Release Candidates on a live site.

Now obviously photocrati wouldn’t have the same level of resources, and so might not be expected to go through such an exhaustive testing sequence, but at least one release candidate would have been good practice.

Shouldn’t have any impact on the statistics, the code is still there, its just that the image is marked to not display.

Have you ticked the box to disble the smiley face in the jetpack configuration page for statistics?

@mt78 there is no sitemap file stored on the server, so if you look at the server files directly you won’t find it. However if you look for the sitemap file using a web browser you’ll see its there – its generated automatically each time its requested, so iits always up to date, as are the subsidiary sitemaps
eg https://mypicks.efikim.co.uk/sitemap_index.xml
(change the site name to your site and you should see the sitemap, and you should be able to add that into the bing webmaster tools)