Repeater issues after master upgrades with multilang fields, data loss possible

[skeltern]

Setup:

• ProcessWire upgraded from older version (e.g., 3.0.227) to version 3.0.246 or dev 3.0.247
• Repeater field is a child in a Matrix Repeater item (probably same issue for Repeater in Repeater)
• Repeater field was created in a master version under the latest master (e.g., in 3.0.227 or 3.0.210)
• Repeater field contains anyone multilang field (text/textarea)
• PHP 8.3 and PHP 8.4, MariaDB 10.11.11

Issue:

• All multilang fields in described context are visible and filled in the backend with a fresh CMS user session (cleared browser history)
• After the first CMS page save in a user session, all such multilang fields on all backend pages lose their value="saved input" attribute (except default language)
• Therefore, any following page save action unintentionally removes all such multilang inputs for all multilang fields (except default language)
• I have already lost some multilang inputs and didn't even realize it, because the default language works fine and is visible by default

Tests:

• This issue seems connected with a session cookie (repeaters_open) and the setting "Remember which repeater items are open? > Yes"
• Setting "Remember which repeater items are open? > No" means all multilang fields work as expected (filled with value="saved input")
• Removing the session cookie "repeaters_open" also shows all multilang fields again until next page save action
• Only older repeater fields are affected (e.g., created in 3.0.227 or 3.0.210), but surprisingly not newly created ones (in 3.0.246+)
• I tried to find a difference between older (issue) and newer (working) repeater fields, but I didn't find any differences
• I can reproduce this issue on 5+ different multilang sites with 2-7 active languages on two different web hosts

Workaround:

• Deactivate "Remember which repeater items are open?" which means you have to open each path after each page save...
• Full CMS (/wire/) downgrade to the latest master version under 3.0.246, specifically to 3.0.227 (my temporary solution)

[ryancramerdesign]

@skeltern Thanks for the report. I've tried a few times, but not having any luck duplicating this. I'm testing on an old multi-language installation where the repeaters were created and populated a long time ago, in the early 3.x versions. I've turned on the "remember which items open" for both the matrix and the nested repeater. I've tried making edits in various open/closed contexts, but haven't been able to lose any content. I'm wondering if you are seeing any JS errors in your console? Are there any other site modules installed on all the installations where you can reproduce it? The only other thing I notice from your screenshot is that you are using an old admin theme, so wondering if you can try with the current theme (AdminThemeUikit), just in case?

[matjazpotocnik]

@skeltern, can you test with dev versions from 229 up to the point where you encounter problems? That would most likely help in solving this issue.

[skeltern]

@skeltern, can you test with dev versions from 229 up to the point where you encounter problems? That would most likely help in solving this issue.

Good idea, thanks. I would do this, but I only see legacy master versions (https://github.com/processwire/processwire/tags). Is there a repository or download option for individual dev versions? The Upgrades module only refers to the newest versions. By the way, I don't use Composer for ProcessWire and would install minor dev versions the old-school way.

[skeltern]

@skeltern ...I've tried a few times, but not having any luck duplicating this...

Many thanks for checking out my issue. The console is clean, and it makes no difference whether I use Admin Classic or UIkit. I tried a lot of things before I opened this thread. All affected sites are sharing the site modules Repeater Matrix and Upgrades.

Next, I tried a clean install of version 3.0.227 and created the issue context. Then, I upgraded to the latest version, 3.0.247. There were no issues at all. It seems that only older installs are affected (created between 2019 and 2023) with a longer upgrade queue (ProcessWire and Modules)?

I'm not sure how to recreate the issue from scratch. So, I just duplicated an affected website (created in spring 2021) and removed all unnecessary stuff. There are only some fields and one page with the described issue left. It's technically separated, so I could provide ProcessWire superuser and FTP access (via email) if that makes sense.

Some more tests revealed that it's connected with the setting "Remember which repeater items are open?" set to "Yes". Page save actions with a closed Repeater item in a Repeater Matrix item work. However, with an open Repeater, each multilanguage value is no longer displayed as value="" and gets lost on the second page save. I can delete the cookie "repeaters_open" in the dev tools to see the multilanguage values again until the next page save.

Every idea is welcome.

[matjazpotocnik]

@skeltern, can you test with dev versions from 229 up to the point where you encounter problems? That would most likely help in solving this issue.

Good idea, thanks. I would do this, but I only see legacy master versions (https://github.com/processwire/processwire/tags). Is there a repository or download option for individual dev versions? The Upgrades module only refers to the newest versions. By the way, I don't use Composer for ProcessWire and would install minor dev versions the old-school way.

Download dev versions as zip file and replace current wire directory with the wire directory in the zip file. I usually start in the middle of the current working version and the latest master/dev. Here are the links to some dev versions:

3.0.243 https://github.com/processwire/processwire/tree/94bc7c346eb809e4b492b9512299c962759782ef
3.0.240 https://github.com/processwire/processwire/tree/38a5320f612a4b38a7353265343219f224f20e6d
3.0.236 https://github.com/processwire/processwire/tree/71a1e9c9d9c5d3a28ae6af86514a9abd49b2ce7e
3.0.232 https://github.com/processwire/processwire/tree/dabc56043ff86f60985fc6daff172dd0963aa90a
3.0.229 https://github.com/processwire/processwire/tree/390ad61ce3d02bf86079384310772590c097e733

So, start with 236, if it's working try 240, if not try 232. On GitHub https://github.com/processwire/processwire/commits/dev you can click on < > to view repository at every commit.

[skeltern]

@matjazpotocnik @ryancramerdesign Matjaž, many thanks for help!

I figured out that my described issue first appears in version 3.0.237. So, I checked out all commits/changes between versions 236 and 237. I was able to narrow down the problem to ".../FieldtypeRepeater/FieldtypeRepeater.module". There are only a few code changes between those versions and I tested them all by trial and error. A small code addition is the troublemaker in my specific context.

• wire/modules/Fieldtype/FieldtypeRepeater/FieldtypeRepeater.module (Line 1371)
• $p->of(true); // ensure RepeaterPage items also formatted)
• Commit

Without this line, everything works as expected again, even in the latest version 247. It would be nice to get rid of this issue in an upcoming release. I am wondering if I am the only one experiencing these hiccups. Maybe it's a rare context and only occurs in multilingual settings.

I don't have a clue about the dependencies here and output formatting. I could only provide access to my test system to see and trace the issue.

[adrianbj]

@ryancramerdesign - can we assume this is what caused my RM issue: https://processwire.com/talk/topic/31047-nearly-lost-a-lot-of-content/#comment-247921