Jump to content

Rikki

Invision Community Team
  • Posts

    24,346
  • Joined

  • Days Won

    81

Rikki last won the day on August 5

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. Yep - and that's where we (or at the very least, I) see the future of Pages - but those apps also have huge open-source communities or a large development team focusing only on that product. It's not something we can click our fingers and bring to life, but it is in our minds. Speaking personally, I have a pretty clear picture of what Pages could be and what would set it apart from the other visual page builders out there, but for the time being that'll stay internal until a definite roadmap is planned out.
  2. All of this is on our radar - it's obviously not trivial though. Trust me, I probably use Pages more than anyone else, so I'm certainly aware of the pain points and potential future for it 🙂
  3. 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.
  4. 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.
  5. 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; }
  6. 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.
  7. 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.
  8. Important note: Don't enable this setting for any untrusted groups (e.g. regular users).
  9. @opentype Fixed the duplication when dragged (in 4.6, so won't show up here immediately) @DawPi Fixed
  10. 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).
  11. You can also email support@invisionpower.com 🙂
  12. 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.
  13. 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.
  14. 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.
×
×
  • Create New...