Published

Commonplace WordPress theme

I’ve been gradually updating the WordPress theme that powers this site with the help of a very talented designer and thinker, my friend Bec Worth.

It began with conversations about overhauling her own site. She had a few disparate Tumblrs with a ton (and I really do mean a ton) of great references, photos, and more that had accumulated over the years. All of them had fallen in to disuse for one reason or another, but she still felt like some sort of outlet for collecting these sorts of snippets and longer-format writing would be really useful. She brought up the Commonplace book as a particular inspiration. I’d never come across it before but it really resonated.

We continued talking about her site, and I started to restructure my old color-heavy Notebook theme (view in Wayback Machine) to strip out the less necessary functionality, improve the accessibility, etc. I wanted to make it something that could be more widely useful to not just me and Bec, but others as well. The early version of this new theme used variable Work Sans (view in Wayback Machine)

She liked where it was going, so we got her set up on a WordPress instance and used the Tumblr importer to pull in all of that old content. Since then, we’ve been using her log and my site to test out ideas and continue pushing the idea of what a Commonplace Book could be on the web. For more along these lines, I recommend reading her post “What would a Commonplace Book feel like on the web?

What’s next

It’s far from finished. The type is nowhere near as tight as Bec’s designs, I need to spend a bit more time on that! Amongst other things, I need to clean up the table of posts, add a thumbnail view, and improve the gallery block styles. We’re also going to figure out a way of highlighting work and other projects, something that draws a bit more attention than normal posts.

And color! We’d like to make it possible for people to select preferred text colors, maybe on a post-by-post basis or per category. Color is tricky though, I’d like to preserve some baseline of legibility and I’m not sure how much I could do as the developer to enforce that. Also, how do we handle this if we introduce dark mode support? The HSL or LCH color spaces might be helpful.

I’m not planning to submit this to the WordPress theme directory. Right now, this means that installation and updates are pretty manual, the theme has to be uploaded via FTP before it can be installed. Because of that, I’ll eventually set up an update server so that anyone using the theme can perform one-click updates from the WordPress admin area. Note to self: see this article for more on how to do this.

Realistically, people using the theme might want to change up certain aspects of the theme to be more “them”. Instead of adding a ton of theme options like font pickers and that sort of thing, I’d like to encourage people to tinker with it themselves. This is going to require a bit of documentation to point people in the right direction. I’ll probably start with how someone with little-to-no CSS experience could go about changing the font (i.e. upload font files in the Media library then add the necessary CSS lines in the Customizer, or setting up a child theme).

Clearly, it’s a work in progress!

But anyone is welcome to give it a try for themselves. I recommend it if you’ve been looking for a place to keep important references or get thoughts out of your head. Head to the commonplace-wp-theme GitHub repository to download it and read a bit more.

If you do end up using it, we’d love to know.

Published

How I handle proposals 🧐

This post outlines how I handle proposals as an independent web developer, almost the whole pre-project arc including gathering info, writing and sending the proposal, and what happens after it’s sent.

I love chatting about potential projects with anyone who will entertain me, but I can’t stand writing proposals. My goal is to make the process streamlined enough that I hate it a bit less and am able to get proposals out the door much faster.

This is an important topic and something I’m continuously trying to improve. A good proposal lays solid foundations for a project and sets the tone of a working relationship. Sometimes it even helps weed out the people I’d prefer *not* to work with.

Some of this has evolved over years of freelancing, but a lot of it is brand new or newly refined. Moving from the UK to the US has given me the opportunity to reconsider my procedures and improve the commissioning process both for myself and for my clients.

I’m pretty happy with my approach, but I’m sure it could be improved. Also, what works for me may be totally unworkable for someone else. So take this as one person’s perspective, and please share with me if you have other ideas.

Read more

Published

How I handle rates, pricing, and invoicing 🤑

Pricing is a minefield, and I’m not sure I’ll ever feel like I’ve got it totally right. That seems like a drag but on the sunny side, as an independent developer I’ve got total control over what I charge and can continue to adjust it as necessary.

This is where I’m at with pricing methodologies, rates, and invoicing at the moment. Please send me your thoughts if you have other ideas.

Read more

Published

Sorting out WordPress error “Updating failed. Error message: The response is not a valid JSON response”

I moved a brand new WordPress site on to new hosting recently and was confronted by an “Updating failed. Error message: The response is not a valid JSON response” error. Seemed kind of inexplicable, not a lot of info in the console either. I’ve done the same thing a bajillion times with this and other hosting providers and have never run in to this error, so it seems kind of weird.

This issue on GitHub outlines a lot of the potential causes, but this comment specifically sorted out my problem. Turns out you just need to flush the permalinks? Another off-then-on-again type of fix.

