This repository pulls the desering.org project from Webstudio Cloud and deploys it as a static website to GitHub Pages.
Only changes that have been PUBLISHED in the web interface are "pulled" by this automation.
Install globally:
npm install -g webstudio@latestRun without installing:
npx webstudio@latestWebstudio offers dynamic (docker, vercel, netlify) and static (ssg,
ssg-netlify, ssg-vercel) export options
(docs). We are using ssg
in this repo.
To connect to a Webstudio project, either run webstudio and follow the guide
or run webstudio link --link <share-link-here>. This will create the following
necessary files:
~/.config/webstudio-nodejs/webstudio-config.json- contains Webstudio project IDs and access tokensmy-project-directory/.webstudio/config.json- linksmy-project-directoryto a Webstudio project
Click "Publish" in Webstudio Cloud to ensure that the latest changes will be used in the next steps:
-
Sync site data from Webstudio Cloud to your local directory:
webstudio sync
This will download and populate
.webstudio/data.json. -
Generate a local project based on the
ssgtemplate:webstudio build --template ssg
This generates a vike project based on the ssg template with content from the
.webstudio/data.jsonfile. Files inapp/__generated__/*contain the content, structural elements, style, etc., and files inpages/**/*contain generic templates that depend on the content inapp/__generated__/*. This project can be checked in to git for further development, and/or used to build a static site. -
Install dependencies:
npm install
-
Remove redirects that would break a static build:
find . -type f -name "+data.ts" -exec sed -i '' -e 's|throw redirect(pageMeta.redirect, status);|//throw redirect(pageMeta.redirect, status);|g' {} \;
The Webstudio docs mention that redirects are not supported, but the build fails if redirects are present at all, instead of simply ignoring or skipping them.
-
Build the static site:
npm run build
This renders static pages based on the generated project files.
Now, the dist/client/ directory can be statically deployed, for example to
GitHub Pages or Cloudflare Pages.
Important
The SSG build is meant to work only with a base path of / - deployments at
mydomain.com/my-webstudio-site/ are not officially supported. Continue
reading for solutions.
To develop and edit the site, simply use the vite dev server:
npm run devTo build the static site and serve it at the root path:
npm run build
python -m http.server --directory dist/client 8020To build the static site and serve it at a non-default base path:
npm run build
mv dist/client/ dist/desering.org-webstudio/
python -m http.server --directory dist 8020Important
For this to work correctly, you will need to prepare a few things before the build. Read Static deployment at non-default Public Base Paths below.
Tl;Dr: Yes, it is possible to export from Webstudio. The resulting code is generated and not easy to work with. A rebuild is necessary, because editing content in the exported site cannot be left to non-technical people.
-
Design and content are not separate.
- All data is contained in a huge
data.jsonfile - Different "build targets" (ssg, vercel, docker, etc.) are static templates that use the data file
- The
ssgbuild target generates.tsxfiles, but they depend on components built and maintained by Webstudio - Untangling this is difficult
- All data is contained in a huge
-
Webstudio does not support static deployments with base paths other than
/.- This makes a PoC difficult but is not an issue for the final site.
- For the fun of it, this repository contains a PoC for making it work. See Static deployment at non-default Public Base Paths.
-
The "Events" page itself renders correctly based on data from our CMS, but pages for each event do not.
- This requires some rework: either generate event pages at build time, or build an SPA that can handle navigation to paths that don't exist on the server.
- Maybe this behaves different in "dynamic" builds, which might also allow for easier extraction of a usable website.
To support static deployments at non-default public base paths, the following areas need to be covered:
CSS and JS assets are covered by setting
the base option in vite.
Navigation links in app/__generated__/* files use the Webstudio
Link component
which does not support prefixing with a base path.
Image URLs are run through the imageLoader included in the ssg template,
but it passes the given file through
without modifications.
Other assets like the social image, favicon, fonts and background images
inside the
+Head.tsx component
are rendered using both the assetBaseUrl and the imageLoader which does not
do anything and is again missing any base path option.
To understand the inner workings of the Webstudio template and the build process, a few workarounds have been implemented as a PoC. For details, have a look at the GitHub Actions Workflow.
In short, each of the above-mentioned areas is covered with a pre-build step:
- Navigation links: introducing a new vite plugin that that adds the
vite
baseprefix to links in bothLinkandRichTextLinkcomponents. - Image URLs: patching the
imageLoaderfunction to prefix image paths with both the vitebaseparameter and theassetBaseUrl, if given. - Other assets: introducing a new
assetLoaderfunction to prefix assets references inside the+Head.tsxcomponent with the vitebaseparameter.
This is the first step towards more elegant or correct solutions, like:
- Implementing a better
Linkcomponent that supports thebaseparameter invite.config.ts, to get rid of the vite plugin that prefixes navigation links with the base path. - Not exporting the
assetBaseUrlat all and instead making all file paths use either the existingimageLoader, or a newassetLoader, in case images and other assets need different treatment.