Repository navigation
Add Typlog Publisher v0.3.7 - #53
Closed
haohailong wants to merge 1 commit into
Closed
haohailong wants to merge 1 commit into
haohailong wants to merge 1 commit into
Conversation
Contributor
Author
|
Closing this PR in favor of a new submission for Typlog Publisher v0.3.8. The new version adds recovery for drafts deleted in Typlog: after confirming that the original draft is missing and the site remains accessible, users can create a replacement draft and associate the document with its new Post ID. Thank you for reviewing this submission. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add Typlog Publisher
Typlog Publisher
Adds
extensions/markedit-typlog.jsonfor Typlog Publisher, an MIT-licensed MarkEdit extension for creating and updating Typlog drafts from the current document.Features
:::metadata for titles and tags, falls back to the first H1, and accepts English and Chinese comma separators for tags.profileandsitepermissions, caches site metadata, and supports author selection or no author assignment.Provenance and validation
0.3.7; minimum MarkEdit version:1.36.0.index.jsonand gallery files are left to the registry workflow. Registry timestamps are also left to the publish workflow.Optional follow-up: a native Keychain API
The current public MarkEdit API does not expose Keychain operations. This extension therefore offers plain-text Token storage with a first-use notice, or optional AES-256-GCM encryption with a separate local password. The encrypted mode needs unlocking after restarting the app or opening a new document window; passwords and encryption keys are never stored in configuration files.
Would a future MarkEdit API provide native, permission-mediated secret storage, such as
getSecret,setSecret, anddeleteSecret, backed by macOS Keychain? An extension-scoped namespace, user approval for secret access, and clear handling of denial/deletion would help publishing extensions store API Tokens securely without a recurring extension-specific password prompt. Ideally other extensions could not read the same namespace.This is a follow-up API suggestion, not a dependency of this registry entry. I would be happy to move it to a separate issue in the main MarkEdit repository if preferred.