Oolong

Thanks! I would not have thought to look under Yoast > Search Appearance > Taxonomies, and would not have guessed that ‘SEO Title’ meant HTML page title.

I’ve changed it to
%%sitename%% %%sep%% %%page%%
which doesn’t seem to have had any effect so far, but if I need further help I’ll take it to the Yoast forum.

Thanks again!

• This reply was modified 2 years, 5 months ago by Oolong.

Thanks @t-p! That showed “og:image’ property should be explicitly provided, even if a value can be inferred from other tags”.

I’ve now installed the Yoast SEO plugin as recommended on other relevant posts, so I can manually set the image that Facebook (and Twitter) associate with each page, but surely this should be happening automatically? Or does it just assume that only Featured Images should ever be used for previews, or something?

I found a workaround by not using the Index template at all – just making a normal page, inserting a Latest Posts block, and inserting some ad hoc styling into ‘Additional CSS’ so that it’s not completely unformatted.

I still have no idea why the theme was trying to render it in white-on-black in the first place. It doesn’t look like that in the site editor. Is there a well-hidden ‘swap foreground and background colours’ setting somewhere?

Oh wow, thanks @saturn3! That’s done the trick.

I did not foresee them moving Style settings out of the Settings bit, while leaving many style settings in the other settings tab – and I did not notice that half-moon icon, and would not have guessed that might be what it was.

Huge relief to solve my own problem, but the default should still absolutely not be black on black, especially while the editor doesn’t underline links! Not sure if the theme maintainers look at this forum much?

Yes, I’ve used the settings that make the colours show up.

I’ll post the same thing in the theme area, thanks Lisa.

DarkTable is an image editor for Linux, focusing on RAW editing. It’s generally pretty good.

It’s possible it’s only too-big pictures that are failing, though I haven’t done extensive testing. :-/

I switched between Twenty Thirteen and Twenty Fifteen, but I’ve switched back again now and the Media Library still seems to be working.

Thanks. Switching theme seems to have caused the Media Library to start working again, though it hasn’t fixed the upload problem. Experimenting further, I now realise it’s not all images that it chokes on – it may be only ones exported from DarkTable! This is still baffling, since these images work perfectly well everywhere else, but at least it gives me something to go on…

For now, I’ve fixed it by the strange and convoluted route of copying the text for the posts from phpMyAdmin into the WP backend. For some of the posts I also had to use Notepad++ to remove characters it was interpreting as ?, but at least one just needed pasting to remove the misinterpreted characters.

I’ve asked in the NFS forum about DB_COLLATE, too. Thanks.

Thanks Tara. Yes, I contacted my hosts’ support forums. Sort of helpful but not at all conclusive.

The error logs on my server don’t include anything relevant-looking; it doesn’t seem like it’s spewing an error in response to being asked to edit a post that confuses it. I think the only plausibly related bit (from several days ago, so I expect it’s a red herring) is this:

[Sun Dec 08 10:39:52 2013] [error] [client 172.17.0.141] Cache couldn’t make dir ‘./cache’., referer: (url of wp-admin)/themes.php?activated=true
[Sun Dec 08 10:39:53 2013] [error] [client 172.17.0.141] Cache unable to open file for writing: ./cache/05e1e45a843408773b36e78958f9ba5a, referer: (url of wp-admin)/themes.php?activated=true

There isn’t a DB_COLLATE line in my wp_config file, which I haven’t edited for a long time, nor. DB_CHARSET. Based on this, I’m guessing I probably shouldn’t just add them. I can’t think why it would ever have been anything but UTF-8 anyway…

If DB_CHARSET and DB_COLLATE do not exist in your wp-config.php file, DO NOT add either definition to your wp-config.php file unless you read and understand Converting Database Character Sets. Adding DB_CHARSET and DB_COLLATE to the wp-config.php file, for an existing blog, can cause major problems.

Twenty Thirteen.

Thanks Tara.

Unfortunately, no, deactivating all the plugins didn’t help.

Switching theme to a different default didn’t help (nor did updating Twenty Thirteen and switching back to it).

Resetting the plugins folder didn’t help.

I guess I’ll see if there’s anything on the support forums of my hosts, NearlyFreeSpeech.

Any other ideas?

I don’t think it’s your fault at all! I’m getting this in version 5.2 of the plugin.

I just went into the code and commented out lines 27 through to 39 – a ridiculous bodge, but it seems to work. Then I re-entered my settings.

This means putting a /* after flickrid')) { and a */ after ('flickrRSS_settings', $settings);

Done – either way the pages Google gives me as spam links now go to my Nothing Found page, as they should.

The page-flipping thing is presumably JavaScript based, of course, but that doesn’t give me a whole lot to go on…

Thanks… the first link gives some specifics on how I could exclude posts with this custom field from my query, which does take me to a working answer, but a kludgey one, as I said. And meta_query is nice – surprised I’d missed that – but I’m not seeing a way to use it to solve this problem with reasonably elegant code. Actually, I’m not seeing a way to use it here at all, which makes me wonder if I’m just being dense.

Oh, local like that. That makes more sense then. Yes, if it had 469 million other WP users I expect the solution would have been much easier to find, and I wouldn’t have bothered to ask here in the first place. Cheers!