Pretty much what the title says.

Firebase offers this but only on their $150/month plan.

Automated backups are cooler, but perhaps a button to backup to S3 would suffice for now.
Might be nice to store the last backup date, and nag users if it's been more than 5 days.

Should also settle on calling them "Content Type" anywhere they appear.

Should have a standardized way to provide a preview URL when defining a schema, so that users can have a straight-forward "Preview" button on every piece of content they edit.

It'd depend on the back-end systems doing the right thing, so this may be problematic in practice.

EDITED: This used to talk about unique names, now after #104 has landed it's all about unique slugs.

If you don't specify the auth type currently you're still forced to /login when attempting to load the page. That check needs to be smarter.

Not sure if this was never the intention (in which case the readme needs an update), or just doesn't yet work.

{
  type : "select",
  options : {
    one : "one", // doesn't work
    two : {
      value : "two" // works
  }
}

They should act like radio, IMO.

We should update a local data representation, then sync that to firebase every so often (5s-ish?). Sometimes going out to firebase is just too laggy.

When the firebase data updates we can use lodash.assign to merge them back together, with local data splatting over the firebase data to ensure that local edits aren't lost. This isn't 100% safe if multiple people are editing the same content at the same time, but it's as close as we've got w/o doing something much more complicated.

Probably using ajv?

Might be valuable to be able to say "Field B should only show up if Field A is Value C".

It keeps coming back up, I'm a bit wary of it though. Could be super-useful, could also be a bit of a slippery slope towards self-aware schemas.

They complicate styling, we should just remove 'em.

nav.js still has lots of legacy pagination code, it should all be removed.

Right now layout reserves space for the nav component, but IMO it shouldn't. Layout should only care about the left-most nav and the content area beyond. Pages should show the sub-nav if they want it (since only content-edit does). Right now they're too coupled.

This was removed in 7efcee1.

Content table should be sortable by some form of fields.

Name/Created/Updated at the very least.

In an ideal world we'd support users who wanted to author content on any device. Low priority.

Could really use both a UX & a UI pass.

When viewing all the entries for a schema it should be paginated.

We've been using Remarkable in GW.com, but perhaps there's something better.

Almost certainly tied to my changes to make saving manual, need to investigate ASAP.

Don't forget the ability to group them!

Would be useful to be able to search for content by name, I assume.

All content entries should have the option to set an unpublish date field, similar to the publish field.
Every piece of content won't benefit from this, but will be nice for those that do (news posts, sidebars, CTA features). The two fields can be used together without needing an additional publish state field.

Various states:

https://github.com/tivac/crucible/blob/master/src/pages/content-edit/publishing.js

It adds SIX HUNDRED KILOBYTES to the size of the unminified bundle.

That is without source maps, cripes.

Would be helpful when you want to force someone to make a conscious decision:

{
  "type*" : "select",
  options : {
    nag : {
        selected : true,
        disabled : true,
        value    : "Please make a section"
      },
    one : {
        value : "option 1"
      },
    two : {
        value : "option 2"
      }
  }
}

http://purecss.io/layouts/email/ seems like a good inspiration.

Currently it appears as "Loading...".

Would be potentially worthwhile to keep tabs of things users have edited in some sort of order so we can show them recency info.

Could just do it in local storage, but might as well shove it into Firebase since we're already wired up to it and they're (potentially) authed. Wouldn't track that if they aren't authed, obviously.

It's already got a route, but it needs some UI somewhere. Probably in the nav bar?

Just rip it all out.

It can just grab it from the URL since it's only ever used when the URL has a schema param in it.

Throws a JS error current.items is undefined from listings.js

Right now the key for a schema input is also used for the label, but may want to have different values.

{
  "What is your name?" : {
    type : "text",
    key  : "name"
  }
}

This does make is less apparent when you've stomped on a previous input:

{
  name : "text",
  "What is your real name?" : {
    type : "text",
    key  : "name"
  }
}

Right now the delete button is there but non-functional. Should almost certainly have a "confirm" requirement.

Everyone knows that any good home-spun CMS needs a natty logo to go with the cool name.

I suggest that we hit up some ANet Photoshop wizards to come up with something based on this:

I would also be okay with someone coming up with a slogan that has something to do with pouring molten hot content.

Crucible supports a really simple versioning scheme, there should be UI that exposes past revisions, let's you view their data (BUT NOT EDIT), and replace the current revision w/ one from the past (implicitly saving the current revision as a new item on the revisions list).

Visual diffing would be interesting but that's a huge rabbit hole I'm not really ready to fall down just yet. Also probably not so useful as to be worth the time it'd take right now.

Instead of building a "proper" permissions system, we should just make it less likely that someone using it will end up editing a schema on accident.

In the long term this should live in a new place, but for now needing to know to add /edit to the end of a URL is "good enough".

Sometimes you can load the homepage w/o having to login, which seems busted. Need to track it down.

Broke 'em in the transition to the SVG icons, will need to figure out how to fix that.

Options are sticking w/ generated content or including a <svg> tag, basically. Should be straightforward.

So it's easy to check on what you've done.

It's really ugly 👎

Simplify this thing.

Need to figure out what should be on the home page, what is useful for a user?

Because the current behavior is bad.