Need a complete JSONSchema version and invalidator created.

weebly validate does not handle valid client_id values provided from Weebly Developer Admin.

Should accept digits 5-10 characters.

Create the validators for:

• client_id
• version SEMVER
• names (dashboard cards, elements, properties: max length, char. restrictions)
• icon . (character restrictions, file extensions supported, and max length...?????)
• label (character restrictions and max length...?????)
• integer (for number-only inputs)
• tooltip (100 character max, plain text ONLY)

Seeing this issue:

benjamin@Benjamins-MacBook-Pro:~/LOCAL_NODE_PKG_DEV_PLAYGROUND/weebly-cli-local-dev-apps $ weebly add dashboard-card
? What is the dashboard card's name? myTestCard
? What is the dashboard card's version? The version of a dashboard card has to be equal to or less than the app's version. 0.1.0
? Do you want to include a display label for this dashboard card? Yes
? Enter the label text to display for in this dashboard card's header. My Test Card
? Do you have an icon for this dashboard card? No
? Display takeover content from a URL when the link is clicked for this dashboard card? No

TypeError: path must be a string or Buffer
benjamin@Benjamins-MacBook-Pro:~/LOCAL_NODE_PKG_DEV_PLAYGROUND/weebly-cli-local-dev-apps $ weebly add dashboard-card
? What is the dashboard card's name? testesadsv
? What is the dashboard card's version? The version of a dashboard card has to be equal to or less than the app's version. 0.1.0
? Do you want to include a display label for this dashboard card? No
? Do you have an icon for this dashboard card? No
? Display takeover content from a URL when the link is clicked for this dashboard card? No

TypeError: path must be a string or Buffer

The locale property of a manifest is not passing validation when the following valid value is set:

    "locale": {
        "default": "en-us",
        "supported": ["en-us"]

    }

Provide an easy way to bump the version of:

• App (root level)
• Element
• Dashboard Card

The first line is missing from the manifest. Needs to open with:

