Add imagify_get_mime_types filter to imagify_get_mime_types()

[Miraeld]

Description

Closes #1177

Adds a filter on the return value of imagify_get_mime_types(), allowing developers to customize the mime types Imagify considers optimizable when checking whether a file is supported.

This PR adopts community PR #1177 from @mauroTabsSpaces (credited as commit co-author), which originally proposed a plain apply_filters() call. Per our project standard, it was converted to wpm_apply_filters_typed( 'array', 'imagify_get_mime_types', $mimes ) and a filter docblock was added. We adopt it internally because fork PRs cannot pass CI here: our integration tests require the IMAGIFY_TESTS_API_KEY secret, which GitHub does not expose to workflows triggered from forks.

Type of change

• New feature (non-breaking change which adds functionality).
• Bug fix (non-breaking change which fixes an issue).
• Enhancement (non-breaking change which improves an existing functionality).
• Breaking change (fix or feature that would cause existing functionality to not work as before).
• Sub-task of #(issue number)
• Chore
• Release

Detailed scenario

What was tested

• Manual: Without a callback registered, imagify_get_mime_types() returns the same array as before (default passthrough — no behavior change for existing sites). With an add_filter( 'imagify_get_mime_types', ... ) callback registered, the returned array reflects the callback's modification. A callback returning a non-array value is coerced back to an array by wpm_apply_filters_typed, protecting callers from invalid filter output.

How to test

1. In a mu-plugin, add: add_filter( 'imagify_get_mime_types', function( $mimes ) { unset( $mimes['pdf'] ); return $mimes; } );
2. Verify PDFs are no longer treated as optimizable (e.g. bulk optimization / media library no longer lists PDFs as supported).
3. Remove the filter and confirm behavior returns to the default (PDFs supported again, depending on the $type argument passed to imagify_get_mime_types()).

Affected Features & Quality Assurance Scope

• imagify_get_mime_types() in inc/functions/attachments.php — used by mime-type support checks across the plugin. Default behavior is unchanged when no filter callback is registered, so regression risk is limited to code paths that explicitly hook into the new filter.

Technical description

Documentation

New filter imagify_get_mime_types:

• Signature: wpm_apply_filters_typed( 'array', 'imagify_get_mime_types', $mimes )
• Param: array $mimes — mime types as extension => mime type pairs. Contains images and/or PDF depending on the $type argument passed to imagify_get_mime_types().
• Since: 2.3.1

New dependencies

None.

Risks

None identified. The change is additive (a new filter hook around an existing return value); with no callback registered, output is identical to before. wpm_apply_filters_typed( 'array', ... ) enforces the return type, so a misbehaving third-party callback cannot corrupt the mime types array with a non-array value.

Mandatory Checklist

Code validation

• I validated all the Acceptance Criteria. If possible, provide screenshots or videos.
• I triggered all changed lines of code at least once without new errors/warnings/notices.
• I implemented built-in tests to cover the new/changed code.

Code style

• I wrote a self-explanatory code about what it does.
• I protected entry points against unexpected inputs.
• I did not introduce unnecessary complexity.
• Output messages (errors, notices, logs) are explicit enough for users to understand the issue and are actionnable.

Unticked items justification

• No new automated test was added: the change is a single-line addition of a wpm_apply_filters_typed() call around an existing return statement, with no branching logic to cover. Manual verification (see "What was tested") confirms both the default passthrough and the filtered path.

Additional Checks

• In the case of complex code, I wrote comments to explain it.
• When possible, I prepared ways to observe the implemented system (logs, data, etc.)
• I added error handling logic when using functions that could throw errors (HTTP/API request, filesystem, etc.)

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 duplication

Metric	Results
Duplication	0

View in Codacy

🟢 Coverage 100.00% diff coverage

Metric	Results
Coverage variation	Report missing for 3fb41021
Diff coverage	✅ 100.00% diff coverage (50.00%)

View coverage diff in Codacy

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (3fb4102)	Report Missing	Report Missing	Report Missing
Head commit (325baa8)	19540	647	3.31%

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#1184)	8	8	100.00%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

¹ Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct.

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}