Is there an utility for admin_enqueue_scripts in class.settings-api.php ?

Hi @mathieu sorry for the delay in response, I was out of the office,

This issue is triggered by the third party settings class I am using, and it would only impact the color picker for settings, which I am not even using, but I didn’t notice it, and I didn’t modify the third party script. So removing this should be a good thing and I will investigate this deeper to see if I could disable it directly from the plugin.

I will update this post when an update for the plugin that fixes this is ready.

Thank you for reporting this issue!

Thanks ??

Hey @mathieu the latest release, 3.3.9 automatically removes the action right after the class that adds them is called, so you can safely update and remove the code that you added.

Thank you for the report once again, I will close this issue, but feel free to reopen if needed.

Hi,

Great, however, I discovered that it creates other issue on pages that doesn’t have the media player loaded. You seem to load pretty much everything on everypage even if there is no upload happening on a page.

stockpack-load-admin.js?ver=3.2.4:1 Uncaught TypeError: Cannot read properties of undefined (reading 'search')
    at Object.<anonymous> (stockpack-load-admin.js?ver=3.2.4:1:20702)
    at i (stockpack-load-admin.js?ver=3.2.4:1:110)
    at Module.<anonymous> (stockpack-load-admin.js?ver=3.2.4:1:51573)
    at i (stockpack-load-admin.js?ver=3.2.4:1:110)
    at Object.<anonymous> (stockpack-load-admin.js?ver=3.2.4:1:51525)
    at i (stockpack-load-admin.js?ver=3.2.4:1:110)
    at stockpack-load-admin.js?ver=3.2.4:1:903
    at stockpack-load-admin.js?ver=3.2.4:1:912

I do however have a fix AND a tricks that solves the issue.

The idea is to check if did_action(“wp_enqueue_media”) is true

In class-stockpackmedia.php, you can do this, it works

        public function enqueue($admin = true, $no_dialog = false)
        {
            if (did_action('wp_enqueue_media')) {

                $this->enqueue_script($admin);
                $this->enqueue_style($no_dialog);
                $this->enqueue_settings($admin);
            }

        }

But I think there’s a better way that keeps your exact same logic and doesn’t messed up anything.

The idea is to use stockpack_frontend_load later when enqueue scripts are called. That makes the “frontend_load_stockpack” filter much more useful.

Here’s what I tested successfuly.

        public function enqueue($admin = true, $no_dialog = false)
        {

            if (stockpack_frontend_load()) {
                $this->enqueue_script($admin);
                $this->enqueue_style($no_dialog);
                $this->enqueue_settings($admin);
            }
        }        
        
        public function templates()
        {
            if (stockpack_frontend_load()) {
                include_once(__DIR__ . '/../templates/attachment.php');
                include_once(__DIR__ . '/../templates/empty.php');
                include_once(__DIR__ . '/../templates/details.php');
                include_once(__DIR__ . '/../templates/downloader.php');
                include_once(__DIR__ . '/../templates/dialog.php');
                include_once(__DIR__ . '/../templates/attribution.php');
                include_once(__DIR__ . '/../templates/no-search.php');
            }
        }

        public function enqueue_frontend()
        {
            if (stockpack_frontend_load()) {
                $this->enqueue(false);
            }
        }

        public function load_frontend_style()
        {
            if (stockpack_frontend_load()) {
                wp_enqueue_style('stockpack-frontend', plugins_url('/dist/css/stockpack-frontend.css', STOCKPACK_DIR), false, $this->version);
            }
        }

And then somebody can filter it out with :

    add_filter("frontend_load_stockpack", function ($load) {
        if (!did_action("wp_enqueue_media")) {
            return false;
        } else {
            return $load;
        }
    });

Let me know what you think

Hi @mathieu thank you for looking into this, the frontend_load_stockpack was initially called later, but was changed to improve compatibility with builders plugin that also work on the FE.

I will test the changes and see how I can make it also work with the builders and get back with a plugin update by the end of next week.

Thanks ?? please let me know.

Have a nice weekend.

@mathieu I have updated the plugin. I couldn’t easily change the loading to be later, as I needed to register the settings pages earlier, but I was able to not load the css and js if the wp_enqueue_media action was not called in the stockpackmedia class. This also removes the javascript error that you mentioned.

Thank you for diving deeper into this, let me know if you have any questions or issues.

I am closing this ticket, but feel free to reopen.

Yes it works well but you are still loading a tons of templates for nothing.

        public function templates()
        {
            if (did_action('wp_enqueue_media') || (isset($_GET['page']) && $_GET['page'] === 'stockpack')) {

                include_once(__DIR__ . '/../templates/attachment.php');
                include_once(__DIR__ . '/../templates/empty.php');
                include_once(__DIR__ . '/../templates/details.php');
                include_once(__DIR__ . '/../templates/downloader.php');
                include_once(__DIR__ . '/../templates/dialog.php');
                include_once(__DIR__ . '/../templates/attribution.php');
                include_once(__DIR__ . '/../templates/no-search.php');
            }
        }

Otherwise it works very well.

Hopes I am not getting too annoying.

I am just in a phase where I am optimizing everything and your plugin is good enough that I am willing to go deep in the code to help you make it better.

Cheers.

@mathieu I think this can definitely be added, but to make sure that the plugin only runs in just the situations it needs to run I will probably have to split the settings part from the rest of the plugin, which is not super easy at this time. The main focus of the plugin was compatibility, the performance footprint should now be considerably reduced if the scripts are not loaded, but I will also add this about templates soon. Are you also concerned about the php running on pages that it’s not needed?

• This reply was modified 5 months, 1 week ago by ionut.calara.

If the php would noticably slow down the experience for the people I pay to write content, absolutely.
But I don’t feel that is the case with your plugin anymore since you stop enqueuing the media player everywhere.

If every plugin would always load everything on every call with no regards to performance it would get bloated quick.

I run a tight ship ??

I removed the templates, so the performance footprint should be no longer noticeable. As you mentioned loading scripts and styles is what is that makes the experience for people in the admin worse.

Thank you for pointing these issues out, this will make a difference for all the users.

Thanks a lot ?? Have a nice weekend!