Forem: Josh Vickerson

Incremental Content Management with Laravel and Eleventy

Josh Vickerson — Thu, 05 Feb 2026 22:24:34 +0000

This is a recording of a talk I presented at the 11ty Meetup on February 4th, 2026. I tell the story of how I used Eleventy to quickly add a blog to an existing website and application originally built with Laravel. It worked so seamlessly, I went from request to working solution in about 30 minutes. After a year and a half of use, what initially felt like an unusual idea has turned out to be rather pleasant to work with.

I think there's a lot of unexplored territory when it comes to combining the simplicity of a static site generator and the power of a full application framework. By mixing and matching tools I believe it's not only possible, but in many cases preferable, to manage a website's content without a monolithic CMS like Wordpress. Instead, we build content management functionality in pieces, constructing the website in such a way that it does the heavy lifting of pulling disparate sources together for you.

I've started referring to this as "Incremental Content Management".

This 30-minute talk focuses on one example of this approach.

Setting App Time Limits on iOS Using Shortcuts

Josh Vickerson — Mon, 29 Jul 2024 19:57:54 +0000

I've become a huge fan of making interactions with my phone more intentional. As I age into my 30's, I find the constant pinging, vibrating and / or screen-lighting of push notifications to be an intense annoyance. I've ruthlessly disabled all but the most critical of notifications, and set healthy time limits for time-sucking apps like Instagram using the built-in settings on my iPhone. As a result, my phone use is more, "when I mean to" rather than, "when I'm prompted to."

But despite setting a 75-minute time limit in Screen Time for Instagram, there was one problem Screen Time couldn't resolve for me: using the entire day's limit in a single session.

Now, I know Instagram has settings for break reminders, but it's not the only app that can become an accidental time suck. Not every app has break reminders built-in, nor should every app have to make them. This is a perfect task for my operating system to manage. I would love for Screen Time to offer more granular controls for app usage. Not just a daily limit, but a session limit with a minimum break time between sessions.

For example, my 75-minutes per day limit for Instagram seems healthy enough. Except when I open it "for 5 minutes" and accidentally spend an hour or more scrolling through reels without fully realizing it, triggering my whole day's limit before lunch. At that point, the damage has been done. I spent a huge block of time mindlessly scrolling, and it completely kills my ability to focus and be productive. Not to mention I generally feel like garbage after such a long span of time with my "brain off" like that.

I wish Screen Time would allow me to change my daily limit from "75 minutes a day" to "75 minutes a day, but not more than 15 minutes at a time and at least 45 minutes apart." This would be a powerful tool in helping people manage consumption of endless-feed apps like Instagram in a more moderate way. Since Instagram, TikTok, etc. are incentivized to have people look at them as much as possible, we can't depend on them adding consumption controls out of the goodness of their hearts. This increased granularity in app usage limits is now the only new feature I want my phone to have.

In the meantime, I've created an iOS shortcut that allows me to achieve the first half of that feature request in any app I'd like. It adds less friction than the Screen Time limit screen, but having used it for a week I've found it incredibly helpful in avoiding getting sucked into the endless feed blackhole in the first place. With this, I've cut my daily average time spent in Instagram from 62 minutes, to 12 minutes. I don't expect it to stay this low, but I certainly feel far more in control of my Instagram consumption which is the ultimate goal.

It's incredibly simple.

iOS Shortcut for App Session Time Limits

All this shortcut does is prompt you to set a timer whenever you open specific apps. Using the Shortcuts app, create an automation that runs whenever specific apps are open to start a timer. You can have it set a specific time limit, or as I opted to, have it prompt you for a time limit each time you open the app.

This, of course, doesn't really try to stop you from using the app in the way Screen Time could. But I've found that the timer going off is usually enough to snap me out of it, and I close the app. Again, Instagram offers built-in settings for this, but this shortcut can be applied to any app I'd like.

And if you're a fan of the Pomodoro technique, this can be a great way to automate setting your timers, if any of your work involves focused work in particular apps.