I think the WordPress devs might eventually create a more helpful error message for this, but in the meantime this is worth keeping in mind.

Published

WordPress “Upgrade database” process hangs on Laravel Valet

I’m working on a WordPress site for a client that involves importing a whole bunch of their legacy content. I decided to work with a copy of their old database for this. I set it up locally in Sequel Pro, accessed /wp-admin, and was met (as expected) with a “You must upgrade this database”-style screen. I clicked the button and… nothing. Eventually I had a 504 error.

I use Laravel Valet to develop PHP sites locally on my MacBook Pro, so I checked the NGINX error log ~/.config/valet/Log/nginx-error.log for hints about what was going on. I repeatedly saw an error along these lines (highlighted bits are altered by me to be more generic):

YYYY/MM/DD HH:SS:MM [error] 52486#0: *14 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 127.0.0.1, server: , request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://unix:/Users/username/.config/valet/valet.sock", host: "hostname"

I searched online and found a bunch of suggestions, about checking the valet.sock file, about increasing the fastcgi settings in the NGINX config, etc. Nothing seemed to work.

I then came across this issue which sounds super similar, and they seemed to resolve it with a reboot.

Worked for me too. Turn it off and on to the rescue again. Wanted to mention it here in case anyone else is banging their head against the wall at some point.

Published

Use Portfolio Starter to create a personal site with projects, pages, and posts

Screenshot of Portfolio Starter

This tutorial will teach you how to set up a personal website using Portfolio Starter, a starter kit for portfolio-driven websites made by Sam Baldwin and me. Check out the demo site to get a feel for how it looks, and visit the GitHub repo for more on how it works.

The tutorial is geared towards people that have little-to-no coding experience and are unfamiliar with things like GitHub, Eleventy, and Netlify. By the end of the tutorial you should understand terms like “repository” and “static site”; you’ll be able to edit your projects, pages, and posts; and your website will be hosted for free. Though basic experience with code such as HTML or CSS may be useful, it isn’t necessary for this tutorial since we’ll be using the hosting user interfaces to set this all up.

Let’s get started

Published

CSS note-to-self: `position:fixed;` is not respected within transformed block elements

Note to self: position:fixed; is not respected if the fixed element is within a transformed element.

See a very old meyerweb.com article on the topic. Apparently this is expected behaviour, not a bug, hence why people are still encountering this funkiness nine years after Eric Meyer’s article. As he suggests, it’s a little counter-intuitive!

In my case, it related to a fixed element within a <div> that was being transitioned from off screen to on the screen. I was able to get around it by reversing the transform so that when the element needed to be fixed, I set the containing element to transform: none;. That wouldn’t work in every case though, so YMMV.

Published

A web color space that respects *real* lightness

Lea Verou just published a blog post about the LCH color space. This is super exciting, see her post for detail. Specifically, the improvement has to do with the perceptual uniformity and lightness being visually consistent no matter the hue.

The best way to get a feel for this is to experiment with her LCH color picker. Drag the hue value back and forth, and you’ll see that the tonality of the background remains consistent. It doesn’t suddenly feel a lot lighter in yellow than it does in blue. Do the same thing in an HSL color picker and you’ll feel the difference.

This would help a lot with the color on my site. I’ve never been 100% happy with how the color is handled because it is too hard to control the lightness and thus the legibility. See the List page for a clear example of this, posts in June and February are particularly hard to read. LCH would solve this!

Published

Using CSS, HTML, and maybe a little logic to display images with a consistent surface area

Every once in a while, I have to figure out how to display images on the web with a consistent surface area. It’s usually in relation to making a lot of logos with very different aspect ratios look evenly sized so that none of them stick out like a sore thumb.

I haven’t had to do this in a while but came across a tweet by Nick Sherman that prompted me to think about it again.

To achieve an evenly-sized group of images, you have to calculate a maximum width that is proportionate to the surface area you want. To do this, you need to be able to calculate a square root, you need the width and height of each original image, and all of your images need to be tightly cropped since extra negative space will throw things off visually.

In the past, I’ve achieved this with logic since vanilla CSS doesn’t currently support a sqrt() function (more on this later). I’ve usually used PHP since I tend to work with Kirby CMS pretty often.

The function in PHP:

function max_img_width($img_width, $img_height, $ideal_area) {
  $max_width = round($img_width * sqrt($ideal_area / ($img_width * $img_height)));
  echo $max_width;
}

And the function in use + corresponding HTML:

<img style="max-width: <?php max_img_width(1500, 3000, 40000); ?>px;" src="https://piperhaywood.com/my-image.jpg">

A CSS-only solution that works now

