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.