docs: update marketplace docs for new PR-based marketplace.owncloud.com

[DeepDiver1975]

Summary

marketplace.owncloud.com has been rebuilt as a backend-free, Git/PR-based static catalog (owncloud/marketplace). This updates the server docs to match the new submission mechanism and feature set.

What changed on the marketplace

• Submission is now a pull request adding apps/<app-id>/releases/<version>/package.tar.gz; all metadata is read from the tarball's appinfo/info.xml. No upload form, no account, no database.
• Removed: developer accounts, API keys, trust levels (Official/Approved/Experimental), product tags (Enterprise/Verified/Trusted), user ratings, and the "Request review" process.
• Kept: categories (12 supported), and backward compatibility with the in-instance Market app + occ market:* (the catalog serves the same client API at the same domain).
• Releases are immutable — ship a new version instead of overwriting.

Doc changes

• publishing.adoc — full rewrite to the PR-based workflow (CI validation, immutability, supported categories, PGP + DCO signed commits, optional publisher page). Trust levels, tags, ratings, upload form and review process removed; app guidelines and disclaimer kept.
• market_app.adoc — removed the API-key / My Account login flow; the Market app reads the public catalog directly. DMZ manual-download note kept.
• classic_ui/apps/market.adoc — removed the Marketplace login section and its four login screenshots; describes browsing/installing against the public catalog.
• info.adoc — <category> table updated to the supported set (added files, pim; dropped external-plugins).
• code_signing.adoc — reworded "upload to the Marketplace" to the PR submission step.
• bugtracker/index.adoc — the archived owncloud/marketplace-issues tracker now points to owncloud/marketplace issues; app bugs go to the app's own repo.
• Deleted images: classic_ui login-step-1..4.png, developer_manual app-tile-enterprise.jpg / app-tile-verified.jpg.

Notes

• Code signing (ocsign) remains a required publishing step — not because the marketplace verifies it, but because ownCloud 11+ blocks unsigned apps at install/enable time (documented in code_signing.adoc).
• oCIS web extensions (the marketplace's second catalog) are intentionally out of scope for this Classic-server repo.

Testing

Built locally with Antora against the local UI bundle — all changed pages build with no errors or broken xrefs, and no page references the deleted images. (The only build errors are pre-existing ocis: cross-component xrefs, unrelated to this change.)

🤖 Generated with Claude Code

[phil-davis]

The text reads Ok. In time, we will know if it all works ;)

[DeepDiver1975]

Code Review

Documentation-only change (207+/305−, 15 files) reworking the server docs to match the rebuilt Git/PR-based marketplace.owncloud.com. The writing is clear, accurate to the new mechanism, and internally consistent. Verified below with a few items to address.

Verified ✅

• Both new xrefs resolve: admin_manual:installation/apps/apps_management_installation.adoc and app/fundamentals/market_app.adoc.
• xref:_app_categories matches the auto-generated anchor for == App Categories (default Asciidoctor sectid; no custom idprefix/idseparator configured).
• No dangling references to the four deleted login-step-*.png or the two app-tile-*.jpg images anywhere in modules/.
• external-plugins fully removed; files/pim added consistently in both info.adoc and publishing.adoc.
• {oc-marketplace-url} defined in global-attributes.yml; {marketplace-repo-url} defined in the page header.

Issues

1. Contradiction: empty <category> for themes vs. the new "reject if no supported category" rule (medium)

• info.adoc (unchanged) still instructs theme publishers to ship <category></category> (present but empty).
• publishing.adoc now states a release is "rejected only when none of its categories are supported" and "any value outside the supported set is dropped during validation."
• An empty value is outside the supported set → dropped → the theme has zero supported categories → rejected under the new CI rule. The two pages now disagree on whether a theme can be published. Either the validator has a theme special-case that should be documented, or the info.adoc note is stale. Worth confirming against the actual marketplace validator and reconciling before merge — a reader could follow it and get their submission rejected.

Minor / nits

• PR description drift: the body says a // TODO(marketplace-screenshot) marker is left in market.adoc, but no TODO exists — a real market-app.png was added in b16c7e0d. The marker was resolved; update the description so reviewers don't hunt for it.
• introduction.adoc: the appended marketplace-home image at the end of the page has no lead-in or caption and reads as slightly orphaned. Consider a one-line intro / .caption, or drop it.
• git commit -s -S in the submission steps is correct and matches the project's signing rules. Consider a one-line note that CI requires both the DCO line and the PGP signature (currently only implied via the checklist reference).

Risk

Low — docs-only, no build-affecting config/extension changes. Only substantive item to resolve before merge is the themes/empty-category contradiction (#1).

🤖 Generated with Claude Code

[phil-davis]

I don't see any "real" example of how to "package" an app.

For example, the app repo probably has "bonus" files such as:

README.md
CODE_OF_CONDUCT.md
tests folder.
composer.json
composer.lock
.github folder
vendor-bin folder
agents.md
.php-cs-fixer.dist.php
phpstan.neon
and so on.

Lots of pieces that are not needed to actually run the app in production.

I suppose that to "package" the app, the developer needs to make a tarball that contains only the items really required to run the app in production. An example of how that would typically be done would be helpful.

[DeepDiver1975]

I don't see any "real" example of how to "package" an app. … the developer needs to make a tarball that contains only the items really required to run the app in production. An example of how that would typically be done would be helpful.

Good catch, @phil-davis — the guide said to "package the signed app into package.tar.gz" but never showed how. Added a Package Your App section in publishing.adoc (7e88cf7) covering:

• tarball layout — a single top-level directory named after the app id, with appinfo/info.xml + signature.json inside (verified against a real published package, e.g. bookmarks);
• exclude list — tests/, composer.json/composer.lock, vendor-bin/, .github/, Git metadata, linter/static-analysis config (.php-cs-fixer.dist.php, phpcs.xml, phpstan.neon, .phan/), and contributor docs like CODE_OF_CONDUCT.md;
• ordering that matters — assemble a clean runtime-only copy (composer install --no-dev) → sign → tar -czf package.tar.gz -C build/dist <app-id>;
• a pointer to the existing Makefile.example dist target already shipped with the developer manual, which automates exactly this.