refactor: finish the repeater rendering complexity

[erseco]

Stacked on #240, which is stacked on #239. Review those first; GitHub retargets the base as each merges.

Fifth and last round on class-documentate-documents.php. The file now has no method-level PHPMD alerts.

What is left

	main	#239	#240	This PR
Plugin-wide alerts	76	58	55	52

In this file, only the four class-level alerts remain. More on those below.

The last two alerts

Method	Before
render_array_field_item()	NPath 6,152 · CC 15
render_array_field()	NPath 576

Both came from redoing work the caller had already done.

render_array_field() re-resolved the repeater's title and hover text from the raw definition. But render_repeater_field_row() resolves exactly the same values before calling it — it has to, to draw the surrounding table row. The $label parameter was being handed in and then overwritten with an identical value. It now takes the hover text alongside the label and trusts both.

get_field_title() sanitizes before returning, so dropping the second sanitize_text_field() over the same string changes nothing.

render_array_field_item() spelled out, per column, the same eight lines prepare_schema_row() already spells out per schema row:

$label = isset( $definition['label'] ) ? sanitize_text_field( ... ) : $fallback;
$type  = isset( $definition['type'] ) ? sanitize_key( ... ) : 'textarea';
$raw_field = isset( $raw_fields[ $key ] ) ? ... : array();
$type = $this->resolve_field_control_type( $type, $raw_field );
$field_title = $this->get_field_title( $raw_field );
if ( '' !== $field_title ) { $label = $field_title; }
// ...and the pattern-message-or-title dance for the hover text

Both now call prepare_field_control(). prepare_array_item_field() adds what only a repeater column needs — submitted name, DOM id, stored value, and the item schema entry the single control reads its data_type from. The three-way type dispatch moved to render_array_item_control().

Why the class-level alerts are not touched

#239 said the next step was moving repeater rendering into its own class. Measuring before writing anything showed why that does not work yet, and why no single extraction closes these:

Class metric	Now	Threshold	Gap
Lines	3755	2500	−1255
Methods	105	50	−55
Complexity	537	100	−437

The field-help subsystem — the most coherent movable unit, 13 methods — is ~252 lines. Extracting it closes zero alerts. These four need Documentate_Documents broken into several classes (metabox rendering, the save/compose pipeline, the admin list table), which is a multi-PR architectural project with a different risk profile, not a step that belongs here.

Worth stating plainly: extracting methods within one class, which is what #234, #239, #240 and this PR all did, resolves method alerts and cannot resolve class ones. The remaining four are the honest residue of that approach.

Verification

Same technique as #240, since this is again a pure rendering refactor. A schema with two repeater rows plus the clone template, four column types, titles, descriptions and validation messages, and the field-and-repeater-sharing-a-slug case was rendered against the pre-refactor code and against this one.

Byte-for-byte identical — no deliberate exception this time.

DocumentateSchemaRowTest gains six cases for the column preparation, including that the item schema entry survives the trip. That variable going missing was one of the two bugs #239 introduced, so it now has a test that does not depend on rendering a full row to catch it.

make lint      ✓ PHPCS/WPCS clean
make test      ✓ 1877 tests, 13194 assertions
make test-e2e  ✓ 73 passed, 21 skipped

[codecov]

Codecov Report

❌ Patch coverage is 97.22222% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
.../custom-post-types/class-documentate-documents.php	97.22%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!