Jump to content

Community

Rikki

Invision Community Team
  • Posts

    24,342
  • Joined

  • Days Won

    79

Rikki last won the day on April 20

Rikki had the most liked content!

About Rikki

  • Birthday 08/17/1983

IPS Marketplace

  • Resources Contributor
    Total file submissions: 3

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. This will be updated in the next release, but note that the security vulnerability would not impact us due to the way we use the library.
  2. You can already either allow guests to post, or use a simple 'post before registering' approach that allows people to post their message and then complete the signup process later. Typically allowing guests to post isn't a great idea, but the option is there should you want it.
  3. We have an outstanding bug open whereby child themes don't inherit new theme settings that are added to a parent, but aside from that, child themes should pretty much work as you describe, including custom CSS. When we build multi-brand themes in-house, we tend to add the 'master' brand styles to custom.css, then don't edit that in the child theme at all - let it inherit so that it's always up to date. If there are any styles used that we actually want to be branded, we use CSS variables for those. Then create separate CSS files in the child themes that have any styles specific to that brand, and also set our brand-specific CSS variable values. So something like /* custom.css in parent theme */ .someTitle { font-family: ...; font-size: 30px; color: var(--branded-title, #000); } /* sub.css in a child theme */ :root { --branded-title: #ff0000; }
  4. We only automatically convert colors primarily because they make the most sense as CSS variables. CSS variables also have to be valid CSS values, so we can't easily convert all theme settings into CSS variables. If you only use a theme setting in a couple of places, it probably won't be worth making it a CSS variable - just use the theme setting as before. You are correct that the font size plugin converts to px. If you need other units, simply use them directly, or make them a CSS variable - but you can't pass the CSS variable into the font size plugin like your example. Instead just use them directly; assuming the value of your theme setting was "3rem", you could do font-size: var(--theme-your_setting);. For your last example, remember the variable value has to be a valid CSS value. So the --theme-my_line_margin_top variable should include the % symbol - you can't concatenate it like you've done. Based on the examples you've described, I would just continue using your theme settings as before.
  5. If you're familiar with HTML enough that it would be useful to see the HTML the editor is generating, you can use web inspector tools in your browser to modify the HTML directly if you wish.
  6. Important note: Don't enable this setting for any untrusted groups (e.g. regular users).
  7. @opentype Fixed the duplication when dragged (in 4.6, so won't show up here immediately) @DawPi Fixed
  8. That will be an option in the upgrader. It will create a single rule where 1 post = 1 point, then keep your current rank names. For all intents and purposes it'd then work the same as the old system (plus the new stuff like notifications and user menu summary, which didn't exist before).
  9. You can also email support@invisionpower.com 🙂
  10. Yes, this isn't a bug per se. Jqmigrate is a tool that allows us to polyfill some APIs that changed in the latest jQuery releases, without having to make large changes to our own code immediately. Think of it as a compatibility layer. The logging you see simply indicates when Jqmigrate has needed to polyfill some behavior.
  11. In 4.6 the "Stop all email notifications" link will correctly stop any notification emails from being sent. In 4.5 there is a bug that allows digest-type emails to still go out when they shouldn't - but that isn't intended behavior.
  12. It will "just work" on self-hosted, but only for users who have supported browsers/devices. That's basically all of them except Safari/iOS. Apple has its own web push notification system for desktop Safari but we have decided not to support that right now, and of course iOS doesn't support web push at all. It's only tied to existing notification types for the time being, but a 'bulk' option sounds like a useful tool to me, so we might be open to that in future. You cannot make Push enabled by default because users must subscribe to them in an opt-in fashion. You can allow/disallow push for any notification type though. The banner that shows up explains the benefits of accepting, but you can of course adjust if you like. It's the same banner (with some updated copy) that shows in the 4.5 notification list for new users.
  13. As we approach the release of Invision Community 4.6, I wanted to take you through some improvements for using Invision Community on a mobile device. Web push notifications For some time, we've used the local browser notification API to show users notifications. There's a big drawback though: users had to have the site open in a tab for these to work. This is particularly problematic for mobile devices. In 4.6, we've added support for the WebPush API, which allows sites to push notifications to users' browsers & devices even if the site isn't open - or even if the device is asleep. We already have support baked in for push notifications via our beta mobile app, so we've piggy-backed on that system and expanded it to support browser-based push notifications. Choosing push notifications For users, it's a simple process. A little while after joining a community they will prompted to accept notifications from the site when they open the notification list dropdown (or they can opt-in any time from the notification settings screen). After accepting, they will be able to choose a "Notification List + Push" option for any of the available notification types. Push notifications enabled Existing users, who may have already granted permission to the site in the past, will be re-prompted to accept push notifications upon logging in after the 4.6 upgrade. Push notifications typically show on the homescreen of a phone or in the notification tray of a desktop computer, so receiving dozens of notifications could be overwhelming. For that reason, Invision Community will automatically merge related notifications - for example, multiple mentions from the same topic, or multiple new topics from the same forum. Grouped push notifications And, of course, users can stop push notifications across all of their devices with a single click if they want to opt out. We're excited about the engagement potential of push notifications, since they allow you to immediately reach users who aren't currently on your site - a job previously left to email alone. On the subject of notifications, one more thing: we've heard your feedback about notifications for new replies/mentions being merged with notifications for likes/quotes, and will be separating these two types into their own permissions in 4.6. We're acutely aware that making notifications annoying results in users turning them off, so we're always looking to ensure there is a reasonable balance. Splash Screen Images When you add a website to your phone's desktop, it appears like a native app. Tapping to launch the site can show a blank screen for a few seconds while the website is loaded. Fortunately, you can now set a 'splash' image in the Admin CP which is shown when launching the app. Sharing using native share options Another enhancement coming in 4.6 is the addition of the device share sheet when sharing content from within Invision Community. Users will now see a "More Sharing Options" button (providing their device/browser supports the underlying API) which, when tapped, will open the device share sheet. The options available depend on the device, but typically include actions like sharing links in WhatsApp, posting to Facebook or creating a note. Offline support With a larger share of users now using mobile devices for most of their browsing comes the problem of patchy phone signal and internet connections dropping out. For a dynamic web-based platform like Invision Community, it's difficult to offer much in the way of full offline support, but starting in 4.6 we will present a branded offline page to users when they have no internet connection and try to access the community. We hope that you are looking forward to these PWA improvements coming in Invision Community 4.6!
  14. jQuery is obviously not needed in 2021 - I'd love to do away with it. In reality, we have many thousands of lines of JS and the cost/benefit of rewriting everything for that reason alone isn't really there. Plus, we'd likely end up with a lot of helper methods that are essentially reimplementing some of jQuery's helper methods. We use some of the more advanced jQuery features too, so it wouldn't be as simple as updating .find to .querySelectorAll. So, the answer is: yes, I agree, but it isn't as simple as saying "let's do that". Also, in reality, if we were going to take the opportunity to redo our entire frontend codebase, we'd likely move to a reactive framework to build a better frontend, rather than simply rewriting what we have now but without jQuery. This will happen in time - we can't stay with the same code forever - but again it's about finding the right balance.
×
×
  • Create New...

Important Information

We use technologies, such as cookies, to customise content and advertising, to provide social media features and to analyse traffic to the site. We also share information about your use of our site with our trusted social media, advertising and analytics partners. See more about cookies and our Privacy Policy