Repeaters Not Saving Consistently / Odd Behaviour

[sharpenator]

Hi all

I've just taken over the codebase for a new site in development that uses ProcessWire, and so far I'm really impressed with it all, and have managed to find solutions to all my problems to date. Thanks so much for everyone who has contributed to the project so far.

However - there is a problem that has cropped up with some of our pages and I can't find any mention of it anywhere online.

When editing in the CMS, some repeaters get into a state where new edits are no longer saved. So you make an edit, hit save, get the "page has been saved" message, but they are just as they were before. Interestingly though, if you add or delete a new repeater block at the same time as editing any of the repeater blocks, the changes are then saved properly. Similarly if you edit any other normal field on the page, along with one of the previously "unsaveable" repeater fields, the changes are saved properly too.

Has anyone seen this problem in the past?

We are running a fairly old version of PW (2.2.12), so I'm happy to upgrade if this was a known issue that has been sorted.

Thanks

s

[Nico Knoll]

I think you should make a backup and try to upgrade it. Shouldn't break anything and repeaters should work better afterwards

[sharpenator]

Has this been a known issue in the past then that you've heard of?
Would be kinda cool to know if an upgrade will sort this before I go there.

[Nico Knoll]

Well.. I never heard about this error before. But I think it's always a good thing to stay updated because of compatibility and stability reasons. And I think Processwire kind of releases a huge updated only once a year this shouldn't be as annoying as with WordPress which offers an update like every day.

And I think that repeaters were more like in a beta stage in 2.2 or at least really buggy as this search will show: https://www.google.de/search?q=processwire%202.2%20repeater%20bug&rct=j

[arjen]

I've seen this before and if I recall correctly in our case this was due to a PHP version below (<) 5.3.8. When we updated the problem was gone.

[sharpenator]

OK cool - thanks for the advice, I will try upgrading PW and PHP and let you know if it solves the issue.

[sharpenator]

Hi guys
OK - so I've eventually got round to upgrading my ProcessWire install to the latest version, and I'm still seeing this issue - repeaters in certain templates not saving at all, unless I edit the amount of repeaters or a different field elsewhere in the page - see my original description above. Also I've noticed that if I change the "ready-edit-items" number in the settings for the repeater, this seems to have no impact at all, i.e. it always just gives me the default 3 items?

Can anyone suggest a fix or way of debugging this?

Thanks

s

[arjen]

Did you also manage to upgrade the PHP version? That solved it in our case. Also make sure you meet the requirement for MySQL (> 5.0.15). Furthermore when something seems a bug try to replicate it in a brand new install.

[sharpenator]

Yes my PHP and mySQL are all over the required minimums too.

[arjen]

Did you try a fresh install? The point is there could by any number of reasons it won't work, i.e. from interfering jQuery scripts to conflicting modules. If it works in a fresh install, you've narrowed it down to your own installation.

[sharpenator]

Well I've got the latest version of PW in there, but not sure I want to go for the complete fresh install route quite yet - this is a mature site back-end and there's a tonne of content in there too. Sounds like it might be related to a 3rd party module or some of our own code somewhere though, if this hasn't been a well-known problem in the past. I'll debug on the browser side to see what might be going on when saving - something in there isn't registering the fact that input field(s) have changed their content I'm guessing, or it could be on the database / back-end saving side too I guess, but perhaps less likely.

[arjen]

I don't mean that you completely rebuild your website Just try to narrow down your options and install a fresh PW and recreate the repeater setup. That's ten minutes at most. If you can rule out a ProcessWire bug you can dig deeper.

[sharpenator]

Well the pages and repeaters across the site have been working fine for a while, it's only now that our editing team are using it properly that this issue was noticed. The saving works fine when editing some pages using exactly the same template - so I'll do some more testing and try and find out what the broken pages that won't save have in common.

[cstevensjr]

Yes my PHP and mySQL are all over the required minimums too.

It would help if we knew what versions of PHP and MySQL you are now working with.  

