Wordpress Customizer Preview window issue

[maxxd]

Hey y'all. This is (hopefully) a dumb question and something I'm just overlooking.

 

I've created a very simple widget that includes a separate php file. The separate .php file is actually just a large but simple HTML form consisting mostly of checkboxes. That's it. So, everything works great in the front-end and the widgets page of the back-end. I run into trouble, however, on the Customizer page. Including the template file like so:

private function renderTemplate($template){
	ob_start();
	require_once($template);
	$form = ob_get_clean();
	print($form);
}

will cause the entire page to load multiple times in the preview window. It's clearly in a loop, though the require_once() should prevent this (note that the method is private because I'm calling it from the public widget() method after a check to make sure the file actually exists and is what I expect it to be).

 

If I comment out the lines of the method (so the functionality is gone but the call doesn't throw an undefined function error), everything works as expected.

 

Has anyone else seen this type of behavior or know of a way to simply not render the widget in the preview window?

 

I can't use is_admin() because the preview window forces a front-end perspective and is_admin() always returns false. I even tried a conditional on the value of the global $pagenow, but the value of $pagenow resets itself to index.php before the previewer loads the index page, so it's exactly like calling the method from the front-end. Which needs to happen, obviously, or the user wouldn't see the widget at all.

 

I also tried to just use file_get_content() instead of require_once() on the template file, but ran into the same issue.

 

Anyway, any ideas or experiences are very much appreciated.

[QuickOldCar]

Does seem like is a loop, is most likely doing the output buffering or running function multiple times, so the require_once is meaningless since calls function each time.

 

In the same way can add an action can also remove it from specific areas

remove_action()

As for your is_admin(), use something like this if ever need it.

if(current_user_can('manage_options') || is_super_admin()) {

[maxxd]

I haven't tried is_super_admin() because the preview window loads the page from a front-facing perspective, so I assume that would fail the same way that is_admin() does. I'll give it a shot, though.

 

The remove_action() idea is intriguing - I wonder if I can flat out remove the widget section from the customizer panel entirely, and whether or not that would have any effect at all... hmmm...

 

Thanks for the ideas!