opentype

You would create a database with one category only and don’t set it to “article mode”. Then you can set certain fields (like the selectbox field) as a filter and drag a filter widget on the page. 
The “articles” will only be shown in a list mode by default. You probably will not like that. 
Alternative solution: Don’t use filters and create a category for “PC“, “Nintento”, “Xbox”. Then you can have the “article mode” front page looking like a blog and users would open the categories to see the articles belonging to these topics. 

Suggestion - If you have a lot of blocks you have created over the years, it would be cool to see in ACP if they are being used or not (can they be deleted). I am at fault for having too many unused blocks...🤪

You can turn off “Post before Registering”. Type “post before register” in the ACP search to find it. 

Afterwards, guests need to register first before submitting a post. 

Try Recovery Mode
 

That’s what the “closed tag system” is for. You set up all the tags you want as admin in the ACP and then users can only use those tags. 

I will add this on my notes when doing internal testing on stuff 🙂 

While you are working on Pages …
If the Media section remains as it is, it seems to have performance issues. I have one installation where WordPress content got imported, ending up with around 300 images in the media section. 
Opening the media page takes forever and can even crash the browser. It tries to load all 300 hi-res images at once. I also can’t get around that and do something else like creating a new folder, because that doesn’t stop loading the images. 
Other queries seem problematic too, like just opening a folder in that section. Even if it is empty it can take 45 seconds to open on that installation with 300 images in other folders. That shouldn’t be the case. 

You would create a database with one category only and don’t set it to “article mode”. Then you can set certain fields (like the selectbox field) as a filter and drag a filter widget on the page. 
The “articles” will only be shown in a list mode by default. You probably will not like that. 
Alternative solution: Don’t use filters and create a category for “PC“, “Nintento”, “Xbox”. Then you can have the “article mode” front page looking like a blog and users would open the categories to see the articles belonging to these topics. 

You would create a database with one category only and don’t set it to “article mode”. Then you can set certain fields (like the selectbox field) as a filter and drag a filter widget on the page. 
The “articles” will only be shown in a list mode by default. You probably will not like that. 
Alternative solution: Don’t use filters and create a category for “PC“, “Nintento”, “Xbox”. Then you can have the “article mode” front page looking like a blog and users would open the categories to see the articles belonging to these topics. 

You would create a database with one category only and don’t set it to “article mode”. Then you can set certain fields (like the selectbox field) as a filter and drag a filter widget on the page. 
The “articles” will only be shown in a list mode by default. You probably will not like that. 
Alternative solution: Don’t use filters and create a category for “PC“, “Nintento”, “Xbox”. Then you can have the “article mode” front page looking like a blog and users would open the categories to see the articles belonging to these topics. 

I wouldn’t even know what the goal would be. If the database is live, the only thing left to test with independently is IPS files, which shouldn’t be touched anyway. 

Even if you were able to optimize the data in one way or another, you are only pushing the problem away some months into the future, when the space is used up again. A 2GB limit is just too small for a successful Invision Community installation. 

Even if you were able to optimize the data in one way or another, you are only pushing the problem away some months into the future, when the space is used up again. A 2GB limit is just too small for a successful Invision Community installation. 

It says “See the JavaScript console for technical details”. That’s where you need to look. 

Even if you were able to optimize the data in one way or another, you are only pushing the problem away some months into the future, when the space is used up again. A 2GB limit is just too small for a successful Invision Community installation. 

Even if you were able to optimize the data in one way or another, you are only pushing the problem away some months into the future, when the space is used up again. A 2GB limit is just too small for a successful Invision Community installation. 

Even if you were able to optimize the data in one way or another, you are only pushing the problem away some months into the future, when the space is used up again. A 2GB limit is just too small for a successful Invision Community installation. 

I would rather say calling it a “hosting issue” is the unfair assessment, when having such limits is essentially a default in the entire hosting industry.
https://kb.mailpoet.com/article/150-lists-of-hosts-and-their-email-sending-limits
And even if I would go through the trouble of moving everything to a paid service like for example Amazon SES (just to get bulk mails out without issues despite having a perfect email delivery otherwise), I then have their sending limits per day. The issue remains, just with different limits. 
It’s not some edge-case issue on a cheap shared hosting environment that we are asking to “work around”. It’s just a reasonable way to deal with email delivery in standard hosting environments. And in contrast, it feels rather unreasonable, that I can have a perfectly working local SMTP delivery; in my full technical and legal control; highly optimized delivery through DNS settings; no privacy issues because no 3rd-party services are needed; working perfectly fine for all transactional mails; all at no extra costs … and then potentially have bulk-mails fail in an unpredictable manner because the background tasks may or may not take the right amount of time. 

I would rather say calling it a “hosting issue” is the unfair assessment, when having such limits is essentially a default in the entire hosting industry.
https://kb.mailpoet.com/article/150-lists-of-hosts-and-their-email-sending-limits
And even if I would go through the trouble of moving everything to a paid service like for example Amazon SES (just to get bulk mails out without issues despite having a perfect email delivery otherwise), I then have their sending limits per day. The issue remains, just with different limits. 
It’s not some edge-case issue on a cheap shared hosting environment that we are asking to “work around”. It’s just a reasonable way to deal with email delivery in standard hosting environments. And in contrast, it feels rather unreasonable, that I can have a perfectly working local SMTP delivery; in my full technical and legal control; highly optimized delivery through DNS settings; no privacy issues because no 3rd-party services are needed; working perfectly fine for all transactional mails; all at no extra costs … and then potentially have bulk-mails fail in an unpredictable manner because the background tasks may or may not take the right amount of time. 

