Using WordPress
Not so long ago, to me “WP” was an echo from the past, meaning “WordPerfect.” Now I am using WordPress for this site. From pure habit, I started a logbook, realizing later that it might be useful for others. The log is more or less chronological, with the oldest stuff first. I should say that I have some very rusty experience with Apache and html. Many ears ago, I maintained a “trac” website, mainly configuring it.
Legend: Concepts in WordPress in italics. Plugins & tools in bold.
Pre-Start – trying a local WordPress site
I needed a website to present my new book(s). It had to be up & running in a jiffy, but I also wanted something that can grow with me. I know that I will be wanting to use FTP to a local host for experiments. I need to have a “Downloads” section, and a number of static pages, plus maybe a blog. I will want to try php and CSS, as well as SEO tools.
After looking around, I homed in on WordPress.
I then learned that WordPress.com is very basic, kind-of blog-only, whereas WordPress.org gives you more flexibility, but no hosting. Just the code.
I now fetched “XAMPP“, which implements a “localhost” server on my PC. I downloaded WordPress from WordPress.org and unzipped it as instructed. I had to provide username and password for both the site and the database. The database is called MariaDB, but seems to be identical to MySQL.
None of the above required any programming, and it all just worked on my PC. At the next reboot it didn’t. I realized the need to start XAMPP Control Panel after boot, restarting database and web-server here. This is fine, as I don’t want this running all the time anyway.
The Dashboard at the left edge in “edit mode”, together with the top-menu that WordPress adds in the live site, works pretty neat.
I toyed around with some Themes, and learned that it is possible to work entirely online. It seems that the workflow was different from what I expected. You can work “normally” online, and export to the local environment for experiments. So I decided to go for the next step.
Getting a WordPress site
I now went looking for a site, free of commercials, but not too expensive. I need daily backups, and the “one-click-install” was tempting. I found a site offering to handle the domain-purchasing also, and went with that. An afternoon after work, I purchased the package, did the one-click install and was up & running on my new domain the same evening. I tried a few Themes, ending up with “TwentyFifteen” aka 2015, and started writing Menus and Pages.
I downloaded the “Under Construction” plugin and activated it. Now I could experiment more privately. This plugin shows a picture with a discrete “login” button. Once logged-in, you can access the site but others cannot. Incidentally, you later login by writing “/login” after the home-page URL.
Later, when I had removed the “Under Construction” sign, I unchecked the feature that says that new Pages are automatically added to the primary menu. This means that when I work and publish in iterations, it is very unlikely that anyone sees it. It is easy to add Pages to the menu later via the Dashboard.
Switching WordPress Theme
After a couple of sessions, I got tired of “2015”. It was too targeted towards blogging. In “2015” content is in the center, while there are sections left and right – one of these with a Sidebar including Menu. Between the outer sections is some empty space, into which you can put a background image. To me, this was too messy. I switched to “2017”, after testing a few others. It is a great feature that you can test with a live preview. I hadn’t written much content and was prepared to lose it all, although it seemed I wouldn’t. After the switch, my Menu-system was gone, but my Pages had survived. These are saved in the database, and thus not affected by the choice of Theme. In other words there are no html-pages (until a cache is installed).
It is important to check how the theme looks when the browser-window is made smaller. Most themes with horizontal menu, will change this to be vertical as the window becomes narrow. Changing appearance with the client media is said to be “responsive”.
Writing a little code
Before changing any code, it is important to create a “Child-Theme”. Otherwise your changes will be overwritten at the next update. I simply downloaded a plugin – “Child Themify” – that helped me. I have later learned that this is very simple to do manually, but the plugin worked fine.
When you only want to code a little, according to documentation there are three template files: header.php, footer.php and style.css. On top of this, you can also write html/php-code in standard Pages in text-mode. This does not require the child-theme.
When any of the three template-files need changing, it must be copied from the “parent” theme to the same place in the child-theme and edited here. Now I downloaded the “File Manager” plugin and activated it. With this I could browse and move the files from within the Dashboard, but there was no editor!
This had to be enabled in “wp-config.php“. This is “outside” the dashboard and the website, but can be accessed via sftp. Instead I simply used the providers file-manager from their control panel. In the following line, replace “true” with “false”:
define('DISALLOW_FILE_EDIT', true);
I tried changing the “footer.php” to give me the credit instead of WordPress 🙂
I had done this in my brief encounter with the TwentyFifteen theme. This time however, the code wasn’t in “footer.php”. Instead, it was under “template-parts/site-info.php” (discovered by debugging as described below). Once found, it was easy to change.
Note that in WordPress the file path is the absolute URL on the running system, not a relative path in the server-source-tree as I would have expected. There are php-functions to help with this – e.g. php_content(myfolder/myfile), will give you the absolute path to “myfile”, as long as “myfolder” is a direct child of “wp-content”. You can also “spell out” the path completely.
Debugging
When trying to get a grip of what is happening, it is practical to use “Developer Tools”(standard component) in Chrome, or “FireBug” (must be downloaded and installed) in Firefox .
It is a good idea to debug in “Incognito” or “Private” mode, to avoid various browser extensions influencing the results.
Using one of the above, you can inspect the code when its running in your browser. Don’t forget that this is the html that the browser sees. It does not exist on the server – except as pieces of code inside the database. The good thing about this, is that you can change it, and see what happens, without destroying anything. At the next refresh of the page, it is back to normal. The bad thing is that you need to find the real place to edit afterwards. There are many great videos on this on YouTube.
Organizing Files
WordPress follows a naming-scheme for uploading files. This scheme is preset in “settings” in the Dashboard. Preparing for blog-content, these uploads are often organized in year-month folders. I prefer to have images in an img-folder under “uploads”. Likewise I now have “downloads” under “uploads” – hmm.
Going Local Again
I had removed the “Under Construction” sign and was beginning to gather content. Thus, I was not happy about major experiments – who knows whether the backup can be restored?
It was clear that you cannot just copy files to the local server. The database needs to be migrated as well. This involves translating links.
I ended up downloading the “All-in-one WP Migration” plugin. I exported the whole enchilada to my PC, where I imported it in from my local WordPress. The only downside of this plugin is that you need a working WordPress site to import from. However, I had exactly that. It worked like a charm.
Like the other plugins used so far, the “All-in-one WP Migration” is free – up to zipped packages of 512 MB. This site took 143 MB. After the local import I dared remove stuff like unused Themes. An export now took 125 MB.
Changing URL
It annoyed me that my site was called www.klauselk.com – instead of simply klauselk.com. This can be changed in the settings, but I felt a little uneasy doing it. There were tons of complex descriptions on how to do this after the fact – implying that this simple way was a “nogo”. Anyway, now that I had a backup, I did it. It worked fine.
Introducing a WordPress Cache
My website is not as fast as I would like it to be. Luckily there are Cache plugins. I was attracted to “WP Super Cache”, but documentation stated that the permalinks “must be custom”. Feeling weary about changing this fundamental thing, I checked out “W3 Total Cache”, and installed it in the local copy. Now everything looked like sh..
Luckily the warnings told me I had a problem with CDN – which is a paid service that gives you hosts on all continents. I do not have this, so obviously it failed. I got it to work by disabling anything with CDN, but in the meantime I had found a note on “WP Super Cache”. It stated that permalinks only needed to NOT be the total basic ones based on ID only. My permalinks were not this type, so I now tried “WP Super Cache”. I found it easier to understand, and kept it. The acceleration is great.
Later, my provider gave me a “Varnish” cache and CDN, so I dropped the above caching.
SEO
Somewhere along the line, I decided to install “Yoast SEO” – Search Engine Optimization. It asks a lot of questions. To answer some of these, you click some links. Then you are inside Google, authenticating the site and your ownership. It was a little confusing, but it works. Along the line Google asks you to give the path to your “sitemap” xml-file. This is a file that tells Google which pages you have. Actually the name is “sitemap_index.xml”, and it refers to four other files – one for each the following: pages, posts, tags and categories.
This helps the “webcrawler”, finding not just the site, but also all pages & posts in it. Yoast dynamically updates this as needed, which is why you give the path to Google – not the file. Note that if Yoast is uninstalled you need to “update URLs” to generate the default WordPress sitemap – and register this at search.google.com.
Similar steps can be done with Microsofts Bing, and other, to me unknown, sites.
Improved Tools
In spite of my initial ideas on FTP and local editing, I had used a WP-based editor and file-manager up until now. I pulled myself together, and installed FileZilla and Notepad++. I know FileZilla well, while Notepad++ was unknown to me, as I am used to nice paid tools. However, in this project the sport is in doing it all for free – except the hosting.
In the management console for my webhost, I found the SFTP URL, and port. Using this together with my password, I could finally access files via (S)FTP. By clicking on a remote file inside FileZilla, I could open it in Notepad++. This, behind the scenes, created a local copy of the file. When I closed the file, FileZilla asked me whether I wanted it copied back to the remote web-server again. Clicking “Yes” was all it took. Very nice, finally being able to edit with a language-aware crisp editor 🙂
The console also gives access to the “WP-CLI” – a command-line interface that can be used to perform numerous tasks in a faster way than using plugins.
Downloads
I needed to support download of e.g. source-code. There are “Download Managers”, but for the first time I experienced that the documentation on when to pay for what, was difficult to understand. “This and that format is free”. Yes – does that mean that the others are not?
Here & Now, I don’t really need bells & whistles and I ended up with simple, powerful HTML – directly in the page, as pure text. An example:
<a href="https://usercontent.one/wp/klauselk.com/wp-content/uploads/downloads/udp_ip6.zip?media=1713983280" download="">udp_ip6.zip</a> - Linux UDP on IP6
PageSpeed Optimizations
In Google Analytics there is a sub-item called “PageSpeed”. It gave very poor readings for the main page. Basically it gives a percentage, and this was 17! Digging into the log, I learned that the book-cover in PNG-format was 3.7 MBytes. I compressed a JPG to ~600 kBytes. That got me close to 80 on PC and 70 on mobile units. The white logo was compressed by using fewer colors:
magick convert elk_white.png -colorspace gray -colors 2 logo_white.png
I found that I could use the ImageMagick Display to shrink the logo’s to half size a number of times.
The secondary problem was “Render Blocking CSS and Javascript”. From various nice pages – e.g. http://wpbeginner.com – i learned that I should install the “Autoptimize” plugin and enable it to optimize JavaScript and CSS. I did this. Now both mobile and PC are ~86. This helps on all pages. However, still CSS blocked rendering. Following this video: https://youtu.be/k56E_7SFQoE and this tool: https://jonassebastianohlsson.com/criticalpathcssgenerator/, I managed to “Inline & Defer” CSS.
A third problem was that I was not using “ExpiresByType” headers in the .htaccess. This is described here (read the text AFTER before doing as described):
https://speedrak.com/blog/add-expires-header-optimize-cache-control/.
This globally sets the site to report “Expires” dates on static content such as figures, enabling the clients browser to cache e.g. figures that are shown more than once. Naturally it also makes it faster to reload a page.
UNFORTUNATELY all other pages than the main page now caused a 404 error. Ups. The wpbeginner had the cure – rewrite permalinks. In the dashboard, go to Settings-Permalinks and hit “Save”.
Later I dropped “Autoptimize” as I found it too complex and error-prone when used with other plugins.
Added “klauselk.dk” domain
I used to have a “manual” redirect from my previous site at “klauselk.dk” to this “.com” site. I decided that the time had come to kill the dk-site completely, and have “klauselk.dk” send users directly to this site.
So should I “re-registrate” name-server at my registrar (DK-Hostmaster), as well as some changes in e.g. wp-config?
It turned out that the easy way was to ask my new webhost to “move” the old URL. This naturally involved a check-mail from DK-Hostmaster. Now at the webhost’s control panel for the dk-URL – under “DNS” – I chose that the dk URL should point to this site.
Introducing SSL and HTTP/2 to WordPress
This website does not really handle any transactions, but since I write about embedded security it makes sense to use SSL/https. It turned out to be pretty straightforward. My provider offers the SSL certificate – it just needed to be enabled. The provider recommended to use the plugin “Really Simple SSL”, which I did.
Then I went to Google Webmaster tools and introduced two new sites in my “property set” – namely the “https://” version with and without “www”.
I submitted the usual sitemap.xml to both. I also updated in Google Analytics.
Finally I added the https versions in Bing as well.
Enabling SSL means that HTTP/2 is now automatically used. The provider had already enabled this for https, so now it got active. However, a lot of traffic was still HTTP/1.1.
After a google analytics test, I did a test with pingdom.com. This allows you to test the speed in other areas of the world. I found that the redirect from http to https was time-consuming – it added 0.5s to the load time. In the “Really Simple SSL” plugin I removed the redirect in the application and moved it to the .htaccess file. This saved me 0.5s from San Jose to Denmark.
Speeding up again
After doing nothing at this site for a time I checked Google Analytics again. And the site was slow. A few experiments resulted in the following few changes in Autoptimize:
- Remove jquery and others from the “Exclude scripts from Autoptimize” box.
- Remove Google fonts.
- Remove WordPress Emojis
- Remove comments in HTML
This improved speed significantly.
I added my latest book-cover – and again saw problems with it’s large image load-time. I decided to try the plugin Imagify. This plugin claims to reduce size of files in the website (using the company’s cloud-server). It was easily installed, but even though it claimed to have shrunk my files, nothing had happened (they even had the original size). So back to using ImageMagick on my PC. The following converts a PNG file to a JPG version – and at the same time reduces it size dramatically:
magick convert CoverThirdEdSnip.png -resize 50% CoverThirdEdSnip.jpg
WordPress Updates
WordPress and it’s plugins are updated all the time. I tend to hesitate a little before applying these updates – expecting things change to the worse, but normally it all works surprisingly fine.
I am really glad that I created a child theme. This lets me update the site theme without loosing customizations. Recently – after an update – the burger menu stopped working. The “burger menu” is the menu used on narrow devices – like my iPhone. It shows three horizontal lines – hence the burger name – and when clicked, you should see menu-items in a vertical list.
After the update the menu worked once – then clicking it did not help. A reload made it work again – once! I suspected the “Autoptimize” plugin, and when I disabled “Optimize JavaScript Code?” here, my menu worked again.
Improving the slug
The slug is the part of a page URL that you assign to the specific page to be appended to your base URL. For this page it is “wordpress-logbook”. Yoast and other SEO tools recommend that it is a human readable text that describes your page – not an ID number or similar. It is easy to change the slug. A test will show that the page now has the new URL. Be warned however, that Googles cache now is “out of synch”. A correctly setup Yoast plugin in WordPress will submit an updated sitemap to Google, but it will take up to several days before Google caches are updated. Apparently, Google uses the slug as yet a keyword to your content.
You can perform a URL Inspection in Google Search Console. Here you may also ask Google to update a specific page, but it still doesn’t happen overnight.
The morale is that it may be OK to change the slug on a page, but you probably shouldn’t do it right before a big campaign.
Google Site Kit and Tags
At some point I had installed the GADWP – Google Analytics Dashboard for WordPress. I preferred to use the “real” Google Analytics page instead of the dashboard, but the plugin also setup scroll events – so fine. During a maintenance session, WordPress urged me to update to ExactMetrics, which I did. The new dashboard was lousy – but worse; my scroll events had gone. Goodbye ExactMetrics.
After some browsing I found Googles new “Site Kit” which creates a dashboard in the WP environment with a an assembly of pages from Google Search, Analytics and more. The dashboard looked nice, but still no scroll events. Site Kit also aggregates data from Google Tag Manager (GTM). I checked this out and it seemed to enable me to create tags & events at a rather abstract level. So now I created an account at GTM. I also installed a WP plugin – also called Google Tag Manager.
The plugin claimed that Scroll Events are “natively supported”, but they didn’t just work out of the box. I had to configure this inside GTM. I found a good description here: https://www.lovesdata.com/blog/tracking-scroll-depth.
All in all a lot of work to regain the lost scroll events. But at least I now have a framework for adding more tags and an improved dashboard.
Pages, Posts and the Menus
The nature of my web-site is not really that of a blog. This means that whatever I have written in posts may be visible from Googling, but not really through the menu system of the site. Some of the posts are short-lived and can be forgotten, but others are more long-lived. Is it “right” to update the latter? – after all, they do have a date in the slug. I decided to “upgrade” a number of posts to pages. But if I change the slug of existing posts, a person doing a search might run into a “page not found”. In the end I decided to copy the relevant posts into pages.
Now I needed more menu-entries. The classic solution is to add a hierarchy – which I did.
The morale is that it is wise to remember from start what to put in posts and what to put in pages.
I also decided to condense many of the things in this log into a table – always showing the current status of my choices and not the history. This is the WordPress Tools page. Finally I decided to create the new page with the “new” block editor – mainly because the classic editor cannot do tables. I have done tables earlier using html. The experiment worked OK.
Improved Search on the Site
WordPress was originally created for blogs. This can be seen in many ways. An example is that in the posts-section you have a search-bar in the twenty-seventeen theme – but not in the pages-section. I now have too many pages to ignore this problem. I scanned some reviews and ended with the “Ivory Search” plugin. The free version allows me to format the search-field as I like and it even allows me to exclude some posts from the search (the ones that are updated to pages). I am pretty happy with this plugin.
Math on the Web
I wanted to try the nice Latex stuff from my books on the web. So I started a page on digital filters. Obviously I needed a plugin to handle this. After some googling I decided on “KaTex”. I liked the idea that when using the Gutenberg editor, I would be able to see both Latex source and result while editing. This worked really nice!
It is great that you can see the math in the “backend” – but the “frontend” is what really matters. Here the user got “KaTex is not defined” – no math. I was suspecting the “Async Javascript” plugin, so I disabled it and Voila! – now KaTex worked. Here’s the generic FIR filter:
y[n]=\frac{1}{a_0}(\sum\limits_{i=0}^Pb_ix[n-i])A small debugging session showed me that 300-400 ms (on a PC) was spent on the KaTex stylesheets and fonts before First Contentful Paint. This is OK when you use the math – but not when you don’t. Katex offers the ability to only use it when needed – but also warns that this may cause issues with other plugins. It worked for me, and I saved the many ms.
Spring Cleaning
After the above experience I had to acknowledge that plugins can be nice, but they can also interfere with each other, and it was time to clean house. I started by making a backup at my providers site. Then I warmed up by deleting unused themes. Now to “Really Simple SSL”. It has always annoyed me that all the http references to my own pages was caught runtime (at least until cached) and replaced by https.
Since I already had changed the sitename to include “https” – in WP as well as on Google and Bing (see Introducing SSL) – this was not needed now.
So now I got a new plugin! Yes – there’s a difference between a tool plugin that you run manually in the backend, and something that runs every time users are visiting. This time it was the “Better Search Replace”. This was used to replace all occurrences of “http://klauselk.com” with “https://klauselk.com” in the database. I then went into .htaccess and replaced the code from Really Simple SSL with something very similar. Later I found that when deactivating Really Simple SSL you can ask it to leave this code.
The above is described at WPBeginner.
SEO again
At one time I realized that “posts” easily go out of focus. For this reason I copied some of the most “timeless” posts to pages – that are now maintained. I didn’t want to delete the original posts, as this would cause errors for anyone who somehow had links to an old page. However, there is no reason for people doing new searches to land on the old posts. The simplest solution seemed to mark the old posts with “noindex”.
Since I am using Yoast for SEO, this was easily done in the Yoast section under the relevant text – under “Advanced” – “Allow search engines to show this content in search results” – “No”. A test showed that the marked posts were now removed from the sitemap (in the post-sitemap.xml file).