Jump to content

Fields not saving in repeater


Pierre-Luc
 Share

Recommended Posts

I have 2 simple text fields next to a checkbox and date picker, all into a repeater, which are not saving. They both represent a time value and have the following options activated :

  • Striptags: On
  • Size and MaxLength: 10
  • Pattern: ^(0?[0-9]|1[0-9]|2[0-3])(:[0-5][0-9])$

I've ran out of ideas on what could cause it. Any help is appreciated, I can give any of you access to the dev site if needed. This is on 2.4 stable.

Link to comment
Share on other sites

I have recently updated a project (dev) to latest PW and some fields aren't saving anymore. Like image description, some dropwdown in a repeater etc. This has been working fine for months (1year) now and suddenly many problems arrived.

Link to comment
Share on other sites

Ok just updated to 2.4 latest, still same problem.

I have some hooks that hook into page save and do manipulation on data. After disabling them it seems to work again. So this raises the question what has changed in PW that those make such problems in that it doesn't save. They're pretty basic simple one before save and one after save. Makes me kinda worring about doing such thing in PW suddenly it seems that they're not as future save as I thought.

Edit: seems I got it working again . Well it seems I have done some trackChange in there when cycling repeaters in the save hook. Not sure why I had them in there. Also changed the hook to Pages::saveReady and am not saving the page, just the repeaters.

Link to comment
Share on other sites

I was able to isolate the bug and replicate it. I deleted all my fields including the repeater and started anew.

The structure is as such:

event_dates -- repeater, mandatory
    event_day -- date (Y-m-d)
    event_allday -- checkbox
    event_day_start_time -- inputtext with regex
    event_day_end_time -- inputtext with regex

They all display at 50% to make a 2x2 grid.

The bug happens when I put a visibility constraint on event_day_start_time and event_day_end_time of event_allday=0. This happens whether or not there is a display rule.

I am unsure this bug also applies to other field types or when fields are outside a repeater where the visibility is also constrained by a checkbox or another kind of field. I'm in rush mode to have it go live by yesterday.

Link to comment
Share on other sites

Repeater doesn't support field dependencies (yet). Or is it in already?.

Not sure what you meant to reproduce, but don't ujderatand. All works fine... except if you have advanced hooks or something.. Like me. :)

Any 3rd party modules installed like any of Nico Knoll?

Link to comment
Share on other sites

Is that so that the repeater doesn't support field dependencies Ryan ? This is mentioned nowhere in the documentation or in the UI. That would be extra helpful to have it mentioned on both the repeater and inputfield-dependencies pages if that's the case.

What I meant to reproduce is the two time fields not saving any data whatsoever when there are visibility rules.

I don't have anything weird installed : Images with cropping, Map Marker, CKE, HTML Purifier, Video embed...

Link to comment
Share on other sites

  • 1 month later...

Just chiming in to say I've run into the same problem. I'd love to see a fix for this, since I consider inputfield dependencies a killer feature from a usability standpoint!

Since the Issue was closed I thought I'd ask here: Is support for dependencies inside a repeater actually planned for a future release?

  • Like 1
Link to comment
Share on other sites

  • 3 months later...

It's not directly a workaround, but you could use the current dev version of processwire. There you could replace repeaters with PageTables. They have a quite similar functionality, but use real pages, where the dependencies should work.

  • Like 1
Link to comment
Share on other sites

I was using the repeaters to add variable content. Each repeater had a dropdown with options "Header", "Text", "Image". Selecting one would reveal a corresponding field. So the admin is able to add a varying number of different types of field in a custom order. Would I be right in saying PageTables create a new page for every "repeater"? I've just updated to the dev branch and tried to use PageTables, but it's asking for a title/name for every content section I want to add, which is not really what I want to do as I'm trying to add fields, not pages.

Link to comment
Share on other sites

Repeaters are actually dynamicly created pages with more or less random names. As long as you do not render the name/title of those PageTable pages, there not that much different from handling repeater pages, you could name them however you want. The biggest different would be, that the created pages show up in the pagetree.

  • Like 1
Link to comment
Share on other sites

Ah, that's interesting to know.

I think the main problem with the PageTable solution is the requirement of entering page titles for every content section (which are a single fields my case). Unfortunately it's too time consuming when adding a lot of content as it essentially doubles the number of required fields. I'm also not so keen on the idea of convincing a client to enter data which in every case is unused/redundant.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...