Published

Notes from MozFest 2019

This is super delayed! I typed up my rough notes right after MozFest finished in October but never pressed publish. Voila.

MozFest is 10 years old! This was their last year at Ravensbourne in London. Sad, but I’m excited to see where it heads next.

This is a haphazard brain-dump of everything I want to remember and follow up on, a lot of questions for future consideration and resources that I need to explore. See also Common Knowledge’s notes from MozFest written by Gemma Copeland.

Read more

Published

Enabling Imagick extension with Laravel Valet

Edit 4 February 2021: I was just revisiting this and realized that an important bit of the mkdir command below was partially missing. 😅 Apologies to anyone who ran in to confusion because of that!

After setting up Laravel Valet and MySQL with Homebrew a while ago, local development has been pretty smooth sailing. Today though, I ran in to some trouble getting the Imagick extension up and running. After some searching online, this discussion thread got me going in the right direction.

I had Homebrew and pkg-config installed already, so the first thing I did was install ImageMagick with Homebrew by running brew install imagick. Next, I installed the Imagick extension with PECL by running pecl install imagick. It’s worth keeping an eye on the output related to this installation. At the very end of the output, I got this error:

ERROR: failed to mkdir /usr/local/Cellar/php@7.2/7.2.19_1/pecl/20170718

Someone else in the discussion thread ran in to a similar problem, so I roughly followed their directions.

I ran pecl config-get ext_dir to get the extensions directory that the PECL config expects, then I copied that output and ran mkdir -p copied_directory (of course please replace copied_directory width your output) to create the necessary directory myself. I then ran pecl install imagick again, and this time there were no errors, likely since it no longer had to create the directory. Note that the output from this successful installation ended in Extension imagick enabled in php.ini.

To wrap it all up, I ran valet restart and then ran php -i | grep Imagick to check that Imagick Imagick in the PHP configuration. It returned a few lines in relation to classes and the ImageMagick version indicating that everything was set up as necessary.

Note that this only applies to the PHP version that is currently in use by Valet. I use a few different versions depending on the project, so I’ve repeated the pecl install imagick step for each of those versions as well.

Published

Notes from Redecentralize 2019

Been a busy few days with Redecentralize on Friday followed by MozFest over the weekend. Redecentralize was a one-day unconference at 4th Floor Studios in Whitechapel. The event was expertly organised by Ira Bolychevsky and her crack team.

It was a day of thought-provoking conversations and notebook scribbling. This is an attempt to decode the scribbles, make some follow-up plans, and to generally summarise the day from my perspective. There was a lot going on so I can’t cover it all, but I’m going to keep an eye out for other people’s notes via the Redecentralize newsletter.

\              \                      \                   \
\\\   \   \    \\            \        \\       \       \  \\
\\\\\ \\\ \\\  \\\   \    \  \\     \ \\\  \   \\  \   \\ \\\ \
\\ \\\\\\\\\\\ \\\\ \\\\  \\\\\\   \\\\\\\\\\\ \\\ \\\ \\\\\\\\
\\   \\\  \\\\\\\ \\\\\\\\\\\\\\\\\\\\\\ \\ \\\\\\\\\\\\\\\\  \
 \     \    \\  \   \    \\\  \  \\\   \  \   \\\ \\\ \\\  \   
              \            \       \            \   \   \

Read more

Published

Configuring and troubleshooting Netlify Large Media

Sam and I were working together to debug some issues encountered while configuring Netlify Large Media for a particular repository. It’s a *very* cool option when it comes to media for static site generators, particularly since it allows you to transform images. This is a run-down of the process, including a few specific snags we hit along the way.

Read more

Published

Setting up Laravel Valet + MySQL via Homebrew

After far too much delay, I’ve finally ditched MAMP Pro. 🎉

I’m now trying Laravel Valet + MySQL via Homebrew for local PHP development on my MacBook Pro. The notes below are an account of the steps I took for future reference. There were some fiddly points getting started and I expect there to be more, but I’m pretty pleased with the swap overall.


0. Back up databases

The pre-step is to back up any preexisting databases so that you can set them up later if needed. Personally, I use Sequel Pro for all local and some remote database management, so I pulled my necessary exports from there.

1. Install and configure Laravel Valet

