On WordPress

I’ve been using WordPress almost since I first started Web Development. It’s almost a right of passage for PHP developers in many ways. It’s one of the most used web apps across the Internet as well as one of the most popular open source PHP platforms you can find.

It’s super easy to install and doesn’t require a great deal of technical knowledge to operate, but one of the most impressive features of WordPress is that with technical knowledge you can mould it into almost anything you can imagine. Not just a blogging platform anymore, WordPress is much closer to a powerful application framework, and if I’m honest, it’s one of my favourite development platforms.

Admittedly, there was a time when my impression of WordPress was much less positive than it is now. Anyone who’s been in web development for a while has heard the negativity, but let’s be honest, most software sucks, and it’s WordPress’ ability to continually evolve and improve that makes it the incredible platform that it is.

As of 2019, I use WordPress on a daily basis. This site runs WordPress and in my job I operate well over 70 web applications, many of which are WordPress as well. We use WordPress for it’s core function as a publishing platform, but we push it much further than that. Custom themes using the latest Javascript technologies, plugins that connect to dozens of different services and extend the core functionality, we use it for Internet facing websites as well as internal tools for reporting and analytics.

We have sites that serve content to tens of thousands of subscribers and millions of hits a month. Everyday, WordPress’ ability to cope with everything we can throw it surprises me, although at this stage, it probably shouldn’t anymore.

WordPress 5 and Gutenberg

Late in 2018, WordPress 5.0 was released with the new block editor Gutenberg. Lot’s of people online were frustrated with the changes and if you search the web you can find posts both positive and negative.

As an example, the Classic Editor plugin that reverts back to the old WordPress editor has well over 3 million installs just in the few short months since WordPress 5 was released.

I don’t really have an opinion on that, the freedom that WordPress gives you means you have the right and the ability to use the software however you want. Don’t like Gutenberg, that’s fine.

Personally, I enjoy Gutenberg and have only good things to say about WordPress 5. It took some adjusting at first, but the block editor feels much more natural now.

For what it’s worth, I give WordPress 5 and Gutenberg a big thumbs up and can’t wait to see what comes next.

The future of WordPress

I can’t say what the future of WordPress will be, I’m not a core developer and I’m not involved with how WordPress is run. I have contributed to WordPress in a number of small ways though, both documentation and code, so who knows. That is the benefit of open source after all.

Beyond that, I hope WordPress continues to evolve and improve. Regardless of what cranky people with opinions seem to think, change is good, and WordPress will need to change in order to stay competitive.

For myself though, I plan to make more contributions to WordPress itself outside of my job. I’m constantly working on improving my Javascript skills, and more than that, I will keep pushing myself and my team on what we can create with WordPress.

Programming in the real world

Articles and courses on learning to code are all over the web right now. It seems everyone wants to code, and for good reason, it’s super fun.

So I wanted to write a bit about my experiences with learning to code and what it’s like to code in the real world. This is not so much a “how to” article as it is my own personal opinion.

I started to code at the age of 12 back in the late 90’s because I wanted to create my own computer games. Back then, the Internet was a lot less helpful than it is now, although to be fair, it was still pretty good.

There were no coding websites like code.org and YouTube wasn’t around, so I had to search for tutorials and try to figure things out for myself. This was actually one of the best things that could have happened because I was forced to explore and experiment on my own.

Don’t get me wrong, all the resources we have available now are brilliant, and I use code.org and hour of code regularly to teach my kids the basics of programming, but I think having to rely on trial and error and making my own mistakes turned out to be my greatest asset in the long run because I’m used to not having the answer handed to me.

Programming in the real world is a lot less about language features and having things work the first time around, and much more about problem solving. But more than that, real world programming is about results. It would be wonderful if we could all work on whatever projects we want, using whatever new language or framework we want and have the luxury of starting from a blank canvas, but the reality is most of us who become working programmers have a boss and business requirements that dictate what we can and can’t do.

