cstate/cstate v5.0

cState v5.0 - Biggest Update Ever

on GitHub

Migration guide

If you can, please use v5.0.1

This update has some high priority bugs in it which are fixed for v5.0.1. If Hugo does not build from this release, check if NETLIFY.TOML has the Hugo version set to exactly 0.80.0 (not 0.80). See emergency fix here.

The Netlify CMS configuration file is not valid and is fixed in v5.0.1.

As of today, April 17th, 2021, 1215 people have starred this repository. Thank you for your continued & use of cState. Hope you enjoy the new features!

v4 to v5

Some considerations:

• The new way of handling time means ALL DATES AND TIMES MUST be in UTC. Netlify CMS, for example, should automatically set the time to UTC in the frontmatter, without you doing anything.
• The new way of handling time might screw up your archives. If you did not use UTC for ALL issues before, consider or not upgrading your site and starting anew (from scratch). It's as easy as clicking Deploy to Netlify from the README and setting the old site as an archive, linking it to the footer, if you'd like.
• There aren't many breaking changes unless you rely on informational or the resolved variables for issues. Those are now booleans instead of strings.
• API may not work for versions earlier than 0.73 -- testing happens on 0.80 term is needed to be added as an output method to the config file, but it got renamed in one of the versions etc etc. Some context: gohugoio/hugo#6911

What you MUST change:

config.yml

At the very bottom or top of your config.yml, if you wish to use the Last modified feature, add this:

# For features like Last modified, you
# need to use a Git repository. If you
# are using Netlify, you are already
# using Git (with GitHub, GitLab, etc)
#
# So, should Git information be used
# for this website?
#
# We recommend to keep this at `true`.
# BOOLEAN; `true`, `false`
enableGitInfo: true

Next, here are the newly introduced options. You can disable all these (or not even copy paste this bit) and use cState as usual.

  # Should relative time (x min ago) be used?
  #
  # IMPORTANT: In the frontmatter, the dates MUST be in
  # the UTC time zone for this to work preperly. If you 
  # use Netlify CMS, all good — the CMS picks UTC time
  # by default. Otherwise, there may be very inaccurate
  # times if multiple time zones are in your issue files.
  #
  # FOR YOUR CONSIDERATION: This feature was introduced in
  # v5. It may be a breaking change in the case when you
  # wish to use relative time but old issues do not have
  # UTC time (and therefore are out of sync by ±24 hours)
  #
  # Read the wiki for more: 
  # https://github.com/cstate/cstate/wiki/Customization#time 
  #
  # If enabled, will display relative times in places like
  # the incident history and summaries instead of using
  # dateFormat and shortDateFormat (except for if you use
  # the old shortcode).
  #
  # Default: `true`
  # BOOLEAN; `true`, `false`
  useRelativeTime: true

  # If enabled, doesn't show seconds on relative times.
  #
  # With option ON (true):
  # "Last checked <1 min ago"
  #
  # With option OFF (false; default):
  # "Last checked 20s ago"
  #
  # Default: `false`
  # BOOLEAN; `true`, `false`
  skipSeconds: false

  # Should there be an automatic "Last updated"
  # text shown below issues?
  #
  # Default: `true`
  # BOOLEAN; `true`, `false`
  enableLastMod: true

If you will use relative time, and therefore UTC, consider editing the dateFormat for people who do not use JavaScript (and other fallbacks). Copy and change the options to this:

  dateFormat: January 2, 2006 at 3:04 PM UTC
  shortDateFormat: 15:04 UTC — Jan 2

To make the API work flawlessy, change the Output Formats to this:

outputs:
  page:
    - html
    - json
  section:
    - html
    - json
    - rss
  home:
    - html
    - json
    - rss
    - svg
  term:
    - html
    - json
    - rss

Upgrade to Hugo 0.80

On Netlify, make sure you are using Ubuntu 16.04 (not the old build image) in Build & deploy settings. You can change the HUGO VERSION in the Environment Variables from the Netlify UI or also edit the netlify.toml file.

netlify.toml / vercel.json

Add this to your netlify.toml for your site if you don't have it already:

[build.environment]
    HUGO_VERSION = "0.80.0"

[[headers]]
    for = "/*.json"
    [headers.values]
      Access-Control-Allow-Origin = "*"

Docs for headers: https://docs.netlify.com/routing/headers/#multi-value-headers

Vercel equivalent (made by contributor);

{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "Access-Control-Allow-Origin", "value": "*" },
        { "key": "Access-Control-Allow-Methods", "value": "GET,OPTIONS" },
        { "key": "Access-Control-Allow-Headers", "value": "X-CSRF-Token, X-Requested-With, Accept, Accept-Version, Content-Length, Content-MD5, Content-Type, Date, X-Api-Version" }
      ]
    }
  ]
}

Changelog

This update brings a lot of requested and long-awaited features, also some bug fixes to your status page.

A different (better) way of handling time — #139 (#128, #135, also see #123)

What is time? It is an important element for a status page to get right. And there are so many ways to show the time. But some are more confusing than others.

Prior to v5, cState did not give too much thought about what kind of time zone the user was in. Yes, there were (and still are) relative calculations of "how long an outage takes", but does the end user know exactly in which time zone at 6PM the issue began?

date: 2019-10-04 18:05:00

For small countries like Lithuania, there is one time zone that everybody is familiar with — GMT+2 in our case. So you could have the time and date, as shown in the config, be 'synced' to Eastern European/Lithuanian time. Would be confusing for people in vastly different time zones like those of North America, but it might not be a big issue for some.

If you have an international user base, then this is a real problem. Again, your company in San Francisco could choose to use the time in that specific region and add on to the date text that we are using this time zone, not another one. Still, this can be prove to be annoying.

For new setups, cState defaults to relative time and ASSUMES YOU USE UTC TIME.

Thanks to all the people who suggested and worked on this feature, most notably @khamer.

Expanded read-only JSON API (version 2!)

There are lots of updates to the API to make it actually useful. Read here

There aren't many breaking changes unless you rely on informational or the resolved variables for issues. Those are now booleans instead of strings.

Also see #159

Are you looking for a monitor bot or extension to show when something is down on your site?

Check out the new cState project HTML Embed

Other new features

Last modified

lastMod (last modified date) is now available through the newer, v2, API and I am trying to figure out how to implement it properly in the UI. There's a param in config.yml enableLastMod if you want to check it out.

Category status

Now when a category is closed you can see the status of it. #101 Groups take on the status of their most degraded child components/systems. Opening the category, like always, shows the individual statuses. This feature is only available with JavaScript on.

On new websites, Vercel deployments will automatically allow cross-origin requests

Introduced in #176 from @jacobhq — copy the file introduced in the new exampleSite directory (or cstate/example repo when v5 goes live to production) to use this functionality for the API.

Things requiring attention of some users:

• On new sites cross origin on Vercel works #176 from @jacobhq (add file if upgrading)
• Updates to Docker by Nevexo from #162 (see Docker docs in wiki)
• Added Tagalog translation by @TheWhackFactory from #153
• Added Italian translation by @Enrico204 from #166
• Bug with Google Analytics now fixed!

Minor changes include:

• Slight improvements to XML
• Improved documentation and code style
• Added "Hyrousek" status page #155
• Added Josh.win status page
• "All systems operational" changed to "No issues detected" in English language file