Note
Thank you to everyone who has used this starterkit in the past. I'm grateful that something built for myself has been useful to others. I have moved from Vue to Nuxt for my projects and will not be maintaining this starterkit actively anymore. It is stable, but be aware.
I recommend to check out Cacao Kit, which is the evolved version of this starterkit. It uses Nuxt and KQL with a headless Kirby setup. It is my best practice starterkit for your next project with server-side rendering. All features of this starterkit are included!
SPA with Vue 3 and Kirby: SEO-friendly, automatic routing, i18n and more!
Explore the starterkit live Β»
This boilerplate is a tight and comprehensive integration of Vue.js in the frontend and Kirby as headless CMS. The content is provided as JSON through Kirby and fetched by the frontend.
Some notes about the folder structure with some additional comments on important files.
The frontend will store pages between individual routes/views. When the tab get reloaded, the data for each page is freshly fetched from the API once again.
The stale-while-revalidate mechanism for the usePage
hook allows you to respond as quickly as possible with cached page data if available, falling back to the network request if it's not cached. The network request is then used to update the cached page data β which directly affects the view after lazily assigning changes (if any), thanks to Vue's reactivity.
Kirby is not a free software. You can try it for free on your local machine but in order to run Kirby on a public server you must purchase a valid license.
Kirby-related dependencies are managed via Composer and located in the vendor
directory. Install them with:
composer install
Install npm dependencies:
npm ci
Duplicate the .env.development.example
as .env
::
cp .env.development.example .env
Optionally, adapt it's values.
Vite will load .env
files according to the docs:
.env # loaded in all cases
.env.local # loaded in all cases, ignored by git
.env.[mode] # only loaded in specified mode
.env.[mode].local # only loaded in specified mode, ignored by git
During development Kirby can't access static files located in the src
folder. Therefore it's necessary to create a symbolic link inside of the public folder:
ln -s $PWD/src/assets ./public/assets
During development a .lock
file will be generated inside the src
directory to let the backend now it runs in development mode. This file is deleted when running the build command.
βΉοΈ Alternatively, you can set a
KIRBY_MODE
env variable containing eitherdevelopment
orproduction
to set the app mode programmatically and overwrite the.lock
file mechanism. This may ease setups with Docker.
You can start the development process with:
# Runs `npm run kirby` parallel to `vite`
npm run dev
Afterwards visit the app in your browser: http://127.0.0.1:8080
For Valet users: Of course you can use a virtual host alternatively!
Vite is used in combination with backend integration and only serves frontend assets, not the whole app. Thus, http://localhost:3000
won't be accessible.
The backend is served by the PHP built-in web server on http://127.0.0.1:8080
by default, but you can adapt the location in your .env
file.
Build optimized frontend assets to public/dist
:
npm run build
Vite will generate a hashed version of all assets, including images and fonts saved inside src/assets
. It will further create a manifest.json
file with hash records etc.
βΉοΈ See ploi-deploy.sh for exemplary deployment instructions.
βΉοΈ Some hosting environments require to uncomment
RewriteBase /
in.htaccess
to make site links work.
All development and production related configurations for both backend and frontend code are located in your .env
file:
KIRBY_DEV_HOSTNAME
and KIRBY_DEV_PORT
specify the address where you wish the Kirby backend to be served from. It is used by the frontend to fetch content data as JSON.VITE_
are available in your code following the import.meta.env.VITE_CUSTOM_VARIABLE
syntax.For example, setting KIRBY_CACHE
to true
is useful in production environment.
To change the API slug to fetch JSON-encoded page data from, set
KIRBY_CONTENT_API_SLUG
to a value of your liking (defaults to app
). It can even be left empty to omit a slug altogether!You can't use Kirby's internal API slug (defaults to
api
). If you insist on usingapi
for your content endpoint, you can rename Kirby's by adding aKIRBY_API_SLUG
key and set it to something other thanapi
.
Multiple languages are supported. A comprehensive introduction about multi-language setups may be found on the Kirby website.
To enable language handling, you don't have to edit the config.php
manually. Just set
KIRBY_MULTILANG
to true
.KIRBY_MULTILANG_DETECT
to true
(optional but recommended).Then, visit the panel and add new languages by your liking. The Panel automatically renames all existing content and file meta data files and includes the language extension.
Language data is provided by the global site
object, which can be accessed via the useSite()
hook.
To keep page data fresh with stale-while-revalidate, set:
VITE_STALE_WHILE_REVALIDATE
to true
MIT License Β© 2020-2023 Johann Schopplich