Repeater admin input uses formatted field value, causing Hanna Code to be replaced on save

[Alfred-Bes]

Repeater admin input uses formatted field value, causing Hanna Code to be replaced on save

With the help of AI, I was able to trace what appears to be the cause of this issue: output formatting seems to remain enabled while repeater inputfields are created in the admin.

I found an issue with a multilingual text field inside a Repeater.

Environment

ProcessWire 3.0.255
FieldtypeRepeater
FieldtypeTextLanguage
TextformatterHannaCode

The multilingual text field has TextformatterHannaCode assigned.

Example value:

A [[test]] B [[hanna_test]] C

Where:

[[test]]

is not an existing Hanna Code, and:

[[hanna_test]]

is an existing Hanna Code that outputs:

HANNA-TEST

Actual behaviour

After saving the page, the database still contains the correct raw value:

A [[test]] B [[hanna_test]] C

However, when the repeater item is rendered again in Page Edit, the input field contains:

A [[test]] B HANNA-TEST C

So the existing Hanna Code is already formatted before being placed into the admin input field.

At this point the database is still unchanged.

If the page is saved again, the formatted value is submitted and the database is then changed to:

A [[test]] B HANNA-TEST C

The original Hanna Code tag is therefore permanently lost.

Expected behaviour

Admin input fields should always receive the unformatted/raw value:

A [[test]] B [[hanna_test]] C

Hanna Code should only be rendered for frontend/output formatting.

Cause / workaround

The issue appears to be related to output formatting being enabled on the repeater item when its inputfields are created.

In:

/wire/modules/Fieldtype/FieldtypeRepeater/InputfieldRepeater.module

the current method is:

protected function getRepeaterItemInputfields(Page $page) {
	return $page->template->fieldgroup
		->getPageInputfields($page, "_repeater{$page->id}");
}

Changing it temporarily to:

protected function getRepeaterItemInputfields(Page $page) {

	$of = $page->of();

	$page->of(false);

	$inputfields = $page->template->fieldgroup
		->getPageInputfields($page, "_repeater{$page->id}");

	$page->of($of);

	return $inputfields;
}

completely fixes the issue.

With this change:

Database: [[hanna_test]]
Admin:    [[hanna_test]]
Frontend: HANNA-TEST

as expected.

So it seems that getPageInputfields() is currently receiving a repeater Page with output formatting enabled, causing textformatters to be applied while populating admin input fields.

I also checked ProcessWire 3.0.259 and the current dev branch, and the relevant code appears to still be unchanged.

This used to work correctly in older ProcessWire versions.

[adrianbj]

@Alfred-Bes - can you please test on the latest dev version - I'm not sure but I wonder if processwire/processwire@24ade9a might have fixed your issue as well?

[Alfred-Bes]

@adrianbj - Thanks. I tested this on the latest dev version, ProcessWire 3.0.271.

Unfortunately, the issue is still present there.

The Repeater module is still version 111, so that part has not changed either.

I also did another test that may be relevant: I created a new repeater field, but added the exact same existing multilingual field (button_txt) to it. In this newly created repeater, Hanna Code works normally and the raw tag remains intact in Page Edit.

That makes me think the underlying cause may be similar to my earlier issue:
#2249

The original repeater that shows the problem was created a long time ago, when the site was still running ProcessWire 3.0.174. I later made a fairly large jump in ProcessWire versions.

So it now looks like repeaters created under an older ProcessWire version may retain some legacy configuration or state that behaves differently after upgrading, while a newly created repeater using the same fields does not show the issue.

Without my workaround, the old repeater still behaves like this:

Database after first save:
A [[test]] B [[hanna_test]] C

Page Edit after rebuild:
A [[test]] B HANNA-TEST C

At that point the database is still unchanged. Only after saving the page again is the formatted value written back to the database.

Applying the workaround around getPageInputfields() fixes the issue:

protected function getRepeaterItemInputfields(Page $page) {

	$of = $page->of();

	$page->of(false);

	$inputfields = $page->template->fieldgroup
		->getPageInputfields($page, "_repeater{$page->id}");

	$page->of($of);

	return $inputfields;
}

This workaround is not intended as a proposed final solution, but mainly as a proof of where the issue appears to occur and of what change prevents it.

So commit 24ade9a does not appear to fix this particular issue, and the fact that a newly created repeater works correctly may point to a legacy repeater configuration/state dating back to ProcessWire 3.0.174.

[adrianbj]

@Alfred-Bes — thanks for the excellent diagnosis; your workaround was pointing at exactly the right place. I've tracked down the underlying cause and it also explains your old-vs-new repeater observation (and the prefill failure in your #2249).

FieldtypeRepeater::formatValue() enables output formatting on the repeater item Page objects themselves, and those same objects are shared with the unformatted value. So whenever anything gets a formatted value of the repeater field while Page Edit renders — typically a hook or module building an SEO preview, sitemap entry, etc. — the item pages are left in a formatted state, and InputfieldRepeater then builds its inputs from formatted values (Hanna Codes rendered, language values collapsed to a string). The next save writes those back to the database. That's also why only your old repeater is affected: it isn't legacy field config — it's that only the old field is referenced by whatever module does a formatted get during the edit render; your newly created field isn't in any module's config yet, so nothing flips its items.

Proposed fix, essentially your workaround formalized in the same pattern the module already uses on the processing side (formToPage()): now opened as PR processwire/processwire#353 (commit 9dd6955a) — it guards getRepeaterItemInputfields() with an of(false)/restore toggle, covering regular repeaters, FieldsetPage and ajax-loaded items, and adds a regression test that fails on the current code and passes with the fix. Verified against a real install using TextformatterEntities as a stand-in for Hanna Code.

[ryancramerdesign]

Thanks for the detailed report and follow-up testing, and thanks to @adrianbj for tracing the shared repeater-item state and preparing PR #353. This is fixed in commit 8faf7c4b. Repeater item inputfields are now always populated from raw values, while their prior output-formatting state is restored afterward. This prevents formatted Hanna Code, entity-encoded text, and collapsed language values from being written back on the next save.