Jump to content
This topic contains 20 posts. A summary containing the most significant posts is available

Featured Replies

Posted

Could contain: Page, Text, File

Are you planning on cleaning up deprecated APIs?

thanks

  • Author
 

We still rely on an upstream library that makes use of this API. As noted here, we're moving towards native JS in v5.

Judging by my quoted post from 2020, should we expect a change in 2028?😇

  • Community Expert
 

Judging by my quoted post from 2020, should we expect a change in 2028?😇

As was already mentioned in the post you mention from 2020, it is a large change that requires a major change in the platform. v5 is that major change, and even with that, we are having to move it part by part. While I understand you want this to change over night, its going to take time. 

Google says: "Deprecated APIs are scheduled to be removed from Chrome." Will you beat this removal date, and do you know what that date actually is?

 

Google says: "Deprecated APIs are scheduled to be removed from Chrome." Will you beat this removal date, and do you know what that date actually is?

 

This one?

https://developer.chrome.com/docs/web-platform/deprecating-unload

If so, Ending with 100% of users by the end of Q3 2024

Assuming that means anyone on v4 won't be able to use Chrome after the deprecation?

Edited by Clover13

I don't know what the schedule is for v5, but it seems to me that some sort of patch might be needed here for v4, as this is ~6 months away. It's hard for me to believe that v5 will come out with enough time for everyone to get upgraded by then.

This is the removal timeline from the Google article:

  Quote

In addition, from Q3 2024, we intend to start a generic phase where unload will gradually cease to function on any sites, starting with 1% of users and ending with 100% of users by the end of Q1 2025.

Deprecation means that it will be removed soon, not cease to function. Q1 2025 maybe that date of cease to function. However, that does not sound firmed up.

Also, it is worth noting that a library we use has this function in it. Whether or not that we use the functionality it uses as a part of it is another thing that a developer can confirm. It also may not be detrimental to your sites at all so I wouldn't panic just yet 😉 

  • Author
 

Also, it is worth noting that a library we use has this function in it.

This sounds very strange - you are developing a very successful product - fact. But you use a third party javascript that changes the results of your work...And you don't reduce the value of your product when it degrades in use...
Why not create a complete set of just your product…
There is a Bulgarian proverb - but it's untranslatable to write it to you, and it sounds vulgar... But it's strange to me - issues with libraries constantly arise, and not just now, and you justify yourself with them, but you don't trying to make your libraries compliant with the new web criteria - and manageable by you...

 

but you don't trying to make your libraries compliant with the new web criteria - and manageable by you...

In V5, we will indeed be changing this and this has been outlined multiple time 🙂 . I'm not sure where you read we weren't. It isn't something we are able to just patch tomorrow though, I'm afraid. It is a long process to remove our dependency on the JavaScript libraries we use currently.

 

This is the removal timeline from the Google article:

Deprecation means that it will be removed soon, not cease to function. Q1 2025 maybe that date of cease to function. However, that does not sound firmed up.

Also, it is worth noting that a library we use has this function in it. Whether or not that we use the functionality it uses as a part of it is another thing that a developer can confirm. It also may not be detrimental to your sites at all so I wouldn't panic just yet 😉 

So if I understand your response, perhaps my site won't function properly for 30-50% of Chrome users by the end of this year, and 100% one year from now, if you don't fix this issue in time?

 

So if I understand your response, perhaps my site won't function properly for 30-50% of Chrome users by the end of this year, and 100% one year from now, if you don't fix this issue in time?

That is the exact opposite of what I said. 

  • Author
 

In V5, we will indeed be changing this and this has been outlined multiple time 🙂 . I'm not sure where you read we weren't. It isn't something we are able to just patch tomorrow though, I'm afraid. It is a long process to remove our dependency on the JavaScript libraries we use currently.

Let me be skeptical... I became your customer when version 4.0.x launched with similar promises... That was 9 years ago... Now you are promising a change with version 5.x.x... I'm not sure that will happen I'm...I'm sorry...

  • Community Expert
  • Management

We are not going to simply allow all our customers to never use Google Chrome again. ðŸ˜… That would be a terrible decision.

We will ensure it's resolved ahead of the removal later this year. We use an older plugin for jQuery to manage browser history state. We already plan to move that to native JS APIs in v5 and v4.

Please check AWS S3 as well

Could contain: Page, Text

  • Community Expert

It's the same file, simply loaded from a different file storage.

 

It's the same file, simply loaded from a different file storage.

Oh that’s right, I recently moved my theme resources to S3. I thought maybe there was some AWS integration script/API being called.

  • 2 weeks later...
  • Community Expert
  • Management

We are working on having this fixed for the next release. We expect a beta fairly soon and would appreciate a lot of testing as the old plugin touched on a lot of areas.

Recently Browsing 0

  • No registered users viewing this page.