I would rather say calling it a “hosting issue” is the unfair assessment, when having such limits is essentially a default in the entire hosting industry.
https://kb.mailpoet.com/article/150-lists-of-hosts-and-their-email-sending-limits
And even if I would go through the trouble of moving everything to a paid service like for example Amazon SES (just to get bulk mails out without issues despite having a perfect email delivery otherwise), I then have their sending limits per day. The issue remains, just with different limits. 
It’s not some edge-case issue on a cheap shared hosting environment that we are asking to “work around”. It’s just a reasonable way to deal with email delivery in standard hosting environments. And in contrast, it feels rather unreasonable, that I can have a perfectly working local SMTP delivery; in my full technical and legal control; highly optimized delivery through DNS settings; no privacy issues because no 3rd-party services are needed; working perfectly fine for all transactional mails; all at no extra costs … and then potentially have bulk-mails fail in an unpredictable manner because the background tasks may or may not take the right amount of time. 

I would rather say calling it a “hosting issue” is the unfair assessment, when having such limits is essentially a default in the entire hosting industry.
https://kb.mailpoet.com/article/150-lists-of-hosts-and-their-email-sending-limits
And even if I would go through the trouble of moving everything to a paid service like for example Amazon SES (just to get bulk mails out without issues despite having a perfect email delivery otherwise), I then have their sending limits per day. The issue remains, just with different limits. 
It’s not some edge-case issue on a cheap shared hosting environment that we are asking to “work around”. It’s just a reasonable way to deal with email delivery in standard hosting environments. And in contrast, it feels rather unreasonable, that I can have a perfectly working local SMTP delivery; in my full technical and legal control; highly optimized delivery through DNS settings; no privacy issues because no 3rd-party services are needed; working perfectly fine for all transactional mails; all at no extra costs … and then potentially have bulk-mails fail in an unpredictable manner because the background tasks may or may not take the right amount of time. 

There is already the BULK_MAILS_PER_CYCLE constant to solve issues with hosts that have trouble with many emails at once. 
Equally, if not more important, is how many emails are sent in a given timeframe. It’s normal for hosts and email services to have some kind of limit in that regard, but with the way IPS sends out bulk mail, it unpredictable when these limits are being hit and there is no way around this problem when the limits are hit. 
I suggest a solution like a MAX_MAIL_CYCLES_PER_TASK constant or setting to limit the amount of cycles run each time a cron is being fired. So, for example, I could set 1 run of 100 emails with the cron running every minute resulting in 1000 mails in 10 minutes. 
I understand that IPS isn’t all that focussed on features that would only help self-hosted customers, but it seems like an easy implementation which could help a lot of users. It’s actually the behaviour that people are already expecting. 

There is already the BULK_MAILS_PER_CYCLE constant to solve issues with hosts that have trouble with many emails at once. 
Equally, if not more important, is how many emails are sent in a given timeframe. It’s normal for hosts and email services to have some kind of limit in that regard, but with the way IPS sends out bulk mail, it unpredictable when these limits are being hit and there is no way around this problem when the limits are hit. 
I suggest a solution like a MAX_MAIL_CYCLES_PER_TASK constant or setting to limit the amount of cycles run each time a cron is being fired. So, for example, I could set 1 run of 100 emails with the cron running every minute resulting in 1000 mails in 10 minutes. 
I understand that IPS isn’t all that focussed on features that would only help self-hosted customers, but it seems like an easy implementation which could help a lot of users. It’s actually the behaviour that people are already expecting. 

There is already the BULK_MAILS_PER_CYCLE constant to solve issues with hosts that have trouble with many emails at once. 
Equally, if not more important, is how many emails are sent in a given timeframe. It’s normal for hosts and email services to have some kind of limit in that regard, but with the way IPS sends out bulk mail, it unpredictable when these limits are being hit and there is no way around this problem when the limits are hit. 
I suggest a solution like a MAX_MAIL_CYCLES_PER_TASK constant or setting to limit the amount of cycles run each time a cron is being fired. So, for example, I could set 1 run of 100 emails with the cron running every minute resulting in 1000 mails in 10 minutes. 
I understand that IPS isn’t all that focussed on features that would only help self-hosted customers, but it seems like an easy implementation which could help a lot of users. It’s actually the behaviour that people are already expecting. 

There is already the BULK_MAILS_PER_CYCLE constant to solve issues with hosts that have trouble with many emails at once. 
Equally, if not more important, is how many emails are sent in a given timeframe. It’s normal for hosts and email services to have some kind of limit in that regard, but with the way IPS sends out bulk mail, it unpredictable when these limits are being hit and there is no way around this problem when the limits are hit. 
I suggest a solution like a MAX_MAIL_CYCLES_PER_TASK constant or setting to limit the amount of cycles run each time a cron is being fired. So, for example, I could set 1 run of 100 emails with the cron running every minute resulting in 1000 mails in 10 minutes. 
I understand that IPS isn’t all that focussed on features that would only help self-hosted customers, but it seems like an easy implementation which could help a lot of users. It’s actually the behaviour that people are already expecting.