Businesses don’t generally care about programming languages and design patterns, they want you to get the project finished and out the door as fast as possible in order to generate income. A project sitting around being discussed by developers and designed using the latest software engineering methodology doesn’t make the business any money.

My first programming language was QBasic because it was freely available and already installed on the computer I had access to at the time.
Honestly I don’t remember much about how to use QBasic, but what I do remember is the process of writing a few lines of code, breaking things, trying to fix it, breaking something else, over and over again until eventually the code worked but didn’t actually do anything I wanted it to.

It was frustrating, but it was also incredibly rewarding because at the end of the day my brain became used to the debugging and testing process, which in my mind is much more important than anything else I’ve learned.

Some might want to argue with that last statement, that debugging was the most important thing I learned, but it’s true. Very rarely do we as programmers get the opportunity to have our code work first time round, and even less often do we get to work on something new. 90% of my day job is fixing or extending existing code, and you can’t do that without knowing how to debug. The language itself doesn’t even really matter, it’s the mindset and the process you go through in order complete your task. And in all honesty, debugging broken code and extending existing code are both very similar activities.

Let me explain why. When something is broken the first thing you need to do is try to recreate the issue. Often this is done by running the code and watching what happens, though obviously, the more familiar you are with the code the faster you can start to narrow down what might be wrong.

The point is, you start by testing the running application. Same goes for when you need to extend the code to do something new or different. You can’t just open up your editor or IDE and start coding, you need to familiarise yourself with how the existing code works. What’s the process it goes through, what input does it accept and what output do you see?

Often, being able to track down a bug, or the specific file of a running web application that you need to modify is the hardest and most beneficial part of the process.

For example, there’s a web application that I support that runs 8 separate business websites. The application is written in very old PHP code, is not written using a framework, stores data in multiple databases and has been gradually extended and modified over several years. It’s actually quite scary when a task comes up for this app as it’s always risky, it’s always time consuming, and modifying anything always leads to unexpected issues elsewhere in the code.

Many times over the last couple of years I’ve thought how good it would be to rewrite this monstrosity in something more modern, a new framework, and being able to start fresh. But the reality is, not only does my boss not see it that way, rewriting an existing application, especially one that has years of custom logic, is generally always a bad idea.

Millions of lines of code, much of which runs our entire society, exists out in the “real world” that will likely never be rewritten into the new popular languages. Why? Because they work, and the risks and expense of rewriting them far outweigh the task of maintaining them.

It’s unfortunate (sort of), but very true.

Which leads me to the next most important skill for a programmer is the ability to read and understand someone else’s code.

I’m not talking about reading a simple CRUD app you found on github, I’m talking about a real application. One that’s a total mess would be a great learning experience.

I learned more about software development trying to understand that beast of a code base I just mentioned than I ever did reading tutorials or watching videos. Not because it’s an example of good coding practices (it’s not), but because it’s an example of a real application that has a real commercial use and for the very reason that it doesn’t follow good coding practices. We all know the real world is not as nice and organised as we would like it to be. Software is as a much an expression of the real world as anything else humans have created, because we are messy and unorganised.

Never in over 10 years of being a working programmer have I ever had the “benefit” of working on an existing code base that was well organised in every way. Again, some might argue with that, perhaps it’s just the experiences that I’ve had, or perhaps I’m not as good a programmer as I think I am, regardless, the real world of programming often sucks.

So, if you’re a new programmer, or an existing programmer who wants to step it up a bit, what are you supposed to do?

My advice, is to not focus on learning all the new, latest frameworks and programming languages, but focus on the basics. Learn how programming languages themselves work. Write your own framework in your favourite language.

Next, find existing open source code written by someone else and study it. Try looking on github or Sourceforge. Get something (large and messy) installed and working, then try to extend it, or fix a bug.

I also recommend learning beyond the programming layer. Learn the platform and operating system your code will run on too. I specialise in Web Applications running on Linux and (more often than not) Apache. But I also know Nginx quite well and can jump between the two if I need to.

