Wolfie

This issue has been resolved in our recent 4.7.14 release of the platform. Please upgrade to resolve the issue, and if you see any further problems at that point, please let us know.

I mean the function to get the default Engine is already in Db.php.  If this will be getting removed with InnoDB becoming a requirement, then this suggestion is moot.
 
So does this mean that MyISAM will be losing support (such as in IPS5)?  Again, if so, meaning that InnoDB will be required/forced, then (IMO) it solves the issue anyways.  Would be my preference, to be honest.
 
Always a risk no matter what you do.  It's why backing up the database and files is always recommended before upgrading your community.  So backup your database and then follow @Randy Calvert's advice and do it via SSH if possible.
 
Agreed.  SSH/console is much MUCH faster and less likely to cause issues.  Any issues encountered are likely ones that would happen anyway.
1. Backup (export) database.
2. Run query to get list of tables using MyISAM, sorted largest to smallest (storage usage).
3. Update very large tables individually, then the rest of the tables in groups.
4. Done.
 

Correct.
Please ensure that your account has the moderator permission to manage the sidebar in ACP -> Members -> Staff -> Moderators. Just because you're an administrator does not mean you have permission to manage the sidebar.

It's always good to be safe!  😄 

If you're using the default skin that comes with the software, then I recommend seeing if any of the skin templates have been altered.  Also, check the various 3rd party apps you have installed (if any) to make sure that they are legit.  It's quite possible that something is happening internally (not guaranteed, but better to check and be sure).  If the skin is a 3rd party skin, ask the author if they'd be willing to examine the skin to see if it's been altered in any malicious way.
Assuming that everything is clean internally, it's time to look outside of the IPS suite.  Have you installed anything else on your domain that isn't party of the suite?  Subdomain, another URL for a different type of page, etc.?  If so, check the contents there to see if anything has been maliciously added.  If not, then you may need to contact your hosting company for assistance in figuring out how someone was able to install malicious code on your site.  There could be a security update they need to install or a setting that needs to be changed.
Before doing ANYTHING though, download a full backup of EVERYTHING!  (Full database and all the files for your website.)  This will serve two purposes.  One is in case something more goes wrong, you can restore and retry.  Second is that you could provide the files (and/or data) to someone you can trust to look through and see if they can find anything malicious.
Better safe than sorry!

Update your purchase in the Client Area so that Marc can see the situation for himself.  (See his requests for an example member.)
Also, what steps are they following that they encounter the issue?
 

Thank you for bringing this issue to our attention! I can confirm this should be further reviewed and I have logged an internal bug report for our development team to investigate and address as necessary, in a future maintenance release.
 

Are these still present so we can take a look?

Not to be a downer to this idea as I think it's a really good one, but I'm wondering how this would best be implemented.
1. When someone signs in?  If someone is already signed in, then they wouldn't get flagged.
2. While active on the site?  That could add a lot of CPU overhead to keep checking.
3. When the filter is added?  What if the filter is immediately deleted because it was entered incorrectly?  How would it go back and undo any accounts accidently flagged?
4. As a task?  That could take awhile depending on how many members the site has.  After all, it might be multiple new filters to compare existing accounts to.
Again, I like this idea.  I'd also like to be able to flag a user to change their email address via the ACP without needing a 3rd party app to do it.
 
 

Something like this?

Purchased = Items you paid for (or free but previously downloaded at some point).
Installed = Installed on the current community, apps, themes, etc., all in one spot.
 
I wouldn't mind a filter to see free vs paid, or be able to specify a max price of something, or limit to a particular submitter/author.

I hope this is an incomplete in-progress version, because it's lacking basic features that make it extremely inconvenient to use. The main issue is it's difficult to find and install plugins I've already purchased. Currently, I have to open Marketplace in the ACP, open a second browser window, go to the website Marketplace, look at my list of purchases, copy the name of the one I want to find, paste it into the ACP marketplace, then I can install.
I can't even search for plugins from memory most of the time. The Marketplace in the ACP seems to only be capable of searching for exact terms. For example, if my plugin has "Forums" in the title, it won't come up if I search for "Forum" instead. However, this wouldn't matter to me if I could easily access my purchased plugins in the first place.
I don't mind going to the website for the full-featured experience, but I shouldn't have to have to constantly go back and forth between two browser windows. If I'm going to be required to use the ACP to install the plugins I've purchased, it should make it much easier to find them.

