Some posts have ‘Continue Reading …’

They shouldn’t though. I couldn’t figure it out at all. Why should posts, mostly from the older pages, suddenly start showing the Continue Reading link. Here’s an example:

Continue reading

There are lots of posts like this. All in the later pages. I’ve checked the theme settings and it’s fine. The next obvious thing was the blocks or raw HTML itself to see if there was some sneakily embedded tag that was causing mischief. Nope. All looks fine.

I finally found the problem. White space in the excerpt widget. Easily resolved by deleting it. But why? How has this happened? And it looks like it’s always the same amount of whitespace. In the screenshot below you can see the highlighted whitespace just before deletion.

It’s annoying, and what’s also annoying, is whether it’s going to happen again. I’m wondering whether a recent update caused this but I can’t think why it should.

Mysterious whitespace appearing in the excerpt widget

By copying the whitespace and pasting it into vi, then saving and running od on it I get:

dougie@office:~$ od -c temp
0000000 \n \t \t \t \t \t \t \n
0000010

I’m not sure how meaningful that is, but if it’s accurate it looks like that, for whatever reason, lots of my posts have acquired a newline, 6 tabs, and a newline. I wonder why.

Horizontal Scrollbars

Are a thing. Quite a big thing. I like to keep an eye on ideas about good practice for presenting information on the web. I still haven’t got my head round the alt tag for images – where and how to use the alternative text and image title attributes for instance. And is opening an image in a separate tab good or bad? And how much do I care?

At the moment I’m using the twentysixteen theme. I quite like it. Nice and simple. Recently I wanted to paste a bit of code so I selected Code Block in the Gutenberg editor. It looked terrible. A sort of unwrapped inverse video that I found not very clear to read.

So I tried it with the preformatted block option. I think it looks better. Cleaner, and with a border. But the code I pasted was wrapped, and I find that difficult to read.

But is it just me? I started searching for how to add a horizontal scrollbar to the code or preformatted block and found it a muddy field. First discovery I made was that this behaviour seemed to be particular to the twenty sixteen theme; the other themes I tried defaulted to horizontal scrolling.

And I seemed to be in a minority in liking horizontal scrolling. All the search results were for people trying to work out how to disable horizontal scrolling, whereas I seemed alone in wishing to find out how to enable it. I’m intrigued to find that on the whole it seems people don’t like horizontal scrollbars in code windows.

But I like it so I tried to work out how to enable it. I think I’ve sorta managed it but whether it’s right I’m not sure. Seems to work. I used the Inspect facility of Firefox to prod and poke and try a few things, then I added:

.wp-block-preformatted {
    white-space: pre;
    overflow-wrap: normal;
}

and

.wp-block-code {
    white-space: pre;
    overflow-wrap: normal;
}

to the Additional CSS section of my theme customisation.

That seemed to work so I went hunting for the settings. I’m using a child-theme and I quite like to know where things live. I looked for recently changed files but there were no likely culprits. I was a bit puzzled so back to the internet, and I discover that these customisations are saved in the database itself. I’m not sure why, but I wasn’t keen on this. I’d prefer it if they were there, in green and black in a text file that I could see.

So I’ve removed the code from my Additional CSS bit, and put it in style.css in my child-theme directory, and it still seems to work.

I do like the way other themes do it though. I think the styling is nicer in twentytwenty but I don’t like the way it displays categories and tags in block capitals. Maybe I’ll tinker in that direction somewhere down the line.

Another layer of security for WordPress

A simple way of deflecting brute-force attacks is to require an additional password to access the WordPress login screen. Lots of security plugins will do this for you, but again, sometimes it’s better to DIY.

I put a .htaccess file in the wp-admin directory and that almost completely worked, but mystifyingly, and irritatingly, there would be regular failed login attempts. Not very often. About very 20 minutes or so. But I was irked (I tell you), as I couldn’t work out why they were happening.

My .htaccess file looked a bit like this:

<RequireAll>
AuthName "my site"
AuthType Basic
AuthUserFile <myauthfile>
Require valid-user
</RequireAll>

A few searches made references to differences between apache 2.2 and 2.4, and I thought that perhaps it was a syntax thing. But that didn’t seem to be it.

I did two things in the end, so I’m not sure what fixed it.

  1. I modified the .htaccess entry to specifically reference the file wp-login.php.
  2. I moved the .htaccess file to the parent directory.

So the relevant code looks something like:

<FilesMatch "wp-login.php">
AuthType Basic
AuthName "Secret stuff"
AuthUserFile <my auth file>
Require valid-user
</FilesMatch>

Disable xmlrpc.php

Thanks to the Simple History plugin, the first thing I noticed on my new WordPress install was hundreds of brute-force login attempts:

Anonymous user from x.x.x.x 4:25 pm (less than a minute ago)              Failed to login with         username "dougie" (incorrect password entered) warning       Showing 212 more     

And then more alarmingly, immediately the same thing on a new test user I set up a few minutes later. Of course, just because frustratingly I can’t work out how the attacker extracts the new WP username immediately doesn’t mean it ain’t happening. But the attack vector, so to speak, was the xmlrpc.php file.

Several ways to tackle this, and initially I used a security plugin to fix it. But given the choice, I’d rather do things like this manually so I have a better idea what’s going on, and maybe learn something too.

I pasted the code suggested from https://www.hostinger.com/tutorials/xmlrpc-wordpress into my .htaccess file:

    # Block WordPress xmlrpc.php requests
    <Files xmlrpc.php>
    order deny,allow
    deny from all
    allow from xxx.xxx.xxx.xxx
    </Files>

changing the allow from to the static IP for my regular connection, although strictly speaking I don’t think I need that and will try taking it out altogether sometime.

Publishing failed – JSON error

Migrating WP blog to my VM. New install of WordPress. Test posts with Guttenberg (Block) Editor. Following error:

Publishing failed. Error message: The response is not a valid JSON response.
Publishing failed. Error message: The response is not a valid JSON response.

An interesting rabbit hole. Lots of searches rightly suggested that using the classic editor would get round the problem. Or that by changing the permalinks settings to Plain would fix it. It did, but not much help if you want your permalink settings set to something else.

Eventually I discovered that the issue for me was with the .htaccess file not being processed, which was fixed by adding something along the lines of

<Directory /var/www/html>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
</Directory>

to the /etc/apache2/apache2.conf file (on Debian Buster). This worked for me, but I get the impression it’s better practice to edit the files in /etc/apache2/sites-available instead for any local code in case apache2.conf gets overwritten on an upgrade. Probably also need to do a:

a2enmod rewrite
systemctl restart apache2

So for me the cause of the error message was quite obscure. Useful link: