Adds support for WooCommerce settings tabs

[eriktdesign]

Just was experimenting and found I could add this pretty easily -- take it or leave it :)

It adds whatever tabs appear at the top of the WooCommerce settings page tabbed navigation to the palette under "WooCommerce Settings"

I was just fooling with with the dist/main.min.js file on my installation, so I haven't done any build with this, but it's tested working on my machine.

[rosswintle]

Hey Erik. Thanks for diving and and suggesting this. Nice to have a little contribution.

I'll have a think about adding this. It kinda breaks my convention of being able to get to anywhere from anywhere, by only allowing in-page navigation. And I need to figure out: If I add this then what else am I opening myself up to.

So give me a few days to think and I'll get back to you.

Of course, you can carry on using your own version with this in! :-)

Thanks for all your help and support.

[eriktdesign]

Ahh, I thought that these were being cached somewhere, and so would continue to work after you'd visited the WC Settings page once. I agree that it should be "get anywhere from anywhere"

[rosswintle]

Let's leave it open.

The cache is only kept for the front-end and as such it's re-built and re-saved on every back-end page load.

So if you went straight from a WooCommerce settings page to the front end then you'd have them cached.

HOWEVER... I'm doing a little something with ACF (which is why the palette load is still a little slow).

        // Add ACF items?
        // TODO: Make this better. Possible ASYNC somehow?
        this.acf = new Acf();
        if (this.acf.isAcfInstalled()) {
            const acfLinks = await this.acf.getFieldGroups()
            // console.table(acfItems);
            const acfMenuItems = acfLinks.map(
                item => new TurboAdminMenuItem(
                    item.label + ' (ACF)',
                    item.link,
                    ''
                )
            );
            this.menu = this.menu.concat(acfMenuItems);
        }

I'll leave you to look at the Acf class yourself.

If there are other things like this - and I think there are - then I'll probably build out some kind of API for detecting them.

[eriktdesign]

Interesting -- I did a little cursory looking around, an I don't think WooCommerce currently exposes those tabs in a JS object.

As far as the caching goes, here's a thought (and bear in mind that I'm really a backend WP developer, just a dabbler in JS): What if the cached menu items were only completely rebuilt on certain events -- say, detected login, detected plugin activation/deactivation, and perhaps a dedicated command in the palette like "Clear Turbo Admin Cache", or of course if the cache is empty. I know generally the menu stuff won't change much between pageloads unless a plugin is activated.

[rosswintle]

Believe it or not, I'm a back-end coder too. This is a GOOD way to learn some JS! 😬

Yeah, I wouldn't expect tabs to be revealed in an API as they are a UI element, not data.

The ACF stuff says "If there is a 'Custom Fields' menu item, then load the ACF page in the background and scrape the entries from it."

So I could also say "If there is a 'WooCommerce' menu item then load the WooCommerce settings page in the background and scrape the tabs from it.

This is entirely possible, but if I'm doing this for ACF and then Woo, then I probably want some API I can use for doing this repeatedly. I'm kinda building a framework for injecting items into the palette asynchonously, so this kind of thing will come.

This is one of the challenges with doing all this in an extension. I ONLY have access to the DOM! So whatever information I need to collect needs to be in the DOM. I don't even have the global JavaScript scope on window so to get the wpApiSettings object which contains the API URL I need to find the <script> tag where that object is defined, and evaluate the JavaScript code within it! Which is kinda crazy.

The limitations of being an extension make certain things that should be easy actually very hard! It's an interesting challenge.

As far as the caching goes ...

Yes, this is all good thinking. I'd thought I could at the very least keep items in the palette that have "disappeared" on a page load. So you're adding newly found items, but not deleteing old ones. Unless you log out (which I do currently detect).

(I'll raise a new issue for this change of caching approach!)

But I don't like the thought that you only have these items in the palette after the settings page has been visited. Hence the "preloading" approach outlined above.

[rosswintle]

Oh! You PR'd the plugin! Argh. Now I'm all confused. Really need to sort a workflow out (see Twitter!!)