Andrew Wegner | Ponderings of an Andy - Pelican

Automatically checking for broken links using Github Actions

2023-02-13T16:30:00-06:00

Introduction¶

Over the past six months or so, I've been making changes to the site. This culminated in November with a theme update and site relaunch. I have a couple more articles planned about things I've learned from that relaunch, started with today's article. The site is over a decade old, with the initial article in 2009, with over 100 posts since then.

A decade plus is a long time to assume that links will remain operational. I wrote a short series of articles about how broken links impacted Stack Overflow over 7 years ago, including a proposal to fix it and how I performed the link checking from a technical perspective. Now, I want to make sure that I don't have dead links all over my site, especially because this is the site I give out in a professional context.

GitHub Action¶

The Github Action script, is available in the repository where the content of this blog is kept. It's in the .github/workflow/ directory.

Scheduling¶

My goal for this project was to check links for the entire site on a regular basis. I was hoping roughly once a week. Fortunately, GitHub Actions allow you to schedule your actions, using syntax like this:

on:
    schedule:
        - cron:  '12 1 * * 5'

The important thing to note, which is called out in the docs, is that * is a special character in YAML, so the string has to be quoted. Using this schedule, my link checks will run every Friday at 1:12am. For me, timezone doesn't matter, but the documentation says this is going to be UTC time.

Checking links¶

The next thing that has to happen is the actual checking of the links. I use broken-link-checker for now. I picked this because I'm familiar with it. It hasn't been updated since 2018, though, so in the future I may spend some time either looking for an alternative or building an alternative. For the time being though, it works just fine.

I put this snippet into my actions file.

steps:
    - name: Run Broken Links Checker
    run: npx broken-link-checker $WEBSITE_URL --ordered --recursive \
    --user-agent "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/109.0" \
    --exclude linkedin \
    --exclude "udemy" \
    --exclude "ude.my" \
    --exclude "eia.gov" \
    --exclude "backpack.tf" \
    --exclude hlsw \
    --exclude dell \
    --exclude supermicro \
    --exclude mysql

The quick break down:

$WEBSITE_URL is an env variable that I define as https://andrewwegner.com/
I set up a user-agent because several sites block the default one. I did something similar in my Stack Overflow analysis 7 years ago.
All of those excludes are due to those specific domains still not allowing automatic scraping. It's a little disappointing that I need these, but excluding these few to ensure the rest are functional is more important to me than trying to figure out a work around.

Create an issue¶

If broken links are found, it doesn't do me any good to have that buried in a log somewhere without alerts. Perhaps unsurprisingly, I don't check Github every day. My goal was to create an issue on the repository if broken links were found. I did that using the following, and the Create an issue action.

- uses: actions/checkout@v3
  if: failure()

- uses: JasonEtco/create-an-issue@v2
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  with:
    filename: ${{ env.ISSUE_TEMPLATE }}
  if: failure()

The important line here is the filename: line. Using another environment variable, I defined a file with my issue template. Everytime an issue is created by the action, it will have the same format.

Issue Template¶

My template is defined in the same directory as my workflow and currently looks like this:

---
title: Website Contains Broken Links
labels: ''
assignees: ''
---

## Broken Links Detected

Broken Link Checker found broken links on https://andrewwegner.com

