David Bee

The code should work as is with any theme really. Can you enable debugging in WP (add define( 'WP_DEBUG', true ); to your wp-config.php file and refresh the page to see what errors you’re getting. If you paste it here I can debug it further.

It’s actually relatively easy to keep the SMUSH Lazy Loading active! The problem has to do with the fact that GiveWP loads the form data inside an iFrame but the template doesn’t use the regular wp_header and wp_footer, which SMUSH relies on to load the data necessary for the lazy-loading to work. So we need to add the styles and scripts manually. Here’s how you can do this in your functions.php

/**
 * Enqueue Smush Lazy Loading styles into Give form iFrames.
 */
function enqueue_smush_styles_for_give_iframe() {
	if ( class_exists( 'WP_Smush' ) ) {
		WP_Smush::get_instance()->core()->mod->lazy->add_inline_styles();
	}
}
add_action( 'give_embed_head', 'enqueue_smush_styles_for_give_iframe' );

/**
 * Enqueue Smush Lazy Loading scripts into Give form iFrames.
 */
function enqueue_smush_scripts_for_give_iframe() {
	if ( class_exists( 'WP_Smush' ) ) {
		// Get options.
		$options = Smush\Core\Settings::get_instance()->get_setting(WP_SMUSH_PREFIX . 'lazy_load' );

		$script = WP_SMUSH_URL . 'app/assets/js/smush-lazy-load.min.js';

		// Native lazy loading support.
		if ( isset( $options[ 'native' ] ) && $options[ 'native' ] ) {
			$script = WP_SMUSH_URL . 'app/assets/js/smush-lazy-load-native.min.js';
		}

		wp_enqueue_script( 'smush-lazy-load', $script, array(), WP_SMUSH_VERSION );
	}
}
add_action( 'give_embed_footer', 'enqueue_smush_scripts_for_give_iframe' );

Absolutely! Done!! Have a great weekend Konrad!
D

Got it. Great suggestion. This is a smaller theatre company, so the number of shows will pretty much always be smaller than the number of users (actors). But it’s good to know for future reference anyway!

I figured I’d do the WP_Query on acf/update_value/name=actor filter or acfe/pre_save_post/post_type=show to order the show post IDs right away and save it to the usermeta table at that point. That way it’s all handled when the shows are being created and the front-end retrieval is fast on user profiles. Hopefully, that logic makes sense to you as well?

Anyway, you’ve been extremely helpful with this! Appreciate it!

Great to know! Thanks a TON for taking all this time to provide the samples and detailed explanation!

From a performance standpoint, is there a difference between saving the User’s Shows as its own usermeta field entry and retrieving that, rather than just running a WP_Query() to try to retrieve them dynamically?

Regards!
David

Thanks for the detailed response Konrad! Really appreciate it! And you’re a true rockstar for the amount of work you’ve put into the plugin throughout the years.

In my case, for each actor, I not only have to attach the user ID (the user relationship) but also fill out the character name field. Which is why I think I have to do it as a flexible content/repeater field.

I’m pretty code savvy, so I don’t mind getting my hands dirty in the code. But it sounds like my option #2 may be the easiest way to go. Would you agree? Though I’m curious to hear how you would suggest implementing a custom bi-directional relationship in this case.

Thanks!
David

After doing some basic plugin conflict testing, turns out there’s some conflict with the “Options Framework” plugin (which is required by my theme). Can you take a look?

Hi, here you go: https://www.davidbawiec.com/contact/

Hi @adeelkhan

Correct, this occurs even after clearing caches.

You got it! Done!

And thanks for looking into it! Appreciate it!

Cze?? Konrad!

Thanks for your patience and the super quick response!

I’d written this complete response, and then just as I was about to post it, I decided to do one more test and finally found the issue!! So here’s the complete process of what I found:

So to answer your question:
I am plugged into init via: add_action( 'init', array( $this, 'setup' ) );. So as such I’m plugging in on priority 10. So well past the initial hook.

Within the setup method I have (among many other things):
add_action( 'admin_menu', array( $this, 'admin_menu' ), 999 );

This is what sets up my admin page (with submenu item under the ACF Custom Fields menu item:

	public function admin_menu() {
		add_submenu_page(
			'edit.php?post_type=acf-field-group',
			'Update Old BB Fields',
			'Update Old BB Fields',
			'administrator',
			'update-old-bb-fields',
			array( $this, 'admin_page_display' )
		);
	}

So you can see this ends up calling the ‘admin_page_display’ method, which is what ultimately tries to call my ‘get_field()’. So technically I’m hooked into init 10, and things SHOULD work, but they don’t. Somehow, ACF Extended PHP AutoSync fields don’t show up.

I tried moving the add_action( 'admin_menu', array( $this, 'admin_menu' ), 999 ); hook out of ‘init’ to just have it hook directly, but that isn’t giving any success either. And at that point, I’d be firing at admin_menu:999, which is long after ‘init’ priority 5 so things should work flawlessly.

I even tried running the same tests hooked into add_action( ‘load-custom-fields_page_update-old-bb-fields’,…). And it also returned the same negative result. Somehow the fields aren’t being registered on admin.

This is when I got one more idea. What if, ACF fields don’t get registered on ACF admin pages?? So I moved my sub_menu_page to the Tools menu item instead using:

add_submenu_page(
			'tools.php',
			'Update Old BB Fields',
			'Update Old BB Fields',
			'administrator',
			'update-old-bb-fields',
			array( $this, 'admin_page_display' )
		);

And BOOM! Suddenly everything works like a charm. So it seems as though the fields don’t get registered when visiting the Custom Fields (ACF) admin pages. Does that sound right to you?

David

I feel like I’ve reached a whole new level of stupid. *face-palm*.

DUH. Thank you!

This was a marvelous idea! Thanks!
David

I love your copy-paste response to every query. But this does not relate to the PRO version. It relates to the basic version of the plugin as well. So I’d appreciate your help in either resolving the problem or pushing through this feature request.

Thanks!

This should apply to all template files.

For example:
/wp-content/plugins/bookly-responsive-appointment-booking-tool/frontend/modules/booking/templates/3_time.php
/wp-content/plugins/bookly-responsive-appointment-booking-tool/backend/modules/appointments/templates/index.php

And so many more that reside in /template/ directories between the regular version and various pro add-ons.