The two most likely culprits are a broken preloaded plugin or a broken theme. Let’s look at how to fix both.

Broken Plugin

The quickest way to fix this is to go in with ftp or go to your webhosting file manager and rename the plugin directory to plugin.nw. Preloaded plugins sorted.

Broken Theme

Themes are trickier. You have to rename the active theme, then rename one of the default WordPress themes to the name of the broken active theme. For instance. Say I’m using the theme “Broken” – I rename “Broken” to “Broken.nw” I then rename “twentynineteen” to “Broken” I can now go into theme selection in my WordPress and choose a working theme. Now that everything is working I can rename “Broken” back to “twentynineteen” then “Broken.nw” to “Broken”

This happened to a client recently. They had selected a third party theme and a WordPress update broke everything. All they were getting was this critical error:

It turned out the theme that they had installed broke the latest version of WordPress. The convoluted instructions above for renaming the theme brought the site back online.

This is one of the reasons I have resorted to using the WordPress default themes and then customizing them myself. When you use a third party theme it relies on that third party to keep the theme updated. It adds a dependency over which you have no control. Personally I prefer to keep things as simple as possible.

To access your hosting file manager, you need to log into your hosting account, select cpanel, then look for file manager under the files section. I will update this post as I encounter and fix more WordPress problems.

In other news it’s great to see the Government give out the password security advice that I gave in my last blog post. Perhaps they were reading it Let’s hope everyone updates their systems to take this into account! There’s nothing more infuriating than a prescriptive password system telling you to use a capital letter. And a number. And a punctuation mark.

The recent default WordPress themes have seen a trend towards minimalism, with themes that are optimized for readability. The last two themes have added extensive support for the WordPress block editor. Out of the box, they offer enough functionality to provide a good looking website with a minimum of tweaking, but have the flexibility for advanced customization. Or in the words of the developers, they offer a blank canvas.

The first thing to do with any new theme is to create a child theme. Themes, particularly new ones, are regularly updated and if you don’t create a child theme, you run the risk that a theme update will overwrite any customizations that you might have painstakingly implemented.

The new Twenty TwentyOne theme looks good without any tweaking. It has good looking typography and it supports dark mode.

It has deleted the company logo and I see from the specifications that the logo dimensions have changed. Twenty twenty required a 300 x 300 pixel logo, whereas twenty twentyone needs a 300 x 100 pixel one. The new theme supports dark mode so it will also be important to ensure that any logo works against both a light and dark background!

It has also capitalized the company name for some reason and there’s a lot of white space at the bottom of the page. The page titles are in a rather large font but I think it might be worth sticking with. I’ll take a deep dive into it when I have more time.

UPDATE: Perfomance of the updated website was shocking. It took over a minute for the main page of the website to load! As a result, the whole website has been reinstalled and the php version updated. Load times are back to normal. If you notice any issues please get in touch.

We could implement a number of algorithms into the code, but there are all kinds of inherent weaknesses with the approach, from finding holes in the algorithm to reverse engineering the Java code.

The safest and most secure option would be to rely completely on a third party for encryption. The simplest method would be to create an encrypted drive partition from a file. There are a number of programs that can do this such as BitLocker or the open source VeraCrypt. Plenty more options can be found here. If you think how much space you think you’d need for encrypted projects, then double it and create a partition that size. Then mount this to a drive letter. It’s important to use the same drive letter, so use something like Y: or Z: that won’t be used by anything else. Open AssetJournal and create a new Projects directory on the encrypted partition. Create a new project in this directory and work away. Once you close AssetJournal and unmount the partition, the project will be completely encrypted. If you wanted encrypted cloud storage, you could create your encrypted volume within a dropbox or tresorit folder.

We personally favour VeraCrypt. The fact that it is open source means that everyone can get in there and look for flaws and it means a secret backdoor is less likely to be hidden in the system. VeraCrypt has been externally audited to ensure it’s integrity. It’s also cross platform which is a big bonus.

A guide to creating encrypted partitions with VeraCrypt. And a guide to do the same thing with BitLocker.

As a small software development company, Covid-19 doesn’t have a great impact on us. Computer programmers have naturally been practising social distancing for years! It’s an occupation that requires intense concentration with hours spent staring at obscure looking computer code. A lot of the kinds of technology that people may be using for the first time to allow them to work remotely, programmers have been using for a long time. So if you need any advice on the technology side of things do get in touch.

