Runar

Quickest and common aren't always most secure or best case for every implemention, and I think it's great to spawn a discussion on this!
As we maintain code repositories for our IPS instance, an important consideration is that we don't include those secrets in committed code and maintain separate values for each instance. Our production values are intentionally different from test. This adds an additional layer of assurance that we won't inadvertently hit the wrong database, even though we isolate the environments on separate networks as well. Security is all about layering and compensating controls.
Your secrets are only as good as your weakest link. If somebody else can access your filesystem in a shared hosting environment, or can write code to output the values of variables set within the IPS session, then your efforts are likely giving you a false sense of security.
You can do things like encrypt credentials with a library and decrypt them in constants.php, or use a proxy for MySQL where the credentials are stored at the proxy level. Referring to values in a file that lives out of your web root is another option, and as you pointed out, passing them through the web server. Lots of options. Just remember to consider that with the most secure of deadbolts, if you leave it unlocked, or the back door open or a ladder propped up against the side of the house, you're only as secure as your weakest link.

There are many ways to handle/store secrets (such as database username and password) when developing websites. Some use environment variables, while others write the secrets directly in the code. Currently I use fastcgi_param in an nginx configuration file to make them available to PHP, but the downside of this is that the variables and their content is displayed together with all other environment variables, for example when using phpinfo().
So, how do you solve this? Do most people just store them in conf_global.php?

A plugin is nice and all, but it requires maintenance on both ends. Support for this being integrated into the IPS platform is more ideal.

That's true, but it's disabled by default in version 57 and above, and must be manually enabled.
This is also true, so it's not really a problem that it's not supported in all browsers.
All I wanted to say was that this (preload) is not a quickfix to remove render blocking CSS from every visitor. I have added your example to my own site and it works perfectly!

I’m not sure if you can call it a side effect or bad impact, but preload is not supported by neither IE nor Firefox: https://caniuse.com/#feat=link-rel-preload
Though, the website will still work in IE or Firefox!

Hey again, so I did have a chance to test it and I have to apologize as I think the problem was on my end and I think you're all good! 
I think there may have been some formatting in my Notes App that I was using to copy and paste to/from.
The bottom line is that your plugin has no problem embedding pasted links, whether they are plain text or rich text, so long as there is no additional formatting within the URL (like the URL is bolded or some such). This is the same functionality level as the built-in embedding, such as Youtube links.
Thanks for jumping on this, even though it turns out it was all my bad!

This plugin makes it easy and fast to add a marker (badge) to a topic, by placing a button next to the «Reply to this topic»-button. The marker visually stands out, both when viewing the topic and when viewing the forums.
It's similar to using tags, but with tags you and your members will have to edit the topic and manually add the tag. Also, unless I’m mistaken, there is no way to restrict a tag to specific forums or members. This plugin is kind of a combination of tags, prefixes, and saved actions (multimoderation), and you can allow everyone to use the markers, not only admins and moderators.
Here are a few pictures showing the visual differences between markers, tags, and prefixes.
When viewing the forum:

When viewing the topics:



Let me know if you have any other questions!

Hm. This is not currently a feature, but I'll see what I can do.

That's true, but it's disabled by default in version 57 and above, and must be manually enabled.
This is also true, so it's not really a problem that it's not supported in all browsers.
All I wanted to say was that this (preload) is not a quickfix to remove render blocking CSS from every visitor. I have added your example to my own site and it works perfectly!

so I take it this issue isn't addressed at all in the upcoming 4.2?

In my community we’ve got one forum for items for sale, and one for items our members are looking to buy. I would love to have different badges and prefixes in these different forums (SOLD in the first and BOUGHT in the latter). Would this be possible in a future update?

In my community we’ve got one forum for items for sale, and one for items our members are looking to buy. I would love to have different badges and prefixes in these different forums (SOLD in the first and BOUGHT in the latter). Would this be possible in a future update?

In my community we’ve got one forum for items for sale, and one for items our members are looking to buy. I would love to have different badges and prefixes in these different forums (SOLD in the first and BOUGHT in the latter). Would this be possible in a future update?