Overview on How to Use the W3C Link Checker

I thought I would write up how I’m checking broken or redirected links on my website. Or more importantly, on my list of places to eat at Gotta Eat Here.

For many years I have been using the W3C Link Checker to check one page/URL at a time for Gotta Eat Here or many on my website or slides.

The tool has a few options that you can play around with, but I leave them as the default. You can even check a box to save the options as a cookie, which I assume stores your choices if you decide to use them.

The one option I use would be the “Check linked documents recursively, recursion depth:”. That has an INPUT field of how many levels you want to go down in your website.

After entering a URL in the URL field, you can decide if you want to check more than one page or not. To do so, then check the “Check linked documents recursively, recursion depth:” field. NOTE – You can only check pages that are not behind a firewall.

I can’t remember exactly, but it used to let you check 200 or 250 pages at once time. This is great if you want to submit it and let it wander through your website looking for broken links.

I use that feature when I’m checking my entire website. You can also submit your website in chunks using the folder structure you have set up and start with them.

I haven’t paid attention if doing so will jump out of that folder. or not if links go to other places in your website. Here’s hoping there’s an option for that in the list of checkboxes.

How it works is the W3C Link Checker goes through all the links on a page. The tool will tell you if the link is broken or redirected, not allowed to be checked by tools like it, etc. An example would be Google maps does not let you check or Twitter, etc.

For the redirected links, it’s great to point out issues on your website. For example, that a Twitter link might still have the URL as HTTP instead of HTTPS.

I have found that most redirect issues are either the website is now using HTTPS, or they changed platforms. Meaning they switched to PHP from HTML or something like that. Or maybe the website in the case Gotta Eat Here the restaurants got better URLs. That is either shorter and easier to remember or got they got the .COM of what they used to have.

The W3C Link Checker gives you a summary of how long it took to check all the links on a given page or set of pages. The report lists the page(s) it’s processed and what it found. Then at the end, it has a total time to process is doing more than one page.

Using the W3C Link Checker is excellent for the Gotta Eat Here website. It allows me to check my list of restaurants, be that by city or state. The tool gives me an idea that the place might have closed during the pandemic if the URL is broken.

How I’m Using GitHub

I have had a GitHub account since March 6, 2013, but I never used it until much later in 2016.

I started working on a list of places to eat when I traveled and using GitHub to backup/store my code.

First GitHub Use

My first use of GitHub was on September 30, 2016, when I created my first repro for the place to eat project. At some point, I purchased the domain name GottaEatHere.com to put the information on. I bought a bunch more domains because I wasn’t sure what I wanted to call the application.

Reason for Using GitHub

The reason I started the project was for the An Event Apart and Microsoft 10K Apart contest. Besides, people had been asking me for recommendations of where to eat. So I figured I build a small web-based application to kills two birds with one stone. The contest was where people had to build an application in less than 10 kilobytes (KB) of code.

I spent some time upfront figuring out how best to do that. I wanted to learn PHP or at least get better at it, so that’s where I started.

Planning the Application

My first thoughts were I would need two or three Kb for CSS. Then another three Kb for my HTML template, and the remaining Kb for logic to render the pages content.

I decided to use JSON files because I wasn’t sure if a database would count against the total of 10 Kb. Which allowed me to learn something else new too.

I worked to get my PHP application to render a list of five or six cities, and I think five restaurants I loved going to. Each city had its know JSON file, and they were half Kb in size or something like that.

The 10 Kb or less version of the application had a lot less information per city and restaurant. I think it had a name, address, phone number, URL, and a short description. Now it has a bunch o other information.

A person chooses a city was from a drop-down list. Then the PHP would read the JSON file for the city that a person picked. Then render the restaurants for that city. Nothing fancy, but it got the job done. I didn’t expect to win anything, and I didn’t.

Of course, the whole time, I was making sure it was as accessible as possible.

Using GitHub Daily

On November 18, 2016, I started making more commits to add more places to eat along with more cities, along with information.

November 18th was the day I started making at least one commit or added an issue to GitHub every day. It might have been for new fields, cities, states, etc., to GitHub every day.

Over the last four and a half or so years, I have only missed doing something on GitHub about a dozen times. So that works out to three or four times a year. I’m okay with that and don’t lose sleep over it if I do. Some of the updates and issues were related to my slides, and others were for code examples for the slides.

My use of GitHub is still through their desktop application. It lets me create new repro’s, create issues for new features, cites, restaurants, etc.

With only me working on the projects, I have not had to worry about creating branches, merging others’ code, etc. At some point, I need to learn how to do that through the application or the command line.

Need to Learn More Git

So here’s to learning more Git. Be it through the GitHub application or, more importantly, through the command line.