Tag: wordpress

Posted on

A few quick definitions

Regarding the last post I put up (here if you’re reading this on annathepiper.org, and here if you’re reading it on Dreamwidth), I thought I’d do another quick post with some definitions of terms I’m throwing around, for those of you who aren’t in the tech industry and might not know what I’m talking about:

API: An API is basically a known set of ways that a program, operating system, or in this case a website makes available for others to hook into and use. For example, Apple has an API for developers to use if they want to create apps for iOS. What I’m doing is playing with the REST API that WordPress makes available as part of the WordPress code.

Service: A service is a thing that sits underneath a website and does a lot of under-the-hood things for it. I described this on Facebook as being part of a website’s engine. It’s not something a user would see just interacting with a site in their browser, but it’s an important thing nonetheless, and it’s there to help the website do its job.

REST API: REST is specifically one type of format an API might take for access to a web service. This Wikipedia page has more if you want to read up on it. But for purposes of this post, I’ll simply say that the REST API endpoints I’ve worked with to date, both in the context of a job and on my personal coding projects, are endpoints that return JSON payloads that I can test against.

JSON: JSON is a file format with a specific syntax and structure. It gets used a lot in web services as it’s reasonably easy to parse, as well as hand back and forth through various steps of a web site’s operation. So when I see a JSON payload come back off a web service endpoint, I can use my test automation to analyze that payload and look for interesting things in it. For example, an HTTP response code, like a 404. Or an error message or error code. OR, if the test is specifically looking for a successful response, I might be looking for an expected title or body of content. Since I know I’m dealing with JSON, I can set up my code to drill down into the payload and look for these specific things.

Endpoint: An endpoint is basically one of several routes you can use to do things with a service. It’s more or less a URL that you can use to make the service report back on various things.

So with all of those identified, does it make more sense now if I say that my demo tests are hitting the documented WordPress REST API endpoints, looking at the JSON I can get back from those endpoints, and analyzing them for various things? Let me know! And let me know if you have any questions. :)

Posted on

Coding projects update

As of this writing, I now have a total of five repositories on my Github account: the misc-configs repo for various config/supplementary files, and two each for Java and Python work. For each of those languages, I have a repo for the REST API portion of this project, and one for the Selenium.

All of the repos can be seen on my Github account.

What I’ve been calling the rough “phase 1” of this project is now more or less complete. I’ve got basic test cases in place in both languages for both the REST API side, and the Selenium side. As I’ve written about before, the API tests are dealing with the service endpoints that handle publicly viewable information. The Selenium tests are mostly oriented around testing parts of the homepage of my little test WordPress site.

Now I’m moving into the rough “phase 2”. In this phase, I’m adding more Selenium tests. This’ll include adding some sidebar tests for the homepage, as well as tests for additional sections of the site (a post and a page), and making sure that the elements are correct on the selected links. I’ll also be testing site search and adding a new comment to a previously existing post, since that’s something I can do without authentication.

“Phase 3” of this project will get into dealing with stuff that requires authentication. From the REST API side, this’ll mean dealing with the service endpoints that handle things at the site admin level (such as making a new post or comment, or editing a previously existing one). From the Selenium side, I’ll want to see about verifying logging in and logging out of the site, and making sure that the links displayed in the “META” area of the sidebar update themselves accordingly.

(NOTE: I am NOT going to try to test the actual WordPress admin UI. That’s a whole different kettle of fish than testing a front-facing site.)

In related news, I’ve also discovered the Githubs “Projects” functionality, and I’ve made myself a project there to cover the work I’m doing. This amuses me, as their Projects board looks a lot like JIRA, the bug tracking/project management software we used at my Former Day Job, as well as at the short contract I had after the layoff at the tail end of last year.

Interested parties can find my current active project on my Github projects page. I’ll be adding additional projects to that once this one is complete–like the WordPress plugin work I want to do!

I’ve actually had job recruiters and interviewers ask me about this work, now that I’ve got a link to my Github on my resume. This has proven beneficial in interviews I had last week, and I even got useful tips on additional libraries I can research, as well as aspects of version 8 of Java I hadn’t had experience with yet. I’ve gotten positive feedback about how I do comments on things, as well as on the various Readmes I’ve put on the repos.

So while the work hasn’t yet actually proven critical in landing me a job, it has proven useful in helping me demonstrate that I not only know how to code, but that I like it well enough to do it on my own time and to plan out larger projects.

This is, I feel, a very valuable thing for me to be able to demonstrate.

Posted on

Today’s WordPress Test Demo update

