move most configuration options into cards

Ticket

+commit
 

Too many configuration options cannot be accessed within wagn.

 

Here are the cards we currently have:

Some card names begin with a star (*).  These "star cards" are

  • referred to in Wagn's code, and/or
  • key to Wagn's default structure
Note that *title and title are two different cards -- the star leaves the name for other uses.  Also see an alphabetical list of all star cards.

 

Rules

Wagn configuration works by connecting Sets (groups) of cards to Settings (configuration options). 

 

These star cards help form sets:

And these represent settings:

Note that you can go to a set or setting card to see all rules associated with it.

 

Mail / Signup

These are used for flexible email and account-related emails.

The following configure signup communications, including email notifications and thank-you pages:

 

Related Cards

Each card has a "related" tab entirely configured through cards:

 

Other

These cards are simple single card config options:

These cards are included in the Classic Layout and have autogenerated content.
  • *head — required, goes in HTML head
  • *navbox — the navbox
  • *account_links — links to current user's card, sign in/out, and signup
  • *version — current Wagn release
  • *alert — where notifications show up, defaults to bottom-right corner
  • *foot — required, goes just before /body on page's HTML
These cards offer metadata about any card when plussed to them (eg Home+*when created)

These cards configure valuable searches:

Here are the inaccessible config options:

 

 

  1. Suggest the following additional cards:
    • *css -- replaces local.css √√
    • *title -- replaces wagn.rb site_name config  √√
  2. The most obvious rule breakers are the system setting cards. Our fix should probably also address the other emails needed to move from wagn.rb. I propose:
    • *invite, which includes
      • +*subject - default subject for invitation emails √√
      • +*message - default √√
      • +*from - whom invitation emails come from (if not set, then from current user.  Note, same address would be used for all the account info emails - invites, forgot password, add account to card...) √√
      • +*thanks - card where you go after successfully inviting someone √√
    • *signup, which includes
      • +*to - whom to mail notification of signup / request √√
      • +*from -  if not set email is from person who signed up√√
      • +*thanks - card where you go after signup√√
      • +*message - sent out after successful automatic registration√√
      • +*subject - subject for that message√√
  3. sample_wagn.rb should have only the remaining options that can only be configured - and each should be documented. This is the first experience that most people have of Wagn code. For some the only experience!

 

 

local.css, site name, various emails (for warnings, invitations, etc)

 

Let's use this space to include changes that we need to make after we have this functionality.

 

  1. on connectipedia.org, we need to edit *css to fix spotlight / highlight issue:

    See http://www.connectipedia.org/wagn/Adult_-_continuing_education+background

    It has a highlight and a spotlight (through experimenting i found which is which - adding styling in the menu would help). I like the rounded look on the highlight! However, in edit mode, they both show as spotlight.

    Same problem when i tested by editing http://www.connectipedia.org/wagn/John_Abbe and Daniel Bachhuber's signature line shows as highlighted in edit mode.

 

*table of contents - I know i'm the one usually arguing to put everything in cards :-), but is there any conceivable value in having a card for this? May not be worth the time now, but could eventually just do this in code, and in any case offer a much nicer interface for it (which ideally would only appear if the card in fact had four or more headers).

  --John Abbe.....Sun Jan 04 03:43:16 -0800 2009


Solution reads: Any built-in cards that must be a certain type, but need not have any initial content, should be built-in anyway, and set to the correct type.

If we're going to do that, we should have meaningful default values, not blank content, because otherwise it will mess up funcionality. Eg, Wagn does behaves differently when there is vs. isn't a *home or *logo card. This is actually a pretty cool opportunity to make these features more discoverable...

  --Ethan McCutchen.....Sun Jan 04 09:24:42 -0800 2009


re "*table of contents". Does "in code" mean in the database? I guess one value of having a card is that it gets exposed to WQL, which could have value for site upkeep (moreso once we have advanced search and bulk updates...).

I suspect that you're right, it won't be worth the time pre 1.0, but worth thinking about!

  --Ethan McCutchen.....Sun Jan 04 09:27:52 -0800 2009


That's what i'm thinking - is there any admin situation in which you want to find cards that do or don't have their ToC suppressed? (By "in code" i meant, not having a card.) I guess more important to me than card-or-not is just having a better interface for this, so i added that to our mini-design list.

  --John Abbe.....Sun Jan 04 22:34:57 -0800 2009


not sure exactly where to put the *error cards, since our setup had us directly configuring the plugin in wagn.rb...

  --Ethan McCutchen.....Wed Feb 11 18:11:28 -0800 2009


Think this belongs in discussion more than solution:

At present, the "actual" search cards are referred to in the related card code, but I think ideally that will all eventually be built out of editable cards, so there may just be *related if any star card at all. But I think it makes sense to keep them for now. Do we want to change the link and update names for more simplicity / consistency? They sure are gangly. Could be hairier than warranted... Recommend status quo for now.

  --Ethan McCutchen.....Thu Feb 12 14:13:31 -0800 2009


Let's move all of the "initial setup for new Wagn" components into a new ticket and test all the others, consistent with the card title. The initial setup ones won't make it into this release.

  --Ethan McCutchen.....Mon Feb 16 10:29:24 -0800 2009


Ready to test those settings, but we also need to make several migrations before we're through.

-e

  --Ethan McCutchen.....Mon Feb 16 10:30:10 -0800 2009


Moved some stuff as requested to implement initial setup for new Wagn

  --John Abbe.....Tue Feb 17 14:09:26 -0800 2009


At ((removed reference to sandwagn)) i set *title to Sandwagn and deleted *home, and now ((removed reference to sandwagn))goes to Wagn.

 

Anyway, i can't see why we have both *home and *title - the solution says the latter replaces wagn.rb site_name, and Installation says that's the "name of the Wagn's front page".

 

I thought *title might set the browser window title, but it doesn't do that.

  --John Abbe.....Tue Feb 17 17:26:08 -0800 2009


I set ((removed reference to sandwagn)) to be a Phrase and a Pointer, but in neither case do i get redirected to the page indicated (instead i go to the home page).

  --John Abbe.....Tue Feb 17 21:43:26 -0800 2009


 

((removed reference to sandwagn)) exists, but the Message box in the invite is blank (and the email received only has what i typed in there plus the account details).

 

 

((removed reference to sandwagn)) exists, but the email i get still comes from the User who invited.

  --John Abbe.....Tue Feb 17 21:46:11 -0800 2009


Got clarity from Ethan offline about *home vs. *title, documenting at implement initial setup for new Wagn

*message and *from fixed; *thanks in progress...

  --John Abbe.....Wed Feb 18 21:16:40 -0800 2009


Everything looks good now. Closing.

  --John Abbe.....Thu Feb 19 22:03:21 -0800 2009


Documentation in process on http://new.wagn.org/wagn/Config

 

Other documentation to update:

custom signups

custom welcome email

customizable site appearance

 

  --John Abbe.....Sun Mar 01 07:41:37 -0800 2009