Daniel F

This was fixed and patched a while ago. Are you still seeing the issue?

yes pls 🙂

Correct, it's based on the total members count. I agree, that's a fair point, which I have forwarded to our internal suggestion list.

Could you please submit a ticket so that we can take a look at this

Thanks. It's always better to submit a ticket so that we're really aware of any issues.

Look at my reply again;)

Yes the endpoint is correct. The fix is to change Request::I()->follow_app to Request::I()->followApp !

You can disable this in your ACP on the System => Streams page.

Thanks, I have filled a bug report for this. (At a quick glance it seems that there's a typo in the used request variables - followApp vs follow_app )

What do you mean with the second column? If you mean the sidebar, following code should accomplish this: \IPS\Output::i()->sidebar['contextual'] .= \IPS\Theme::i()->getTemplate( 'app1', 'module' )->sidebartemplate( $yourVariables );

There's a core_member_status_updates database table in 4.x BTW, are you sure that you're upgrading from 3.4??? The step in your error indicates you're on IPB 3.2

Turns out this was caused by @DawPis DP45) Mod Action Notify Enabled 2.0.5.1 plugin which was creating custom notifications which were associated with the core application. So once the plugin was disabled, the 3rd party notifications were still loaded because they were associated to the core application but the parse method was missing because of the disabled plugin. We're going to catch the error on the frontend, but this will also result in a guideline change, any future submissions which need own notification types will have to be a proper application with an own notification extension.

It was already approved;)

@Adriano Faria Could you pls reupload the file. I have no idea what's going on here, but it's "gone" 😞 We'll take a look at this ASAP.