Morgin

Sorry to bug one last time - is this still a relevant way of having the ad show up inside a box like a regular post? If I wanted to drop the profile picture and left column and only have a single box containing the ad, could i just use the article itemscope, delete the aside class, and keep only the div class? Thanks @newbie LAC!

Can you do ads after every X posts (i.e ad after every 10th post, so if 20 posts per page is the setting, there would be 2 ads) in your enhanced ads app?

Is this possible with this plugin? that is, given different users may have changed their settings for how many posts show per page, would it be possible to have this simply show an ad after every 10 posts, as opposed to after x posts on a page (or all pages). Also, what does "reverse" mean?

Time based would be the wrong approach. They will more than likely implement support for prefers-color-scheme (https://web.dev/prefers-color-scheme/), release an official dark version of the default skin and acp skin, allow admin to turn on “support native dark mode” and set the default skins for light and dark, maybe add an admin toggle profile setting to let users pick which themes to use for light and dark, and boom done. User has their device on dark mode, they get the dark skin. Can override to have always dark skin in profile or normal theme toggle. Simple, quick, painless.

Love it!

Nothing is really “necessary”. Objectively though, it’s an option for users that many enjoy having, so I think saying it’s not desirable is simply false. All major browsers and OSes now support native dark mode. There’s a reason (hint: has to do with being desirable.) For me, I use it at night if I’m in the rocking chair with my infant. I have an iPhone X so anything that uses true black is very dark which is perfect. I read a lot of reddit (which supports dark natively) because it’s not too bright for the room.

I think rather than IPS doing a night theme, it would be better to add an admin option to designate a light theme and dark theme, and once that's completed, the front end displays a user option for "follow device dark mode setting". I think that approach is more than sufficient. I guess you'd also need to then have the core check for https://drafts.csswg.org/mediaqueries-5/#prefers-color-scheme and select the appropriate theme based on what the admin selects for each. That to me seems a better solution than IPS doing its own dark theme (maybe down the line you could, but what's missing from the suite is the ability to check for prefers-color-scheme and having it just work). Edit: Or I could just read the whole thread and see that @opentype who is much smarter than me already covered this. 🤦‍♂️

https://caniuse.com/#feat=prefers-color-scheme this is a great solution then since it follows the user device setting. I will also +1 for inclusion in the IPS core as a toggle option for users.

@stoo2000 not to pile on but also wanted to see if you might be open to adding Mailgun support? It has replaced Sparkpost for me given it has a free tier up to 10k emails a month. Thanks!

@Callum MacGregor Any chance you'd be willing to update this to add Mailgun API support and/or Amazon SES email support? @Mark Flagging you in case you guys had plans to add other e-mail delivery API's in an upcoming update so no duplication of work.

For what it’s worth, they have answered that question before too. They are simply taking a different path than xenforo, which has splintered support for PWAs/push. Invision wants to roll it out when it works and is stable for everyone, regardless of device/browser. Its probably not what you and others prefer (and since I’m not an android user I’m fairly ambivalent), but it’s their strategy and their call to do it that way. I trust they have the data and metrics we all have access to (and more) to have made that judgement call.

Yes? There are no notable PWA improvements in 13 or 13.1. You can literally test this yourself on an iOS13.1 device using the testing tool on the site I linked. Look, I know the point you are trying to make. @Matt can confirm how many times I’ve slid into his DMs trying to nudge him to be loud and obnoxious with Apple on behalf of Invision Community clients regarding the slow uptake of PWAs. I’ve been beating that drum here for a long time and I’ll be the first to be back on their case if and when Apple ever decides to join the rest of us in the modern age. Until that time, there’s no path to a viable one size fits all native app for individual communities. We’re having our lunch eaten by other social platforms that can gamify user behavior with frequent pushy native notifications. People complain they don’t like that, but it’s wildly popular, so seems like it works. I want my users to be able to get push notifications so they keep coming back and don’t forget about my site. This seems like literally the only solution that is viable and hits the minimum requirements for a native app. I think everyone would love a world where each of our communities got their own app and it was cost effective and easy to support. We don’t live in that world until PWAs are universally supported. So here we are. This solution will at least work for some people, overlaps with technology goals of future development in any event, and long term could be a springboard for other improvements. There’s no downside in my opinion because for me at least, a native mobile app even with all these compromises is still much more important than updates to blogs which as far as I’m aware is a pretty niche and minimally utilized part of the platform.

https://medium.com/dev-channel/progressive-web-app-progress-in-ios-12-2-beta-1-build-16e5181f-a18cd05ca361 theres a lot more missing in webkit’s PWA implementation than push notifications. There has basically been no progress on this list in a year. So I reject your claim that Apple is coming around on this. They have shown zero interest aside from some responses on Twitter that they are starting to look closer at it now.

I don’t think you are giving enough credit to how much of a game changer being able to maintain the app codebase in react native is vs. having to support separate android and iOS codebases using somewhat proprietary languages. I believe Invision has spoken of this before and my recollection is they are very upfront why their previous efforts failed - they are first and foremost a web application company, and not an app company, and they underestimated the work involved in maintaining those codebases and planning features under mobile app constraints. An enhanced API being developed to permit a react native app codebase is hugely beneficial to the platform as a whole. It’s going to open up all sorts of additional neat ways for developers to interface with the platform using modern web first tools. There’s ultimately also a fair bit of overlap with some of the foundational work that has to be done to expand PWA support, so this isn’t like they are focusing on one technology for the detriment of another.

As a strategy, it certainly would make sense too - there’s a lot of money to be made in taking what you’ve done with Invision cloud and commoditizing it to cannibalize communities from competing global platforms. I mean, tapatalk tried to give that a go with acquisitions like Yuku among others and they offer a turnkey community solution now, it’s just not very good. There’s room for that type of product to exist alongside providing the platform itself as sort of a white label community solution for others. Given I’d like to see Invision around for a long time, I’m fully aware that on the business and revenue side you may need to look at Invision itself becoming the community that serves up turnkey subcommunities while handling all the messy account and admin stuff. As long as there always remains some separation for those that need it between Invision as a Reddit/Facebook type of omnibus platform (if or when you make any moves that direction), and Invision the neutral decentralized community software provider, I think we’ll be in a good place.