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. Maybe even for core-developers, as there is nothing like hearing experiences from a first-time user. 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. This last year I have had a “simplesite” for my book. No coding or html there.
Legend: Concepts in WordPress in italics. Plugins & tools in bold.
Pre-Start – trying locally
I needed a website to present my new book. 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 give username and password for both the site and the database. The latter 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 webserver here. This is fine, as I don’t want this running all the time.
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 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.
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 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”:
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.
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 .
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 at YouTube.
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.
It annoyed me that my site was called www.klauselk.com – instead of 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.
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.
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”. This is a file that tells Google which pages you have. This helps the “webcrawler”, finding not just the site, but also all pages in it. Yoast dynamically updates this, which is why you give the path to Google – not the file.
Similar steps can be done with Microsofts Bing, and other, to me unknown, sites.
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 🙂
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, powerfull HTML – directly in the page, as pure text. An example:
<a href="http://klauselk.com/wp-content/uploads/downloads/udp_ip6.zip" download="">udp_ip6.zip</a> - Linux UDP on IP6
In Google Analytics there is a sub-item called “PageSpeed”. It gave very poor readings for the “landingpage”. 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.
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):
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 landing page now caused a 404 error. Ups. The wpbeginner had the cure – rewrite permalinks. In the dashboard, go to Settings-Permalinks and hit “Save”.
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.