I mean the function to get the default Engine is already in Db.php.  If this will be getting removed with InnoDB becoming a requirement, then this suggestion is moot.
 
So does this mean that MyISAM will be losing support (such as in IPS5)?  Again, if so, meaning that InnoDB will be required/forced, then (IMO) it solves the issue anyways.  Would be my preference, to be honest.
 
Always a risk no matter what you do.  It's why backing up the database and files is always recommended before upgrading your community.  So backup your database and then follow @Randy Calvert's advice and do it via SSH if possible.
 
Agreed.  SSH/console is much MUCH faster and less likely to cause issues.  Any issues encountered are likely ones that would happen anyway.
1. Backup (export) database.
2. Run query to get list of tables using MyISAM, sorted largest to smallest (storage usage).
3. Update very large tables individually, then the rest of the tables in groups.
4. Done.
 

Or just open the site in incognito mode (or anonymous/private/whatever your browser calls it).  Accept the cookies.  Click on a link to browse the site.  Click to accept the cookies again.  Click another link or just refresh.  Cookie bar appears again (at least for me).

That would indeed seem to be the case. Doesnt seem to be everyone though, which is odd. But then thats why the devs handle the devvy things

Or just open the site in incognito mode (or anonymous/private/whatever your browser calls it).  Accept the cookies.  Click on a link to browse the site.  Click to accept the cookies again.  Click another link or just refresh.  Cookie bar appears again (at least for me).

I imagine the fix for the typo will be to simply remove the deprecated section completely.  Sorry to anyone that it affects!

I imagine the fix for the typo will be to simply remove the deprecated section completely.  Sorry to anyone that it affects!

A legendary report. I can't wait for the next one 🤪

Part of this report is in humor, but is still pointing out actual findings. 😉

I prefer rotisserie chickens.
 
I imagine that if the server is running slow for whatever reason that it could be possible for it to happen, but it'd still be unlikely.  It's why I think the person in question is just being a troll with how they are crafting their display name.  The real question is, are they using the same email address?

Usernames are no longer a thing though, at least not in 4.7.  Your options for logging in include email address (recommended), display name, or both, at least for the built-in login method.  So when I said it is a display name and not a username, I wasn't wrong.  The four names shown are all display names, but I bet they're using a combination of lowercase L's and uppercase i's.  Notice there are only four registrations with what appear to be the same name.  That's two available letters being used twice each, so 2^2 = 4.  If they were being used 3 times each, it would be 2^3 (8) possible usernames using a combination of i's and L's.  (Imagine "softie ellla" as being the display name.)
Doing this is actually an old trick that has been used many times, and is actually a trick scammers will use in an attempt to trick people into believing that they are a well known legitimate entity.  I'm sure you can imagine some people would be disappointed to learn that it wasn't "LIONEL RICHIE" that sent them an email saying that they won tickets to see a concert of his, but rather "LIONEI RICHIE" (notice the uppercase "i" instead of an uppercase "L" in his name).
I'm pretty sure that even if someone managed to submit their registration multiple times really fast that only one would succeed.  Once one succeeds in adding the account to the database, the next attempt would find it already exists.  I'm not saying it's impossible, but it is very unlikely.  It's more likely the person did something deliberate by mixing i's and L's to make accounts with similar appearing display names.
 
 

See video for what this likely refers to - on a device where the "accept cookie" button has been clicked, the cookie bar still appears for a brief moment on page refreshes and then is hidden.
And here is how it can be reproduced:
Enable the cookie bar for guests Clear cookies and go to the site as a guest Cookie bar appears - accept cookies Login Refresh page - all is well. Clear cookies again and go to the site as a guest When the cookie bar appears, do not click either button Login to the site If/when the cookies bar appears, accept cookies Refresh the page - there's your cookie bar briefly. Tested on Firefox & Chrome on Windows 11.
 

Forums - YNWA.TV (Test site) — Mozilla Firefox 2023-06-19 11-26-28.mp4

I think they're referring to the cookie popup issue.

Seeing an error during the upgrade process can be frustrating enough.  But not knowing what part of the process the upgrade is at makes it even more so.  Therefore, when an error happens, the app and upgrade file in use when the error happened should be shown.  Not only provides more information to the administrator performing the upgrade, but it's more information that can be provided when they are seeking assistance.