HeadStand

Sure, go ahead. A new version has been pushed to the Marketplace and is pending approval. It contains a fix for this issue.

Still not seeing all of them. By any chance, was this restricted only to anything under "front", or was this patch also applied to "global"?

One of my clients had a user who reported an issue with entering their credit card info. They kept getting the message "Invalid card number". We asked them for the card number and it seemed to work fine when we tested it. This one turned out to be a sort of user issue but only sort of. There were 2 things going on here. First, they were entering the card number with spaces. The back-end code for the credit card field does strip out spaces and dashes (\IPS\nexus\CreditCard::93) but the input field itself is set to have a maxlength of 16. So when he pasted the card number in there (no I do not want to know why this person is copy/pasting card numbers, this is not my problem), it truncated it and lost a digit off the end. The second thing that we found was that the spaces he was pasting weren't actually spaces, but some weird character. 🤷‍♀️ I would suggest altering the field validation (same location as above) to run a regex check for anything that is not a number and then throwing a very clear error message that only numbers 0-9 can be entered in the field. This seems to be the cleanest way to eliminate these kinds of errors. Thanks.

It's compatible as is. No update required. I'm going to update the file in the MP now so that it's marked appropriately.

No issues on my end. The query that appears to be locking things would be happening only if a field were deleted, not added. And that would be something handled by the IPS core code, not my custom.

A new version has been pushed to the Marketplace and is pending approval. Changes include: Tested for compatibility for IPS 4.7 and PHP 8 Date fields were not saved properly. Fixed. Address fields were not saved properly. Fixed.

A new version has been uploaded to the Marketplace and is pending approval. This update has been tested under IPS 4.7 and PHP 8.

As a developer, this is extremely upsetting, actually. And of course, as others mentioned in this thread, with CIC this is completely impossible. Does IPS intend to provide developers with another way to access the database for clients that are hosted in the cloud? Or are we expected to submit support tickets every time we need to do our own troubleshooting for 3rd party apps/plugins?

That's definitely fine... I did double-check all my method signatures in my hooks. Everything looks fine on my end.... I'll reach out to @rebraf and ask for a copy of his app so that I can try to troubleshoot. Most likely it's not an issue with either app, but we may be sort of bumping into each other.

This plugin is compatible as is with 4.6. I just double-checked everything.... no changes required whatsoever for compatibility. It's just not marked that way in the marketplace, which I'll fix. I don't have the Email Drip Campaigns app, and I'm not sure why it would break that piece? Without seeing the code I can't even make a guess. What errors do you get?

A new version has been uploaded to the Marketplace and is pending approval. Changes include: Empty sections left the placeholder in the newsletter when using a custom template @Claudia999 Error generated when accessing the Notifications in the ACP. Fixed. @Sonya*

Full documentation is provided on the "Additional Information" tab of the resource (https://invisioncommunity.com/files/file/8408-newsletters/. There is a full PDF that describes everything here..... Basically you set up the key and then you need to create individual issues before you send them. A newsletter is the settings that are used for each issue. If you're using manual content, the only thing you want to reconfigure is the content of the newsletter, you don't want to be required to create another newsletter each time.

A new version has been submitted to the Marketplace and is pending approval. It contains a fix for both of these issues.

A new version has been pushed to the Marketplace and is pending approval. It contains a workaround for unsubscribe links not working correctly with Sparkpost and Sendgrid.

Mainly because it has the ability to reply and react to content directly from the Stream. The stock Activity Feed forces users to navigate away from the feed if they want to interact with the content.

I did fix it by plugin, but yuck.

Reviving this thread because I figured out the actual problem and it's a fun one. I can't even figure out how to work around it. 😞 Unsubscribe works just fine for any outgoing email provider that doesn't use a bulk feature. For example, SMTP and PHP basically just send out each email one at a time. However, providers like SendGrid use an API call that allows you to send the content and replacement variables. This causes a problem here: <a href="http://localhost/toke/index.php?app=core&amp;module=system&amp;controller=redirect&amp;url=http://localhost/toke/index.php?/unsubscribe/%26email=*|member_email|*%26key=*|unsubscribe_key|*&amp;key=bd193a982da6f0499469b704762626d6720084d9d052e03039eb9ff7424db222&amp;email=1&amp;type=bulk_mail" style="color: #4a8aca; text-decoration: none; display: inline-block">Unsubscribe here</a>. The URL that is used for tracking includes parameter values of *|member_email|* and *|unsubscribe_key|*. Now... while these values do get properly replaced when the email goes out, the issue is with the key parameter that is passed to the redirect controller. The key is generated by a hash of the URL... which has *|member_email|* and *|unsubscribe_key|* instead of the actual email and unsubscribe key. So when the end user clicks the unsubscribe link, the URL no longer matches the hash. The only solution I can think of is to replace the entire tracked link with a replacement variable. So something like <a href="*|unsubscribe_url|*" style="color: #4a8aca; text-decoration: none; display: inline-block">Unsubscribe here</a>. I don't think this is fixable by plugin, which is going to drive me bananas.

A new version has been pushed to the Marketplace and is pending approval. All Collection properties (except the key) are now translatable.

A new version has been pushed to the Marketplace and is pending approval. It contains a fix for this issue.

That's supposed to be automatic. If there is no data to display, it shouldn't generate that section. Are you experiencing issues with that? Not at the moment.

Could be related to this: But I'm not 100% certain. Can you PM me with the link that is in the email itself? I just need to look at the structure to confirm. Thanks.

I don't mean to come off as horrible... 😆 I generally try to be better about support, but I've just been drowning lately. Doing the best I can.

Based on the exception above, it seems like you had data already in that column that was longer than whatever IPS decides to set it to. The field generation itself is controlled entirely by IPS. My code does not actually create or modify the database columns. I love how I have to get into my personal life on these topics..... I had covid in January, followed by my kids. Fell massively behind with work. My private clients take precedence over marketplace support. In general, if you have something urgent, feel free to PM me. I usually respond to PMs much quicker than these topics.

All of these are handled by the core IPS functionality, it's not specific to my app. 1. IPS does not offer a time field 2. Again, the options available for each field type are handled by the core IPS functionality. 3. What did you set the length to?

Done, but it's pending approval now.