Okay, enough blathering... Here are the setup instructions, followed by screenshots if you're more of a visual person:

Create a new automation in the Shortcuts app, selecting "App" as the trigger
Choose the app(s) you want to set time limits for, "is opened", and "run immediately"
Select "Start Timer" as the action
Enter a duration, or select "Ask Each Time" from the keyboard (recommended)

Now, whenever you open the apps you selected, you'll be prompted to set a timer. I find this super flexible to be able to set a short limit if I'm just checking messages, or longer limits when I'm specifically taking a break. If I'm feeling particularly disciplined, I'll hit cancel on the prompt and not set a limit.

I hope this shortcut proves as helpful for others as it has been for me!

Side note: I intend to submit this feature request to Apple, as soon as I find the best way to do so. If there's ultimately a place for others to indicate support for this idea, I'll update this post with a link.

Excluding Livestreams from the YouTube Data API in JavaScript

Josh Vickerson — Mon, 20 Nov 2023 21:10:23 +0000

Over the past year, I’ve been working with 8BitJosh to create and maintain a website to showcase his YouTube video content. As a Twitch streamer and YouTube content creator, reaching new audiences can be a difficult task. Josh wanted a website to help make his content easier to find, so that’s what I’ve helped him do.

I turned to Eleventy and Netlify to create a low cost website for content creators. By leveraging Eleventy’s excellent data cascade and the YouTube Data API, I was able to create a simple integration that ensures Josh’s website always features his latest videos. Using the YouTube Data API’s Playlists endpoint, I can readily fetch videos from the “recent videos” playlist on 8BitJosh’s YouTube channel.

While he produces videos to publish on YouTube, Josh primarily livestreams on Twitch. Thanks to a recent policy change, Twitch streamers are now allowed to simulcast to multiple platforms. When this change went into effect, Josh started simulcasting his livestreams to YouTube. As a result, past streams now appear in the recent videos playlist after his livestreams end. For the website, Josh only wanted to feature his produced videos, not past livestreams. This required updating the script that fetches videos from YouTube.

This post details the initial integration I wrote, and the changes required to exclude livestreams from the YouTube Data API. It’s written in JavaScript, and is structured as a module for use in Eleventy’s data cascade.

Fetching Recent Videos from the YouTube Data API

Here’s the initial version of my script, which I saved as a global data file for Eleventy called newestVideos.js:

require('dotenv').config();
const Cache = require('@11ty/eleventy-fetch');

const PLAYLIST_ID = 'PLAYLIST_ID';
const NUM_VIDEOS = 6;
const API_KEY = process.env.YOUTUBE_API_KEY;

module.exports = async () => {
  try {
    const {items} = await Cache(
      `https://youtube.googleapis.com/youtube/v3/playlistItems?part=snippet&maxResults=${NUM_VIDEOS}&playlistId=${PLAYLIST_ID}&key=${API_KEY}`,
      {
        duration: '12h',
        type: 'json'
      }
    );
    return items;
  } catch (ex) {
    console.log(ex);
    return [];
  }
};

If you’re familiar with fetching remote data in Eleventy, this script is probably pretty straightforward. But let’s go through it a few lines at a time.

In the first few lines, we’re doing a little bit of setup. We use dotenv to read an environment variable that holds our API key for the YouTube Data API. This keeps us from storing our API key in the code, which is great for security. We use eleventy-fetch to make the API request, which makes it simple to cache API responses to avoid making too many requests. Then we create a few constants: a string for our playlist ID, the number of videos we want to display on the site, and we read our API key from the environment.

require('dotenv').config();
const Cache = require('@11ty/eleventy-fetch');

const PLAYLIST_ID = 'PLAYLIST_ID';
const NUM_VIDEOS = 6;
const API_KEY = process.env.YOUTUBE_API_KEY;