The first step is to install Laravel Valet. Their installation docs are pretty much all that is needed. The only caveat is that I’d be a little careful about updating Homebrew or Composer willy nilly, just be wary if you already have it installed and need your preexisting version for any reason. While completing the installation steps, pay attention to the warnings! Complete any recommended steps if you can, they pop up for a reason.

If all went well, at this point you should have an Apache server so you’d be ready to work on a file-based website such as one that uses Kirby CMS or a static site generator (Hugo, Gatsby, Jekyll, etc).

2. Install and configure MySQL with Homebrew

To work on a database-driven site like a Craft CMS or WordPress build, the next step is to install MySQL via Homebrew.

The Laravel Valet docs mention this step, but for me it was nowhere *near* as simple as their two-command recommendation. I think there was likely a conflict with my preexisting MAMP-specific MySQL setup and possibly an old Homebrew installation. I ran the commands from the Valet docs to install MySQL v5.7 and run it, but I would get the error The server requested authentication method unknown to the client [caching_sha2_password] on the front-end. This error indicated that it was actually running MySQL v8 (read more). Sure enough, mysql --version returned mysql Ver 8.0.16 for osx10.14 on x86_64 (Homebrew). To sort it out, I had to reinstall and restart the MySQL service.

To remove MySQL, I followed these instructions. (Be careful with those commands, they remove a lot of stuff.)

After I’d gotten rid of MySQL, I ran the Homebrew commands below to install, link, and start the service.

brew install mysql@5.7
brew link --force mysql@5.7
brew services start mysql@5.7

Note that I tried doing this without the link but consistently ran in to the error Can't connect to local MySQL server through socket '/tmp/mysql.sock' when trying to connect in the next steps. Linking seemed to sort it.

The Homebrew installation command recommended a step involving mysql_secure_installation which sets the root user’s password. We need this for phpMyAdmin and Sequel Pro (coming up below), so I completed this step as well.

3. Set up and / import databases

Once MySQL is set up and running, it’s time to set up your databases. Check out this article for some useful instructions on how to create a user and database on the command line. To import one of your SQL exports from earlier, run mysql -u [username] -p [databasename] < [filename.sql] replacing the bits in brackets with your username, database, and filename. When prompted, enter the password you set up via mysql_secure_installation.

Otherwise, you can do add your database via a UI such as phpMyAdmin (see Laravel Valet-friendly steps) or Sequel Pro.

4. Adjust PHP settings (optional)

I usually adjust my PHP settings (e.g. memory_limit, max_execution_time, post_max_size, etc.) to something that is similar most of my sites’ production hosting environments. Ideally this would be less manual (Docker? Ansible?), but that’s exploration for another day.

I thought that changing the PHP settings would be as simple as adjusting the php.ini file that is specified in the “Loaded Configuration File” value returned by phpinfo(). I edited /usr/local/etc/php/7.2/php.ini and then ran valet restart to restart the server and… it didn’t work. One of my changes was respected according to phpinfo(), but the rest weren’t.

I checked the “Additional .ini files parsed” value and saw that the file /usr/local/etc/php/7.2/conf.d/php-memory-limits.ini was also in use. After I edited this file to include my preferred settings and restarted Valet, all was well.

5. Adjust Nginx config (optional)

Valet’s default Nginx config should normally be sufficient, but you might have to tweak it for certain edge cases.

My edge case was the British Earways site (read more). I was working with it locally and suddenly ran in to a 413 Request Entity Too Large error when attempting to upload a very large audio file. To get around this, I needed to raise the client_max_body_size Nginx directive.

To adjust the Nginx configuration, I first had a look at the main config file by running /usr/local/etc/nginx/nginx.conf. Scanning through that, I saw a few includes:

