No longer possible to get nggallery content from admin-ajax context??

I’ve been trying to find a way this could be done, but unfortunately we also don’t initialize the display type controllers when is_admin() is true.

All I can think of is to recommend using ajax that isn’t in the admin, but check to ensure there is an authenticated admin user. I’m sorry I can’t help more.

To be clear is_admin() is supposed to be true when they’re in a /wp-admin/ area of the site, no matter whether or not the user is an administrator.

There was a workaround for pre-2.0.7x-series but the latest Nextgen Gallery seems to absolutely not want you to see preview of shortcode with the_content filter.

I wonder if there is any official word on why this is the case (other than a tiny optimization for admin dashboard), and is there any workaround without completely rewriting ajax calls that are calling WP standard wp-admin/admin-ajax.php to call another url?

I don’t have the contributor tag for my account here but I am one of Photocrati’s programmers working on NextGen. We started wrapping our display logic in is_admin() checks for performance around version 2.0.34 (starting with this commit). We unfortunately had a lot of performance issues with NextGen 2.0’s first release, but I think we’ve fixed a lot of it since then.

If you don’t require the action to be authenticated you could register your ajax on wp_ajax_nopriv_(action) which would have the display type controllers available.

The problem isn’t authentication, and actually is_admin() has nothing to do with whether the user’s admin.

The problem is for WP ajax calls, is_admin() is true (it’s a /wp-admin/ url), and therefore all attempts to get post content with shortcode don’t work.

You can try calling the shortcode register functions, but all the register_hooks are like:

if (!is_admin() && ((!defined('NGG_DISABLE_LEGACY_SHORTCODES') || !NGG_DISABLE_LEGACY_SHORTCODES)))
        {
            C_NextGen_Shortcode_Manager::add....

Are you going to add any constant or filter to allow shortcodes to be rendered if the page is in admin dashboard?

As you can see in the answers to this question, plugins that use this is_admin() really shouldn’t need to: https://wordpress.stackexchange.com/questions/188942/why-not-register-shortcodes-if-is-admin-dashboard

I wonder what the specific reason was for this behavior in Nextgen?

We used is_admin() as a kind of performance optimization so that we could avoid loading the gallery rendering logic in the /wp-admin/ area. It’s a decent request so I’ll be updating that check tomorrow to include a filter for users that want to enable (or disable?) loading our frontend logic.

I’ve checked in a change that replaces our !is_admin() checks with a filter (‘ngg_load_frontend_logic’) with two parameters: enabled (set to default at priority -10 if !is_admin()) and our module ID (in case one may wish to only enable certain display types). It should be in our next release and I think it should solve this problem.

Thanks, but this fix is unfortunately not really usable. Since that filter is called initially, and not on an action like ‘init’, it’s not likely to ever actually be filtered.

As you can see in wp-settings.php, the functions.php of themes are called after the plugins have all been called up – and in this case, it has decided whether or not to register shortcodes. I think even other plugins may or may not be able to filter depending on order of loading – unless you can call something within Nextgen to tell it to re-add-shortcodes in this case?

So do you have to add a filter for ngg_load_frontend_logic in wp-config.php for this to work? It seems this was never tested to work if the code it needs to work with is in a theme – filters that are immediately run aren’t actually filter-able – see for example https://wordpress.stackexchange.com/questions/196305

Unless I’m missing something and there’s a function to call to re-run the add-shortcodes?

You’re totally right; I hadn’t at the time considered themes – sorry about that.

I’ve updated the filter applied to provide the is_admin() check and make it also check the ngg_options option:
get_option('ngg_options')['always_enable_frontend_logic']

By setting that attribute to TRUE and updating ngg_options then subsequent loading of the plugin should go as you desire. It will be in our next release, though I don’t know when exactly that will be.

Thanks programmin!

Thanks, that’s next best thing to not having the in_admin check I suppose. Btw I think I asked this before, but do you have documentation for all those options in ngg_options in wp_options table?

The closest would be just examining the C_NextGen_Settings_Installer class’ comments: that file on BitBucket.

Not every entry is commented but most are.