opentype

yes. Latest beta from yesterday.

It’s not. Internal data storage was never an intended use for Pages databases.

Or convert to PHP template code? Like {{$variable = 5;}} I assume this continues to work?

Sure, that works too.

Suggestion to IPS: Move "basicRelationship" into the Pages Template section and make it selectable per database. It was always a bit weird to have that set up as a theme template. Not only would it solve the problem that Jimi and I are having and allow us to convert existing installations to 5.x, it would actually be a cleaner solution (separate Pages and theme templates) and make things easier, as we wouldn’t have to fill that template with tons of IF statements to only apply to certain databases. If you really want to show off, add some nice stock templates yourself. Not just the existing CSV type, but “grid with record-image” and things like that.

☞ https://invisioncommunity.com/forums/topic/473885-feature-deprecation-discussion/?do=findComment&comment=2908407 ☞ https://invisioncommunity.com/forums/topic/473885-feature-deprecation-discussion/?do=findComment&comment=2908422 My suggestion from that topic: ☞ https://invisioncommunity.com/forums/topic/473885-feature-deprecation-discussion/?do=findComment&comment=2907946 Could still be added to 4.x.

Actually, it was already available for some time, so http image calls on https pages wouldn’t break the SSL delivery. This was solved by importing all these images as attachments. But it was removed again after some transition period. Personally, I would love to see this feature with a white-list option. People often link community-related images from a few known sites in our field, which we absolutely don’t want to loose, but certainly will at some point in the future. Picking these sites for an automatic import would be great. Importing every linked media can easily lead to legal troubles (and significant fines), when the content is copyrighted, as it usually is.

To be clear: I specifically chose the feedback forum, not one of support forums, because this was meant as a feedback topic, not a “I am looking for help/instructions for my site(s)” topic. To make the point again in more detail: Defaulting to simple PHP mails has been the industry standard for php web apps for like 20+ years and Invision Community is no exception to this. It (usually) works right out of the box without the need for any configuration. There is now a significant change happening in this area. It’s something that is all over the web tech news and I see it happen across my various websites as well. Mailbox providers are significantly raising the bar to get mails delivered, demanding multiple positive checks for the various authentication options. This makes it a concern for many (self-hosted) IPS customers who start out new or usually don’t touch the default settings. They will wonder why so many registrations get stuck or why mails don’t seem to get delivered at all, because Google throttled the delivery after a php bulk mail without proper authentication. Right now, the IPS description calls the option “sufficient for most sites”, but this might be worth reconsidering. And that was the point of this topic. I’m not making a claim about how this could be addressed. Maybe it can be reliably addressed directly in the code, maybe not. Maybe the onboarding process should instantly ask for SMTP details. Maybe it can be helped indirectly with things like allowing different services for transactional and bulk mails. All I tried was raising awareness for this issue, because I see it happening all the time and I see it getting worse.

Dude, what the hell? No one has asked how one would set up DKIM. That was never in question. Nope. For phpMails and SMTP, Invision Community only seems to allow one mail service for both transactional and bulk mails. So, setting up a transactional-only service doesn’t seem like a good solution unless the website never sends out (marketing) bulk mails.

Setting it up is. Making it part of the mails needs to happen where the mail is created.

PHP mails have been a good default with acceptable delivery for many years. But now the major email services all check for SPF/DKIM/DMARC and reject mails without proper DKIM headers, which I can set up for my domain and mailboxes, but not for PHP mails sent from Invision Community. Any chance this could be added?

Should be no problem. You can just set up the new page under a new URL and then switch the URLs when the recreation is complete.

I get the idea, but I also wouldn’t hold my breath. It’s a niche use that goes against the entire framework revolving around community accounts. Not to mention that no one will agree on what those “essential“ information will be for that toggle. (I speak from experience regarding my Pages templates adding tons of options, which never were enough.) A custom app changing the template output for all user-related information might work though and would probably not be too complicated.

Are you sure about that? That must be new then. That function has always done what it says and deleted a template from a template set, effectively breaking the entire template set.

Tested it and I see the same in my store.

That’s not a useful question, because there is no general answer. Every potential customer needs to decide for themselves. And based on that calculation you either buy it or not — like with every single product decision in a supermarket, car dealership or whatever. Some communities make hundreds of dollars in ads every month. They don’t worry about investing $15 for a small improvement. Just look at it from the developer’s perspective. A plugin takes X amount of hours to code, test and support in the future. Multiply that with an hourly rate and you have the amount of money the developer wants to get back in earnings through the plugin price times the expected sales. Ending up with $15 for products that aren’t sold thousands of times isn’t surprising. It’s a bare minimum. And here comes the really bad news. Those prices only worked with the Marketplace and its large audience. With Invision Community 5, we can expect these smaller plugins to either go away or get much more expensive, because of fewer sales and the calculation presented above.

I have to agree with SoloInter: There needs to be a way to keep the strategically(!) created tags, independent from fitting in a most-used basket or low numerical limits. There is of course the noise of user-generated forum tags, which might have little value or even do more harm than good. But the strategically created tags need to be kept, independent from any hard limit. In fact, in the new system they can finally shine and be more useful than ever, but they need to be there to begin with. The alternative of dropping the tags and having the admins go through years of content to add them back in, isn’t really a viable option.

I might misunderstand it, but besides the technical difficulties, it sounds a little questionable legally. Wouldn’t the users have to voluntarily sign up for a paid subscription?

It’s an empty ad slot taking up space.

Check the “Existing Attachments”. It might still be there.

From the entire suite or forums? While it does not work well for certain content types, I use it heavily for pretty much all my Pages databases across all my communities. Best fonts, best books, best microphones, best anything. For all the data we collect around our community topic. Tens of thousands of votes that can’t just be trashed. They would at least be converted into an alternative system.