Rikki

It's a legend lost to time. We just keep them in case removing them releases a terrible curse.

Unless I'm misunderstanding your report, the email address you see is that of the user that is checking out - i.e., their own email address.

While TestFlight (and Android) allow you to submit feedback, honestly the best way is to submit a ticket in the usual way. Thank you!

CSS is flexible enough to allow you to do that without needing unique classnames. For example: .ipsType_richText a { color: red; }

It's under Customization -> Appearance -> Icons & Logos. As for push notifications, I'm not sure what our plans are on that.

We already have PWA support, though that doesn't include push notifications yet.

We are a way off of offering a white label service still - we plan to get the main app stable and add more functionality first. We'll post an announcement when we're ready to accept some interested sites 🙂

@opentype to the rescue 🙂

Thanks for the feedback; it sounds like a couple of the issues you noted are bugs, so we'll be able to address those as such. We've been upfront that firstly the app is in its early stages but also that it won't necessarily be ideal for every community. If you have a lot of customization (be it plugins or lots of custom pages) it's probably not going to be the best solution for you. We may devise a solution to that in future but right now it'll be focused on core 'out of the box' functionality. I'll lock this since you have struck out your first post, but I just wanted to address you

In 4.5 we've tried to keep headers consistent, so that buttons are where you expect them to be, there's space for additional buttons as each page/app might require, and so that each page/app can extend the data shown in the header without the whole thing breaking down. In 4.4, this was a problem - sure, on perfect example pages, the follow button worked well in the top right. But using a different app where more buttons need to be shown, or even just having a long topic title, suddenly it wasn't so pretty and usable. The new header is designed to be flexible and extensible according to require

We don't load (many) polyfills ourselves - they are included with libraries that we use. Those libraries will only execute them when needed, but the code is still sent to the browser since we bundle and minify javascript.

None of our own CSS selectors use the .sp prefix - that comes from a third-party library we use. But frankly, the possible overheard for the browser is so negligible that it isn't even worth worrying about,

Apologies again! Update your app to get the latest build and things should be good now. At the time of this post, the app was approved in the Play Store but still pending review in the iOS App Store, but should be available soon. Note that in both stores it's still in the beta process (Beta in the Play Store, TestFlight in the iOS App Store) so you won't see it unless you specifically opt in to the beta.

We have no problem with choices - that's why we have thousands of choices in the AdminCP. But every choice, no matter how small it may seem, has a cost in terms of development time, future maintenance, documentation, UI complexity and so on. And that's not even counting the problems with the feature that we've already outlined, specifically that they aren't the same for all users and therefore cannot be relied upon in the way you want them to be.

The date in every post provides a direct permalink to the post. Incorrect post numbers based on a user's individual permissions would certainly present more of a usability issue for both disabled and able-bodied users. It's absolutely fine that some people would like to have post numbers back - we understand people don't always like change - but please let's not try and justify it as being a legal requirement.