Good progress on the coding project today! \0/ Things accomplished:

  • Added new test cases involving Categories, Tags, Pages, and Comments, to bring the total number of test cases up to 10
  • Added the ability to run the cases via a Maven configuration as well as TestNG, and updated my pom.xml to use the testng.xml as its suite file
  • Checked all the new test cases and related work into wp-test-demo-java
  • Renamed my wordpress-dev repo to misc-configs, because that’s really what it’s for miscellaneous config files
  • Updated my Postman collection to include all the endpoints for the test cases I wrote today, and checked the new version of that into misc-configs
  • Updated the Readmes on both wp-test-demo-java and misc-configs to more clearly explain what the repos are for, particularly wp-test-demo-java, as I’ll be pointing recruiters at that
  • Installed Jenkins (again) on my dev laptop, so that I can run the automation as a local Jenkins job as well as within IntelliJ, and to keep up my practice using Jenkins

I have decided, too, that I’ll be doing this project in phases.

Phase 1: REST API tests that hit the endpoints that can serve up publicly available data. I.e., the kinds of data you’d see as a user just browsing a WordPress site.

Phase 2: Selenium-based tests that will do front-end type tests. For example, “If I click on this link, does it take me to this expected target page?” Or, “If I click on this thing on the menu, do I get the correct dropdown off of it?”

Phase 3: This is the ambitious part. There are also REST API endpoints for WordPress that’ll let you get at the stuff you’d ONLY see as an authenticated user, such as post revisions and settings and the like. Time permitting, I may learn about the various ways to actually do that authentication properly so that the test suite can actually get at those endpoints.

Right now, though, I’m going to focus on phases 1 and 2.

Posted on

Practicing with running WordPress in Docker today

So one of the things I want to do during my between-jobs downtime is practice my coding. And in particular, since I thought it’d be nice to a) start small and b) play with something I’m actually interested in coding (as opposed to, say, just focusing on random interview-type questions which will eventually bore me to tears), I decided I’d try to play with making a small WordPress plugin.

I’ve already done one that I’m running locally on Annathepiper.org: namely, to show y’all my archive of roleplay logs. Eventually I want to do a newer version of that, something that might let me actually practice setting up a simple web service.

For now though I’m going to do something less complicated. There’s a very old plugin called “lj-tag-parser”. This thing has a very simple job: allowing the LJ-style syntax for usernames and communities in your WordPress posts and comments. I’m using it right here on annathepiper.org, which is why you can actually see LJ-style usernames and tags if I write something like, say, userinfoannathepiper.

However, this thing hasn’t been updated in ages. And I thought it’d be nice to expand it to allow Dreamwidth-style syntax in addition to LJ-style, and possibly also allow generation of such tags via shortcodes.

But before I do all of that, I wanted to make sure I could set up a clean WordPress dev install.

In the past, when I’ve played around with dev-type WordPress stuff, I just did this on a separate blog on my annathepiper.org network. But coming at this with my SDET hat on, I thought it’d be cleaner and more appropriate to developing my coding experience if I set it up the way I’d do it in a work environment.

Which means a brand new, clean WordPress dev install. And in particular, using official WordPress and MySQL images from Docker.

For those of you who aren’t in the tech industry, suffice to say that Docker is a tool that lets you do exactly this kind of thing. You can set up a thing you want to play with in its own little container on your system, without having to worry about it interfering with anything else you might be doing. Docker lets you go about this in a few different ways. You can go get official images for things (like, say, the latest WordPress install) and do a single run using that image.

Or, if you want to do something a bit more complicated (like, say, running the official WordPress image AND a MySQL image that you’ll need to actually power the WordPress install), you can chain them together using a thing called Docker Compose.

Docker Compose works by you setting up all the config data you need in a file called docker-compose.yml. I’m still fairly new to the syntax this thing requires, but fortunately, I learned a bit about it while I was still at my previous day job at Big Fish. So I was able to utilize that knowledge to build a file that’d let me set up that clean WordPress dev install I want.

I did have to jump through a few hoops to get all the info I needed, though. Here are some pages that proved useful:

So now, as of this writing, I have a nice little set of Docker containers running on my dev box on Linux. And the nice thing about doing this via Docker, especially, is that I could take this exact same docker-compose.yml, reboot my box into Windows, and use it there too. All I need to be running locally is Docker and Docker Compose. The rest of it comes in with the images I specify!

And for the interested, I have checked in my final docker-compose.yml up on my personal Github account, and you can see it right here.

Posted on

Upgraded annathepiper.org to WordPress 5.0

This is a test, this is a test, this is a test. This is me playing with the new “Gutenberg” editor that comes with WordPress 5.0, and yep, this is sure different.

Gutenberg is oriented around the concept of “blocks”. It keeps offering me things to do to various types of them, including paragraphs and shortcodes. I’m not sure yet if I like this experience yet. But at least there’s a plugin I can install to restore the classic editor if I decide to get rid of this.

For now, anyway, I’ve got this version of WordPress installed on my personal network of sites (which includes both annathepiper.org and angelahighland.com). Assuming nothing obviously explodes, I’ll be rolling it around to the other sites hosted on murkworks.net this weekend.