Support

Account

Register Login

Forum Replies Created

  • Hi @geert

    Hard to know where to start…

    Okay, so most people on the web with a WordPress site probably has shared hosting (I’m guessing). They have little to no control over the servers settings and limitations. Here’s some standard PHP values which are unlikely to be set higher in such shared hosting:
    http://php.net/manual/en/info.configuration.php

    disclaimer: I’m not gonna research everything here before (limited time) so some is a little bit of guesswork when it comes to numbers.

    max_input_vars there is one of the most interesting ones. Basically it says that PHP will accept a maximum of 1000 input fields to send to a single request (page load). In the case of WP admin that would likely be a POST request. WordPress per default already have quite a bit of fields for a standard edit screen. There’s a whole bunch of hidden fields as well as formats, categories, tags, featured image, title, editor, permalink, visibility, status etc. Let’s say you also have a few regular custom fields. Then you also add a repeater field to this. Each row might contain 2-10 fields + some hidden fields ACF uses to keep track of everything. Maybe you even have nested repeaters! So for each row there’s 2-10 fields + a nested repeater which in term contains 2-10 fields. And say you add in a gallery field there as well. That’s at the very least 1 field for each image.

    You’re quickly gonna find that you hit the 1000 input vars limit if you abuse repeaters. That’s gonna stop you from adding any new content to the page before you delete other. That in itself should be enough to reconsider huge repeater fields. But to make matters worse there’s also server limits like max_execution_time and max_allowed_packet (mysql). Saving all these fields will take some time and if you’re not on a great internet connection you may hit the max_excecution_time which will lead to your page save ending abruptly and unfinished. max_allowed_packet is a variable for mySQL which basically limits how large of data chunk you may insert in one go. It’s much harder to hit but it’s possible.

    If you’d be on a VPS you could prevent all of this by just upping your server stats. However you’ll still get a very slow admin experience and let’s face it, you’re patching a leaking boat and probably have to pay a hefty price for it (big servers aren’t cheap).

    Then there’s also the issue of WordPress database structure and the performance of WP_Query. 10up has written a great article on performance with WP_Query and one of the things to avoid is post meta lookup. Usually there’s no choice BUT we can at least do what we can to use simple post meta like a single date field or a boolean. And of course try to minimize the amount of post meta for each single post. https://10up.github.io/Engineering-Best-Practices/php/#performance
    Consider that ACF adds two rows to wp_postmeta for each field (both regular and sub fields).

    So if we can refactor our data structure to use a custom post type which would contain some fields and then perhaps link different posts/post types together with the post object or relationship field we’ll end up with safer and quicker admin requests, faster and often more versatile use of wp_queries in our front end and a better DB structure more fitting of WordPress strengths and weaknesses.

    It’s hard to say a number of repeater rows that’d be “too much” since it depends on what they contain. But for me, if I find that I’d end up with more than 20-30 row of simpler repeater data or 10-15 rows of more complex ones I would consider a different solution. Sometimes it’s hard to predict tho. We’ve had customers where they were supposed to use repeaters for just a few categories of Press media attachments but they ended up dumping soooo much media there that we eventually had to rebuild it for them with a CPT where each post was a single media file and a taxonomy for the categories of media.

    Hope that was a sufficient answer 🙂

  • @kennethbl so when you imported the ACF field group containing a text field the value of that field instead came out as an array..?
    Did you have any previous meta fields in the site you imported to that might’ve had the same field name? (saves to same name in wp_postmeta).

    Did you check the imported field group to see that everything looked fine?

  • No problem!

    Glad you worked it out anyway and sorry for the delayed answer 🙂

  • @kahil

    Thanks for all the feedback. You should probably jump over to the github repo tho if you want to take things further so we don’t highjack this thread.

    As for styling you have two options. You can set the id parameter to get a custom ID for the form. And you can set extra classes on the form element by passing it to the form_attributes parameter as an array.

    [show_acf_form id="mycustomid" form_attributes="class|mycustomclass"]

    As for the email alert I kinda think it’s outside the scope of what an ACF Form Shortcode plugin should do. You can however easily create the functionality yourself. Here’s a working (not tested) example using your field keys. Just update the “mycptslug” strings. 

    
<?php
function send_email_on_submit( $post_id, $post, $update ){

	// If this is just a revision, don't send the email.
	if ( wp_is_post_revision( $post_id ) )
		return;
    
    $post_title = get_the_title( $post_id );
	$post_url = get_permalink( $post_id );
	$subject = __('A design has been approved');

	$message = 'A design has been approved:\n\n';
	$message .= 'Name: ' . get_field('field_57210e7e7a217', $post_id) . '\n\n';
	$message .= 'Email: ' . get_field('field_573b9511ba9f5', $post_id) . '\n\n';
	$message .= $post_title . ": " . $post_url;

	// Send email to admin.
	wp_mail( get_option('admin_email'), $subject, $message );
    
    
}