You originally stated that you were working with an old version of PW.  To help anyone properly troubleshoot your issue it would be extremely helpful to know what upgrades you have done to your infrastructure (Apache, PHP, MySQL) so far.

Are you able to create a development site and import your data to properly test any proposed fixes before committing further changes to your production website?  I would suggest you remove all third party modules, in a testing environment.  If you then continue having problems then it points exactly at your core install.  If the problems go away, then you need to troubleshoot which third party module is causing the issues.  I would suggest adding a third party module at a time until the problem reoccurs.

Finally, you should also let us know whether the modules (Core and 3rd Party) on your website are at the current release versions.  Just an FYI, having PHP and MySQL above the minimums and having up-to-date software are 2 separate things.  I do believe this great community will do it's best to help you resolve your issues.

No matter what, these are just suggestions that follow basic troubleshooting criteria.

[sharpenator]

I can give more info for sure, thanks for your help guys.

PW 2.4.0

PHP 5.3.22

MySQL 5.1.53

Apache 2.2.17

This issue has been seen across other servers too, some windows (local devs) and some linux (staging / live). I've upgraded my local dev version to the spec above to try and sort this issue out basically - so I have some freedom to play around with testing etc. As I mentioned before it's only on some pages this is happening - some of the pages edit absolutely fine that use the exact same template, so I'm thinking there might be something in the content iteslf that might be affecting it.
Can anyone guide me to the right part of the PW code that is triggered when you hit save in the CMS editor (client or server side pointers are all helpful).
Thanks again

s

[teppo]

Just a quick update: I've been experiencing this issue on a couple of sites too. Don't have a definite solution, but it's great (well, in a way..) to know that it's not just me.

So far all I know is that this is quite likely connected to change tracking and triggered only by very specific conditions -- having a repeater with Page type field in it and selecting root page more than once triggered it in one specific case, but only if there was more than one repeater on that page (etc.) Kind of hard to post an issue for it when it happens on one site but identical setup built from scratch doesn't suffer from it

Note: I can confirm that PW version doesn't matter here.. at least around 2.4.5 the issue still persisted. I'm not aware of any updates that could've fixed this since then.

[sharpenator]

Ah ok cool.

Yes - in my current set up I have some pages that it always happens for, and some that seem to save fine, so I'm trying to spot patterns now in the ones that don't work, and creating pages from scratch to try and get some repeatable steps here for other people to try. No luck yet, but early days. It would also be good to establish if it's a client side issue - i.e. is there something in the "this field has changed" js code that that is breaking in certain circumstances.

[sharpenator]

OK - update on this, thanks to teppo for getting me curious about page type fields. I can now recreate the bug  - there is a certain page field in the template involved, which uses the PageListSelect input type for a single page. If there's something selected in there, the repeater lower down the page doesn't save properly. If I unselect the page, bingo - the repeaters lower down in the page save fine again. To be clear - the page field is not in the repeater, it's in a completely section of the content.

Will do a bit more investigating and come up with a simple recreatable case soon.

Thanks everyone for your help thus far

[sharpenator]

HI there

So I haven't been able to recreate a simpler test page for you to try and recreate this issue yet, but some more observations as I work through this

- Once the "naughty" page select item has something selected within it, the repeater save issue is there for all repeaters on the page

- It doesn't matter what type of selector I use, the bug is there for all types (.e. Asm vs select vs whatever)

- It doesn't matter if the page item is a multiple or single, or null vs boolean in those options

- The position of the page item within the page content structure has no bearing on the bug

- I have deleted and recreated the page field from scratch and the bug is still there

- There are other page items on the page, so there might be something in teppo's suggestion that multiple page fields could cause this

- From a quick debug, it looks like the new repeater edit data gets through to the backend, but for some reason it doesn't register as a field that has changed when the page field elsewhere in the page has something selected

Will keep you posted on further investigations, but if anything here sparks a light bulb or something I can test out, please let me know - I don't actually have a workaround for this issue yet, other than getting content editors to add and delete a new repeater item each time they edit, which is not great really.

Thanks

s

[sharpenator]

OK final say on this one, I have a workaround now

