Support

Account

Register Login

Forum Replies Created

  • Hi @felixzb2 I have this exact problem. Did you ever figure out a solution?

  • I can confirm that I am seeing the same bug with 5.8.1.

    Thanks for the suggested patch.

  • Okay, a full night’s sleep allowed me to figure out the obvious solution:) I just used a little logic to check the page template. Although I did have to make sure to exit out if there was no change so the “Title” label showed up on other forms as usual. 

     function my_acf_prepare_field( $field ) {
	
    if ( is_page_template('my-page-template.php') ) {
       $field['label'] = "Changed Label";
       $field['instructions'] = "Changed Instruction";    
    }
    
    if ( $field ) {
        return $field;   
    } else {
        exit;
    }
}
add_filter('acf/prepare_field/name=_post_title', 'my_acf_prepare_field');

  • Hi James — I just implemented this and it works. However, it changes the name of my Title field on all my front-end forms. I’m trying to figure out how I might apply this to just one form. Any suggestions?

  • Hi Jonathan,

    That’s a very thoughtful response and I appreciate it. But I think we got off track with your first assumption. All the information is specific to a company. So each CPT “reports” post is built around a single company.

    Let’s see if I can give you a visual…

    We have a custom post type called “reports” and we write a single report for each company.

    CPT “Reports”:
    –Company A
    –Company B
    –Company C

    So in the example above we have three “posts” in our custom post type.

    Each post makes use of several dozen custom fields, including text, selects, taxonomies and repeaters, etc.

    CPT “Reports”
    –Company A
    — title
    — description
    — taxonomy
    — repeater for “events”
    — event 1
    — event 2
    — etc.
    — commentary
    — price
    — etc
    –Company B… same fields as company A
    –Company C… same again…

    Now, the report is published and a customer can view the report for Company A. This is the key–> when things need to be updated, the analyst uses a front end form to go into that Company A “reports” CPT and he updates the post. (In other words, he does NOT create a new report for that company.)

    (It is important that the analyst works on a single view of the company on one page/form — it would be difficult to enter information about a company by jumping around to different forms.)

    Some fields in the report never change — like “title.” Some fields are overwritten, like “price.” Other fields are added to over time, like the repeater field on “events.” We do this because we keep track of historical events that were logged over time and we display them in a data table.

    The setup is working great for us except for the fact that those repeater fields will get very long over time.

    Does that make more sense?

  • Hi Jonathan,

    Sorry — I might not be explaining things correctly. As you say, we are already set up so each report is a custom post type and each single report is made up of a bunch of fields. So let me give you a more specific example:

    One field in our front-end form uses a repeater to enter ‘events’ that occur on a ‘date.’ Say, an ‘Earnings announcement’ happened on ‘April 14th.’ Reports are edited weekly by returning to the front-end form to make edits.

    After a while — say one year — there may now be 50+ entries in that one repeater field (and there are more repeaters in the form). Soon there may be 100 or 200 entries. So when the analyst goes to the form to enter another ‘event’ — they have to scroll through all the previous entries to get to the bottom to enter a new event.

    This is where creating pagination, in a repeater field, in a front-end form, would help compact things. Does that make more sense? Screenshot attached.

    Dan

    Screen-Shot-....png

  • Hi Jonathan,

    I am trying to solve a similar problem but I’m not sure I follow your suggestion.

    We created a front-end form, only available to admins. We use a couple repeater fields set up as tables, where each entry is basically a single line with a couple of items (a date, a couple words of text and a checkbox or two). The entries update a custom post type (a “report”) and we paginate the results to the end-user using jQuery Bootgrid (which works great, btw).

    Our problem is on the form. Since the reports are updated weekly it doesn’t take long for the repeater fields to get lengthy. We’d like to paginate the repeater in the front-end form for the authors (who will mostly be working with only the latest 3-4 entries in the repeater anyway).

    I tried implementing the jQuery Bootgrid approach on the form, but there are too many jQuery conflicts to make it work. Can you give me more details on your suggestion above? Perhaps you’re suggesting some way to only display X number of results in the repeater in the front end form?

  • Everything seems to work fine now. It seems the changes I implemented above cause some errors with another plugin that were not cropping up until we added these. They’re fixed now, and that plugin was custom database development so I don’t imagine it affecting anyone else.

    Thanks for the help — things are working great now and all of our reports are showing the “last updated” date.

  • Ok, thanks. I think I was able to get this working. The post_modified date is now updating when we edit on the front end. However, I am also seeing new errors pop up with another plugin, so not sure if I did this right. (It’s possible these errors may not be related.)

    I’m not that familiar with the wpdb class so let me know if anything looks incorrect.

    Here is my code:

    function my_acf_save_post( $post_id ) {

  // bail out early if we don't need to update the date
  if( is_admin() || $post_id == 'new' ) {

     return;

   }

   global $wpdb;

   $datetime = date("Y-m-d H:i:s");

   $query = "UPDATE $wpdb->posts
	     SET
              post_modified = '$datetime'
             WHERE
              ID = '$post_id'";

    $wpdb->query( $query );

}

// run after ACF saves the $_POST['acf'] data
add_action('acf/save_post', 'my_acf_save_post', 20);

    Thanks!

  • Using ACF v5.2.6

    It seems to happen mostly with repeaters. Using select fields within the repeaters. The selects are using the jquery chosen function. (Not sure if this is ACF or my theme.)

    For some reason the chosen function is deciding to display the selects as disabled.

    I’ve learned can get the selects to work if I choose “stylised UI” in the options. I’m guessing this bypasses the chosen js function, which is why they work.

    So it’s a workaround that moves me forward, but doesn’t solve the mystery.

Viewing 10 posts - 1 through 10 (of 10 total)