[Resolved] Split: View settings don't persist

[Author]

Posts

[Nigel Supporter Languages: English (English ) Spanish (Español ) Timezone: Europe/London (GMT+01:00)]

I was referring to your staging site.

Thanks for confirming your browser. I had an odd experience on Friday in a zoom call with the developer where we were making changes side by side to the exact same page and not only was it working for the dev and not me, I couldn't even see the changes the dev made so that if we both loaded the template at the same time, he saw different content than I did, and what he saw matched what was saved in the database, whereas what I saw did not.

He was using Chrome, I was using Firefox. For some reason Firefox was responding to the REST requests with a local service worker, rather than from the server itself.

Now that you have confirmed you are using Firefox, too, we can pursue investigating why that happens, it is unexpected.

I imagine Edge probably works, given that it is now based on Chrome.

I'll pass the info on to the developer, and let you know when they find something.

[Nigel Supporter Languages: English (English ) Spanish (Español ) Timezone: Europe/London (GMT+01:00)]

This was a real head scratcher given what the developer was seeing vs what I was seeing when we were both editing the page at the same time but seeing different results.

I eventually tracked down the problem, which arises from the Super Progressive Web Apps plugin.

That plugin installs a service worker in any browser that visits the site.

That service worker remains installed and active even if you de-activate the plugin.

So some users (those that visited the site when the plugin was active) will see one thing (in this case, the problem), while other users who visit the site when the plugin has been de-activated will see something else (in this case, everything working normally).

The question of which browser is used (Firefox or Chrome) was a red herring, simply reflecting whether the user had the service worker installed in their current browser or not.

So the problem happens when saving the template because the service worker caches requests that don't then reach the server.

From my understanding of the purpose of the plugin—to give an app-like experience on mobile devices—it should only be operating on the front-end, I don't imagine that you need an app-like experience for working in the WordPress admin pages.

I suggest you contact the developers for clarification: should the service worker be operating on back-end operations. If it *is*, this is creating compatibility issues, and you would need to know more about how to disable it in the back end (I couldn't find any such settings).

You can file support requests on the plugin page: https://wordpress.org/support/plugin/super-progressive-web-apps

Alternatively, submit issues on their github repo: hidden link

I should point out that the only way you can save templates in the back end without the problem recurring is to get rid of the service worker from your browser, and don't reactivate the plugin to prevent it being added again.

In your browser dev tools you can go to the Storage tab and clear each kind of storage.

[francescoG-3]

Hi Nigel,
thank you for your reply.
I have written on https://wordpress.org/support/plugin/super-progressive-web-apps

I'm waiting for a reply.

[Nigel Supporter Languages: English (English ) Spanish (Español ) Timezone: Europe/London (GMT+01:00)]

OK, let me know if they reply with something we can use to prevent this.

[francescoG-3]

Hi Nigel,
they have replied me this:
Can you please let us know what issues you have been facing? Also it’s better if you share screenshots as well. So that we will have a look and let you know back.

You can find the topic here: https://wordpress.org/support/topic/issues-with-service-worker-caches-requests/#new-topic-0

[francescoG-3]

Hi Nigel,
There is a new update for Super PWA plugin, and contains:

2.1.12
Date: 29.May.2021
Enhancement: Need An Option to exclude the URL #183
Enhancement: Improved Tabs UI design #190

[Nigel Supporter Languages: English (English ) Spanish (Español ) Timezone: Europe/London (GMT+01:00)]

I'm not sure if the URL exclusion list they just added will help here, as we are likely looking at REST API requests, but I'm not sure, I've asked the developers for more details.

[Nigel Supporter Languages: English (English ) Spanish (Español ) Timezone: Europe/London (GMT+01:00)]

The developer confirmed that saving the template on the back end includes POST requests to the REST API and it is these the SuperPWA plugin is interfering with and which need excluding.

But there isn't just a single request endpoint that needs excluding.

We would need details of a mechanism to have such requests excluded.

The plugin authors are invited to contact konstantinos.g@onthegosystems.com if they would like to discuss details.

[francescoG-3]

Hi Nigel,
from the Super PWA support I had this reply:

Can you please try to send screenshots of SuperPWA exclude URL setting? So that we will have a look and let you know back.

[Nigel Supporter Languages: English (English ) Spanish (Español ) Timezone: Europe/London (GMT+01:00)]

I'm not sure that makes sense. The URL setting they just introduced in the latest version, yes? We are not using that setting, so there is nothing to show.

[Nigel Supporter Languages: English (English ) Spanish (Español ) Timezone: Europe/London (GMT+01:00)]

I have tried adding the URLs of the REST API routes to the plugin settings for URLs to exclude, but they do not work, the service worker still intervenes in such requests.

These are examples of the URLs I added to the exclusion list:

hidden link
hidden link
hidden link
hidden link

(I added them as a comma-separated list, as per the plugin instructions.)

But it doesn't work.

[francescoG-3]

Hi Nigel,
sorry for the delay, but from Super PWA plugin support I have the reply today.
Well, they have replied to me this:

You can place only that site URL not other sites and also when you are placing the URLs do not place stars* at the end. It shoud be only with /.

[Nigel Supporter Languages: English (English ) Spanish (Español ) Timezone: Europe/London (GMT+01:00)]

Yes, well, that's the problem, when Toolset communicates with the server using the REST API it uses many different endpoints, it is not possible to provide a definitive list of them all, they may change over time, the plugin needs to provide a way of using wildcards to exclude *all* requests to Toolset REST API routes.

We can't provide a solution, the problem originates with the SuperPWA plugin. If they have an alternative solution than the URL exclusion list we'd be happy to hear it.

[francescoG-3]

Hi Nigel,
from the SuperPWA support I have this reply:

Can you please let us know what issues you have been facing exactly? Please let us know, So that we will let you know accordingly.

I don't know why they don't want to write an email directly to the Toolset authors...

[Nigel Supporter Languages: English (English ) Spanish (Español ) Timezone: Europe/London (GMT+01:00)]

That is a really unhelpful reply.

The issue you are having is "settings saved via REST API requests on Toolset admin pages appear out of date because they are being served by the SuperPWA service worker instead of the server itself. SuperPWA should not be interfering in these requests. The simplest way to prevent this is to exclude the service worker from any requests to the Toolset REST API routes. Because these can include many endpoints which may evolve over time, that means allowing wildcards when declaring the URLs to be ignored."

There really is nothing we can do here, although it was difficult to diagnose the issue itself is very simple, as is the solution, but SuperPWA are the only ones who can implement it.

If they are unable to help then I'm afraid you'll need to make a choice between using Toolset or SuperPWA for your site.