[Action required for Plugin Authors]: Upgrade to Plugin API v4 by January 4, 2024

Announcements
1

Hi plugin creators,

Today we’re releasing Plugin API v4. All plugins that use server-side actions need to migrate to Plugin API v4 by January 4, 2024. We will begin to flag plugins that have not been updated to v4 as “deprecated” on November 1, 2023.

Changes in Plugin API v4 affect server-side actions only. AWS Lambda, which we use to run plugin server-side actions, announced that it will end support for Node 14 in January. Therefore, plugins that use server-side actions will be required to switch to Bubble Plugin API v4, which runs on Node 18, by January 4, 2024.

Updating to Plugin API v4 will likely require you to make code changes to your server-side actions. For an update guide, please see here!

Screen Shot 2023-06-22 at 11.24.39 AM
Screen Shot 2023-06-22 at 11.24.39 AM2684×424 42.2 KB

What is the timeline for the API v4 upgrade?

All plugins using server-side actions need to migrate to Plugin API v4 by January 4, 2024. To make the update process as smooth as possible, we’ve split the migration period into three phases, outlined below. We recommend that you update your plugins during the first phase. In the second phase, we will display deprecation warnings in the editor notifying plugin users about plugins that have not yet been upgraded. In the third phase, we will officially deprecate server-side actions on Plugin versions <4.

Phase I: Today – November 1

  • Plugin API v4 released
  • We will start sending friendly email reminders to those who maintain plugins with server-side actions, nudging them to update.
  • We recommend updating your plugins during this phase so that your users have ample time to upgrade their plugins to the latest version.

Phase II: November 1 – January 4

  • We will begin to display warnings in the editor flagging plugins with server-side actions that haven’t updated to v4 yet.
  • We will begin to send emails to plugin users encouraging them to update their plugins that use server-side actions to the latest version.

Phase III: January 4 - 10

  • We will officially deprecate server-side actions on Plugin versions <4 on January 4, 2024.
  • We will conduct two Plugin API <4 brownouts in January to help identify any plugins or apps that haven’t been upgraded yet. During these brownouts, all server-side plugin actions will run on Node 18. This means that, in practice, server-side actions on any plugin whose Plugin API version is < 4 will break.
    • January 4: 2 hours
    • January 8: 8 hours
    • On January 10, 2024, we will stop supporting server-side actions on Plugin API Versions <4.

TL;DRs:

  • How do I upgrade?
    • Read our detailed upgrade guide here!
  • When is the deadline to upgrade?
    • We recommend upgrading your Plugin API version by November 1, 2023.
    • Plugins that use server-side actions must be updated by January 4, 2024.
  • How do I know if my plugin needs to be updated?
    • If your plugin uses server-side actions, you will need to upgrade to Plugin API v4. Otherwise, the update is not mandatory.
  • What exactly is the difference between Plugin API v3 and v4?
    • Server-side actions run on Node 18 in Plugin API v4 (whereas v3 uses Node 14). This is a significant change because we run asynchronous functions in Node 14 using fibers, which is deprecated in Node 18. Plugin authors will need to switch over to using more modern async Javascript syntax.
    • See the update guide for a detailed changelog.
  • Will my plugin break if I don’t upgrade?
    • Any server-side actions on plugins that do not update to Plugin API v4 by January 4, 2024 will likely break.
  • The AWS announcement linked above says October 10 is the EOL deadline, but here you say January 4—what’s up with that?
    • AWS was able to grant us a short extension to their EOL deadline, moving it to January, in order to allow plugin authors more time to migrate their plugins.
9 Likes
2

We are able to publish now?

1 Like
3

Yep! If you’re using the Alpha, you’ll need to switch to the full v4 API version in the “shared” tab of your plugin. We didn’t make any changes to the behavior of the API between the Alpha and the full release, so it should be as easy as just switching versions.

1 Like
4

As an agency, we’ve got 50+ apps

Any easy way to know which are affected?

Thanks
Zubair

5

Switching to NODE VERSION 18!!! Instead of 16 - thank you :slight_smile:

1 Like
6