We’re creating this as an asynchronous function so we don’t block other build tasks, and using arrow function notation since our module only contains this one public method. The request is being contained in a try / catch block so API errors don’t break the build. If there’s an error, we simply log it and return an empty array.

module.exports = async () => {
  try {
    ...
  } catch (ex) {
    console.log(ex);
    // If failed, return back an empty array
    return [];
  }
};

Within the try block, we’re making a request to the playlistItems endpoint, setting the number of results to our desired video count, using the playlist ID and our API key. For 8BitJosh’s site, the playlist ID is for his channel’s recent videos, which the API will return sorted newest to oldest by default, which is precisely what we want. Our API request also includes the part parameter, which is how we specify to the YouTube API what details we want returned. We're requesting the snippet property, which includes details like the video title, date it was published, and thumbnail images.

const {items} = await Cache(
    `https://youtube.googleapis.com/youtube/v3/playlistItems?part=snippet&maxResults=${NUM_VIDEOS}&playlistId=${PLAYLIST_ID}&key=${API_KEY}`,
  {
    duration: '12h', // 12 hours
    type: 'json'
  }
);
return items;

With the above request, we'll receive a response like this:

{
  "kind": "youtube#playlistItemListResponse",
  "etag": "FzfXldAFpYl7qA-fl-t58SyrNYw",
  "nextPageToken": "EAAaIVBUOkNBWWlFRFV6TWtKQ01FSTBNakpHUWtNM1JVTW9BUQ",
  "items": [
    {
      "kind": "youtube#playlistItem",
      "etag": "c6kYc1nwdfWI0aVAuj49856IJfE",
      "id": "VVU4QnJ6NnJXV3hBUUtWZFgxVmV3cjlRLjMza1RDSUVYQV9Z",
      "snippet": {
        "publishedAt": "2023-11-17T14:11:13Z",
        "channelId": "UC8Brz6rWWxAQKVdX1Vewr9Q",
        "title": "Spider-Man Remastered! Playing through the whole series!",
        "description": "Playing through Spider-Man 1, then Miles Morales, the Spider-Man 2!",
        "thumbnails": {
          "default": {
            "url": "https://i.ytimg.com/vi/33kTCIEXA_Y/default_live.jpg",
            "width": 120,
            "height": 90
          },
          "medium": {
            "url": "https://i.ytimg.com/vi/33kTCIEXA_Y/mqdefault_live.jpg",
            "width": 320,
            "height": 180
          },
          "high": {
            "url": "https://i.ytimg.com/vi/33kTCIEXA_Y/hqdefault_live.jpg",
            "width": 480,
            "height": 360
          },
          "standard": {
            "url": "https://i.ytimg.com/vi/33kTCIEXA_Y/sddefault_live.jpg",
            "width": 640,
            "height": 480
          },
          "maxres": {
            "url": "https://i.ytimg.com/vi/33kTCIEXA_Y/maxresdefault_live.jpg",
            "width": 1280,
            "height": 720
          }
        },
        "channelTitle": "8bitJosh",
        "playlistId": "UU8Brz6rWWxAQKVdX1Vewr9Q",
        "position": 0,
        "resourceId": {
          "kind": "youtube#video",
          "videoId": "33kTCIEXA_Y"
        },
        "videoOwnerChannelTitle": "8bitJosh",
        "videoOwnerChannelId": "UC8Brz6rWWxAQKVdX1Vewr9Q"
      }
    }
  ],
  "pageInfo": {
    "totalResults": 542,
    "resultsPerPage": 6
  }
}

The only property we're interested in is the videos themselves, so we’re using destructuring to extract the array of video objects items. We cache this response for up to 12 hours, and return the items.

And that’s it! We now have a usable collection of video objects.

Displaying Remote Data in an Eleventy Template

As a bit of an aside, I wanted to show how this collection is used in Eleventy. Because this module is setup as a global data file, the array of videos is available to us in every template using the name of the file. In this case, newestVideos.

The site uses nunjucks templates, and outputs links to the videos as “cards”. Our template code looks something like this (some site-specific markup has been excluded for brevity):

