To be honest, the guides and ideas on this page aren't for non-tech users. I'd like to write some all-in-one steps or tools for them, but I don't have much time. I also can't reply to questions. So if you're a tech-savvy user with the ability to help, don't hesitate to email me. Thanks, and sorry to my non-tech friends.
Version 7 introduces many changes from version 6 in code structure and syntax. To see what's new in v7, read this post. This note guides you through upgrading from v6. If you want to create v7 from scratch, follow the "Step by step guide to create a site like this site (v6)" and then read this note.
- This note and the updated databases are for
v7.0.2.
- Unlike v6, v7 doesn't use the "bookmarks" and "projects" databases. It has a new database for the "reading" section. Check the differences between your v6 database and the current databases. The database links remain the same—here's
dat.com-reading-db-ex.
- The source code has changed significantly, but I've kept the commits continuous with version 6. You can pull the latest commits onto your current code without many conflicts.
- Review
example.env.local—there are many changes.
- v7 uses
pnpminstead ofyarn. Install it first. All commands are nowpnpm run ...
- We no longer use the
notion-xsubmodule. Everything is included in this version.
- We no longer rely on the
notion-clientpackage from react-notion-x because it's too heavy for this site's needs. Everything we need from the unofficial Notion APIs is now built into this site. We only usenotion-utilsandnotion-typesfor typing and tools.
- Caching: In v6, if fetching from the Notion API failed, the site would return a 404 error. With caching, the site remains accessible even when fetching fails. This works because we now fetch data through Upstash's Redis. We only fetch from the Notion API to update the data stored in Redis.
- SoftTTL: How long to wait before updating the cache on Redis (fetching fresh data from the Notion API and updating Redis).To bypass this timing and make changes appear immediately on the website, use
pnpm run warm-cache(see the scriptwarm-cache.tsfor usage details). - HardTTL: If an error occurs and isn't fixed, this is how long we have to resolve it. If the error resolves itself, the timer resets to 0 and starts counting again. For example, if HardTTL is 30 days and fetching content for a post fails: errors continue until day 15 (15 days left to fix the problem) → error resolves and fetching works normally → timer resets to 0 (full 30 days again). If the error persists past day 31 without a fix → a 404 page appears, just like in v6.
To disable this feature, set
DISABLE_REDIS_CACHE="true".There are two types of TTL (Time To Live): SoftTTL and HardTTL. You can modify their values for each category in
config.ts.I've also added a GitHub action to automatically warm all caches right after a successful production deployment.
To use this feature, you need an account on Upstash and to fill in the corresponding variables.
⚠️ Don't use this feature in development mode—it will significantly increase your usage!
- Email service: In v6, we don't know when the site has errors on Vercel. With this feature, an email is automatically sent to your admin email whenever errors occur on Vercel. This helps you quickly identify and fix issues.To disable this feature, set
DISABLE_ERROR_EMAILS="true". To use this feature, create an account on Resend and fill in the variables.
⚠️ I've ignored 429 errors because they're temporary and we don't have a solution for them. You can change this in the code if you want!
That's all for now. If you find something missing, please add comments below.