SeNioR-

It works on a different principle. IP blocking only works with the registration form. The user can still browse the forum, e.g. by logging out of the account or opening it in incognito mode, but he will not be able to create a new account from this IP.
The IP block is useless, if someone has a changing IP, all you need to do is reset the router or the Internet connection itself and you can create an account again.

Ban by IP prevents any username from signing in.  To be honest, blocking by IP nowadays is almost useless. I can switch IP addresses with my ISP with the click of a button, or use a VPN, or switch to a mobile device and wander around, etc. 
The behavior of blocking only logged in accounts has been like this as long as I can remember. To be honest, if you want to block the entire IP… don’t try to use software. Either use the server (like htaccess or a server firewall like csf) or with a WAF (like cloudflare).

The \IPS\Helpers\Form\Date class does not account properly for a member's timezone when the min and/or max options are set.
 
This is the file's code on lines 303-314 in the validate() function:
if ( $this->value and $this->options['min'] !== NULL and $this->options['min'] > $this->value ) { $string = $this->options['min']->setTimeZone( $timezone )->localeDate( \IPS\Member::loggedIn() ); if( $this->options['time'] ) { $string .=' ' . $this->options['min']->setTimeZone( $timezone )->localeTime( \IPS\Member::loggedIn() ); } throw new \LengthException( \IPS\Member::loggedIn()->language()->addToStack('form_date_min', FALSE, array( 'sprintf' => array( $string ) ) ) ); } /* Check maximum */ if ( $this->value and $this->options['max'] !== NULL and $this->options['max'] < $this->value ) { $string = $this->options['max']->setTimeZone( $timezone )->localeDate( \IPS\Member::loggedIn() ); if( $this->options['time'] ) { $string .=' ' . $this->options['max']->setTimeZone( $timezone )->localeTime( \IPS\Member::loggedIn() ); } throw new \LengthException( \IPS\Member::loggedIn()->language()->addToStack('form_date_max', FALSE, array( 'sprintf' => array( $string ) ) ) ); }  
The code doesn't account at all for the timezone when checking the min/max values against the entered value:
$this->options['min'] > $this->value $this->options['max'] < $this->value The timezone is added only inside the IF check to display the error, but not before it for the check:
$string = $this->options['min']->setTimeZone( $timezone )->localeDate( \IPS\Member::loggedIn() ); $string = $this->options['max']->setTimeZone( $timezone )->localeDate( \IPS\Member::loggedIn() );  
This causes the check to fail for a user close to the UTC timezone, while it passes for a user with a more distant timezone.
 
