rebraf

@Jim M Brandon here.
You need to submit the request as an "AJAX" request, that's the key. Here's a code snippet you can drop into postman or execute on the server to reproduce. It will cause the error on demand.
curl --location '{base_url}/events/event-search/' \ --header 'X-Requested-With: XMLHttpRequest' \ Swap out {base_url} with an Invision base URL.
I can reproduce the error here on this community easily with this for instance:
curl --location 'https://invisioncommunity.com/events/event-search/' \ --header 'X-Requested-With: XMLHttpRequest' \  
Hope this helps! The problem is that the $select variable in the controller isn't initialized basically (or rather, it's initialized inside an if statement but that if statement isn't hit, however a separate query is ran for AJAX requests later on expecting the variable to be set).

Thanks @Gauravk and @rebraf! 
Thank you for bringing this issue to our attention! I can confirm this should be further reviewed and I have logged an internal bug report for our development team to investigate and address as necessary, in a future maintenance release.
 

@Jim M Brandon here.
You need to submit the request as an "AJAX" request, that's the key. Here's a code snippet you can drop into postman or execute on the server to reproduce. It will cause the error on demand.
curl --location '{base_url}/events/event-search/' \ --header 'X-Requested-With: XMLHttpRequest' \ Swap out {base_url} with an Invision base URL.
I can reproduce the error here on this community easily with this for instance:
curl --location 'https://invisioncommunity.com/events/event-search/' \ --header 'X-Requested-With: XMLHttpRequest' \  
Hope this helps! The problem is that the $select variable in the controller isn't initialized basically (or rather, it's initialized inside an if statement but that if statement isn't hit, however a separate query is ran for AJAX requests later on expecting the variable to be set).

Update: I did hear back from rebraf via PM - as his license has currently expired he is unable to reply to the support message.  He says he will continue support for Email Drip Campaigns through 4.x but will have to evaluate the situation as 5.x approaches, depending on Invision's plans and the subsequent changes which may need to be made.
So stay tuned, I guess.

Could you perhaps offer your apps via a third party website and we just install/maintain them as "Custom" and not via marketplace. I am seeing many developers moving this way.
It would prevent many of us who have invested in this (and other) apps from being essentially now orphaned.

Custom Redirects is not triggering any PHP8 compatibility warnings when I test it locally with 4.7.2 installed as far as I can see.

I updated my installation to 4.7.2 and ran the compatibility scanner and only one application (not in the marketplace) is being flagged. I suspect the compatibility scanner isn't running correctly for some reason since it is throwing errors at the code level.
Can you tell me what the compatibility scanner (on the support tool) is saying about this application isn't compatible? I've gone through and looked at all the hooks and I don't see any that should be triggering a warning off the top of my head.

Many thanks for your help.
Now currently rebuilding thumbnails. 

This is the support topic for my custom redirects plugin.
 

(B) already exists, so if you move a user to another group when he purchases, you can already accomplish this (and if you don't, you could always set up a new secondary group that you mover users which will accomplish this).

Yes I intend to certify my apps for 4.7 soon. 

(B) already exists, so if you move a user to another group when he purchases, you can already accomplish this (and if you don't, you could always set up a new secondary group that you mover users which will accomplish this).

Yes I intend to certify my apps for 4.7 soon. 

It does have certain conditions already, mostly based on demand/requests. It would be possible to add another condition "When member receives a badge" if there is enough support for adding it.

Videos do not work in email (most email clients do not allow them) and so Invision strips videos out of emails. This has nothing to do with the drip campaign application itself I'm afraid.
The only way to "test" the campaign would be to assign it to yourself in the ACP manually.

As mentioned above, you'll need to send me a PM with ACP details so I can investigate. I am unsure from the screenshot alone why it wouldn't be working as you expect.

Generally speaking, images in emails should work. Are you attaching them in the email? Remotely linking to them? Do they not display in any email clients at all?
Testing an individual step is not a bad idea. I'll note that for a future version.
Can you download the raw email (how you do this varies between email clients) and send it to me in a PM? Note that I'm not talking about exporting the email as a pdf or anything like that, but downloading the original email with email headers.

Videos do not work in email (most email clients do not allow them) and so Invision strips videos out of emails. This has nothing to do with the drip campaign application itself I'm afraid.
The only way to "test" the campaign would be to assign it to yourself in the ACP manually.

Pull up the member in the ACP and scroll down on the bottom left hand column. You can add members to campaigns, restart campaigns, and remove members from campaigns (that have not yet ended).

This application works independently from any other functionality you may be using (within Invision, or third party addons), so if you have configured your Commerce installation to send a custom email when a user purchases a product and you configure the drip campaigns application to send a series of emails when a user purchases a product, indeed they'd get both sets.
You have two basic options:
Set your first email in the drip campaign series to wait a period of time. The commerce email would go out right away, and then the drip campaign could start (for example) 3 days later. It depends on your intended use case if this would be the ideal approach, but it's certainly doable. Disable Commerce sending any custom emails after purchase and roll that into the drip campaign instead. The obvious answer is "Yes" because just about anything is possible, but it's a bit tricky. If you asked "can you add a trigger when a user downloads any file", that would be something that could be put together pretty easily, but when you want to restrict to specific files there needs to be a way for you to specify which one, and there's no real simple method within Invision to choose specific content items (only specific nodes). 
Not a bad idea, however it would need some testing. My fear is that a user could end up with getting steps duplicated (i.e. receive the same email from the campaign twice) if they were on a campaign that had a step paused and then that step is later re-enabled, but I'm sure this could be worked around. I'll think on it some.
Is this a feature anyone else has a need for?

There shouldn't be any negative performance impact on high traffic boards, no.
A campaign can be initiated by current activity, but the emails are sent via a task.

I don't think I'd advocate for automated changes based on what is being brought up, but I wouldn't be opposed to some additional options on the campaigns.
Allow more than one instance of this campaign Automatically cancel this campaign if purchase/subscription is cancelled That first option would have to be implemented very carefully. The reason it behaves the way it does presently, as I recall, is because if you set a campaign to initiate when a user reaches 10 posts or whatever, you definitely wouldn't want the campaign to fire at 10 posts...and 11 posts...and 12 posts...and so on.

I don't think I'd advocate for automated changes based on what is being brought up, but I wouldn't be opposed to some additional options on the campaigns.
Allow more than one instance of this campaign Automatically cancel this campaign if purchase/subscription is cancelled That first option would have to be implemented very carefully. The reason it behaves the way it does presently, as I recall, is because if you set a campaign to initiate when a user reaches 10 posts or whatever, you definitely wouldn't want the campaign to fire at 10 posts...and 11 posts...and 12 posts...and so on.

I don't think I'd advocate for automated changes based on what is being brought up, but I wouldn't be opposed to some additional options on the campaigns.
Allow more than one instance of this campaign Automatically cancel this campaign if purchase/subscription is cancelled That first option would have to be implemented very carefully. The reason it behaves the way it does presently, as I recall, is because if you set a campaign to initiate when a user reaches 10 posts or whatever, you definitely wouldn't want the campaign to fire at 10 posts...and 11 posts...and 12 posts...and so on.

Those are interesting use cases.
Running custom PHP, specifically, is not very complicated. The rest would require a bit more time and energy investment.
I would be interested in seeing if anyone else has a need or use for those suggested additions.