- pact.FormFieldType gains RequestOptions, called with the application's
database once per form schema request for each type the form uses
- the form schema route merges the answer into a copy of each field's
typeOptions; a fields.yaml key wins, the compiled schema never changes
- an error logs one warning naming the type and serves the fields.yaml
options only
- TestFieldTypeRequestOptions covers every screen, the precedence, the
call count, the error path, unchanged schemas, form extension fields
and the authenticated handler; a runnable example backs the docs
- the typeOptions description, the regenerated OpenAPI document and
schema.d.ts, the field types page and the pact and cabana READMEs
document it
- pact.ContentDescriptor gains Kind and Tools with the ContentKind and
ContentTool constants
- pact.ContentRecord gains PublishedAt, Parents, Authors and TopHeading;
pact.ContentLocale gains Images, Videos and Headings, with the value
types ContentRef, ContentPerson, ContentImage, ContentVideo and
ContentHeading; every field is optional
- TestContentDescriptorFields proves signpost hands them through and
that a type setting none of them describes as before
- the runnable content example, the pact and signpost READMEs and the
menu item types page document the fields
- CR-01, CR-02, CR-03, WR-01, WR-04 and WR-05 fixed, with commits, tags
and the live checks of release 195aa213c546
- WR-02, WR-03, WR-06 and IN-01 to IN-09 deferred, one todo each
A plugin developed inside an application replaces its required plugins
with sibling directories (../user). Checked out on its own, that
directory is missing and plugin.yaml lost the minimum (golem15.user: ""),
so the manifest differed between the two layouts and TestPluginManifest
could not pass in both. Such a module is now fetched at the version
go.mod requires, as a consumer would see it.
- listedModule.fallback marks a local replace whose directory is absent
- fallback modules download separately, so one unfetchable version does
not hold up the others
- TestDeriveMissingReplace over a file:// proxy (offline)
The smoke fixture's acme.blog has v0.1.1 for framework v0.6.0 under a
newest release that needs v0.7.0; plugin:install picks v0.1.1, so the
marketplace now marks it compatible.
The comment-keeping summer.yaml edit refused a flow-style plugins list
(plugins: [{id: a, module: b}]) that plugin:add used to handle with a
full rewrite. The edit now replaces an inline list, over one or several
lines, with a block list of its items plus the new ones and keeps every
other line. A list it cannot edit in place (a tagged one, say) falls
back to the full SaveManifest rewrite with a note that the comments were
not kept. plugin:install gets the same behaviour.
With a framework version that is not a release (a devel build, an empty
FrameworkVersion) every plugin with a minimum was marked as needing a
newer framework, and Compatible looked only at the newest release, so a
plugin whose older release fits was marked although plugin:install
would install that release. An unknown framework now gives no marker
(and no needs-framework note on the Installed tab), and a plugin whose
newest release is too new is looked up (cached, four at a time) and
counts as compatible when an older release fits.
pluginCatalog.lists was keyed by every distinct query and category and
never dropped an expired entry, so searching distinct strings grew the
process without limit (each entry can hold a 4 MiB answer). Storing a
search into a full cache now drops the expired searches and then the
ones that expire first, keeping at most 256.
validateGitURL refused only a password, but GitHub, GitLab and Gitea take
a token as the user part of an https URL. Such a URL was printed and
written to .gitmodules by git submodule add, and so committed with the
application. An https URL with any user info is now refused with a hint
to use a credential helper; the user of an ssh URL stays allowed.
A failure after the first change left the application half-modified: a
checkout moved into plugins/<vendor>/<name> but not registered, go.mod
edited, submodules without summer.yaml entries (and the next install
refused the leftover directory), or some submodules updated and others
not. Both commands now snapshot go.mod, go.sum, go.work, go.work.sum,
summer.yaml and .gitmodules (with its index entry) before applying; a
failure restores them, removes the submodules the run added (index
entry, submodule config, absorbed git dir, checkout; registered right
after the move) and checks moved submodules out where they were. What
cannot be undone is named in the error.
summer build always emitted party.Describe and []party.Info, so an
application whose framework requirement predates v0.6.0 stopped compiling
once the CLI was updated. The build now checks the party package go list
resolves in the application (a static look for Describe and Info, not a
version compare, since a local checkout reports the previous tag until
it is tagged) and, when they are missing, writes main.go and
plugins.gen.go exactly as before, with a warning to move the framework
to v0.6.0. An unresolvable party package keeps the current sources.
plugin:install pinned only modules chosen in the same plan, so a second
plugin package in a module the application already required was
installed at the newest release, moving the plugin already there, and
with --source the repository was cloned a second time. PlanInstall now
seeds every module of summer.yaml: a plugin in one installs at the
installed version with no go get or clone (only its summer.yaml entry),
and is refused with a plugin:update hint when that version has no
release of it or is not a release. A git URL whose repository is already
a submodule, or whose module the application has, is refused.
plugin:update dropped a go.mod require that was not a strict vX.Y.Z and
treated it as v0.0.0, so a module at a commit after v0.4.0
(v0.4.1-0.<ts>-<hash>) was moved back to v0.4.0. kiosk.Newer now places
a release against a release, a git describe string or a pseudo-version
(by the tag it builds on, in Go's version order); plugin:update and the
admin Plugins screen badge share it. A pseudo-version with no tag before
its commit is left alone with a note naming go get <module>@<tag>.
- PluginsView: tab switching, one request per typing burst and a blank
search without q, name fallback on cards, copied state clearing, a
refused clipboard write, a failed marketplace request
- useSettings: settingsPath prefers path, then controller, then the
singleton form; settingsEntryForPath