There seems to be a CSS-only way to go about this though. Apparently you can approximate square roots in CSS by using a series of CSS variables and calc(), see more info in this thread.

I will warn you: this is ugly. Also, it heavily relies on CSS variables which may or may not work for you depending on your browser support requirements. Here’s the CSS and the image markup:

img {
  --width: 0;
  --height: 0;
  --ideal-area: 40000;
  --area: calc(var(--width) * var(--height));
  --ratio: calc(var(--ideal-area) / var(--area));
  --guess01: calc(calc(var(--ratio) + calc( var(--ratio) / var(--ratio))) / 2);
  --guess02: calc(calc(var(--guess01) + calc( var(--ratio) / var(--guess01))) / 2);
  --guess03: calc(calc(var(--guess02) + calc( var(--ratio) / var(--guess02))) / 2);
  --guess04: calc(calc(var(--guess03) + calc( var(--ratio) / var(--guess03))) / 2);
  --guess05: calc(calc(var(--guess04) + calc( var(--ratio) / var(--guess04))) / 2);
  --guess06: calc(calc(var(--guess05) + calc( var(--ratio) / var(--guess05))) / 2);
  --guess07: calc(calc(var(--guess06) + calc( var(--ratio) / var(--guess06))) / 2);
  --guess08: calc(calc(var(--guess07) + calc( var(--ratio) / var(--guess07))) / 2);
  max-width: calc(var(--width) * var(--guess08) / 2 * 1px);
}
<img style="--width: 1500; --height: 3000;" src="https://piperhaywood.com/my-image.jpg">

I’d want to do some more browser testing since this results in a pretty gnarly calc() situation by --guess08, but at first glance this seems like it might be a worthwhile solution. It doesn’t give us exactly proportionate surface areas but it gets very close. It only starts to fall apart with super skyscraper-y and letterbox-y images.

A few quick notes regarding why this is written as it is and ways that it could be tweaked:

I capped the number of guesses at eight because any more seemed to just fail, Chrome and Safari wouldn’t interpret such a big calc() equation.

I set the default width and height to zero so that there is no max width restriction if the image tag is missing the width and height CSS variables. This could be changed, as could the ideal area variable (increase to get larger images, decrease to get smaller).

The 1px value in the max-width calculation is required so that the value is interpreted as a unit. That said, it doesn’t have to be pixels! Could change this to another unit like 1em or 1%.

If I wanted to display these evenly centred, I’d probably give the images some margin and then wrap them in a container with styles as below:

.container {
  align-items: center;
  display: flex;
  flex-wrap: wrap;
  justify-content: center;
}

Could also use CSS grid for a more consistent spacing result.

And a final reminder: this only visually scales the images. Try to avoid loading a 3000px wide image if you’re going to be displaying it around 200px wide, your users and the planet will thank you.

A CSS-only solution that might work in the future

So apparently more complex math functions including sqrt() might be coming to CSS in the future! See this issue raised by Lea Verou in the CSS specifications editor’s drafts repo and the exponential functions section from CSS Values and Units Module Level 4 in the W3C editor’s draft from 3 February 2020 (a couple days ago!).

I’m not sure when this would become part of the spec and no idea if / when the browsers might implement them, but here is a snippet that should work with that new function in theory:

img {
  --width: 0;
  --height: 0;
  --ideal-area: 40000;
  max-width: calc(var(--width) * sqrt(calc(var(--ideal-area) / calc(var(--width) * var(--height)))) / 2 * 1px);
}

I’m happy that Nick asked the question on Twitter, I actually need this on an upcoming project where I’ve only got Twig to work with which doesn’t support square roots, and I’d prefer to avoid JavaScript in this instance. Hopefully this is the solution, will update here if so.

A picture says a thousand words, so see Nick’s very nice demo of area-based image sizing with CSS to check out one possible outcome.


Edit 05.02.20

Edited a few words for clarity, added Nick’s demo, added future example incorporating a CSS-based sqrt() function.

Thanks Sam Baldwin for bringing future math function support in CSS to my attention!

Edit 06.02.20

Simplified the PHP + HTML example.

The original PHP + HTML example used a --max-width CSS variable instead of just applying a max-width directly. I used a CSS variable because I thought that they were compliant with a strict Content Security Policy that includes the style-src directive set to unsafe-inline. That assumption was incorrect, though there does seem to be some discussion about the topic.

Thanks Lizzie Malcolm for questioning the CSS var usage in the PHP example!

Edit 18.02.20

Changed parenthesis-enclosed arithmetic so that each is enclosed in calc(). Plain CSS seems to interpret arithmetic enclosed in parenthesis just fine, but SASS doesn’t seem to like it.