Support

Account

Register Login

Forum Replies Created

  • I’m grappling with this too. If we look at the core blocks and padding specifically, they use inline styles on the wrapper element for the block. For example this is a row/group with padding, where they add the presets from the native padding controls.

    <div class="wp-block-group has-white-color has-primary-offset-background-color has-text-color has-background is-nowrap is-layout-flex wp-container-7 wp-block-group-is-layout-flex" style="padding-top:var(--wp--preset--spacing--30);padding-right:var(--wp--preset--spacing--30);padding-bottom:var(--wp--preset--spacing--30);padding-left:var(--wp--preset--spacing--30)">

    Frankly speaking I’m not sure this is good, in terms of performance etc… but I guess it’s the only way to support styling every block individually… if they added classes something like Tailwind utility classes (p-4) then the options would be limited to whatever utilities are available. This supports both the presets and custom, so if you used padding-top: 2rem it would output that, again in the element styles.

    I was searching for a WordPress core function that would take $block[‘style’] and give me back the list of styles, but according to ChatGPT nothing is available for that. Possibly core does this in React/JS code, or maybe there is a PHP function but it’s not shared for dev use.

    What I’ll probably do is make a PHP utility function like makeBlockStyles($styles), pass in $block[‘style’], have it form the styles attribute and return it. Then output my wrapper element like <div styles=”{styles}”>. Best thing I can think of so far.

    Let me know if you came up with a better approach?

  • I wonder if we could use this same approach but instead of 1 block to get the same field from all instances of a given block type, like get_field_block_type( $fieldKey, $blockType );

    It would look over the blocks, but then check for block type and when matching construct an array of the data like:

    function get_field_block_type( $fieldKey, $blockType ) {
  $data = [];

  // PARSE BLOCKS

  // LOOP OVER BLOCKS...

  if( $blockType == $block['type'] ) {
    $data[] = get_field( $fieldKey, $block['id'] );
  }

  // END BLOCK LOOP

  return $data;
}

  • Very nice function @dmchale we have run into situations where we need this with some of the more advanced block types (that use templates made from Gutenberg blocks) for the ACF Engine project https://github.com/eatbuildplay/acfengine/.

  • Maybe it needs an array instead of a single cat name such as ['layout'] because I think you can add multiple like ['layout', 'custom'].

  • You’ll need a way of detecting which page is being handled by the pagination. If you can access the $page variable then you can put a loop around the render of the ACF field like:

    if( $page == 1 ) {
 print get_field('field');
}

  • Good points John. It makes my head hurt just thinking about the variations that can exist with those complex fields and nesting. I’ve seen similar situations discussed involving a range of other features as well. It makes me wonder if there is some better system for handling nested field data to avoid the use of indexes in the meta key names… not sure if I’m describing that clearly enough but I’m referring to ‘flex_field_1_text’ where as you mentioned we often need to “figure out how many layouts the second post already has and then substitute the correct index”.

    I think the approach I might prefer (of course I understand I may not be thinking of all the requirements here) is to have nested field data assigned a unique id and then referenced by json. Essentially so that if you could access that main reference data, you would then be able to track down it’s rows.

    If I were to tackle something like this I this I’d try to utilize the loading and storage native to the ACF API as much as possible. Meaning first try to identify if the fields/types/groups are used for the given post. Don’t try to copy or get the data at that point, just organize the results of that test. Then use the get_field() and save_field(). It seems more likely that we could deal with the various complexities by loading the data with get_field(), but I think processing that before using save_field() would still be a massive undertaking.

  • If we call that feature say “selective copying of field data” meaning you can select specific fieldtype, or fieldgroup, then yes I’d agree that’s more of an ACF-specific feature.

    I think there might be a couple of different ways to do that but something like the process below would be needed:

    1. Pass in the selection of fieldtypes, fieldgroups to the class, perhaps an arguments array like $args = array(‘fieldtypes’ => array( ‘repeater’ ));. Or a setter like $copyPost->setAcfFieldTypes( array(‘image’, ‘flex’) );

    2. When looping over all meta data, load the field associated using the meta name to find the key. Then check if the fieldtype matches that array of fieldtypes to copy. Similar idea for fieldgroups, essentially find out if they that meta data item should be copied. Use continue to skip over meta that doesn’t match the criteria.

    3. When matches are found, copy it the same as shown in that snippet using the queries.

    Having to handle the data one item at a time might not be very efficient in terms of queries but it’s probably possible to delay the query until all the data has been organized.

  • Mark, I’d be surprised to learn that Duplicate Post (https://co.wordpress.org/plugins/duplicate-post/) doesn’t copy the ACF field content, because it is meta data and I’d expect it to support any meta data attached? In my plugin QuizMaster (which uses ACF5 Pro for all fields) we wanted to provide a copy feature for quizzes and questions, which are both custom post types. I just looked over the class we adapted from a tutorial on copying posts, and although it never specifically handles ACF, it loops over all metadata and creates a perfect copy. Newly copied posts have all the same field settings as the original. Here is a gist of that class which is a helper in QuizMaster: https://gist.github.com/goldhat/dbe670097922d3cfd6dac2630f1d19a8

    I’d imagine ACF developers might take the view this is beyond the scope of ACF, because it’s more about posts/copying than it is about fields/data. I’d tend to agree with that, because I think if you’re building a plugin with CPT’s (or a site that uses CPT’s) you can make a class that handles copying, that gist is the full extent of our copy feature and it’s only 129-lines. If ACF provided that feature, it would have to include various options, because for instance we only want to apply the copy option to our own CPT’s, not to all the post types.

  • `php
    wp_save_post_revision( $post_id );
    `

    That function will save a revision, combined with add_action( ‘save_post’, ‘FUNCTION ) it could be used to force a revision to save. Though wp_save_post_revision still checks if it should save (if any changes are present) you can filter a positive response using filter “wp_save_post_revision_post_has_changed”.

    A complete solution would require some testing, it’s easy to end up with duplicate revisions or other issues.

    I found this post when researching a different problem, when I manually make revisions that are essentially a clone of the current post all the ACF fields show in the revision history as changed even though they are not changed.

  • I found this thread interesting though it’s completely different from the topic I was searching for. I had to read it a couple of times to understand what was going on and it still isn’t totally clear… but the jist of it is that Single Post Templates provides a custom location setting which is almost the right fit for what you’re doing, but not quite. Well that’s the challenge anytime with plugins, I couldn’t imagine trying to build a site without doing at least some coding. Ideally you’ll be able to get the original author of that plugin to modify the custom rule to suit you’re requirements, I’d suggest offering them money! If that doesn’t work, find another developer, offer them money. Bottom line is WP and ACF and many other plugins offer a lot for free, but there comes a time where you need to buy solutions.

    My firm (http://goldhat.ca) offers discounts on any projects we can later release, or bundle. We have 3 ACF-based plugins already in the WordPress.org directory. Would be happy to look at either adapting Single Post Templates or building a new version. I noticed that plugin not updated in 2-years, so it will be incompatible eventually with WP or ACF if it isn’t already.

  • Found this issue because I faced the same problem on a site now, with ACF5 Pro. If you’re finding this thread searching around the solution is the same except in ACF5 as you can see below the priority on admin_menu is 99.

    From pro\admin\options-page.php constructor:

    add_action('admin_menu', array($this,'admin_menu'), 99, 0);

    So the solution is use priority 100 or more in your admin_menu call as shown below:

    add_action( 'admin_menu', array( $this, 'adminMenuPages' ), 101);

  • There are numerous GPL-sharing clubs/sites now. Most charge a fee, but there is a notable one (gpldl.com) that is free, driven by donations, and it already offers ACF5 pro and is keeping it updated. For people that want the code, without the updates and support it’s already available. Taking ACF pro out of a plugin that has included it, would probably be more effort and less reliable (more likely outdated, or edited) than using a reputable GPL sharing service that has some quality assurance to prevent sharing corrupted or edited files.

    Anybody selling GPL code (including my firm) has to be aware of the possibility of the code being widely available, easily available, even fully updated. I would expect over time more and more choices in the market are going to surface, both GPL-sharing and also GPL-code plus support packages.

    As for ACF, I respect Elliot’s right to “request a policy” which is all it is, a “request” that has no legal basis. One cannot blame him for wanting that, as it’s in his best interest to whatever extent it might improve sales. However, it would have been a lot more of a safeguard before the startup of GPL sharing sites, because again today those sites are much more convenient ways to get ACF5 Pro than having to take it from another plugin or theme.

    I think it is important to think about the ethics of including a codebase when you know that the original developer would prefer you did not. While legally GPL doesn’t change based on what the original developer wants, ethically I think you have to think about it. I’ve thought about it, and my conclusion is there is more help than harm. Meaning lots of people who get a better plugin or theme with ACF5 Pro included are helped. Open source is hugely beneficial from a collective standpoint. Yet it’s also hugely beneficial to us as individual developers, or site owners. It really is win-win. Now as for the harmful effect on ACF or Elliot as a developer… first I’d say it’s a nominal effect, or even a non-issue because again anybody willing to download plugin A to get plugin B included in it, surely would be willing to join a GPL sharing site instead. They clearly don’t want to pay for the support or updates provided by the original author. The hypothetical that they would be forced to purchase if no other option existed, is purely hypothetical because that is never the case with popular paid plugins today. Only smaller less successful plugins that “fly under the radar” will not be in the massive inventories of GPL sharing sites. Even in that case, a person who really wanted the code could probably find it on a torrent site, or ask around on a dev forum and find somebody that has already bought a license. So the real impact of including ACF5 Pro, or any other premium plugin in a project, is $0 in my view. Whatever decline that might already be happening for some sellers (and I don’t think there is any decline currently) will happen because GPL sharing sites are getting bigger and better. Most today don’t offer automatic updates, but if they did… their service would in some ways be more convenient than buying from original developers.

  • I hope it works but you will have to test that out, the other poster seemed convinced that would this way and it should. Hope it restores your faith in using ACF, personally I’ve used the other field manager you mentioned and it certainly doesn’t have the nice interface that ACF offers. But I’m a big fan of ACF and base a lot of plugins around it so I’m heavily biased in favor of it.

    Keep me posted if you don’t getting it working this way I’ll probably fire up a test site right now I don’t have something active with WPML I can try it on.

  • Good clarifying yes I expected it already worked that way that the field groups were copied (as English fields) to the new language. So your saying that doesn’t happen. However it doesn’t happen because they are posts and WPML blocks them from appearing, so the advice given earlier should resolve it:

    If you don’t need to translate the field groups, then you need to set the “Field Groups” Custom Post Types translation to “Do Nothing” on WPML -> Translation Management page.

    And the second option would be embed your ACF fields, which I like to do for plugins because then you can version control the fields… if your using git and your deploying in stages when you add a new field your going to want to test anyway so it does take away the interface but you gain a better testing process and easy deployment.

    Have you run tests of these options to see if either resolve the issue? I see when those options were suggested you replied “… but I do need to translate the field groups”. That is not true as far as I can understand the problem. If your goal is just use the same fields say in Spanish pages as you used in English, and you don’t want Spanish labels in the admin… then you just want to prevent WPML from blockading the normal ACF placement. And that’s technically what’s happening there, it’s WPML that says hold on that’s English content we can’t show that on the Spanish edit page. But if you tell WPML hey I’m not trying to translate those field groups, let them in… they should show up.

  • WPML has a great guide on translation of ACF including a video on how to quickly duplicate the field groups. Unless I’m really misunderstanding the problem this video at about 1:38 shows the English field group being duplicated to Spanish the same as any other post types. But I’m not sure what the benefit is to translation of field groups other than the labels in the WP admin? Are you really fully translating the entire WP admin? Otherwise for the front-end why not just use English fields, any content entered can still be translated.

    https://wpml.org/documentation/theme-compatibility/setting-wpml-advanced-custom-fields/

    The video alone: https://www.youtube.com/watch?v=osUX987d0EQ

    About the suggest automatic creation of the translated versions, would that be useful? If somebody puts up a bounty I might be into making it. Again just not sure how often field groups are actually being translated. It would be a neat challenge though, I think the sync feature would be great if you add a field to English it duplicates that field to the translated versions. That would be a timesaver for sure.

    As far as the suggestion ACF “should” do this kind of thing automatically… I’d have to disagree. This is a translation feature, it’s up to WPML largely to provide the mechanism of translation. The way ACF provides it’s post type for translation is normal compatibility with WPML. If you want something that provides automation or simplifies the process I think it’s normal for that to be an additional plugin specific to bridging ACF/WPML. Certainly it would not be good for performance to have ACF presume you want translate field groups, and start syncing them, when probably 99% of site owners will never use that feature.

  • I’m also struggling to get a working ACF form created by ajax. I’ve tried a couple of the acf.do_action methods that I found but none fully solved the issues. I will say my form has working js validation, and a working select list filter… so it mainly working, and maybe this sample code will help somebody with the issues they are finding. What I can’t get around, is that when I submit the form I land on /wp-admin/admin-ajax.php?updated=true because the ajax doesn’t seem to apply preventDefault() and it acts like a non-ajax form submission.I tried adding my own .submit and using preventDefault but then the form never submits and I see the ajax circle loading endlessly and no data is saved. So using your own preventDefault in a submit handler seems to break the form processing by ACF. 

    
$.post( devcoreAjax.url, data, function( response ) {
        $('#add-record .modal-body').html( response );
        acf.do_action('append', $('#add-record .modal-body form') );
        acf.do_action('ready', $('#add-record .modal-body form') );

        $('#add-record .modal-body form').submit( function(e) {
          e.preventDefault();
        });

        $('#add-record').modal('show');
      });
Viewing 16 posts - 1 through 16 (of 16 total)