feat(files): surface .pad files under the 'Documents' type filter (#27)#130
Draft
Jaggob wants to merge 1 commit into
Draft
feat(files): surface .pad files under the 'Documents' type filter (#27)#130Jaggob wants to merge 1 commit into
Jaggob wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 94f3498cce
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
12a53f2 to
9d7fa47
Compare
Alias the `application/x-etherpad-nextcloud` mimetype onto the core `x-office/document` type in the RegisterMimeType repair step. The Files type filter matches a node against each category's mimetypes including the mimetype alias (`OC.MimeTypeList.aliases[mime]`), so aliased pads appear under the built-in 'Documents' filter — no DOM patching, no JS bundle, no new runtime dependency, and it works across the supported NC range. The browser alias map lives in core/js/mimetypelist.js, which Nextcloud does NOT regenerate on app install/enable — so the repair step now regenerates it itself (best-effort: mirrors maintenance:mimetype:update-js via the public getAllAliases/getAllNamings + the core file builder, guarded by class_exists / method_exists / writability and a try/catch; falls back to logging the manual command). Without this the Documents filter would only pick up pads after a manual `occ maintenance:mimetype:update-js`. Icons: the file list keeps the pad glyph (PadPreviewProvider thumbnail), and the 'New' menu uses its own etherpad icon; the generic document icon only shows on no-preview surfaces (file-picker / search). The obsolete custom mimetype-icon sync is dropped. Verified live on NC 33 via occ maintenance:repair: the alias is written and mimetypelist.js is regenerated automatically; pads show under the Documents filter, file-list pad icon preserved. PHPUnit 409 + Psalm green; Playwright 23/23. Closes #27.
9d7fa47 to
1748c07
Compare
3 tasks
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.
What
Make
.padfiles appear in the Files app's type filter, without DOM-patching the (non-public) filter Vue UI.Approach
Alias the
application/x-etherpad-nextcloudmimetype onto the corex-office/documenttype in theRegisterMimeTyperepair step. The Files type filter matches a node against each category's mimetypes including the mimetype alias (OC.MimeTypeList.aliases[mime]), so aliased pads show up under the built-in Documents filter. No JS, no new dependency; works across the whole supported NC range (the mimetype-alias mechanism is stable, unlike the v4-onlyregisterFileListFilterAPI).Regenerating the browser alias map (the important bit)
The type filter reads
OC.MimeTypeList.aliases, which is baked intocore/js/mimetypelist.js. Nextcloud does not regenerate that file on app install/enable — so without action the alias would sit inconfig/mimetypealiases.jsonbut the filter wouldn't pick pads up until someone ranocc maintenance:mimetype:update-js. The repair step therefore regeneratesmimetypelist.jsitself (best-effort): it mirrors the maintenance command using the publicIMimeTypeDetector::getAllAliases()/getAllNamings()plus the core file builder, guarded byclass_exists/method_exists/ writability checks and atry/catch, and falls back to logging the manual command on any mismatch. (Thanks @codex for catching this.)Icons
The file list keeps the pad glyph (rows render the
PadPreviewProviderthumbnail, not the mimetype icon) and the "New" menu uses its own etherpad icon. The generic document icon only appears where no preview is rendered (file-picker dialogs / search). The now-obsolete custom mimetype-icon sync is dropped.Acceptance
.padfiles appear in the Files type filter (under Documents)info.xmlNC rangeVerification
occ maintenance:repair: the alias is written andmimetypelist.jsis regenerated automatically (confirmed by blanking the alias from the JS and watching the repair step restore it). Pads show under the Documents filter; file-list pad icon preserved.Diff
lib/Migration/RegisterMimeType.php(alias + JS-map regeneration, drop obsolete icon sync),.gitignore(ignore stray root screenshots/probe scripts).Closes #27.