add_action( 'save_post_mycptslug', 'send_email_on_submit', 10, 3 );

  • Hi @pthpndr

    I think it’s probably due to the plugin using WordPress core color library and newer versions of WordPress no longer use that color library. Since a while back it’s using Iris http://automattic.github.io/Iris/

    Having a quick look at the sourcecode of the plugin he does not seem to make sure iris or any other color js library is loaded at all.

    So basically. Your issue is that there’s no color js library loaded with the plugin. To fix it you’d have to modify the plugin to include the library needed and probably rewrite the JS to work with that library instead.

  • Hi @sharongraylac

    Glad you worked it out. If you want a “real” solution to your original problem you can find it here:
    https://support.advancedcustomfields.com/forums/topic/removing-paragraph-tags-from-wysiwyg-fields/

  • Hi @adser

    I have not heard of anyone doing that. But you could create this yourself.
    Think of ACF as “simply a GUI for meta” and acf_form as a way to create new posts with this meta.

    So in your case I guess you would have created a CPT you call “orders” or something. Whenever a post is created or saved in WordPress there are some hooks being called. You could use these to set everything up for a payment gateway. Then if you need to redirect the user straight to your own custom payment page after submission you can use the “return” parameter of acf_form to send them there.

    https://www.advancedcustomfields.com/resources/acf_form/

  • Hi Tim,

    Looks like the same result after updating to 5.3.3.2? Or am I missing something..?

  • @tdmalone

    Just want to make sure.. you say you updated to ACF 5. Did you follow the update procedure to make sure your fields where migrated correctly?
    https://www.advancedcustomfields.com/resources/upgrading-v4-v5/

  • Good to hear 🙂

    Actually when I say that it takes all the options from acf_form() that means you can look here: https://www.advancedcustomfields.com/resources/acf_form/

    The limitations are the same as well so I can’t support adding fields by field name since the function can’t. The shortcode I created is in it’s most basic form just a wrapper for acf_form().

    I’ll take your suggestions under consideration. A landing page for the plugin is a bit over the top tho as of right now 🙂

    I think the next step is to see if I can’t make it work seamlessly with any editor and also add some more documentation to the github repo.

  • Hi @seasterling

    Not sure I follow your explanation of setup..

    So you have a post type A which has a relationship field where you select one or more of post type B. And when you’re on post type A you want to fetch a file url from each post type B connected to the post type A and link the post title to the file?

  • @kahil you can use either the post Id (the ID of the field/field group) OR the field key (or fieldgroup key). The same functionality as with using the acf_form() function. If you’re using acf-json I’d make sure to use the field keys because the ID’s would not exist on a site which only loads the fields from the json file.

  • Hi Maruya,

    In your example you’re not switching to blog id 2 tho? Is this just an error in your example or have you overlooked this? 🙂

  • @kahil I will probably upload it to wordpress.org when I’ve fine tuned it a bit. Currently it’s in a rough form (as you noticed by the silly php warnings) and I’d like to test it a bit first and possibly add some stability and features.

    .. So, what’s the deal with airplane food?

  • Hi Kahil.

    Yes since the shortcode takes *all* options the regular acf_form does you can just as easily use it to update a single text field.

    [show_acf_form fields="123" submit_value="Save" updated_message="field saved"]

    this example would update just a single field with the ID of 123

  • Hey!

    Bit older topic but I thought I’d share this plugin for future googlers etc.

    We needed the ability to add acf_form as a shortcode in a project we’re working on so I just coded a plugin that achieves this. It’s completely self-reliant so no need to add acf_form_head yourself and it only adds it if there’s a shortcode in the post_content.

    To use it just install it like any other plugin and then use [show_acf_form] in the editor (currently only supports the regular post_content editor).

    It takes *all* options that acf_form takes. To set array values just comma-separate them. To set associative array values use | to separate key=>value pairs.

    Example:
    [show_acf_form id="tavlingsansokan-form" field_groups="1496,1451" post_id="new_post" new_post="post_type|tavlingsansokningar,post_status|publish" submit_value="Skicka" updated_message="Ansökan mottagen"]

    It can be found here: https://github.com/jonathan-dejong/acf-form-shortcode

  • About the select field.. If you check the sourcecode and look at the real select-elements taht gets hidden by select2. Is it set as disabled?

    Because later versions of select2 are supposed to pick up on that and disable the select2 created functionality as well (and it can be toggled with JS after initiation).

    I’ve been on Elliot about updating the select2 lib for some time now 🙂

  • Hi @etiennedupuis

    Have you seen that in later versions of ACF you can collapse/shrink a repeater row to a single “line” with your chosen field value on it?

    If you still find it unmanageable, to be frank, you should reconsider how you structure your data. There are more and worse issues with dumping everything into a repeater field. For example hitting your servers limits like max_input_vars resulting in you unable to add information.

  • Hi Fireleaf,

    You can add your ACF fields to an existing form by setting the “form” parameter to false.
    https://www.advancedcustomfields.com/resources/acf_form/

    