{
    "manifest": "1",

A command that runs the manifest.json against a JSON schema validator.

Command to add dashboard card information to the manifest JSON.

Need to support defining new backend services with the CLI.

Since all dashboard-cards must be updated via the API, any app which successfully creates a new dashboard-card must also create a related webhook, subscribe to the correct dashboard.update.card events, and update the manifest.json.scopes to include the Dashboard Card API scopes respectively.

The legacy version of the Weebly CLI, written in Ruby only supported the ability to upload your compressed app (.zip) up to Weebly servers for continuing development, and it would be nice to include that ability from within this version.

• Node version required
• Weebly Free Account
• Registered as a Weebly Developer
• Can authenticate to Developer Admin
• Have created an app and have API Keys from Weebly

Would be nice if the CLI could handle testing and loading of Snippet apps using browsers or PhantomJS.

When the dev chooses to create the element, we should create this directory structure:
files

• assets
• css
• html
• js

When using the steps type, we need to nest the topics.

Make sure we're using TDD to invalidate our outputs.

To make it easier for developers, the CLI should support the ability for developers to add new components to a specified element.

Notice below that there is a missing settings property at the root of each element.
The settings property should have two child properties:

• config
• properties

{
  "manifest": "1",
  "version": "1.0.0",
  "client_id": "1173370737",
  "manage_app_url": "https://weebly.apihacker.com/manage",
  "scopes": [
    "read:blog",
    "read:site",
    "read:store-catalog",
    "read:store-orders",
    "read:membership"
  ],
  "callback_url": "https://weebly.apihacker.com/oauth/callback",
  "oauth_final_destination": "editor",
  "elements": [
    {
      "name": "testing",
      "path": "files/testing",
      "version": "0.1.0",
      "config": {
        "autopop": true
      },
      "properties": [
        {
          "type": "group",
          "name": "settings",
          "label": "Settings",
          "properties": [
            {
              "name": "testsetting",
              "label": "Test Setting",
              "type": "string",
              "min": "5",
              "max": "100"
            }
          ]
        }
      ]
    },
    {
      "name": "My custom element",
      "path": "files/my-custom-element",
      "version": "0.1.0",
      "config": {
        "autopop": false
      }
    },
    {
      "name": "elementNumberTwo",
      "path": "dashboard_cards/elementnumbertwo",
      "version": "0.1.0",
      "config": {
        "autopop": true
      },
      "properties": [
        {
          "type": "group",
          "name": "settings",
          "label": "Settings",
          "properties": [
            {
              "name": "elementNumberTwo",
              "label": "Element Number Two",
              "type": "text",
              "min": "10",
              "max": "50"
            }
          ]
        }
      ]
    }
  ],
  "dashboard_cards": []
}

To get this moving quicker, some code was duplicated that could be refactored and consolidated:

In src/models/manifest.js

• getElements - getWebhooks - getDashboardCards
• addDashboardCard - addElement
• deleteDashboardCard - deleteElement
• createDashboardCardDirectory - createElementDirectory
• deleteDashboardCardByName - deleteElementByName

Membership API has been deprecated and should not be available for apps to elect to use in their scopes.

Let's simplify developer's lives a little more by adding the ability to map events to API requests.

This would really add some power to this CLI utility (almost making it an SDK).

We're so excited that you've decided to create a new project! Now that you're here, let's make sure you know how to get the most out of GitHub Projects.

• Create a new project
• Give your project a name
• Hit the ? key to see available keyboard shortcuts
• Add a new column
• Drag and drop this card to the new column
• Search for and add issues or PRs to your project
• Manage automation on columns

To help make consuming webhooks easier for developers, the CLI should implement the node webhook client into this app.

If you create a new item using weebly add <type>, then there is a failure while engaging with the prompts to define that item, one of two things needs to happen to prevent orphaned items:

1. Cleanup any files or directories that were created
2. Do not create those files or directories until all prompts have completed successfully

While trying to add a new element, I received a few different errors (and in some cases, did not receive errors when I probably should)...

Should we:

1. Be able to use hyphens, underscores or other characters in app, element, and element setting names/labels?
2. Perform some type of verification on the element setting type radio items?
3. Support an interactive prompt for the element's icon to permit tab-completion of paths?
4. Do we rename whatever icon is provided to the expected icon.svg (or can we change that filename in our app)?
5. We should probably permit hyphens and underscores in element and element settings' names used in code
6. We should probably include some interactive confirmations on what we're creating for element settings.

Support the ability to reorder and reorganize dashboard card default content.

• Panes
• Groups
• Component order

A command that shows users what is available on the weebly CLI

All dashboard cards require an update when loaded by Weebly Site Admins when they visit the respective site's dashboard in Weebly. This update must be done via the API. For developer's apps to be notified when the Site Admin loads that page and the dashboard card needs updating, the developer must subscribe to dashboard.card.update webhook events.

So, the following dependencies are mandatory when a new dashboard card is added to an app:

• Webhook defined in manifest.json
• Webhook scope property includes dashboard.card.update (update existing webhook if exists)
• App scopes property is implicitly set by Weebly, so nothing here
• App requires OAuth (if not previously set), app must include client_id, callback_url, and final_oauth_destination properties (the latter should be set to dashboard_card).

Might make things easier to manage moving forward.
Any thoughts?

Developers will want to be able to use the CLI to more easily manage the content within each of their elements. Expose the ability to:

• Select an Element to manage
• Display reorganization display for selected element's components
• Ability to delete any of the selected element's components

To make things easier for developers, we should include the Weebly Node Client when an app is set to use OAuth.

This will allow developers to have apps which are well encapsulated.

We resolved the directory structure for elements in Issue #14 but we should expand upon that and provide some stub files in each of those directories.

If a dev chooses "no" for uploading an icon, need to prompt that says:
"You will not be able to upload and test your element until you add an icon. Be sure to upload it to the root directory for your element.

Hey @robinwhitmore can an app have more than one dashboard_card?

I didn't see in the dashboard card documentation an explicit statement regarding if there is a fixed or maximum number of dashboard cards which an app can make available.

While I was considering the purpose of dashboard cards, my mind considered arguments for both sides and I wanted your input:

• An app should only expose a single dashboard card, because they are installed automatically when a user installs an app. A single card could have multiple groups or use external settings for very complex and informative dashboard cards, so a single card makes sense to enforce.
• An app could have multiple dashboard cards which it installs as a set of smaller, single-purpose management and reporting consoles for complex apps.

I figured I would ask the question, and then we can adjust/improve either this repository or the documentation accordingly.

Found the following issues in the schema. I've bolded the issues that need to be fixed. The rest are description changes/additions.

• /properties/version description: the version must be great to or equal to any sub-components. If you version a sub-component, you must also version the app.

• /properties//client-id description: may want to add that client_id=app_id.

• do we want to add to all URL descriptions that they must use https?

• /properties/webhooks/callback_url description: might be more clear if you say this the url that the event notice/payload will be sent to.

• /properties/dashboard_cards type: I think this should be an array, as you can have multiple dashboard cards

• /properties/dashboard_cards/properties/label description: text to append to the app's name, displayed in the header of the card. the app's name is always used in the title area of a dashboard card. The label property only needs to be used if an app has more than one dashboard card and you need to differentiate between the two.

• /properties/dashboard_cards/properties/link description: An optional URL to content displayed in a takeover when the dashboard title area is clicked.

• /properties/dashboard_cards/properties/default description: This is the default dashboard card content and can contain one or more dashboard component definitions. If null, the dashboard card won't display when the app is first installed and will display after the first update.

• do you want to add all the possible dashboard components?

• The only properties required for dashboard cards are name and version.

• /properties/elements/items/properties/path description: might be better to say path to element's files (or some other term), as there is also a directory named assets.

• /properties/elements/items/properties/version description: must be lower than or equal to the app's version. If you version the element, you must also version the app.

• /properties/elements/items/properties/properties/items/properties/name description: the internal name for this setting.

• /properties/elements/items/properties/properties/items/properties/label description: the name for this setting as displayed in the Settings dialog.

• /properties/elements/items/properties/properties/items/properties/type: the type of setting. If this is the parent properties property, type must equal group.

• /properties/elements/items/properties/properties/items/properties/default isn't valid at this level. it's a child of /properties/elements/items/properties/properties/items/properties/properties.

• You're missing /properties/elements/items/properties/properties/items/properties/properties. This property holds all element settings other than group. The child properties to this properties property are name, label, type, default, tooltip, and then depending on the type value, max, min, step, and values (which is an array that can contain name and value properties or just an array of strings).

• You're missing /properties/elements/items/properties/settings/properties/config/properties/external. The properties for this object are url, label, height, width, modal, and fullscreen.

• /properties/elements/items/properties/properties/items/properties/hidden description: Set to true to not display this setting in the Settings dialog.

• /properties/elements/items/properties/properties/items/properties/private description: Set to true to not allow the published site to access this setting.

• /properties/elements/items/properties/properties/items/properties/tooltip description: A string that displays when hovering over the setting in the Settings dialog.

• /properties/tutorial/properties/content/items: I'm not sure how you set this up in the schema, but this doesn't have to be an object. If type=video or step, then the array is a URL or an array of strings, respectively.

• /properties/tutorial/properties/introduction description: Text that appears at the top of the dialog.

• /properties/tutorial/properties/type description: The type of content. Valid values are step, video, and topics. If the value is topics, then the content array contains label, introduction, type and content properties.

• You're missing /properties/tutorial/properties/content/items/properties/content. This is the content for the nested topic.

• /properties/tutorial/properties/autopop description: set to true if you want the tutorial to open automatically the first time the element is used.

Need to flag this library as beta until the foundation firms.

To make authoring of dashboard cards more flexible and easier to create, build in support for adding individual.sets of components to a dashboard card.

Add a command that gives the ability to add elements to the manifest JSON.

It's likely that devs will configure oauth before dashboard cards are created and so they may decide to use a dashboard card as the final destination before it's created. When a enters a dashboard card as the final dest., we should do the following:

• check to see if dashboard.card.update webhook is configured in the manifest. If not, add it.
• check to see if a dashboard card with the given name exists. If it doesn't ask if we should create the beginning of a dashboard card using that name or if they want to reenter the value (in case they spelled something wrong).