Process hub.yaml details

[claremacrae]

[claremacrae]

Credit to @argenos for this idea, and for knowing how it's intended to work...

[argenos]

I can't dig out the comment from Discord, but the rough idea was to have a hub.yaml file at the root of plugin or theme repos. This would overwrite any information from the manifest.json or the obsidian-releases repository, and makes it much simpler to handle edge cases (e.g. two authors collaborating on plugins, or original author vs maintainer, custom content in plugin pages, etc).

Below is an initial example for plugins, but we could design something similar for themes:

docs: # Link to the plugin documentation
hub_content: [], # List of markdown documents to be included as is to the hub.
needs_theming: true, # Whether your plugin needs custom CSS by theme designers
features: # Help categorization and parsing
  commands : [], # List of files where the hub should parse addCommand docs
  suggestions: [], # List of files where to parse the EditorSuggest docs
  actions: [] # List of files where the hub should parse URI Actions docs
  toolbar: true # if your plugin adds a new toolbar
  sidebar: true # if your plugin **only** adds a new pane to the sidebar. If your plugin has a `custom_view` that can be dragged to the sidebar, set `sidebar: False` and `custom_view: True`.
  statusbar: true # if your plugin adds an element to the statusbar
  codeblock_syntax: true # if your plugin adds custom syntax to Obsidian using codeblocks
  file_type: true # Adds support for other file types (i.e. not markdown `.md`)
  custom_view: true # If your plugin adds Custom views on the note panes, e.g. Kanban. Rendering of codeblock syntax is not included here, see `codeblock_syntax` instead.
  subscription: false # Set to true if your plugin requires an active subscription to use this plugin, e.g. Todoist, Readwise
plugin_dependencies: [] # List of the IDs of the plugins it depends on.

[argenos]

From our pairing session on Saturday:

• Most of the issues on #348 stem from scripted changes, adding the hub.yaml we could interpret these as a trusted source of information, make the PRs separately and merge without reviewing (as those are intentional changes by the author). This includes updates/fixes to:
  • description
  • typos or escaping special characters
  • capitalization
  • changes of ownership
  • website
  • additional plugin/theme features or note contents
• Author pages tend to have some of the heaviest manual edits (links, handles, sponsorship information and other non-scripted contributions), but we need to come up with a solution to avoid people having to update author info in the hub.yaml file of 10 different repos for those things that can be scripted. Options we discussed:
  • point to author info on another repo (e.g. the first plugin). Note: This workflow is potentially going to be confusing
  • Author info is optional, if filled out in a single repo it's sufficient
  • Last plugin/theme wins (which is what currently happens -> to avoid unnecessary changes, first plugin/theme could reduce the number of times this happens)

[argenos]

Based on the points above, I've made some changes to the original proposal:

docs: # Link to the plugin documentation
hub_content: [], # List of markdown documents to be included as is to the hub relative to the root of the repo.
authors: # More than one author is possible, start a new line with - 
    - github: # GitHub user names of the people who created the plugin or theme
      websites: [] # Links to personal websites (optional)
      discord:
      twitter:
      youtube:
      sponsorships:
          buymeacoffee: # Add username to kofi or buy me a coffee here
          paypal: 
          github:
          patreon:
          others: [] # List of formatted markdown strings
maintainers: [] # GitHub user names of those maintaining the plugin (leave empty if it's the same as author)

plugin:
    needs_theming: true, # Whether your plugin needs custom CSS by theme designers
    features: # Help categorization and parsing
        commands : [], # List of files where the hub should parse addCommand docs
        suggestions: [], # List of files where to parse the EditorSuggest docs
        actions: [] # List of files where the hub should parse URI Actions docs
        toolbar: true # if your plugin adds a new toolbar
        sidebar: true # if your plugin **only** adds a new pane to the sidebar. If your plugin has a `custom_view` that can be dragged to the sidebar, set `sidebar: False` and `custom_view: True`.
        statusbar: true # if your plugin adds an element to the statusbar
        codeblock_syntax: true # if your plugin adds custom syntax to Obsidian using codeblocks
        file_type: true # Adds support for other file types (i.e. not markdown `.md`)
        custom_view: true # If your plugin adds Custom views on the note panes, e.g. Kanban. Rendering of codeblock syntax is not included here, see `codeblock_syntax` instead.
        subscription: false # Set to true if your plugin requires an active subscription to use this plugin, e.g. Todoist, Readwise
    plugin_dependencies: [] # List of the IDs of the plugins it depends on.


theme:
    features: []
    plugin_support: [] # IDs of the plugins that have been styled by this theme
    modes:
        - Dark
        - Light
    snippets: [] # Path to css snippets relative to the root of the repo. We could parse the css similar to style settings
    color_schemes: []

[claremacrae]

From one of the Python intro sessions: Important: We need to consider how we would sanitise content we embed, in particular to prevent serving up malicious links.