- When going through the affected template in more detail, I found a nasty repeater-within-a-repeater part of the structure that wasn't actually being used when rendering the page, but was in there nonetheless.

- I removed this from the template, which didn't fix the bug straight away

- But - I then cloned one of the pages affected, so forcing a freshly created version to be made from scratch

- The bug was then fixed in the fresh clone - i.e. repeaters seem to save ok again now, no matter what page field settings I had set

- So my plan is to go through all the pages, clone them, delete the old ones, and the rename the new ones to take their place

- I may do this programmatically using the API

- One thing I'm wary of too: obviously when deleting pages, any references to the deleted page from elsewhere in the content will get broken, so I'll need a way of fixing these, hopefully via the API too

Hope this helps anyone seeing similar weirdness

s

[arjen]

Ouch, repeater in repeater can cause strange issues > https://processwire.com/talk/topic/1358-repeater-inside-itself/page-2#entry27998

Glad you sorted it out.

[teppo]

In our case the problem wasn't repeater in repeater, so it looks to me like the underlying issue remains unsolved; I'll have to continue debugging that one at some point, but for now it's great to hear that your case was resolved. Hopefully I'll be able to grab something useful from what you've posted here, so thanks for that!

[sharpenator]

Cool thanks for your help guys.

@teppo I'll let you know if the "cloning all the pages from scratch" strategy works in the long run anyway.

[K Phoenix]

Hello!

Sorry for the bump, but I thought I'd drop in and mention that I'm having a similar problem. One of my repeater fields stubbornly refuses to let go of its contents, no matter how many times I try to delete them. I don't have any nested repeaters/repeaters within themselves, so that doesn't seem to be the issue here, and deleting the item at the same time I add/edit/delete another item also has no effect. I also tried copying the page with the repeater and deleting the copy's item, but that didn't work either (unless I'm misunderstanding sharpenator's suggestion).

I was running PW 2.4.10 when I first noticed it today. I tried upgrading to 2.5.0 but that hasn't changed anything. My PHP version is 5.5.7 and my MySQL version is 5.5.39. The template in question only has a title and four different (but similar) repeater fields in it. All of the repeaters are very simple, only containing three Page fields (two PageAutocomplete and one Select, if it matters) and a text field, and only one or two items per repeater on the page I'm testing at the moment, so it's not like they should be weighed down by a ton of data. Only one of the four repeaters is giving me this problem; the other three are fine.

The only way I could fix it was to remove the offending repeater field from the template entirely, thus deleting any of the associated data, and then re-add it. My project is still in the very early stages of development and I was only testing a single page, so this is no great loss for me right now, but obviously that "solution" is... not a good idea for sites that may have a lot of data in their misbehaving fields, haha. Furthermore, after re-adding the same field and trying to add another item to that repeater, the item got stuck again.

I think next I'm going to try deleting the broken field and recreating it, maybe rule out some accidental setting that may have caused this. The three working repeaters are nearly identical to one another, so it's possible there is some setting difference there that broke the offending one but isn't on the three others.

I may be able to live with this in the production version since I'm very unlikely to remove these items from an actual page once I've set them up, but I'd feel better knowing I had the option to if it ever became necessary—and since I'd eventually like to release a site profile version of this project, it'd be good to know that other users could delete the items normally, too.

If anyone has any other suggestions for working around this issue, I'd appreciate it. If there's any other info I can provide to help get to the bottom of this, let me know! Thanks again for such an amazing piece of software and for providing such a welcoming community.

[sharpenator]

Hi K

I have actually seen this again in another page now, so I think there is still something fishy going on with pages with repeaters and page fields in in general. The repeater I'm now seeing the issue with has 3 or 4 text fields and am image, and not all pages are affected. Seems to be only pages with certain page fields set.

For the moment, my content editors are using the workaround where they edit a repeater and then add and delete a fresh one at the same time to "wake up" the "something has changed" status. It sounds like this isn't working for you though K.

Sorry I can't be of more help, I'll let you know if I spot anything else. It might be worth trying to recreate this issue constructing new fields and a template from scratch K?