Rikki

Also, you can still view the full (concatenated) CSS files in web inspector. Just click the filename: Then the format button:

Maybe y'all develop differently to me, but personally I wouldn't browse through a random CSS file to find classnames - there's no context (beyond the classname anyway; you don't get any of the cascade, inherited properties etc. that might affect it). It makes much more sense to use the web inspector to see what is actually being applied to the element you want to change. It may be a difficult transition at first but i would consider this an opportunity to improve your own development process.

Set it in custom.css and then you'll never have to worry about conflicts or updates again. That's literally how CSS works (the C stands for Cascading).

Has anyone really been far even as decided to use even go want to do look more like?

Thank you everyone, I'm sad to be leaving but very excited for what comes next. I'm sure you'll still see me around here, just without that Staff badge.

Thanks, I have moved this to a bug report - we'll get it fixed.

You don't have 'a' server when running in the cloud. Our cloud platform has hundreds of instances (which doesn't even necessarily equal the number of actual physical servers) and your site is running on all of them at once. Which one actually handles a user request is decided by a load balancer.

The underline is being added because by default we underline all links in content created within the editor, and so when you wrap the review box in a link, all text inside it becomes underlined. This is the expected behavior even though it doesn't look 'correct' in this specific instance. You could exclude the review widget by adding something like this to your custom.css file: .grw-net-widget, .grw-net-widget * { text-decoration: none !important; }

At some point we will be making the GraphQL API available for general-purpose use, and that would likely suit your usecase better. Keep an eye out for news of that in due course.

It isn't currently high on our priority list. It's called in a third-party library we use.

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.

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 🙂

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.

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.

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; }

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.

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.

Important note: Don't enable this setting for any untrusted groups (e.g. regular users).

You can do location based rules, so you could have one that awards a badge when a topic is posted in a certain forum, yes. You can't award certain badges based on member group though. Showing some recent badges is in the postbit is a good idea that we can consider. I'm wary of adding too much noise though, so it'd be a balance. The badge system we're discussing doesn't interact with member groups right now. We have spoken about tying the achievement and group promotion systems together in future, and that'd likely open up more possibilities along those lines.

Badges already support this - when you create the rule that awards the badge, you can enter a member-facing summary of the rule, e.g. "You posted 50 replies!".

What you're describing is closer to the Badges part of the system, where you earn a badge for doing a particular thing. We don't currently list all badges and what you have to do to get them (but may later), but when you earn a badge we do indicate in your profile what you did to earn it. Ranks however are based on points, and you earn points by doing all sorts of things in the community, with the rules defined by admins. You could earn enough points by creating one topic, or by replying to ten topics, or reacting fifty times - it could be any combination of actions, there's no one thing you have to do.

This will be back in the next build 🙂

@opentype Fixed the duplication when dragged (in 4.6, so won't show up here immediately) @DawPi Fixed

You can also email support@invisionpower.com 🙂

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.