We have had to temporarily put up shutters on some of our clients’ websites and we can only earnestly hope that they can make it through this crisis. These are strange times.

With a potential drop off in new work, it would be a good idea to look at some of the in house software projects that we have had sitting on the backburner and to take the opportunity to skill up our team.

Stay safe and remember to keep washing those hands!

While I was digging around I found an old OpenJournal archive. OpenJournal was, from the marketing: “the leading solution for Web-based knowledge capture and sharing among E&P business units” – basically it was a simple tool for knowledge capture and workflow that was built on a very early version of Java (1.1). It was the first program that I had taken from the initial concept all the way through to delivery on desktops around the world.

There were a number of geologists in our company who would carry out projects on a consultancy basis. OpenJournal was created to allow them to document their projects as they went along. Previous to that they would make copious notes and print screenshots. Once done it all would go off to the secretary to be typed up. That would all have to be read through and corrected. OJ streamlined the whole process and the end product could either be printed off or sent to the client on a disk.

I had already created several VMs in the process of data recovery, so I couldn’t resist taking OJ for a spin!

This rather scary warning is the first thing that you see when you run OpenJournal! User Interface Design Principle No. 1: Scare the bejeesus out of the user! When we originally developed OJ we were very much thinking in terms of minimalism. The program allowed you to create your content with a few basic tools, rather like a cutdown version off Offce, this would then be output as HTML. This meant that OJ content could not only be viewed in OpenJournal, but also by anyone with a web browser.

At some point we had the genius idea of adding our data into the html files in the form of comments. What we didn’t take into account was that people would then mess about with those html files which would then trash OJ’s data! After several support calls, version 1.1 had to be hastily pushed out with this horrible warning. The lesson here is clear – never trust the user and obfuscate your data! If memory serves 1.1 also had to address the fact that Unisys started to license the use of gif files and we had to remove those.

The Project Manager window. Look at those badly scaled graphics! The Landmark one doesn’t even have the right background! We were programmers not graphic designers! Also that weird artex stipple effect!

User Options. 1 of 7! This was always my least favourite part of the UI. It was a custom widget. I haven’t seen anything like it before or since! It did the job though.

And here we have the main interface to OpenJournal. The left side was a tree like structure for your project and the right side was the editor/viewer for your content. Then along the top you have the toolbar. To create a new item you could either click or drag and drop one of the 5 toolbar objects in the centre of the toolbar. Text Editor, Image Editor, New Page, Separator and small red spot.

Initially all the different parts of OJ came up as separate windows, then towards the end of the initial development there was an emergency meeting where it was decided that it would be better to have everything in one window. It was a bit of a nightmare resdesign, but with hindsight it was very necessary. If you’ve ever used GNU’s GIMP editor you’ll know what a pain having lots of separate windows can be!

OpenJournal could be toggled to a draggable toolbar. This way you could keep the program on screen while you got on with your work and it was still easily accessible. I always thought this was quite neat. I have no idea if the users ever made use of this feature.

One of the really useful features of OJ was that it allowed you to take a screengrab of what you were doing and then annotate it. When you ran the screen grab you were presented with this video and you would then drag the little image where you wanted it etiher on the viewer or the hierarchy.

This would then open up your screengrab in the image editor. Even now, the striking thing is how easy it is to use. There are a fairly limited set of tools – there were no libraries or toolkits – everything had to be coded from scratch. Even something simple like drawing a line – all had to be mathematically worked out. I had to go back and relearn trigonometry.

This monstrosity is the tool for entering text! You were limited to the fonts made available to Java. I’ve changed my mind. This is the ugliest part of the UI!

Resizing images was a bit fiddly though. The Apply button helps though.

The other main editor was the Text Editor. Again it feels really intuitive. Modern software is so bloated, you spend half your time trying to find the thing you need or googling how to do the thing you want. OJ was simple, but it did what you wanted.

And here’s end result. You create your content and anyone in your organization that needed to, could then access it either through the browser or through OJ.

Despite being 20 years old, OpenJournal feels surprisingly intuitive – and responsive. There is a lot to like about it and there is definitely a lot to be said for a time when software was easier for the end user to pick up and use. Perhaps there is a lesson there for future development plans!

As the K.I.S.S. principle teaches us: Keep It Simple Stupid!