rebraf

When I have development mode enabled, any databases using custom pages templates throw an error because the system tries to look for the custom templates as actual files on disk (under applications/cms/dev/html/... paths). Is there any work around for this besides copying the template files to disk in the paths specified, and then maintaining them at both places? Can Invision Community not just fall back to the database automatically with developer mode enabled if the template files don't exist on disk maybe?

In Invision Community 4, we could add a hook to the \IPS\Text\Parser class to add a new oembed endpoint and this worked great. Obviously we don't have hooks in Invision 5 however. Is there a way that I'm missing to add a new oembed endpoint? protected static function oembedServices() { $services = parent::oembedServices(); $services['*.loom.com'] = array( 'https://www.loom.com/v1/oembed', static::EMBED_VIDEO ); return $services; }I realize you can add allowed iframe URLs and get a pseudo-embed that way, however it does not embed the video itself but rather a generic loom page that just has the video title. The actual oembed endpoint results in the video itself embedding.

@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).

A 410 response code is not suitable for a redirect - redirect header codes should be in the 3xx range. I would suggest if you want to serve a 410 response instead of a 404 response when content is gone that you should probably seek out (or commission) a plugin specifically designed for that functionality. Unfortunately I don’t think it falls in line with the intention and purpose of this plugin.

This plugin is for topics. It will work for support topics associated with downloads files, but not for comments on downloads files.

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.

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.

The overarching problem appears to be that the thumbnails are extremely small. Your thumbnails are around 240px x 160px (give or take), and so they're just too small to fill the size of the blocks. You have two general options. You can increase the size of your Gallery thumbnails. The default thumbnail sizes for Gallery are 600x600 FWIW, so you've got a pretty significant drop in size. Note that you will need to rebuild your thumbnails afterwards if you go this route. This is the solution I recommend if you want to benefit from a highly visually interesting Gallery page. You can alternatively adjust the CSS definitions to tweak the sizes of the flexbox cells. The default there is 40vh, but if you add something like this to the end of your custom.css the large gaps will disappear .elGalleryFlexbox_cell { height: 30vh; } I do notice that all of your thumbnails are essentially the exact same size, so you're not going to see the masonry layout with this solution that is intended...you need images with different sizes if you want them to appear at different sizes, basically.

(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.

Yes, you can supply a URL external to your community to redirect to. 🙂

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.

Yes, just tested and it works fine.

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.

On the surface it seems right from your screenshot. I assume you are looking at user that has changed from New Member to Member (after the campaign was created) and they did not have the campaign assigned? You may need to send me a PM with your ACP login details and an example member to look at in order for me to take a closer look.

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?

Can I just say, your 6 month old labrador seems like he was quite destructive. Glad to see he chilled out when he reached about 12 months old. 😛

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.

Uploading a new version now that should address the concern.

To confirm, if you go to send a bulk mail and use the filter for "has purchased product ..." do you see the same issue there? Just want to be sure this will resolve your concern before I adjust the behavior.

Should be available again!