<div class="video-list">
  {% for item in newestVideos %}
  <a href="https://www.youtube.com/watch?v={{ item.snippet.resourceId.videoId }}" target="_blank">
    <div style="background-image: url({{ item.snippet.thumbnails.high.url }});"></div>
    <h3>{{ item.snippet.title }}</h3>
    <time>{{ item.snippet.publishedAt }}</time>
  </a>
  {% endfor %}
</div>

In this part of the template, we’re looping through newestVideos, and outputting the video thumbnail, title, and publish date inside a link. The live version includes some classes, which are used to style these links to look like “cards”, along with some structured data markup for SEO purposes.

Excluding Livestream Videos from a YouTube Playlist

When Josh started simulcasting his streams, the above version of the script included past livestreams whenever the site was rebuilt. In order to exclude them, the script had to be significantly altered.

As of the writing of this post, the YouTube Data API doesn’t include a native method for excluding livestream videos (that I could find, anyway). In searching for other solutions, the repeated pattern seemed to be that livestream videos need to be filtered manually, so that’s what I opted to do.

To do this, the script is now comprised of three functions.

The first function, fetchFromYouTube handles making the request to our playlist. Because the API response can now include livestreamed videos, there’s no guarantee that we’ll have the desired number of produced videos in our initial request. Thus, we now extract both items and nextPageToken, which the YouTube API will use to handle paging through the playlist in the event we need to make multiple requests.

For this, I added a new constant VIDEOS_PER_PAGE which is the number of videos to fetch from the playlist at a time. This number is significantly higher than the number of videos we try to display to reduce the total number of API requests, and livestreams may occur more frequently than produced videos.

The cache time has also been reduced. With livestreams included, this playlist may update more often than before, plus as you’ll see, we can cache subsequent requests for much longer.

async function fetchFromYouTube(nextPage = null) {
  let url = `https://youtube.googleapis.com/youtube/v3/playlistItems?part=snippet&maxResults=${VIDEOS_PER_PAGE}&playlistId=${PLAYLIST_ID}&key=${API_KEY}`;

    if (nextPage) url += `&pageToken=${nextPage}`; // include page token if provided

  try {
    const {nextPageToken, items} = await Cache(
      url,
      {
        duration: '1h', // 1 hour
        type: 'json'
      }
    );

    return [nextPageToken, items]; // return token to fetch next page and the results as array
  } catch (ex) {
    console.log(ex);
    // If failed, return back an empty array
    return [];
  }
}

The second function handles another request to a different API endpoint. In order to determine if a given video in our playlist is a past livestream, we have to query the videos endpoint to request the liveStreamingDetails. I called this function checkIfLivestreamed.

This function queries for livestream details (which are start and end timestamps from when the stream was live). If a video was not livestreamed, no details are returned.

For any given videoID, it’s either livestreamed or not - this will not change after the video is published. Therefore, the response from this endpoint is cached for two weeks, allowing subsequent builds of the site to avoid duplicate requests for quite a while. An expiration time was added simply to avoid our cache getting overly large with outdated videos.

async function checkIfLiveStreamed(videoId) {
  let url = `https://youtube.googleapis.com/youtube/v3/videos?part=liveStreamingDetails&id=${videoId}&key=${API_KEY}`;
  try {
    // Cache results from an individual video for 2 weeks, this info almost definitely will not change
    const {items} = await Cache(
      url,
      {
        duration: '2w', // 2 weeks
        type: 'json'
      }
    );
    // if liveStreamingDetails is defined, this video was livestreamed
    return items[0].liveStreamingDetails != null;
  } catch (ex) {
    console.log(ex);

    // If failed, return false; assume video was not livestreamed
    return false;
  }
}

With these two functions defined, we’re now able to setup a loop to perform this querying and filtering. The basic logic is:

Fetch videos from the playlist
For each video, check if it was livestreamed
If the video was not livestreamed, add it to our list of videos to display
Repeat until we have the number of non-livestreamed videos we want to display