[View Results](https://github.com/AWegnerGitHub/awegnergithub.github.io-content/actions/workflows/check-broken-links.yml)

_Use search filter `─BROKEN─` to highlight failures_

The top metadata defines the issue title, and any labels or assignees I want to set up. I'll probably add myself as an assignee once I'm happy with the stability and reliability of the checks.

You can see what an issue created with this template looks like in the repository.

Environment Variables¶

The last section, I've alluded to already - the environment variables. I have two currently defined.

env:
    WEBSITE_URL: "https://andrewwegner.com/"
    ISSUE_TEMPLATE: ".github/workflows/check-broken-links.md"

The first is to set the domain I'm scanning. Mine, obviously. The second is a link to the issue template that is utilized if broken links are discovered.

Things I learned¶

While setting this up there were a few things that I learned or desired that were not immediately obvious while reading documentation. The first was that GitHub actions aren't triggerable without setting up the appropriate on event type. In this case, I want to occasionally run the link checker on command, instead of once a week. That means I need the workflow_dispatch event and it needs to be empty.

on:
  schedule:
    - cron:  '12 1 * * 5'
  workflow_dispatch:
env:
  WEBSITE_URL: "https://andrewwegner.com/"
  ISSUE_TEMPLATE: ".github/workflows/check-broken-links.md"

Notice that the empty workflow_dispatch has no other parameters. It can accept some, if I wanted to provide input to the script at run time, but I have no need for that right now. So, mine remains empty.

A couple nice to haves, that I wasn't able to immediately figure out were how to retry a failed link "later" in the script. While testing the functionality, I had a run that failed because one image, in one article failed. Checking that article showed that it worked. Checking the log showed that the link being checked worked. It was just the internet being the internet with a temporary blip. I'd love to be able to retry failed links a little later in the run or X seconds later, etc. If it fails both times, assume it's broken and report it as normal. Without that retry, I'm a little worried this is going to be fragile, which is part of why I haven't populated the assignee metadata in the template yet.

Another nice to have would be a way to embed the broken links (and page they appear on) in the issue itself. I couldn't find a way to accomplish that with the current tooling, so the template links to the log and you have to search for the appropriate string.

Like I mentioned earlier, I will likely look for a more up to date tool. Or build my own. I'm interested in learning more about how GitHub actions work and this may be a good usecase for myself.

Updating the design of the site

2022-11-17T10:00:00-06:00

Welcome to the update!¶

I have a new theme for the site, and I think it looks great! This is a heavily modified Flex theme. I talk about the changes I made to the theme below, as well as my goals for the site going forward. A new theme isn't going be responsible for hitting all of those goals, but I think it will help. The site was pretty bland before. It did what it needed to do, but it didn't look the best doing it. My skillset is not front end development, but I am rather proud of the new theme and the changes I put in place.

If you're curious about what the site used to look like, jump down to the Where the site was section.

The default version of the Flex theme can be seen on it's demo site, to give you an idea of the changes I've made to my instance.

Look & Feel¶

The logo is perhaps the most subtle change. It's designed, intentionally, to not be a circle (too common on other sites) or a square (too boring). It's an off shape blob. Take a look at it. It very slowly shifts too. You can see it along the bottom of the shirt most clearly. It's designed to move only a little and pretty slowly, so that it's not distracting. It's just active enough to catch your eye if you are looking but not designed to pull focus from the article you are reading.

The default flex theme is very...neat. There are nice crisp lines. It's very clinical. I changed this just a little with a splash of a curved red border between the side bar and the main article. It's not a major change, but it adds a little personality. Combined with the blob/animated head shot, it makes it feel unique among the flex theme'd blogs I looked at to evaluate if I liked the theme.

A favicon is such a little thing, but I didn't have one with the old theme. Having one now adds just a little bit more of a professional touch and it was so easy to do. The color of the favicon, the side bar, and the responsive bars from the tag and category pages all match.

ToC¶

The table on contents on the side bar is an addition I made, because I dislike when the table of contents scrolls off the screen. It's the same reason I froze the table of contents to the side bar on the previous iteration of the site. When I'm reading, I like to know how far I am in an article and be able to easily jump to another section. Since I am also a reader of my site (especially on the technical posts), I try to make it easy for myself too.

Tags/Categories¶

The tags and category pages on my old site were bad. They were a giant list of meta-data and a link to a post. It was messy. I didn't like it, but I also didn't use it so I spent very little time trying to make it work better. With a new theme, I wanted to make the pages more useful, at least to me. I found an excellent post by John Paton on how to make a responsive bar chart for these pages.

Take a look at my tags or categories pages. To me, that looks wonderful. I can get a quick look at how many articles are in each section and clicking on one brings me to a page specifically for articles in that slice of meta-data.

SEO¶

Before you run away...this is a good thing, and I've been doing it for a while. All of my reviews, have been sporting Schema.org Review microdata for years. My blog posts have been sporting Article microdata. This was all hard coded into my template. It was beyond time to update to utilize JSON+LD and provide even more context to the topics I write about.

Initially, I selected Flex because it claims to support Rich Snippets. My results on that are fuzzy, at best. The snippets provided are not full rich snippets. However, they provided a great base. I've updated my instance to support JSON+LD for Person (click view source on my About Me to see it), Article, Review and Breadcrumbs (see the navigation bar at the top of this page). Search engines use all of that to get a better idea of what's on the site. I have a few more I want to implement too, but this gets me beyond parity with my old theme.

I've also made sure that canonical links are included in my articles. I have a couple that Google sees as duplicates due to UTM tags I stuck on links a while ago. Having canonical links in place should resolve some annoying errors and warnings I see in my search console.

Goals of the update¶

I have a few goals with this newly updated site. A couple relate directly to the theme, and a few are general site goals.

Updated Tool set - I was running an old version of Pelican and missed out on some new features. By updating, I'm hoping that I can remain closer to the current release. I like to get the newest features, and that alone feels better.
A useful tags and categories page. Like I mentioned above, they used to be useless. Now, there is more than just a list of 1-2 word phrases sitting on my site across two pages. If I start another series - I believe I have two right now total, I may add a similar series page.
Site face lift. As you can see below, the old version was pretty bland. This update adds some color, makes a few things more accessible, and generally feels less like reading a sheet of paper on a screen. It's not the flashiest thing on the internet, but you can see by my social media links to the left, that I'm not that type of person anyway.
Better SEO. Obviously a template doesn't immediately solve this problem, but it will help. Plus some other plans to add more content (gasp!) and it should help. Right now, though, "Andrew Wegner" returns this page 9th on Google. It's behind someone with a different last name spelling, someone with a different first name, and a few other "Andrew Wegners". While search for a job, I couldn't depend on my site being the one that was clicked.
Lastly, a vanity goal, is to get a Knowledge Graph when searching for my name. It'll take a while before I can get there, but some of the SEO work I'm putting in now will, hopefully, pay off.

Where the site was¶

One last trip down memory lane, as the template that has served as the base of the site since the initial migration from Wordpress in 2015 is retired. The old template was using Elegant. I am the #7 contributor to the theme at the time of publishing this. That's not saying a whole lot, with my brief spurt of activity in 2019, but it was a contribution that I hope others using the theme are able to utilize.

I was stuck on the Pelican 3.0 branch. I really don't remember why. I remember attempting to upgrade to Pelican 4.0 and everything broke. At the time I was unable to spend a significant time to fix it, so I rolled back and stuck with the latest version that ran.

Going through this revamp, I upgraded to the latest Pelican, the newest Markdown and got all the new fancy things. We'll see if they actually improve my experience. From a user stand point, not much should change other than a visual overhaul. It's a static site and is designed to be pretty non-interactive. On my side though, I'm hoping things are a little less brittle.

On to the last pictures of the old template.

The Old Home Page:

A few other screenshots of the old site sit here:

Autobuild and Deploy this Pelican Blog

2018-11-15T08:30:00-06:00

Introduction¶

Several years ago, I migrated from Wordpress to Pelican for this blog. I set it up to run on GitHub Pages. I've been happy with that set up. I can modify my template as needed (which is infrequent), I can publish a post relatively easily and can write the entire post in MarkDown.

There was room for improvement though. The way I originally set it up required me to push to two different repositories every time I wrote a new blog post. Once for the MarkDown file and images, and once for the generated HTML. I wanted to eliminate the need for me to perform the second step.

Previously on this blog¶

Previously, this blog was broken into two repositories. One was the "source" and one was the generated HTML. In my development environment, there was also my local theme and a clone of the Pelican plugins repository, but I never formalized these into curated repositories. The generated HTML was a submodule of the source repository and was placed in the output directory. I used the following command to generate HTML each time I created a new post

pelican content --output output --settings publishconf.py

Using my settings, this would generate my HTML in the output directory. After this was generated, I'd push the content repository which had a .gitignore rule to ignore the output directory, and then I'd push the output directory.

With all of this, I had a requirements.txt document so that I could theoretically generate a post from anywhere, but I failed to keep that updated and in sync with my development environment. On more than one occasion, I tried to write a post on my laptop (not my usual development machine) and failed due to the mismatched dependencies, missing theme and missing plugins.

My development environment was fragile and couldn't be replicated with what I'd posted on GitHub. I'd also forgotten to push the output directory on more than one occasion, which was annoying.

I set out to change all of this with the following goals:

Only a single push to GitHub would generate and deploy the HTML for this blog
I should be able to clone the appropriate repositories and generate content locally in an emergency
It'd be nice to have true separation between the content of the site (the MarkDown articles) and the source code

Warning¶

Earlier this year, I made a public post about how poorly Travis CI handles secure environment variables. The public GitHub issue hasn't been worked on yet. The two issues identified still persist:

Secure variables can be shown via simple string manipulation from a malicious commit
Secure variables are transferred to a third party if the repository is transferred

I feel that they still need to be addressed. They are security issues.

That said, I am using a Travis CI secure environment variable in my deployment script. It is the GitHub token used to push to the repository that contains generated HTML. I have chosen to do this because I am the only one that will be committing to the repository and will not be transferring it to a 3rd party. This is a personal site.

There are alternatives if you don't like the idea of storing your token with Travis CI. I've accepted that risk, even though I believe the issue should be fixed as soon as possible.

Improved Deployment¶

With my goals in place, I started with the "nice to have", because...this isn't work and I can prioritize how I want. I split my blog into three repositories:

Content¶

The content repository is the one repository that I commit MarkDown to. This would be the repository that triggers new deployments and would be the one that changes most frequently. Other than a single .travis.yml file, the only thing in this repository would be content that is used on the site. It'd be my MarkDown articles, associated images, and meta files (robots.txt, and verification files) but wouldn't contain any Pelican code, plugins or theme information.

Source¶

The source repository is where Pelican source code lives. This repository already existed in my first iteration of the blog. I needed to pull out the content and output directories and add in the theme and plugins that had only existed locally. I also updated requirements.txt to contain all of the dependencies I needed to generate the site correctly. I am pretty embarrassed to admit that I hadn't updated this file in almost three years, except to fix a plugin that had broken.

I had Pelican pinned to an old version that I hadn't used in over a year and I was missing dependencies that the Pelican plugins required. This took a lot more time to hunt down than I expected, and it's entirely my fault for not keeping this updated over the years. Fortunately, with the setup, I have to keep this updated or the site won't generate correctly.

Generated Content¶

The last repository is the one that holds the generated HTML for this blog. This already existed and continues to serve exactly the same purpose as before. The only difference is that the content should be pushed to this repository automatically.

Set up¶

GitHub Token¶

With the three repositories set up and content committed to them as appropriate, the next step is setting up the single Travis CI environment variable we'll need. This will be the Personal Access Token used to commit to the generated content repository.

To do this, navigate to GitHub, select your avatar in the upper right, and select "Settings". On the left, select "Developer settings" then "Personal access tokens".

Click "Generate new token" and enter your password as appropriate. Provide a useful description for your token and under the repo scope, select only public_repo. If you are planning on committing to a private repository, you will need to select the entire repo scope. Since my generated content isn't hosted in a private repository, the public_repo is enough. Select "Generate token" at the bottom.

You will be presented with your token. Copy this someplace, you won't be able to access this value again.

Travis CI Environment Variable¶

Now, this token needs to be accessible in Travis CI. Navigate to Travis CI and find your content repository. Under "More Options", on the left select "Settings". Scroll down to "Environment Variables". In my deploy.sh script, I use the variable GITHUB_API_KEY, so that is what I'll use here too. Enter the variable name and the token GitHub provided in the previous step. Do not change "Display value in build log" to true and press "Add".

deploy.sh¶

The next step is configuring the deploy.sh script in the source repository. For my configuration, all that is needed is changing the GH_USERNAME variable to be the name of the user hosting the blog. Still, there is more to the script, if you find this and wish to make changes.

There are a few areas that may be important. The first is that pushes to the generated repository are done with the username "Travis CI" and an associated Travis CI email address. Change these as you wish. I didn't want them in my name, so that I could easily pick out which commits I did versus which ones were done automatically. The old commits in my name vs. the new automated commits look like this in GitHub.

Another important line of code is this one in the deploy script:

git push -fq https://$GH_USERNAME:$GITHUB_API_KEY@github.com/$TARGET_REPO &>/dev/null || exit $?

This line pushes the generated site to the appropriate repository using the GITHUB_API_KEY we previously generated and told Travis CI about. It also sends all output of this command to /dev/null so that the secure key won't show up in the build log. If this isn't done, Travis CI will print out the command and may or may not properly obscure it (see my previous warning, above).

The deployment ends by pinging Google and Bing with my sitemap.xml. This is an automated way of telling the two search engines that the site has been updated and they should recheck the sitemap and reindex as appropriate. It doesn't guarantee they will crawl the site immediately, but it does let them know there is an update before their next scheduled crawl.

.travis.yml¶

Lastly, we need to tell Travis CI what to do when there is a commit made to the content repository. The only non-content file in this repository is .travis.yml.

Right now, I have it building against Python 3.5 simply because that is the version I have installed and utilize most often. There is no reason this blog wouldn't generate against 3.6 or 3.7. I'm pretty sure all of the dependencies will also work against 2.7 right now too.

It will only build when I commit to the master branch. I don't use other branches right now, but if I ever do, they won't trigger a build.

The important bits are in the before_script and script sections.

before_script:
  - git clone https://github.com/AWegnerGithub/awegnergithub.github.io-source.git source
  - mkdir source/content
  - rsync -av --progress ./* source/content --exclude source
  - cd source
  - pip install --upgrade pip
  - pip install -r requirements.txt
script:
  - pelican content --output output --settings publishconf.py --verbose

In before_script, I clone my source repository containing all my Pelican settings into the source directory. Next, I add a content directory into this newly created source directory. I rsync my content to this directory and exclude source because you can't recursively copy a directory into itself.

Then, I get my dependancies installed. I update pip and install my requirements.txt. Finally, I execute the same pelican command I previously used and add on the verbose flag, just in case I need to troubleshoot a failed build.

Deployment is done via the deploy block, but all it is doing is calling my deploy.sh script that I covered above.

deploy:
  provider: script
  skip_cleanup: true
  script: bash deploy.sh
  on:
    branch: master

skip_cleanup is important to leave as true so that the output from the script block isn't cleaned up before we deploy.

Conclusion¶

This post should be the first one that is automatically deployed. I'm sure there are improvements I can and will make to my deploy.sh script or .travis.yml over time, but right now I'm happy with how it works. In testing, a deployment is taking about a minute or two from the time I push a new article. This is about how long it took previously, but now I only need to perform a single push.

I'm also happy with the split of my repositories. I was never a huge fan of having content and source code mashed together, but it worked. Now, I can keep the two separate and easily determine where everything is. Template changes are source code, article changes are content. If I make changes to anything other than content, I can trigger a rebuild within Travis CI with the click of a button. If I am just adding an article, I just need to wait a few minutes for it to be built and deployed. Hooray for automation!

One other thing this split may have done is make it easier to eventually add comments to the blog. That's been a long term goal and one that I've investigated off and on over the past three years. Since I host everything via GitHub Pages and don't have a database, comments would probably need to be done via GitHub comments somehow. I have ideas, but haven't started testing any of those yet. This split will make it easier, I think, when or if I investigate further.

How I set up this site with GitHub Pages and CloudFlare

2015-07-09T11:26:00-05:00

Introduction¶

In a previous post, I described why I moved from Wordpress to Pelican for my blog. This one goes a step further and describes how I eliminated the need for the dedicated server I'd been utilizing as a part of Team Vipers. By eliminating that server, I reduced my costs to zero but kept control over the DNS of my domain (thanks to CloudFlare) and had an easier method of updating the site using GitHub Pages.

GitHub Pages Setup¶

To utilize GitHub Pages, I needed to create a new repository that followed the format GitHubUsername.github.io. This repository would house the content that is this site. I also set up a second repository which contains the source for the blog. This repository includes the templates, plugins and markdown version of the pages. The first repository was set up as submodule.

git submodule add https://github.com/AWegnerGitHub/awegnergithub.github.io.git output

I ignored the output directory in .gitignore on the source repository. Finally, I had to adjust publishconf.py slightly to

DELETE_OUTPUT_DIRECTORY = False

Without this, I was constantly destroying the output repository and had to reinitialize it. This prevents that from occurring.

Now, a new post consists of writing up the Markdown page, generating the page with the command below (or the batch script) and then committing and pushing the changes to the submodule to GitHub.

# Generates HTML files without debugging information
pelican content --output output --settings publishconf.py

The new content is available immediately.

Custom Domain¶

You may notice that the URL for this site isn't awegnergithub.github.io, but instead andrewwegner.com. To accomplish this, I added a directory to the content named extra. In this directory is a single file named CNAME (no extension). In the file is my domain name.

Next, I had to modify pelicanconf.py to add the extra/CNAME to the static path and then on generation move the CNAME file from this subdirectory to the root. I could have put it in the root of content by default, but Pelican provides a way to do this and it keeps content clean. One very important note, the EXTRA_PATH_METADATA is operating system sensitive. Since I am generating the content on a Windows machine, I had to use a backslash instead of the forward slash the documentation shows. I found this after posing a question on Stack Overflow on why it wasn't working as the documentation suggested.

The two important fields to add or edit are:

...
STATIC_PATHS = ['images', 'extra/CNAME']
...
EXTRA_PATH_METADATA = {'extra\CNAME': {'path': 'CNAME'},}

Cloudflare Setup¶

The final thing I needed in order to get rid of my server was control over DNS. I could revert back to GoDaddy, but after a little research found that CloudFlare's additional CDN and security was a "good thing" (because, you know, I'm such a highly traffic'd blog these days). Step one was signing up to CloudFlare. This was a 3-5 minute thing.

Once signed up and signed in, I went to set up DNS. This was as simple as adding my domain name and waiting for CloudFlare to import my existing DNS records. With this, I kept my Google Apps email intact (which is what I was most concerned with). Next, I went and removed the A records. I replaced these with CNAME records pointing to my GitHub Pages URL. I also added a www CNAME pointing to the same location. Since I have Pelican configured to strip it with the setting below, it doesn't matter other than people expect to enter www dot domain dot com in their URL bar.

SITEURL = 'http://andrewwegner.com'

Last, I had to point my name servers to CloudFlare instead of my dedicated server. They provide a list of registrars to choose from. Select your registrar and follow the instructions. My biggest issue here was remembering my GoDaddy password. After I made it into my account, the steps to change name servers were very simple. Once those are saved, you wait for the changes to propagate and enjoy your new GitHub Pages / CloudFlare web page for free.

Why I moved from Wordpress to Pelican

2015-05-03T22:41:00-05:00

Introduction¶

For years, I maintained a Wordpress blog covering various things I've done or created. Most of these revolved around things I created to make administering Team Vipers easier for me and for the rest of the admin team. It was my way of documenting what I'd done (in case I ever needed to do it again) and providing a way to update the Team Vipers community about new plugins or applications that would be deployed to the community.

My Issues with Wordpress¶

The problem I had with Wordpress was that it was just too bulky for the simple posts I was making. I needed a database, a full web server (or a hosting provider), and either time to hunt for the "perfect" plugin(s) or PHP knowledge to do it myself. Early in my development career, I used PHP a lot. That was part of the reason I chose Wordpress.

Oh! I know that language. If I ever need something, I can just whip it up myself.

-Me, before the real world ambushed me and beat me with a stick

Spam¶

I spent time setting up Wordpress. I picked out a theme, plugins, and started saving future me with documentation. Then life happened. For whatever reason, I stopped updating Wordpress. My blog sat out there for weeks or months unvisited by anyone. Then, one morning, my phone vibrated and told me that I had a new comment on my site. Woo!

Except it was spam. Boo!

I marked it spam and moved on with my day. Later that morning, I glanced at my phone again. 32 emails. I am just not that popular. Something was wrong. Turns out, a spam bot found me. I sighed and then removed all the comments and checked the box indicating that users had to be registered to post. That solved my problem for a few months.

Then the bots got smarter. They started registering. They started posting legitimate looking messages, except for that associated URL their name would link to in the comments. They pulled keywords out of the post and formulated a somewhat passable English question using those words. The spam prevention plugins I installed would slow the tide for a few weeks. The bots would adapt and then I'd be awash with spam posts again. Eventually, the solution was to completely disable comments. I'd spent way too much time dealing with spam on a blog that received very little legitimate traffic.

Since I don't utilize the comments, Pelican provides a nice simple page that I can post my thoughts and not worry about getting hit by a spam bot. It also provides plugins so that I can include comments should I ever choose to do so in the future. For the time being, though, I have a nice simple page with no comments. That's exactly what I was looking for.

Security¶

If you watch any technology web sites, you'll notice that there are vulnerabilities found in Wordpress frequently. These require patches, which requires me to do something. It may be as simple as logging in and clicking a button to update, but it is still something I need to remember to do for a relatively minor site. When I'd log in to clear the spam backlog, I'd frequently also install updates for 10-20 plugins, themes or Wordpress itself. It was mostly painless, but I didn't like the idea of the site sitting there vulnerable for weeks at a time because I didn't visit and login.

The dynamic nature of Wordpress and the underlying database exposed a fairly sizable target for a web page so small. Pelican generates static HTML pages. I don't have to worry about SQL injections, unauthorized logins, or anything else. I host a basic set of HTML, CSS and JavaScript files. That's it.

PHP vs Python¶

As I mentioned before, I used to use PHP frequently. It was my go to language. I picked Wordpress with the idea that I'd be able to hack together features I needed. The reality, it turns out, was that I wasn't actually interested in doing that. Instead, I picked out plugins that were close enough to the exact functionality I wanted.

I transferred to a job where I used Python. Instead of having a language I used on the side (PHP) and a job where I was a glorified project manager, without the actual title of "Project Manager", I now had a job where I used a language (Python) for 8 hours a day. My usage of PHP plummeted. I found I could get what I wanted done in my side projects faster and easier with Python. At work I used Python to build tools for engineering problems. At home, I started using it for every day tasks.

Soon, I realized I hadn't used PHP for several versions of the language. My knowledge of the language was outdated. The biggest reason I'd chosen Wordpress was no longer relevant, because I couldn't write anything complicated in PHP without glancing at documentation to do even simple things. It's sad that I lost the intimate knowledge of a language, but I feel that I've been more productive with Python anyway.

Pelican is written in Python. Even more importantly though, it generates HTML files which are hosted. I don't need to run a Python environment on a server. I just need to host HTML files.

Markdown¶

Finally, I've fought with Wordpress's text editor countless times. This happened most often when attempting to add code blocks. It was a pain to do. It was a pain to fix when the blocks broke. Pelican supports Markdown. Markdown is supported by large organizations like GitHub, reddit and Stack Exchange. I use all three of those. I know how to utilize Markdown to create code blocks, headers, insert images, create bulleted lists. All without needing to fight how the text editor is going to actually save the data.