Support

Account

Register Login

Forum Replies Created

  • I just want to chime in here and confirm that this is still an issue, which doesn’t appear to have even been read by the ACF team yet, nearly 6 months later.

  • OK… well, no one here seems to have anything else to say about this, but just in case a future ACF PRO user encounters this same issue, I’ve found a workaround.

    Using the "file:./whatever.css" value still never works for me in the editor (though it’s fine on the front end), but I’ve discovered that registering the script/style first, then registering the block and using the handle in block.json works.

    So for example, wherever you’re registering the whatever block, you’d have these lines:

    wp_register_style('whatever-css', get_theme_file_uri('blocks/whatever/whatever.css'));
register_block_type(get_theme_file_path('blocks/whatever'));

    And then in your whatever block’s block.json file, you’d have this:

    "style": "whatever-css",

    It works!

  • Is no one else having this problem? It is still a major issue for me. My ACF blocks look fine on the front end but totally broken in the Block Editor. It seems like somewhere ACF is using a [something]_path() function instead of a [something]_uri() function when enqueuing the style.

  • Upon further investigation, this was not the answer after all. I made the decision to remove the embedded ACF from my theme and install it standalone, and the problem is still happening… on the front end, the CSS is loading properly, but on the back end, the URL it’s requesting is this (parts in all-caps edited for privacy):

    https://DOMAIN/wp-content/plugins/var/www/PATH/wp-content/themes/THEME/blocks/tile/tile.css?ver=6.2

    It may be worth mentioning that this is a Multisite installation, although I don’t think that has anything to do with it.

  • Answer: Yes, I am doing something wrong, although I haven’t figured out a fix yet. I realized this issue is happening because I have ACF embedded in my custom theme rather than running it as a standalone plugin. (I do this to have more control over updates for a couple of mission-critical plugins I use in conjunction with my theme… but I’m starting to second-guess the benefits of the approach.)

  • Awesome… this looks like exactly what I need! Thanks!

  • The reason this is happening is that there are a couple of spots in pro/blocks.php where the acf_render_fields() function is called with 'field' hardcoded as the fourth input parameter. (Lines 562 and 896 in version 6.0.6.)

    I wouldn’t advise editing the source code in a plugin, but I can confirm that just removing , 'field' from those two function calls does work to get the function to revert to the default 'label' value, and puts the instructions below the field labels rather than the fields themselves.

    I would have to dig a bit deeper into the code to determine how to actually get it to pass the proper 'instruction_placement' value from the field group configuration, but for my purposes I just needed a way to get it back to the default. Anyway… this should be an easy fix for the ACF devs if it’s on their radar. But it seems that it may not be. (I just submitted another ticket.)

  • I’m still fumbling around with this a bit myself, not specifically with ACF blocks, but just my theme CSS in general. A couple of things I’ve done that have helped me along the way:

    1. I prepend main to my CSS selectors in my theme’s general CSS files. For example, in defining the style of my links, instead of just specifying a { } I am using main a { }. I did this primarily because I wanted to apply different styles to the body of my pages vs. the header and footer. (The HTML main tag is part of my templates… you may have a different selector you prefer to use… the point is to make sure it’s something that is always in the body of your front-end pages but not in the body of the Block Editor back-end pages.

    2. I have a bunch of general CSS for forms, contained in a form.css file in my theme. It was wreaking all kinds of havoc in the Block Editor until I realized I should not load it in the editor with the add_editor_style() function. At this point I don’t think I’ll ever have any form field elements in blocks, but… we’ll see.

    The reason I came to the forums today and stumbled upon this is something that may be tangentially related, collisions between ACF and updates to WP core. I noticed some of the ACF elements are laying out weird in the Block Editor, in ways that don’t seem to be related to my theme: the Visual/Text tabs in a WYSIWYG field were broken apart from the editor and too small; the draggable side columns in rows of a repeater are too narrow and the toggle button is partially hidden, etc. This appears to be due to some new handling of box-sizing in either ACF (I know they just did some CSS updates in a recent update) or WP core, or both.

  • I’m focusing mainly on the issue of the autocomplete dropdowns not working when there are multiple instances of the form on the page right now.

    I was able to determine that it did work to have multiple instances with version 5.9.9, but it stopped working with 5.10(.0).

    I’m doing a diff between these versions and not surprisingly there are a ton of changes. It could be difficult to nail it down, and is probably not worth me investing the time in right now.

    I took a look at the changelog for 5.10 and I think this is the item that is most likely to be connected to whatever is causing the problem for me:

    Fix – Fixed issue where Select2 search input wouldn’t have focus in WordPress 5.8+

    I’m guessing that they fixed this focus issue by making a change to a jQuery selector — something that probably was not using a # (id selector) before, but should have been, now is, and I had previously been exploiting a bug without realizing it.

    Oh well…

  • I’m going to do some testing on my setup, to see if I can pinpoint the version where the issues started to appear for me. More to come…

  • That’s interesting, to pursue what might have changed recently. I’ve never used this on the front end without requiring login, so I haven’t had this extent of trouble, but it’s possible that a “lesser” version of the same issue is affecting my logged-in form display too.

  • Thanks… the specific issue with the date picker is that previously it would always be positioned entirely above or below the input; now if that would cause it to run off the screen, it shifts enough so that it doesn’t run off the screen at all… but that results in it covering the input. I was able to work around it by just modifying the page layout so the form starts a bit lower on the page. (This is something I’m only using for personal use right now so the design is not critical.)

    As for the second issue… I agree that it’s odd that it ever worked. But it did, and now it doesn’t, so I’m trying to figure out what happened.

  • Most of the sites I build with WP don’t have a blog component, so they’re not dealing with category archives or thousands of URLs, so I’m not the best to speak to this. It doesn’t look to me like it does either of these things yet.

  • I do recommend considering The SEO Framework as an alternative to Yoast. I find Yoast’s self-promotion really obnoxious, and it has a ton of features that I don’t ever use. The SEO Framework is a lot more focused and I prefer the way its configuration is set up.

    I’ve been moving all of my clients’ sites from Yoast to The SEO Framework as they run into this issue.

  • @Avamposto Yeah, I’m not totally happy with this as a solution but it’s only significant in situations where a site has both the free version of ACF and the paid version of my plugin. I’m not sure how often that happens. (I suspect most site owners who are paying for my plugin either have already paid for ACF PRO, or they don’t use ACF at all, but I don’t have any data to back that up.)

    Ultimately I want to do what you’re talking about — I plan to get my admin screens entirely self-contained so I don’t need to include ACF PRO with my plugin. It’s mostly just been a matter of time. This is a side project for me and since I’m still refining some elements of the editing screen, it’s faster for me to use ACF for that than to “roll my own” editor layout. But I feel like I will be ready to make that break sometime in the next few months.

    Good luck with your project!

  • Ha… well I came up with a solution.

    Let’s see… I kind of have to piece it back together. I got it working nearly a year ago and haven’t given it much thought since then.

    First, I’m using register_activation_hook() to check if ACF (free) is active. If it is, I’m copying a file into mu-plugins that contains the following, to deactivate ACF (free):

    
add_filter('option_active_plugins', function($plugins) {
	$key = array_search('advanced-custom-fields/acf.php',$plugins);
	if ($key !== false) {
		unset($plugins[$key]);
	}
	return $plugins;
});

    That register_activation_hook() also generates an admin notice explaining that ACF (free) has been deactivated because my plugin includes ACF PRO. I also have a “Bypass ACF Check” option I created in my plugin’s settings, that will prevent this from running, so they can keep ACF (free) active if they really want to — but explaining this means they lose the ACF PRO features my plugin depends on.

    There’s a corresponding register_deactivation_hook() to delete my file from mu-plugins and re-activate ACF (free), although honestly I don’t think it’s working properly. (I haven’t prioritized fixing it because none of my users has yet complained about it!)

    So, that’s the first step, getting ACF (free) out of the way. Next we have to actually load the PRO version. I’m doing that with the plugins_loaded action, calling this function. (Actually it’s a method in my main class.)

    Note right away here that I’m checking to make sure the site doesn’t already have ACF PRO installed, because if it does I just use that and don’t load my own copy.

    
		public function acf_init() {
			// Only load our version of ACF PRO if the full version is not already installed on the site
			if (!is_plugin_active('advanced-custom-fields-pro/acf.php')) {
				include_once(plugin_dir_path(__FILE__) . 'vendors/acf/acf.php');
				add_filter('acf/settings/url', function($url) {
					return plugin_dir_url(__FILE__) . '/vendors/acf/';
				});
				// Hide ACF editing screens (EXCEPT if the site also has ACF free installed)
				if (!file_exists(WPMU_PLUGIN_DIR . '/r34icspro-no-acf.php')) {
					add_filter('acf/settings/show_admin', function($show_admin) {
						return false;
					});
				}
			}
			// Add our ACF JSON loading path
			add_filter('acf/settings/load_json', function($paths) {
				$paths[] = plugin_dir_path(__FILE__) . 'assets/acf-json';
				return $paths;
			});
		}

    Some of this may require some modifications (e.g. you may not have the assets/acf-json folder in your plugin, or you may have acf-json somewhere else, and your file in mu-plugins definitely won’t be called r34icspro-no-acf.php); I also stripped out some code that exists for a “dev mode” I have in my plugin.

    I think that’s the heart of it. Then the other big thing I would just recommend is that you should definitely stay on top of keeping your embedded ACF PRO version up-to-date! It isn’t critical for users who have their own version of ACF PRO, but if you’re knocking out their copy of ACF (free), then it’s on you to make sure they’re getting ACF updates. (Of course, some sites might be deliberately holding their versions back, and that’s not something I’ve accounted for here.)

  • More spam. What is going on here?

  • Spam.

  • I’ve been having this issue for some time. I’m skeptical that it’s due to a plugin conflict or my theme, but I haven’t totally ruled it out.

    I went in to edit the field group, which is correctly showing the “Save Custom” toggle turned on. Then I looked at the HTML source for the editing screen:

    <div class="acf-true-false">
	<input type="hidden" name="acf_fields[39393][save_custom]" value="0"/>	<label>
		<input type="checkbox" id="acf_fields-39393-save_custom" name="acf_fields[39393][save_custom]" value="1" class="acf-switch-input" autocomplete="off" checked="checked"/>
		<div class="acf-switch -on"><span class="acf-switch-on">Yes</span><span class="acf-switch-off">No</span><div class="acf-switch-slider"></div></div>		<span class="message">Save 'custom' values to the field's choices</span>	</label>
</div>

    Shouldn’t the hidden field have a value of “1”? How could this be due to a plugin conflict?

    *EDIT* Now that I look more closely, the checkbox input and the hidden input both have the same name attribute. This seems like a problem. Why is the hidden field even there?

  • Sorry… I misinterpreted the “beaker” icon on your avatar and assumed you were an ACF representative.

    A little more detail for what it’s worth…

    This is my first commercial plugin; I mostly do client work, although I do have about a dozen free plugins in the WP Plugin Directory.

    I have to include ACF PRO in this plugin, at least at this point, because I have a custom post type with a bunch of custom fields, and building my own admin editing screens for those, vs. just including ACF PRO, was going to be prohibitively time-consuming. I don’t really like the idea of embedding another plugin in mine (as much as I like ACF!), but I verified my use of it conforms to ACF’s licensing requirements.

    I can’t really ask people who are buying my plugin to also buy another plugin in order to actually use it. Like I said… not my ideal arrangement but it will have to do for 1.0. If this thing really takes off and I can invest more time in it, I’ll probably build my own custom admin screens and remove ACF PRO from it.

  • Thanks… I tested out a variation on your “more forceful” idea after I posted this. I think mine is a bit too forceful at the moment though.

    Seems like it would be a good idea to add something about this to the documentation page linked above… especially since so many sites use ACF nowadays!

  • I have a follow-up question on this, as I’m currently developing a premium plugin that will include ACF PRO. I need to include PRO because one of my admin screens relies on a Repeater field.

    I started from the code sample in the link you provided, which I’m running in the plugins_loaded action.

    The problem is, if the site has ACF (the free version) installed and active, that takes precedence, my embedded version of PRO doesn’t load, and my Repeater field doesn’t appear on the admin screen.

    The only way I’ve been able to find to prevent free ACF from loading is to create a plugin in wp-content/mu-plugins containing:

    add_filter('option_active_plugins', function($plugins) {
	$key = array_search('advanced-custom-fields/acf.php',$plugins);
	if ($key !== false) {
		unset($plugins[$key]);
	}
	return $plugins;
});

    That’s a really ugly solution. I either have to ask users to put this file into their mu-plugins folder (which probably doesn’t exist), or I need to have my plugin write it to their file system itself (eek… I don’t want to do that).

    Is there another way to handle this that I’m missing?

    You mention “I also have some sample code if you need it that will disable any existing copies of pro and make yours the highest priority preventing theirs from loading”… is there any way you could share that here?

    Thank you!

  • I have a follow-up question on this, as I’m currently developing a premium plugin that will include ACF PRO. I need to include PRO because one of my admin screens relies on a Repeater field.

    I started from the code sample in the link you provided, which I’m running in the plugins_loaded action.

    The problem is, if the site has ACF (the free version) installed and active, that takes precedence, my embedded version of PRO doesn’t load, and my Repeater field doesn’t appear on the admin screen.

    The only way I’ve been able to find to prevent free ACF from loading is to create a plugin in wp-content/mu-plugins containing:

    add_filter('option_active_plugins', function($plugins) {
	$key = array_search('advanced-custom-fields/acf.php',$plugins);
	if ($key !== false) {
		unset($plugins[$key]);
	}
	return $plugins;
});

    That’s a really ugly solution. I either have to ask users to put this file into their mu-plugins folder (which probably doesn’t exist), or I need to have my plugin write it to their file system itself (eek… I don’t want to do that).

    Is there another way that I’m missing?

  • I have a follow-up question on this, as I’m currently developing a premium plugin that will include ACF PRO. I need to include PRO because one of my admin screens relies on a Repeater field.

    I started from the code sample in the link you provided, which I’m running in the plugins_loaded action.

    The problem is, if the site has ACF (the free version) installed and active, that takes precedence, my embedded version of PRO doesn’t load, and my Repeater field doesn’t appear on the admin screen.

    The only way I’ve been able to find to prevent free ACF from loading is to create a plugin in wp-content/mu-plugins containing:

    add_filter('option_active_plugins', function($plugins) {
	$key = array_search('advanced-custom-fields/acf.php',$plugins);
	if ($key !== false) {
		unset($plugins[$key]);
	}
	return $plugins;
});

    That’s a really ugly solution. I either have to ask users to put this file into their mu-plugins folder (which probably doesn’t exist), or I need to have my plugin write it to their file system itself (eek… I don’t want to do that).

    Is there another way to handle this that I’m missing?

  • Follow-up on my last post and the mysterious “Enter a URL” message. I scanned my entire codebase and could not find that phrase anywhere, so on a hunch I investigated whether it might be a browser-specific issue, and it appears to be. I’m getting the “Enter a URL” error that is preventing saving in Safari; but if I edit the exact same page in Chrome, it works. Then if I open the page — now containing my # URL — in Safari and try to save without any changes, it fails with the same “Enter a URL” message again.

    It seems to be a browser-specific handling of the new HTML5 <input type="url"> field. Is there a way to customize the pattern attribute for URL fields in ACF? If so I haven’t seen it anywhere.

Viewing 25 posts - 1 through 25 (of 38 total)
1 2