So, the function our module exports now looks like this:

module.exports = async () => {
  const newestVideos = []; // we'll push video items to this array
  let nextPage = null; // prep var for pagination

  // while we're filling the list
  while(newestVideos.length < NUM_VIDEOS_TO_SHOW) {
    // fetch a page of videos from our playlist
    let ytResults = await fetchFromYouTube(nextPage);
    if (ytResults.length === 0) break; // nothing returned, probably an error, end the loop

    nextPage = ytResults[0]; // save id for the next page if we need to paginate
    let videos = ytResults[1]; // videos

    for(let i = 0; i < videos.length; i++) {
      const videoId = videos[i].snippet.resourceId.videoId;
      // if video is not livestreamed, add it to our list
      const liveStreamed = await checkIfLiveStreamed(videoId);
      if (!liveStreamed) {
        newestVideos.push(videos[i]);
      }
      // If we've hit our display limit, stop checking if videos in this set were livestreamed
      if (newestVideos.length === NUM_VIDEOS_TO_SHOW) {
        break;
      }
    } // end for loop
  } // end while loop

  return newestVideos;
};

We create a loop that will run until we reach our desired number of videos. Within it, we request videos from the YouTube playlist. We save the next page token in case we need it, then loop through the returned videos. If a video was not livestreamed, it goes into our output list.

If we reach our limit within the current page of results, we end early to avoid making additional API requests. In the event we do not hit our limit on the current page, the outer while loop will run for another iteration, fetching the next page from the playlist API.

Now the complete newestVideos.js script looks like this (comments removed for brevity):

require('dotenv').config();
const Cache = require('@11ty/eleventy-fetch');

const PLAYLIST_ID = 'PLAYLIST_ID';
const NUM_VIDEOS_TO_SHOW = 6;
const VIDEOS_PER_PAGE = 25;
const API_KEY = process.env.YOUTUBE_API_KEY;

async function fetchFromYouTube(nextPage = null) {
  let url = `https://youtube.googleapis.com/youtube/v3/playlistItems?part=snippet&maxResults=${VIDEOS_PER_PAGE}&playlistId=${PLAYLIST_ID}&key=${API_KEY}`;
  if (nextPage) url += `&pageToken=${nextPage}`;

  try {
    const {nextPageToken, items} = await Cache(
      url,
      {
        duration: '1h',
        type: 'json'
      }
    );

    return [nextPageToken, items];
  } catch (ex) {
    console.log(ex);
    return [];
  }
}

async function checkIfLiveStreamed(videoId) {
  let url = `https://youtube.googleapis.com/youtube/v3/videos?part=liveStreamingDetails&id=${videoId}&key=${API_KEY}`;
  try {
    const {items} = await Cache(
      url,
      {
        duration: '2w',
        type: 'json'
      }
    );
    return items[0].liveStreamingDetails != null;
  } catch (ex) {
    console.log(ex);
    return false;
  }
}

module.exports = async () => {
  const newestVideos = [];
  let nextPage = null;

  while(newestVideos.length < NUM_VIDEOS_TO_SHOW) {
    let ytResults = await fetchFromYouTube(nextPage);
    if (ytResults.length === 0) break;

    nextPage = ytResults[0];
    let videos = ytResults[1];

    for(let i = 0; i < videos.length; i++) {
      const videoId = videos[i].snippet.resourceId.videoId;
      const liveStreamed = await checkIfLiveStreamed(videoId);
      if (!liveStreamed) {
        newestVideos.push(videos[i]);
      }
      if (newestVideos.length === NUM_VIDEOS_TO_SHOW) {
        break;
      }
    }
  }

  return newestVideos;
};

Conclusion

It would be nice if the YouTube API allowed for a parameter to exclude livestreamed videos to keep this as simple as my initial implementation, but overall I didn’t find this particularly difficult to do. So far, this is working really well for 8BitJosh’s site.

