SeNioR-

Same thing happens for me in ACP when editing templates etc.
The codemirror.js is missing semicolons in few places, had to patch it up to edit my theme.

Trying to use the Code button in the editor on this site throws a JS error in the browser's console:

To clarify: The possibility to install 3rd party apps wasn't removed in v5!
Plugins were deprecated, but applications can still be created, exported, imported, etc.. Hooks were replaced with Code Listeners and several new Extensions But all in all, 3rd parties will still be able to create new apps like Member Garage, Member Maps, Classified Ads, Member Info blocks etc..
More information about the upcoming changes can be found in our Dev Blog: https://invisioncommunity.com/developers/devblog/blog/

As a community owner for over two decades, I wanted to give some personal feedback as to what I find very useful (and need) to keep my community alive. 
Big Tech Competition:  The biggest challenge has been competing with other online services like FB, Reddit, Twitter, etc, etc.  You guys have hit the sweet spot in generating useful integrations to these services.  I would also like one for Linkedin but I'm sure that's on the radar.  With any competition like big tech, we can provide a more specialized touch to any community.  I hope we can still maintain this presence and I have a feeling IBP5 will give us even more ways to create active sites that give the big boys a run for their money.
Monetization:  I have a specialized car club and, with Invision, I've been able to monetize our existence and pay our bills.  We are hosted on a dedicated server environment so we have our fair-share of bills.  I've looked into using a cloud-host but the costs don't justify simply putting a machine into a colo site.  We also have other bills like licensing, email services, and annual domain costs.  With the integrations to Google Adsense, Infolinks, and the paid subscription model (built into IPB), this has enabled us to pay these bills and continue well into the future.  The addition of Subscriptions has also helped us a LOT!!!!

3rd Pary Marketplace:  I have appreciated the Invision Community capabilities with 3rd party apps (Marketplace).  However, I see these have been depreciated for the upcoming release.  Some of these modules really gave us an edge and we were able to stand out.  I fear that removing this integration may put us into a general category just like everyone else.  So, I hope the team considers opening this up again or at least making it easier for us to customize our sites to provide unique services.  Some of the more important apps for us are Member Garage, Member Maps, Classified Ads (big one), Tapatalk, and Member Info blocks (we use member numbers for members to use as discount codes to our partners).
Advertising Banners:  We have used, and will continue to use banner sponsor placements on our site.  The one place we are missing is at the top of the screen.  Of course we can always do a pop-up or slide-down style ad.  But people tend to hate these and disable them.  So, if we can add more customizable locations for these banners, it would be a big hit for our business.  
Google & SEO:  This service is so strange and it seems to change every other quarter.  New rules all the time, and I've gone from ~$700/mo in banner income to ~$125/mo.  I have no idea why this is, but I did notice that Google doesn't do very well with active community sites (they prefer static pages I guess).  So, if you are building something new with the release of IPB5, I would be very interested to see how we can improve our SEO or even Google results.
Forum Layout:  I *REALLY* like the new look of your forum design in IPB5.  I cannot wait to use it.  The one thing our members really appreciate are the active notifications and easy way to see how things changed over the last 24/48 hours.  The new features coming seem to compliment this very well.  Not to mention a lot of people have been asking for the light/dark mode and it will be nice to see this capability built-in rather than having to design our own.
Community Experts:  I did see something about the addition of community experts.  VERY GOOD addition!!  In an automotive community like ours, there are always guys hanging around that are considered RL experts as well.  I'd love to give them the recognition they deserve and let people know they actually *DO* know what they are talking about.  I hope this is an 'approved only' capability as I am sure some people may request this status and don't really deserve it.  😉
Downloads, Knowledgebase, Gallery:  These existing capabilities are huge wins for us.  Although I would like to see an update to Gallery, the majority of the existing features work very well.  I hope these stay and continue to see improvements as the product goes into the next stage.
Blogs:  For us, the blog module has been a strange experience.  Some guys know how to use it, while other people tend to post questions and use it like a forum.  If we were to continue using blogs, it might be a great idea to make sure end-users know they are in a "blog module" rather than part of the forums.  It's hard to explain on text but honestly I think people get confused as to what a blog is versus a forum.
All in all, I am so happy to see that I've invested with a company that is taking this product to the next level.  Your team is amazing and it's reassuring to see that private communities are still a necessary part of the Internet.  As we continue forward, please understand that I'll stick around as a long term customer.  Just don't jack up the rates too high on us.   😉
Mike

It’s been that way as long as I can remember!

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.