Fix empty shortcode output

[YanMetelitsa]

Fixies Issue #85 (Shortcode Bug)

Perhaps the text of the message needs to be changed as I am not a native speaker.

[kraftbj]

@pkevan Since you dug into the original report a bit, would you be able to review this one?

[pkevan]

I think we need to be careful with outputting messages to end users here (maybe an error warning which doesn't show in the front-end would be better).

[YanMetelitsa]

@pkevan, in any case, in my opinion, it is necessary to make some kind of display of an explanation of why the shortcode "does not work". In my experience, this raises questions and bewilderment among some users.

[kraftbj]

What about having the message only displayed for logged-in admins?

[YanMetelitsa]

What about having the message only displayed for logged-in admins?

After my last post I thought the same thing - display for admin, something like that:

...
else {
	if ( current_user_can( 'manage_options' ) ) {
		/* translators: %s Field name */
		return apply_filters( 'acf/shortcode/field_not_allowed_message', '[' . sprintf( esc_html__( 'You need to enable "Allow Access to Value in Editor UI" in the "%s" field parameters to display it in the ACF Shortcode.', 'secure-custom-fields' ), $field['name'] ) . ']' );
	}
	
	return;
}
...

[YanMetelitsa]

Also, my bad, I think it would be safer to organize the output as follows:

apply_filter( 'filter', esc_html( '[' . sprintf( __( '%s', 'secure-custom-fields' ), $field ) . ']' ) );

[pkevan]

What about having the message only displayed for logged-in admins?

That could work - or even have that cap check filtered? As it might be better to have editors/admins included by default (on the basis on advanced privileges)

Given there are multiple instances of outputting based on which settings are set outside of the shortcode, we should probably cover all of those which return an empty response.