Here is an example with 2 different timezones (Rome & New York):
DEBUG CODE: ================================================== print_r( $this->value ); print_r( $this->options['min'] ); print_r( $this->options['min']->setTimeZone( $timezone ) ); var_dump( $this->options['min'] > $this->value ); exit; ================================================== OUTPUT FOR ROME TIMEZONE: ================================================== IPS\DateTime Object ( [date] => 2024-03-02 00:01:00.000000 [timezone_type] => 3 [timezone] => Europe/Rome ) IPS\DateTime Object ( [date] => 2024-03-02 00:58:41.440303 [timezone_type] => 3 [timezone] => UTC ) IPS\DateTime Object ( [date] => 2024-03-02 01:58:41.440303 [timezone_type] => 3 [timezone] => Europe/Rome ) bool(true) ================================================== OUTPUT FOR NEW YORK TIMEZONE: ================================================== IPS\DateTime Object ( [date] => 2024-03-02 02:41:00.000000 [timezone_type] => 3 [timezone] => America/New_York ) IPS\DateTime Object ( [date] => 2024-03-02 00:52:00.648474 [timezone_type] => 3 [timezone] => UTC ) IPS\DateTime Object ( [date] => 2024-03-01 19:52:00.648474 [timezone_type] => 3 [timezone] => America/New_York ) bool(false)  
As you can see from the debug output above, the member with a Rome timezone fails to pass the check (TRUE triggers the error), while the New York timezone passes the check (FALSE doesn't trigger the error).
 
The timezone must be added to the min/max checks before the check is done, and not after to display only the error.

Unfortunately, I am not seeing anything particular with this account which would allow them to login anonymously. Creating an account myself, I am also unable to hide my online status. The administrator group is able to do so but that is because you allow it. Please let us know if you see this again. I am wondering if the account was only partially created at the time you viewed this, so we logged it as anonymous. 

We have a few more things to announce, but we're just finalising our internal reviews. I want to do a status update on v5 early next week and outline the next steps.

Finally, one of the most requested features for clubs in Invision Community is coming with our March 2024 release: Pages databases in Clubs.
You may be surprised to see a new feature being introduced for Invision Community 4 during our flow of news for Invision Community 5, but as we're committed to Invision Community 4, we wanted to continue to bring optimizations and improvements to the platform.
What is the benefit of this new feature?
Clubs enable communities to host multiple micro-communities with many benefits. Clubs allow more specialized and focused discussions on specific topics. This can lead to higher-quality content and a deeper exploration of niche subjects that may get overlooked when posted on a busy forum. Clubs also offer the ability to tailor the community experience based on the needs of that community. That customization is what this feature focuses on.
Pages is a powerful application that allows truly custom layouts for content areas. Simply by adjusting templates, you can create a news feed layout (it is what we use for this news blog area!) or something even more customized to your needs.
The March 2024 release allows you to create Pages database categories directly inside clubs, including custom fields and templates.
How does it work?
Setting up your Pages database to allow clubs to use categories is simple. Simply allow categories to be created within clubs when creating or editing a database.

Once that is done, club owners can add a Pages database category to their club in the same way they can add topics, galleries, etc.

Once the Pages database category has been added, you can then add content as you would any other club area with the added features of Pages, including custom templates and custom fields.
This example club uses a custom Pages database listing template to show the articles in a custom format along with custom field data.

Likewise, viewing an article in this example club showcases the use of custom templates to present the content differently from the standard topic templates Invision Community uses elsewhere.

Allowing Pages database categories inside clubs brings the opportunity for more complex custom areas making use of multiple custom fields along with truly custom layouts using templates. This is a great way to bring additional areas, such as news articles, into your club areas to compliment discussions.
We hope you enjoy this feature, and if you have any comments, please leave them below!

View full blog entry

Just a shout out to Team Invision:
We upgraded a site running 4.2.4 (how old is that?) today to the current version of 4.7.15 and it went really smooth.  The site has about 20,000 members (not sure how many topics), but the upgrade didn't take long at all. 😍
We have two big sites running 4.3.6, which we're going to upgrade this week too!

I have a pet peeve, images uploaded to our gallery display their file name as the title. For example a member uploads their image and doesn't change the title image, so it then displays something like DSC2849.jpg instead of for example "Oak Cabinet".
I have rules displayed for image uploading in each gallery, but they are apparently ignored. Is there any way to auto enforce changing the title of an image uploaded to our galleries? Our community is gallery and image heavy, visual arts. It drives me crazy that folks are lazy and just use their default image file title. Any suggestions are greatly appreciated.

If you are unsure how to generate a full backup of your database and files via your server. Please contact your hosting provider for assistance. 

Cannot translate this one 😉 

We are working on having this fixed for the next release. We expect a beta fairly soon and would appreciate a lot of testing as the old plugin touched on a lot of areas.

Ah, I see. That looks like a bug that was introduced when we switched the domain to use youtube-nocookie.com. We'll get that fixed.

It may be worth both of you checking that you have lazy loading enabled - AdminCP > System > Settings > Posting.
Embeds, images, videos, audio are lazy-loaded via a Javascript method if lazy loading is enabled, the native options didn't exist when this was implemented but we have moved to a native solution in v5.

Creating a form you can do with the pages application, and you could simply follow the database to get an email. However the custom logc and excel side of things would require custom development to achieve. 

https://www.google.com/search?q=emojis+in+urls+seo
Google is featuring this result on the top of 1st page for a reason with highlighted text -
Avoid using emojis in URLs as it is generally not recommended and creates indexing problems and SEO issues. Search engines depend on the information containing text to index web pages and those text that has emojis are considered non-standard characters.
URL address - however, it’s not the best place. The website address should be clear and user-friendly. It’s also important to mention that the search engine doesn’t have an obligation to show the emoji and may not be rendered or in color on some O/S's. If it doesn’t display it, you’ll simply see a chain of characters instead which won’t look attractive.

Punycode
Google

Bing (it only shows the first emoji but the unknown character box for the other two)

https://www.google.com/search?q="emojis+in+urls+for+seo"
Most search engines will show no results when using emoticons. So make sure you only use emoji in your page title and meta description, and not emoticons. Finally, Google only shows emoji in its organic search results and not in its Text and Shopping Ads. So don't try to put emoji in your ads.
https://www.searchenginejournal.com/google-says-emojis-wont-hurt-or-help-seo/436079/
About emojis in titles/meta - there’s no guarantee Google will show them in search results. Google rewrites a majority of titles as it is, but even if it chooses to display the title you’ve written it may disregard the emojis. you’re probably better off writing titles and descriptions in plain text. Emojis are allowed, but it’s highly unlikely Google will display them. There’s no SEO advantage to using them, either
 
Avoid Using Emojis or Special Characters
https://susodigital.com/blog/optimising-url-slugs-for-seo
Google’s official guidelines are clear about this: you should not use non-ASCII characters in your URL, if you want it to be as well-optimised as possible. 
This includes emojis, as well as characters from all languages that do not use the Latin alphabet, even if your page is written in one of them.
For search engines, this is mainly important before your page is indexed, but when it comes to user-friendliness, using emojis and special characters in your URL slug can pose more serious issues to your viewers.
In many instances, non-ASCII characters will not display correctly on people’s screens, making it impossible to copy-paste, or type out your link. 
✅ User-friendly URL: www.susodigital.com/blog/what-is-a-url-slug 
❌ User-hostile URL: www.susodigital.com/blog/URL-蛞蝓-是-什么 
 
Similar issues
Xenforo - https://xenforo.com/community/threads/remove-emoji-from-url.159250/
Discourse - https://meta.discourse.org/t/thinking-dont-put-emoji-name-in-topic-slugs/76595/26
 
https://mangools.com/blog/seo-emojis/
What google does or not with emojis has changed over years many times, there is still no guarantee google would include them in ranking and there are instances where google truncated important keywords due to emojis thereby reducing the page ranks.
If the title contains just emojis and users want to search by Title only, not many users are tech savvy to grab emojis from the internet to paste into the search field. Title should always contain some word(s) for searchability (even if it contains emojis).
URLs should work by just the ID without needing to input the optional title text in the slug so if there are any emojis in the URL, it won't be difficult to query by just ID (if users know the topic/article ID). Also there should be an option to search by topic ID, article ID, etc:
https://invisioncommunity.com/forums/topic/470924
When "emojis" exist in the url and we click in the address bar, the cursor is not visible while using left/right arrow keys which is a bad UX.
The aspect of including emojis in the URLs or not can be implemented as a configurable switch in the ACP with a default value of ON so it works as it does now (if at all emojis are excluded from URLs, it should be implemented as a switch in ACP). Those who want to continue including emojis in the urls don't have to do any config due to its default value.

PHP 8.2 will be fully supported in Invision Community 5.
Whilst it may work with earlier versions such as 4.7, it isn't officially supported (there may be issues) and will likely mean that developers mode is unusable..

Hi. seoTitle function currently does not remove Emoji from URLs. Link with emoji becomes unfriendly. Consider adding a new preg_replace
$value = preg_replace('/[^ -\x{2122}]\s+|\s*[^ -\x{2122}]/u','',$value);  
The copied and pasted URL looks like this: 
https://invisioncommunity.com/forums/topic/470924-emoji-in-seotitle-unfriendly-url-%F0%9F%94%A5%F0%9F%98%85%F0%9F%98%B2%F0%9F%92%9B%F0%9F%A4%A9%F0%9F%A4%AE%F0%9F%98%8A/  

I meant "cloud hosting".
 
phew...

"Not to mention, there is a significant update to Pages underway."
Oh God no, our applications are closely ingrained with pages xD might be time to move our databases to azure/AWS O.o
 
One thing one of our admins can't seem to let go of: Version 5 will be available to all cloud customers correct? Including the ones still on a legacy plan?

This wouldn't make sense and would probably be unhelpful in search as those posts attributed to a default single author would actually have been written by multiple people. 
I think having no author details is the best thing to do with it.

You can find the recommended CHMOD settings inside the init.php file:
// File permissions // For example: when making folders for files to be uploaded to, what permissions // that should be created with 'IPS_FOLDER_PERMISSION' => 0777, // Writeable folders 'FOLDER_PERMISSION_NO_WRITE' => 0755, // Non-writeable folders 'IPS_FILE_PERMISSION' => 0666, // Writeable files 'FILE_PERMISSION_NO_WRITE' => 0644, // Non-writeable files Those are the default values IPS suggests (and uses), but depending on your server's configuration, you might need to adjust them. That part is best discussed with your hosting, though.
 
As for writable folders, the default ones usually are applications, datastore, plugins, and uploads.
Anyway, you'll get an error during upgrades if something that needs to be writable isn't. Unless you're having issues with your site (for example, files not uploading, etc), I wouldn't change anything.

Guests aren't "logged in" so you can't log them out. If you don't want them around, the only option is to ban their IP (range?) at the server level.
However, as you mentioned, it's possible those "guests" are actually bots crawling your site to index it. Unless you have some reason to be wary of those guests, I'd just ignore them.

Not a bug, just a suggestion to have a default “guest” author in the mark up.

I created a new type of Commerce package for a client, and when trying to clone it an error is thrown.
Here's the stacktrace:
Error thrown with message "Access to undeclared static property IPS\premium\Package\Premium::$packageDatabaseColumns" Stacktrace: #6 Error in \applications\nexus\sources\Package\Package.php:264 #5 IPS\nexus\_Package:__clone in \system\Node\Controller.php:915 #4 IPS\Node\_Controller:copy in \system\Dispatcher\Controller.php:107 #3 IPS\Dispatcher\_Controller:execute in \system\Node\Controller.php:69 #2 IPS\Node\_Controller:execute in \applications\nexus\modules\admin\store\packages.php:46 #1 IPS\nexus\modules\admin\store\_packages:execute in \system\Dispatcher\Dispatcher.php:153 #0 IPS\_Dispatcher:run in \init.php:934  
The issue is caused by the __clone() method in applications/nexus/sources/Package/Package.php which is missing the isset() check:
foreach ( $this->_data as $k => $v ) { if ( !\in_array( $k, array( 'id', 'reviews', 'unapproved_reviews', 'hidden_reviews' ) ) ) { if ( \in_array( "p_{$k}", static::$packageDatabaseColumns ) ) { $secondaryTable[ "p_{$k}" ] = $v; } else { $primaryTable[ "p_{$k}" ] = $v; } } } Every other method properly checks if the variable is set before using it, but the __clone() method doesn't.
 
Here's an example from the save() method where the isset() check is properly implemented:
foreach ( $this->changed as $k => $v ) { if ( isset( static::$packageDatabaseColumns ) and \in_array( "p_{$k}", static::$packageDatabaseColumns ) ) { $secondaryTable[ "p_{$k}" ] = $v; unset( $this->changed[ $k ] ); } elseif ( !\in_array( "p_{$k}", array( [...] ) ) ) { unset( $this->changed[ $k ] ); } }

If you delete a member and leave their content attributed to "guest", google webmaster tools for these urls will show you:

 
Not a big issue but maybe add a default user page for guest posts? Maybe a guest user profile/url, sort of "catch all". Just an idea.