Happy to see node 18 :slight_smile:

1 Like
7

Can you please cross post this to Plugin Builders and pin it to the top of Plugin Builders until resolution in 2024. This is critical information for plugin builders that should be on the “always reminder” level for the rest of the year.

4 Likes
8

Hey @henry.dowling, so are the following methods also available in the client-side element and action API’s? Or are these only in the SSA API v4? From the migration guide:

We are adding two new utility methods on Bubble Things:

  • id(): returns the Thing’s ID (synchronously – not as a promise).
  • getAll(): returns a promise for an object with all fields of the Thing.
3 Likes
9

All plugins that use server-side actions will need to update to v4 or else they will likely break. For an update guide, see here!

10

Yep, good callout—thanks!

1 Like
11

@henry.dowling Is there a way to check to see if any of my installed plugins are in need of an upgrade - so I can ping the devs of the plugins I’m using as well? Want to make sure I can be proactive as a plugin user / non-dev too.

1 Like
12

Unfortunately, these methods are only available in the server-side action API for now. It’s on our radar to add these for client-side element and action APIs (as well as just generally improve these APIs) but we can’t give a timeline yet.

4 Likes
13

Got it. Thanks for the answer, @henry.dowling. The .id() method is particularly useful and would simplify some functions that I use all over the place.

17

Does Bubble have a solution for app developers using plugins that have not been upgraded for whatever reason?

As we’re talking a no-code platform here, there are without doubt users who rely on plugins, and would have no idea how to code a solution themselves. There are also plugin developers who abandon plugins, meaning it’s likely these two scenarios will overlap.

Ideally, in these scenarios, if plugins are not being updated, Bubble would do something like take over the plugin or relase their own on v4 - I know ths kind of action is questionable for a number of reasons, but what are the alternatives?

6 Likes
18

Watching :eyes:

19

I believe I’m in this boat. One of the difficulties is that, as far as I know, there is no way for Bubblers to know whether or not the app developer is working on updating the plugin until the flag in November. That will only give us two months. Depending on the level of work, two months may be difficult to re-work alternative solutions.

Even then, I sure would hate to rework an app, just to find the plugin did push a supported update in December. Maybe there could be a flag for Plugin creators to indicate whether or not they’ve committed to upgrading to API v4?

Very interested in the solution before having to look for alternatives.

20

I hate that I need to rework plugins and don’t even know which ones need to be changed.

Take inventory than, you ask. Yeah, right! I’d rather remove my plugins that break from the marketplace and build new ones if the old ones break.

There’s likely a f ton of plugins in the same boat as potentially mine.

But yeah, I think that unmaintained plugins, should be randomly given to established plugin builders (builders who have plugins with at least 1k uses) (not agencies like zeroqode or copilot)

It’s like the Wild West out there is finally catching up to modern times and believe it or not, some of those cowboys are just going to die out. Others will get with the times.

4 Likes
21

@henry.dowling the update guide says

We are adding two new utility methods on Bubble Things:
id(): returns the Thing’s ID (synchronously – not as a promise).

and the typescript definition of BubbleThing says

export interface BubbleThing {
//...
// NEW
/** Returns the unique ID of this Thing. */
id(): string
//...
}

But when trying actual code in a plugin id is not a function, but just a property that has the value of the id as string.
properties.thing.id() throws TypeError: properties.thing.id is not a function
properties.thing.id correctly get the id of the thing.

Is this intended behavior?

2 Likes
22

The support just confirmed that it is a read-only field on the Bubble “Thing” data type, not a method, and that the docs will be updated accordingly.
The support was super quick, cheers to them :slight_smile:

4 Likes
23

Hey @henry.dowling , is there any plan to start exposing plugins in our app’s plugin page that have not upgraded to API v4 that have server side actions?

It’s already September so if we use any plugins still on v3 we only have ~3 months to ask/sponsor the dev to upgrade their plugin, or we migrate to a different plugin and ensure its functionally the same…

But right now we kind of have no idea what is safe and what will break in January. And we need time to test multiple plugins and pick best one to replace one if needed.

9 Likes