That said, there may be room for improvement. Maybe I missed something in the YouTube API documentation, or maybe there’s a more concise way to do the filtering. If you have any suggestions, you can always send me a toot.

Native Fallback Values in CSS with SASS

Josh Vickerson — Sat, 26 Aug 2023 20:23:44 +0000

Note: This post was originally published to my blog on October 13th, 2022.

I was inspired by a brief exchange of tweets today with Brandon McConnell about the idea of a "native function for fallback values" in CSS, who was commenting on a wide gamut color demo by @bramus which also demonstrated how custom properties can be used to provide fallback values. Both the idea of a "native function" and custom properties have interesting usecases for providing fallbacks, but it's worth noting that CSS has always offered a native means of providing a fallback value in the form of the cascade.

In case you need a refresher, here's an approachable explainer on the CSS cascade.

Native Fallbacks in CSS

Simply put, repeating rules in the reverse order of your preference acts as a fallback. This is because in the event the browser doesn't understand your preferred value, it will silently be ignored. In Bramus's demo, he shows how we can use the CSS color function and custom properties via @property to access the p3 color space to create a "hotterpink" in place of the CSS named color hotpink. To borrow his example, we can achieve the same thing simply by declaring the values in reverse-preference order.

.background-hotter-pink {
  background: hotpink;
  background: color(display-p3 1 0 0.87); 
}

In browsers that support the color function, the background will be our nice bright "hotter pink". In older browsers, we'll fallback to the duller, but still nice, hotpink. While custom properties can provide more control, plenty of "fallback value" scenarios are readily managed by the cascade as this example shows. The difficulty here is that it's a little verbose, and potentially confusing to put the value you prefer the most as the last one. Brandon's suggestion of a "native function" for this did make me consider if a shorthand for this would be useful... Enter SASS.

Convenient Fallback Authoring with SASS

In Brandon's tweet, he suggested: "Something like… use-first-that-works(value1, value2, value3, valueN) but less verbose". To me, this meant listing the values in the order you prefer the browser use them. So I decided to name the mixin prefer, and the code is fairly straightforward:

/**
 * Generates a cascade of preferred values for a given CSS property
 * @param $property: css property name you wish to provide values for
 * @param $values: any number of values you'd like to use, in order of preference
 *
*/
@mixin prefer($property, $values...) {
  @for $i from length($values) to 0 {
    #{$property}: nth($values, $i);
  }
}

The mixin accepts a CSS property name as a string, followed by any number of values you'd like to use in order of preference. The $property argument is parsed as a string, and $values... becomes a list of all the arguments that follow. Then, we simply loop through the provided arguments in reverse order to generate the correct cascading values. As a usage example, our hotter pink background from above would look like this:

.background-hotter-pink {
  @prefer('background', color(display-p3 1 0 0.87), hotpink);
}

The generated code is the same as the first example. Whether this SASS mixin is easier to read, or easier to reason about than simply writing out the repetitive styles yourself depends on how you think about writing CSS, and your specific usecases, but in some situations I can see this being a little more convenient.

Notes

I should note that I did not test this with any values that contain commas. The color function example here could contain commas, but they're optional. I suspect a comma in that function would break this, in which case the mixin would need to be altered to accept values as strings and parse them as it does the $property argument. In the brief time I explored this idea, I did not think of a usecase where commas would be strictly necessary, so I left it as is.

Implemented as a native CSS function would also aid readability quite a bit. As far as I know, there's no method in SASS to identify a specific property a mixin is being used on, so we must provide it as an argument. In plain CSS this could be simpler, as the function would come after the property name:

.background-hotter-pink {
  background: prefer(color(display-p3 1 0 0.87), hotpink));
}

Whether or not CSS needs this is debatable, but as someone who pretty regularly leverages the cascade for simple fallbacks in realworld projects, I plan on using this mixin when I can to get a feel for what that authoring experience is like. If you find this mixin useful, tweet at me and let me know how you're using it!