<?php acf_form( array(
'form' => false
) ); ?>

    You would still need to add the <?php acf_form_head(); ?> to the top of your template tho (before get_header()).

  • Thanks but at the moment I’m not as active support. I’m sure if you remind James he’ll help you out!

  • Hi Tabboy,

    Alright. I’m not sure since I’ve not used private threads at all yet 🙂

    You say it works in the same browser on a localhost tho. that kind off leads to the issue being with the specific server you’re hosted on.

  • Ah I see..
    Yeah I understand your setup now.Unfortunately your issue remains that at some point you’re gonna run into server-limitations.

    The thing about acf_form and manipulating the output would be that it’d affect the repeater field when you save the changes.

    You could probably hide all but the last 5 rows in the form using CSS but that’s a dirty fix.

    So now that I know a bit more and also your requirements here’s what I’d rather do.

    I would create a new CPT called events. Then setup a new field on each company report which is a relationship field for the events posts. You can have this field in your original acf_form is you like just to be able to remove/add posts that already exists.

    Now you say you don’t want your analysts to jump from a single view.
    Well you can create a separate acf_form on the same page with just the fields for each event which when posted creates a new event which automatically connects to the relationship field for the report (you code this yourself, very simple).

    This would also allow you to manually query all events or maybe just the latest 5-10 to display to your analysts. You can also provide an edit-button for each event. This gives you the ability to separate older events from newer in whatever fashion you want. You could also prevent editing of older events by only allowing events from the past month to be edited (for example).

    Anyway, here’s that dirty CSS fix as well.. You’ll have to change “<yourkey>” to the key of the repeater field. This assumes you’ve set your repeater to display as row. 

    
.acf-field-<yourkey> .acf-table tbody .acf-row{
	display: none;
	
}

.acf-field-<yourkey> .acf-table tbody .acf-row:last-child,
.acf-field-<yourkey> .acf-table tbody .acf-row:nth-last-child(2),
.acf-field-<yourkey> .acf-table tbody .acf-row:nth-last-child(3),
.acf-field-<yourkey> .acf-table tbody .acf-row:nth-last-child(4),
.acf-field-<yourkey> .acf-table tbody .acf-row:nth-last-child(5) {
	display: table-row;

}

  • Hi Dan,

    Okay.. well the problem with a front-end pagination is that you’d still hit your servers max_input_vars limit etc eventually.

    I have a clearer image of your setup now but not completely. So you’re creating a single report post and in this you add “infinite” rows of events. Why are you not just creating a report per event?

    If you need to “organize” or “group” these events (reports) somehow could you maybe use a taxonomy? So say you now have a report called “Traffic” in which you have 100 rows of events. What if you have a taxonomy called “Traffic events” and have 100 report posts each with a single event in them (doesn’t have to be a repeater any more since it’s just one instance).

    say IF that works.. then you’re thinking “My god, we can’t change our structure that much this late”. Well you can.. you just need a smart way to convert your existing data.

    You could code a function which would look through each current report post. Add a term in your new taxonomy for each report post (maybe just use the reports title as the term title). Then loop through each repeater row and create a new report post and assign it to the newly created term along with the rows fields as meta fields on this post. If you got a decent coder it shouldn’t be a problem!

    One advice tho, I’d create a new report post type for transferring to. If there’s an issue (might require some trial and error) in converting you can just clear out all posts in this post type and start over not worrying about mixing old with the new. Then when you’re satisfied you can delete the old report posts and use a plugin to convert all new posts into the old report post type (and then delete the new report post type which would now be empty anyway).

  • Hi Dano,

    I’m not sure I understand your setup completely.
    But my suggestion to linkhousemedia sounds to work the same for you.

    Instead of having all those reports in a single repeater. Split them up so you have a single report as a bunch of fields on a custom post type.

    So on this page where your authors work with these. You can output all the posts in this post type for them to view (and you could create a front end editing form as well). And for creating new ones you can use acf_form() to post to your CPT.

  • Oh, maybe it’s been fixed in a later version then 🙂

    I haven’t paid that much attention to the logs lately and as you can see have been slacking off in the forums 😉

Viewing 25 posts - 101 through 125 (of 1,019 total)
1 2 3 4 5 6 … 39 40 41