opentype

It’s not. It’s a normal reading size (or slightly below) and a pretty good compromise. And the larger size is limited to the main text, which is also a good way to do it. I could still quibble about the line length, but I save it. ;-)

It’s the PWA.

The footer menu collides with an iPhone touch point: Would be good to give it a little more space. Example from my own page with custom CSS:

By the way: can we maybe increase the font size a bit? I think it got even smaller compared to the 4.x default, which I also find too small. I’m in the reading glasses age now.

Subscriptions are useful if you have various subscription tiers and members should be able to upgrade and downgrade between them. Product subscriptions are independent of each other and actually have MORE settings. You can also convert product subscriptions to subscriptions (if you use typical settings) without changing anything at all about the existing subscriptions. The two systems also are presented in different ways. Product subscriptions appear as regular products in a category within the store. Subscriptions have their own page. Just some stuff to consider.

When you change the price, it asks you whether the new price should apply to all or just new purchases. So you can easily change the price for new purchases and keep the existing subscriptions as they are. I’ve done that multiple times.

But the .i-wrapper { max-width: 1800px } could be removed so the background colors stretch without the content.

I would first try to answer, that the IPS ad system is user-group based and already guarantees that ads can be shown only to specific user groups like guests. That answers their question “we need to understand how users are differentiated on your platform”. That might make all the tech stuff with dynamic code to identify users completely unnecessary. You probably don’t have to use ad code for everyone and code in specific stuff to identify the users on the side of the ad provider. You can just set up ads for guests and members in the ACP separately.

It’s a developer feature. It’s not meant to be idiot-proof. They are not going to prevent you from adding faulty code, nor will they remove that option, because adding code to the header is important. There is no bug here. You just found one of millions of ways to break a site with faulty code.

To add some context: It’s actually a foundational issue in the way Commerce is set up. It creates an invoice not when a purchase is made, but already when a product is added to the cart, which for most sites (allowing guest access), is something that even search engine crawlers are initiating by repeatedly following all links. As a result, Invision Community installations can be flooded with empty invoices in the ACP, which are then kept forever. They can be ignored, but they are still annoying, creating huge database tables for no reason and making the ACP overview of invoices hard to browse. So, this really needs a proper solution at some point as it has existed at least throughout the entire 4.x product line. Bradybarrows tries to fix the symptoms instead of curing the illness by trying to delete the invoices in an easier way. But the problem should not even occur to begin with or – if a major refactoring regarding the invoice creation isn’t feasible – should have an automatic solution. There would be nothing wrong with having prune options for these types of empty guest invoices.