Learn databases (SQL and NoSQL) and learn multiple programming languages, because code doesn’t live in isolation. While the main language that I’m hired to work on is PHP, I often have to write Javascript, Python and Java among others, again even if it’s not a fresh new project in the language of my choice, having to integrate with existing code is an important skill.

Most importantly though, is learn to experiment. Don’t just rely on the answers being given to you, learn to think for yourself. Google is a helpful resource, as is StackOverflow and Github, but trial and error, printing out variables and breaking things (just not in production) are just as important.

Migrating from Shopify to WordPress

Shopify is a well known eCommerce platform, and web searches for data migrations either to or from Shopify are pretty easy to find. What I couldn’t find was an explanation on specifically migrating blog articles from Shopify into WordPress.

I recently had a client who ran a Shopify store that only sold one product, a magazine, while the rest of the store was dedicated to the blog content. The business wanted to expand the content strategy and build the subscriber database, so, while migrating platforms wasn’t my first choice, it made sense in the long run as we have more flexibility and control with WordPress.

Moving the product across to WooCommerce was trivial, we didn’t bother scripting that, we just created a new product in Woo, set up the payment options and moved on. Moving the blog content required more thought, and I wasn’t prepared to move them all manually. While they didn’t have a massive amount of blog content, it was enough to want to script the migration.

Shopify have a decent API and setting up API keys is fairly easy. The API documentation provides instructions for setting up an app within your Shopify store, so I won’t repeat that here. Most of the documentation on Shopify development I found was aimed at Ruby developers, which is fine, but as I was writing the script in PHP and running it on WordPress, I wanted something a little closer to home.

I found a PHP library for accessing the Shopify API which I installed with composer. From there it was pretty much following the API docs to fetch the right data.

Shopify stores blog content in a way that was slightly different to what I’m used to with WordPress. Initially I was trying to call the blog endpoint, which was basically returning nothing sensible. Then I noticed from the documentation that ‘Articles’ are stored within a blog, which makes sense as a blog is a collection of articles, so I needed to pass the Blog ID to the articles endpoint.

I think I was expecting what you would find with WordPress. Everything is a post, so calling all posts with no filters should return all posts.

To be fair, I missed it because I was skimming the documentation for code samples, not actually reading the instructions. My bad.

 $shopify = new PHPShopify\ShopifySDK($config);
$blog_id = 123456789;
$blog = $shopify->Blog($blog_id)->Article->get();

As all the articles I was looking for where stored in the same “blog”, calling the above method once returned everything I needed.

After that it was fairly simple to loop over the response and insert the articles into WordPress.