include "/Users/[username]/.config/valet/Nginx/*";
include servers/*;
include valet/valet.conf;

I had a look at /Users/[username]/.config/valet/Nginx/valet.conf, found client_max_body_size and changed that value to suit my requirements, and then restarted the server by running valet restart.

Other useful things

Run brew services list to find out which services are running. This is useful for troubleshooting if you’re having PHP or mySQL errors.

If you’re adjusting the PHP settings in a .ini file, run valet restart, and then suddenly start seeing only an “It works!” screen where your site should be, you probably have to stop Apache first before restarting Valet. Most guidance online recommends running apachectl stop, but I had trouble with this (see related StackOverflow thread). Instead, I ran valet stop, sudo killall httpd, then valet start. This worked smoothly.

Here’s a list of MySQL commands.

For more info about what $PATH is and why it’s important, see this Unix & Linux Stack Exchange thread or notes on the command line geared towards beginners.

I usually use redirect rules to use media from production when developing locally, for example when working on the WordPress theme that powers this site. Laravel Valet doesn’t seem to play nice with the normal .htaccess method, maybe because it’s actually an Nginx server. See “Proxying images to a remote host on Laravel Valet” for an effective alternative using a local driver.

On an image-heavy project using Craft CMS, I ran in to a 504 error brick wall at one point. Could not for the life of me figure out the problem, even after pouring over the error logs. Ultimately I uninstalled and then reinstalled valet, and that seemed to do the trick.


Edit 10 July 2019 – Added further notes based on working with Laravel Valet the past few days, including the PHP and Nginx config adjustments.

Edit 04 October 2019 – Various small wording adjustments and additional reference links. Used these notes for reference when working with SB to adjust his own setup, and it was clear that some bits could use clarification.

Edit 18 October 2019 – Added note regarding 504 errors.

Published

Preventing email spoofing

Been getting a bunch of targeted phishing emails recently. They’re pretending to be my domain registrar, saying that payment is overdue and they’re going to delete my domain permanently. I’ve received similar things before, but this one of the more convincing and aggressive attempts I’ve seen.

This reminded me about a task on my backlog of TODOs, sorting out my domain’s SPF and DKIM. Both are email authentication methods designed to detect forged sender addresses in emails, a.k.a. email spoofing. SPF + DKIM won’t prevent inbound phishing emails, but they do help prevent my own domain from being spoofed in shady outbound emails.

I’d forgotten to add a SPF record so sorted that out. I made sure to add include values for both my email provider and my web host since the web host is responsible for sending things such as password reset emails from the CMS. Unfortunately, my email host Gandi doesn’t support DKIM. 🙁 So that’s a non-starter.

I’ve been considering switching to Proton though, and happily they offer SPF, DKIM, and DMARC. Maybe I’ll make the switch a bigger priority. Gandi has mentioned that they’re working on implementing DKIM though, so maybe I’ll just check back later this year

Eventually I’ll look in to a DMARC policy, but that’s going to come a little later.

A few links that may be useful:


Edit 21.02.20 – Added link to EasyEngine tutorial b/c I previously was using ?all and received a spoofed email from my domain on another email address I have. *facepalm*

Published

britishearways.com

Screenshot of britishearways.com

Last month, I completed a major overhaul of the British Earways website. The design by Valerio di Lucente of Julia is almost entirely unchanged, the adjustments were largely performance-related and under the hood, geared towards modern browsers. Here’s brief rundown of the changes:

  • Style the full-window player layouts using CSS Grid Layout + 100% height (not 100vh since that can lead to unexpected behaviour on mobile browsers), and use CSS Scroll Snap w/ polyfill for scroll behaviour
  • Achieve flexible typography and spacing with “CSS Locks
  • On non-touch screens, implement invisible DragDealer instances so that each player’s scrubber can be dragged
  • On touch screens, add click event listeners that advance the relevant scrubber to the click target
  • Use styled HTML5 progress elements for each player since these are easily manipulated via their max and value attributes and don’t require adjustment if the window is resized
  • Use the Web Audio API to initialise each audio file and trigger the necessary state changes as the time updates
  • Switch the audio preload attribute from auto to metadata to reduce the size of the page when it initially loads
  • Update CMS to Kirby 3 (this was a joy, IMO the panel layout options make v3 much more client-friendly)
  • Adjust post_max_size, memory_limit, max_execution_time, and upload_max_filesize to allow upload of large (150MB+) audio files

I ran in to one issue that isn’t yet resolved. Kirby copies all uploaded media from the private /content folder to the publicly-accessible /media folder. This copying normally happens almost instantly, even with very large files. On the BE site however, the copy is pretty slow. Since the site pulls the audio duration from the audio file itself via the Web Audio API, the displayed duration is incorrect until the file has finished copying. This is almost certainly related to some rate limiting done by the shared hosting company, a legacy from the preexisting site. It isn’t a huge deal since the copying always finishes eventually, but it isn’t the best behaviour. I’d like to raise the issue with the hosting company but don’t have high hopes, shared hosting providers use rate limiting for a reason.

At any rate, I’m really looking forward to seeing how DB uses the site over the next year and listening to the new mixes.