K Phoenix

Thank you both for your replies! Either of those should work, I think, although I ended up going with Martijn's solution for now since it saves me a few fields. (Wish I could mark both as solved, since teppo's contains the explanation for why it doesn't work as-is!) Unfortunately it's going to make some later parts of my templates a hair more complicated than they were going to be, but nothing unmanageable. I guess that's just what happens when large parts of your code rely on something that doesn't actually work, haha. The circular reference issue makes sense now that you mention it, although it's still kind of odd that I got it working earlier—I had that test project set up and "functioning" well before adrian made that report in September, and it still works now even after a few updates. Maybe it's because it behaved differently in an earlier version, and for whatever reason a later update didn't "break it" the way it should have? Ah, well, quirks happen. Thanks again for the quick assistance!

Sorry if that topic title is confusing. I'm really not sure how else I can describe the issue that succinctly! Let me clarify with an example: Say I have three pages: Type 1, Type 2, and Type 3. All pages are using the same template, type-template. I also have three Page fields: Field A, Field B and Field C. All are dereferenced as multiple page/PageArray, and all are set to choose pages with the above type-template, using checkboxes if that matters. This means that my page choices for Field A are Type 1, Type 2 and Type 3, and the exact same for Fields B and C. (Effectively, these three fields are identical; they're direct copies of one another, in fact.) These fields are currently attached to type-template and no other templates. Now say that I'm editing Type 1's page, Field A. If I select either or both of Type 2 or Type 3 in Field A, I can save the page and everything works just fine and dandy. But if I select Type 1 as an option in Field A, I get the "Error saving field "field_a" - Page #### is not valid for field_a" error (where #### is the id of Type 1). The same thing happens if I select Type 1 as an option in Fields B or C. No matter which field I'm editing, I cannot select Type 1 as an option while I am editing Type 1... ...but I can select Type 1 and save just fine if I'm editing Type 2's page. Instead, Type 2 becomes "invalid" while I'm editing the Type 2 page. Likewise, Type 3 is "invalid" only while I'm editing Type 3, and perfectly acceptable on the other two Types. I'm not sure whether needing to select the current page as an option is unusual, but Field A et al. define relationships between the three Types, and I often need to say something like "dogs don't like squirrels or cats (Field A), but dogs do like people and other dogs (Field B)". Right now that "dogs like dogs" is impossible to achieve thanks to the error. I've tried changing the input field type from checkboxes to anything else that lets me choose multiple pages. I've tried all four methods of selectable pages, but I get the error whether I'm selecting using the parent, the template, a custom selector or custom PHP. I would just shrug and assume that maybe this isn't currently possible, but the really baffling part is that it should be, far as I can tell. This project is very, very similar to an earlier test project, and the other project does not have this issue. If I'm on the "dogs" page there, I can select "dogs" as an option for a field with no problem. I've been back and forth and back and forth comparing the settings of the two fields and the two templates, and I can't see a meaningful difference. Both projects are using the same version of PW (2.5.3), although the functioning one has been steadily upgraded from something like 2.4.10 and this new one was installed as 2.5.3. The only other thing I can think of right now is that the environments are different: the working one is on a remote server and PHP 5.5.7, while the broken one is on a local environment with PHP 5.4.36. I don't know; would that affect this? :/ I've done some searching around and so far have turned up a few threads on similar errors, like https://processwire.com/talk/topic/8400-possible-page-field-bug/ and https://processwire.com/talk/topic/7387-pageautocomplete-page-x-is-not-valid-for-y/ . I've tried to read through them and the threads linked within (keyword: "tried"; it's unreasonably late/early here right now and I'm about to hit the hay after posting this, so maybe another read after I've rested will reveal something!), but most of those seem to have to do with using page ids in custom selectors instead of the page names. I've tried both ids and names and still have this problem, and I've tried just using the parent/template options with similar luck. While I can move on with other parts of development (and fill in the rest of those fields) for now, this is definitely important for the site I'm building and I'll need to figure something out eventually. Any insight you knowledgable folk can give me—any fixes, any PHP settings that might somehow be the culprit, anything painfully obvious I might've missed at this unfortunate hour—is much appreciated! And let me know if you need me to provide any more information. Thanks!

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.