foreach($blog as $b) {
$p = wp_insert_post(array(
  'post_title' => $b['title'],
  'post_content' =>$b['body_html'],
  'post_status' => 'publish',
  'post_date' => $b['published_at'],
  'post_excerpt' => $b['summary_html'],
  'post_author' => $author_id,
  'tags_input' => $b['tags'] ));

The only thing left was to import the images to the media library and attach them to the posts, which I wont go into here.

Up And Running With COBOL

In keeping with the current theme of Mainframe programming, I’ve decided to go one step further and learn COBOL as well.

Being a half century old Mainframe programming language, up to date COBOL information isn’t around every digital corner of the Internet, and coupled with me using CentOS (probably), I’ve had to set up my environment manually.

Grab a copy of GNUCobol and untar it

$ tar xJf gnucobol-3.0-rc1.tar.xz
$ cd gnucobol-3.0-rc1

Standard Linux software compilation process applies here

$ ./configure && make && sudo make install

Provided all the dependencies are satisfied, this should compile with no problems, I had to install two additional packages with yum, but otherwise it took about 30 seconds to compile and install the whole thing.

As you would expect, the default install is /usr/local/bin/cobc, but there was one small hiccup that took some Googling to figure out. After compiling your first COBOL program (coming up next) you will likely get the following error

./hello: error while loading shared libraries: libcob.so.4: cannot open shared object file: No such file or directory

This was annoying. Fortunately, it was easy to fix.

$ sudo /etc/ld.so.conf.d/gnu-cobol-3.0.conf

I use Visual Studio Code for most of my development work at the moment, and to my surprise, there’s COBOL packages in the marketplace ready to be installed, which help with syntax highlighing and code formatting.

$ touch hello.cob
$ code .

My first COBOL program is the much loved Hello World:

DISPLAY "Hello World".
Make sure this lines up in the correct column (one tab worked)
$ cobc -x hello.cob
$ ./hello
Hello World


Installing A Mainframe On A Laptop

For as long as I can remember I’ve been fascinated with massive computer systems like Mainframes and Supercomputers. Scenes like in the movie “Hackers” showing the Gibson Mainframes, “War Games” with the WOPR and images of huge data centers filled with enormous machines are a young computer nerds fantasy.

I don’t have a Mainframe, I’m not particularly prepared to buy one either. So as a Mainframe enthusiast, I figured I’d try the next best thing…

This post is intended to be less of a HOW-TO and much more about documenting how I personally got a Mainframe emulator working on my laptop. There’s various other articles around the web that I’ll be referencing, though to be honest, they weren’t as straight forward as I would have liked.  Hopefully by the end you might be able to get something similar up and running as well.

I’m going to build this environment on CentOS 7 running on a Lenovo Thinkpad with 8GB of RAM. Most Linux environments should be similar, though I can’t say the same for Windows or Mac.

First, you can download a Mainframe emulator Hercules using your Linux package manager. You can of course download the source and build Hercules yourself, but this article is not about building software on Linux, so let’s just use yum.

$ sudo yum install hercules

Following the FAQ on Hercules website, http://www.hercules-390.org/hercfaq.html, let’s download a copy of MVS from http://www.ibiblio.org/jmaynard/turnkey-mvs-3.zip. This will give you an ISO archive that you can extract to your home directory. I’ve got a folder called mainframe and I’ve extracted the ISO into the folder mainframe/turnkey-mvs.

Inside the turnkey-mvs folder, there’s an executable called setup so let’s run that with the -a flag that assumes all default set up options.

$ ~/mainframe/turnkey-mvs/setup -a

This will install an MVS image into ~/mvs38j

After the installation completes, you will be asked to enter the MVS master password, which defaults to SECRET

Next you will need an IBM 3270 terminal emulator. I toyed around with building this from source, but it was just easier to once again use the CentOS package

$ sudo yum install x3270 x3270-x11 x3270-text

The next step elluded me for a bit, but it’s necessary to edit the startterm file in the mvs38j folder to add the number of terminal sessions to connect to the server.

$ vim ~/mvs38j/startterm

x3270 -port 3270 &
x3270 -port 3270 &
x3270 -port 3270 &
x3270 -port 3270 &
x3270 -port 3270 &

Now we can start MVS

$ ~/mvs38j/startmvs

This should start up the MVS service that you can connect to.

Open the x3270 application. I had more luck running the GUI version rather than the terminal client. From the Connect menu, create a new connection to localhost:3270. Hopefully this will connect the x3270 client to the MVS service, you should see a connection message in your MVS terminal window.

Now you need to start 3 more of these x3270 sessions and a telnet session

$ telnet localhost 3270

From the initial MVS terminal window (the server) you can now start the inital program load

Command==> ipl 148

IPL 148 tells hercules to load MVS. On one of your x3270 windows you should see the following message:

We’re now ready to start issuing commands to the system in order to get MVS running.

r 00,clpa
r 00,y
s jes2
r 01,format,noreq
r 02,y
r 03,y

IPL should now be complete and you should see the following screen on one of the other x3270 terminals.

To logon, type:

Logon ===> HERC01

Welcome to MVS. For more detailed information on commands and booting into MVS, I suggest reading the MVS Turnkey Cookbook.

Pin It on Pinterest