Colonel_mortis

With 4.5 we got those nice and shiny badges:

However there is not much we can do with these. No way to edit the icon (I know it can be done manually, I am talking about AdminCP options...), to way to change the inverval for how long a "recently joined" member is getting a badge, no option to display badges based on usergroups (not just if someone has moderator permissions) etc.
Also the "hand icon" for recently joined members has received quite some negative feedback. It is misinterpreted for restrictions being in place instead of a waving hand (what I suppose it should be taken for).
Suggestions:
Please add a usergroup-based options: Display profile badge YES|NO (If YES, then 2nd option:) Edit profile badge: Background color (color picker) Icon Remove badge from moderator permissions (not needed anymore with the above option based on usergroups) For recently joined members, please add an option to choose for how many days the joined-recently-badge will be displayed.

I've raised your suggestion internally for further consideration.

I noticed that in a few places you're hacking around support for lower case (http2) headers, and there are a bunch of places where you don't handle them correctly. Is there a reason that you're not lowercasing all headers when storing the headers (and also storing the originals for back compat)? eg there are a bunch of places where you test for $response->httpHeaders['Location'] || $response->httpHeaders['location'], but if you standardise them then you can just test one. You already standardise location, but you may as well do it for everything then deprecate the upper case ones.

4.5 contains a bunch of improvements in this area to make plugins more portable. They can be installed IN_DEV and the majority of their data is now stored within the /dev directory in various PHP/JSON/PHTML files.
We haven't made any changes to the naming conventions required, or the hook class names, but we've also come up with these changes for the same reasons, to greatly improve the ability to develop plugins across installs via Git.
Please consider taking a look at the beta and letting us know whether those improvements are beneficial to your development process.

If a user posts a poll and sets it not to display the names of the people who voted for each option, members don't get warned that their vote will be public and they may wish to share their opinion anonymously. However, the author of the poll can just edit the poll to set it to public, and see the names and choices of everyone who has already voted. This defeats the point of having private polls.
Either it shouldn't be possible to change a poll from private to public, or votes from when it was private should be anonymised.

If a user posts a poll and sets it not to display the names of the people who voted for each option, members don't get warned that their vote will be public and they may wish to share their opinion anonymously. However, the author of the poll can just edit the poll to set it to public, and see the names and choices of everyone who has already voted. This defeats the point of having private polls.
Either it shouldn't be possible to change a poll from private to public, or votes from when it was private should be anonymised.

If a user posts a poll and sets it not to display the names of the people who voted for each option, members don't get warned that their vote will be public and they may wish to share their opinion anonymously. However, the author of the poll can just edit the poll to set it to public, and see the names and choices of everyone who has already voted. This defeats the point of having private polls.
Either it shouldn't be possible to change a poll from private to public, or votes from when it was private should be anonymised.

It would actually be super easy to implement - they just need to remove the check for author != loggedIn()->member_id in checkForNewReplies (just removing part of a single line). The only other consequence of doing this is that you'll get "1 new reply" toasts for your own replies if you have it open in multiple tabs/browsers, but I think that isn't a bad thing.

It would be great if there was a user option to only receive email notifications when they're offline, or to get a summary email of the notifications that they've missed if they don't visit the site for some period of time (as Stack Overflow does).
There's no point getting email notifications when you're actively browsing the site, but equally if you're only an infrequent visitor you don't want to miss any replies to things that you're interested in or that you posted, and something like this would strike that balance (while also helping to boost retention in a user-friendly way).

It would be great if there was a user option to only receive email notifications when they're offline, or to get a summary email of the notifications that they've missed if they don't visit the site for some period of time (as Stack Overflow does).
There's no point getting email notifications when you're actively browsing the site, but equally if you're only an infrequent visitor you don't want to miss any replies to things that you're interested in or that you posted, and something like this would strike that balance (while also helping to boost retention in a user-friendly way).

I don't disagree, and I think it makes sense. However, I would dispute your claim that it requires a new dns lookup, tcp connection and tls setup - it is fetching from the same server as the main content so if your server is correctly configured with keep-alive it will reuse the existing connection, resulting in 0ms overhead. Even if you have keep-alive disabled (as ips did for a while, although they may have changed that now), the dns lookup will always have been cached and if you are running an up to date version of openssl and nginx/apache you can get 0- or 1-rtt tls session resumption, so there should only be 1-2 round trips of overhead.
Resending the cookies is still a reasonable concern, but the others are not.

I don't disagree, and I think it makes sense. However, I would dispute your claim that it requires a new dns lookup, tcp connection and tls setup - it is fetching from the same server as the main content so if your server is correctly configured with keep-alive it will reuse the existing connection, resulting in 0ms overhead. Even if you have keep-alive disabled (as ips did for a while, although they may have changed that now), the dns lookup will always have been cached and if you are running an up to date version of openssl and nginx/apache you can get 0- or 1-rtt tls session resumption, so there should only be 1-2 round trips of overhead.
Resending the cookies is still a reasonable concern, but the others are not.

Agreed, especially as complying with user requests to delete accounts is required for compliance with the GDPR.

Agreed, especially as complying with user requests to delete accounts is required for compliance with the GDPR.