Agreed. The new system could be an extremely powerful tool for site-wide content discovery and search. But if we go beyond a simple structure (like just tagging #news or something), it will be too limiting. For my font-related communities, I use tags for time period (1920s, 1930s, …) and style (sans, serif, blackletter …) and region (Germany, France …). Users would certainly want to combine those and say “show me “1920s + blackletter“ or “1920s + blackletter + Germany“.

It’s in the member group settings:

It’s the Reactions setting in the Notifications settings (for each receiving member). https://invisioncommunity.com/notifications/options/ (Example URL from this community) But it’s probably more a case of talking to this specific member.

What are the attachments showing? What type of emails are being sent out that cannot be delivered? It could be something specific like “Post before Register“ reminders you might want to turn off specifically. In general, you rather want to deal with these emails instead of not receiving them in the first place. It tells you about delivery issues you might want to address. If you never see them, you will never know there are problems. If you want to get rid of them, you would have to send your community emails from a “no-reply“ address, not your regular inbox. You would usually have to set that up with your domain/hosting provider. They might have a specific function for that, or you would simply use a mailbox that you don’t check regularly. (It helps to add some automated delete function [e.g. after 30 days]. That way you can still check the mails, but you are not wasting space with storing these emails forever.)

You can keep repeating it all day long. It doesn’t make it true. I grasped your feature request immediately, even though you lay it out in a way that is much too complicated. You want a fixed price for everyone ("a simple price for all customers") and then have the proper taxation show depending on the customer. I get it. It’s not hard. But you ignore, that this is not how taxation in regular shopping software works at all. There are two systems: You start with a tax-not-included price and then some customers might have taxes added later (usually during checkout) You start with a tax-included price and some customers might get a tax reduction later (usually during checkout) You want a third option, that does not exist. I know you don’t want to see it like that, but by asking for a fixed price for everyone, you are asking the shopping software to NOT DO TAXATION AT ALL, i.e. not to add or subtract anything at any point. Yet, you still want taxation to display. This is where it breaks down and that’t why you keep saying it doesn’t show the way you want and that’s why I keep saying that the problem is that you don’t want to set up the proper taxes in Commerce. If you would, they would show properly, but they will not used fixed prices, because that is not how taxation works in a standard shopping software. And that doesn’t even address the problem of having independent tax calculations in Commerce and Stripe. It’s a mess. And I am justified in pointing that out. If only to make you understand why this functionality is not supported. Once again, I address and explain the topic at hand (tax functionalities), you again get personal and “laugh“ about my comment. It’s called projection, it’s dishonest (framing) and it is completely irrelevant. If you care more whether my comments feel nice enough for you vs. whether they are correct/helpful in their content, and if people aren’t allowed to comment on potential problems with your feature requests, please state that upfront, so we don’t waste our time and only end up being personally insulted for investing time helping you see things clearer. Maybe one day, you will talk it over with an expert for shopping software or a tax consultant and you will realize that all I stated was actually true and you will apologize. Until then, welcome to the block list.

Good luck then. If you can’t appreciate the time invest to give explanations and suggestions about the IPS software and taxation in general, you are on your own.

It’s not possible, because you would be the only Invision Community user who would want use this super strange approach. Taxation that depends on the user needs to be handled in the shopping software itself: from the product page (where base taxes might be shown and might be legally required to show), to the cart, to the checkout (where most of the relevant decisions about taxation need to be made) to the final invoice. In many jurisdictions, it is even required to show this information upfront. But you don’t want to set up any taxation in the shopping software, let it all calculate by Stripe (which is way too late as it happens at the point of purchase), and then have proper taxes in the shopping software (you chose not to have taxation calculated in) because you now want it for the user invoices. That’s self-contradicting. My suggestion would be: A) Again, use the internal taxation methods of Invision Community. It takes a little work but it is not rocket science. (Keep in mind: this is based on your local jurisdiction(s), not the taxation rules of the entire world. As a business in Germany, taxation for the USA is “0 percent“ and I am done. The state rules you mentioned don’t apply to me.) B) Skip the Commerce software altogether and use a custom app to ONLY interact with Stripe for your orders, taxation and invoicing. You need to pick one. You can’t have it both ways.

That doesn’t work. IC Commerce is not built around Stripe. It needs to also calculate taxes properly if the website doesn’t use Stripe or Stripe and PayPal for example. So, relying on Stripe for taxation is not very helpful. It might even make things worse if the tax calculations differ or if the user downloads an invoice from Commerce without tax, but you are calculating tax in Stripe. And this might be why you are struggling with this. You really need to set all this stuff up in Commerce. It’s not the most flexible and intuitive interface, but it does work. The software does allow for B2C and B2B sales, location taxation, VAT ID checks and all the usual stuff. Just remember that you will always input prices without tax. That’s the thing you cannot change. But you can calculate proper taxes.

Most professional online software systems offer this. You choose to set all your prices with tax or without tax and then the software either adds or subtracts the taxes based on this choice throughout the entire system. With Invision Community, you can only add taxes. That’s a little annoying, if only for ending up with rounding errors, where a certain target price can’t even be reached and you end up with 19,99 € or 20,01 € instead of the 20,00 you might want. I probably made a feature request for that as well some years ago. So, yeah, it would be nice, but I am not holding my breath. That’s a foundational underlying principle in any shopping software, not just a matter of adding a few conditions to the cart display or an invoice. I doubt this is easy to implement at this stage – not to mention that this interacts with all the complicated tax calculations that are already going on behind the scenes.

There is nothing wrong in general with adding code like this through the custom.css. I just used your example and it shows up fine.

Is anyone already using Stripe card payments with the 5 beta? I am getting the Stripe forms injected in the checkout but everything seems unresponsive. Can’t even visually type a card number.

Nice customization. Would be a good feature request to set that directly in the Menu Manager.

I appreciate the various layout options and the inclusion of more images in the 5.x widgets, but it seems the new widgets don’t use thumbnails even if they are available. Example: Here is a Record Feed widget which shows the images in a size of just 30×30 pixels, yet it loads the full size record images, which might be 5000 pixels wide each. 😱 Please add a condition to use the thumbnail when available.

A rating is just a value (1, 2, 3, 4, 5), a review necessarily contains a review text in addition to the numerical value.

Pretty sure that was the case, as AllAstronauts had to develop dedicated plugins/apps to make the S3-compatible services actually compatible with the IPS S3-implementation at the time. But I guess moving from S3 to Backblaze should be easy now. In theory. Someone else self-hosted with large files please try it first. I would be extremely anxious to start a move and possibly end up stuck with a locked task and partially moved files.