teraßyte

The function that checks if the IP is banned or has made too many bad requests is the function _checkIpAddressIsAllowed() in system/Dispatcher/Api.php on lines 198-230.

Please go to ACP -> Support -> ensure you're running UTF8MB4

The function that checks if the IP is banned or has made too many bad requests is the function _checkIpAddressIsAllowed() in system/Dispatcher/Api.php on lines 198-230.

It clears up after 5 minutes:
/* If we have tried to access the API with a bad key more than once in the last 5 minutes, throw an error to prevent brute-forcing */ if ( \IPS\Db::i()->select( 'COUNT(*)', 'core_api_logs', array( 'ip_address=? AND is_bad_key=1 AND date>?', \IPS\Request::i()->ipAddress(), \IPS\DateTime::create()->sub( new \DateInterval( 'PT5M' ) )->getTimestamp() ) )->first() > 1 ) { throw new \IPS\Api\Exception( 'TOO_MANY_REQUESTS_WITH_BAD_KEY', '1S290/D', 429 ); }  
It's also possible to make a modification to whitelist IP addresses. It needs a couple of hooks on some functions, but it's doable. I did it for a client before as part of a bigger request.

Time to see the ACP then. 😋

Time to see the ACP then. 😋

As we find ourselves with our toes over the precipice of June; signalling the half way point of the year, I thought it's a good time for an update.

Apologies southern hemisphere.
Invision Community 5 has been in alpha testing for a while, and a small group have found a good number of bugs, and offered their thoughts and suggestions, some of which we've implemented. During this time we've wrapped up the new editor, a boat load of UI improvements and more.
We are now ready for the next stage, which is to give our alpha testers their own Cloud v5 to test with. This opens up testing for the Admin CP, and all areas without using developer mode. v5 has a lot of changes to how CSS, JS and resources are managed. They are now built when we build the apps, and should never need rebuilding. We also store compiled templates now, so lots of slow eval() calls are no longer needed. In brief testing locally, it has made the entire platform super-fast.
We are choosing to use a Cloud v5 to test with, rather than a traditional download for two reasons. The first is that using our hosting platform means we don't have to chase down issues with PHP, MySQL and unix versions which can be time consuming in the early stages. The second is that we're still writing the new build code, so we can't actually produce a versioned zip just yet. 😂
But fear not, downloadable versions will be coming at some point.
We're aiming to have this alpha demo system ready next week, so if you want to help alpha test, drop a comment below. I want to keep the first round (1-2 weeks) fairly small or it becomes overwhelming sifting through the feedback and bugs but please do register your interest.
In terms of functionality, we're wrapping up the tagging changes; I'd expect a blog on that next week. The final parts of the Pages app are coming together. We even tested an upgrade of this site to v5 to see how the Pages built pages looked, and much to all of our relief, it looks great with just a few CSS classes needing updating.
It's been a long journey - and a little longer than we'd first hoped but we're getting closer to betas when the fun really starts.
We're really proud of v5 and we hope you like what we've created.
 

Wasabi is currently experiencing an outage on US-East-1 and US-East-2 due to a cooling issue in their data center. They call it a "slowdown," but when all your CSS, JS, and image files come back with a timeout, it's an outage. 

As Marc said, that's the correct place to upload the files inside the folder ips_xxxxx.
 
There are quite a lot of files that will be useless after the upgrade there, but you can worry about deleting them later. While I always suggest cleaning up the old files, you should confirm that the upgraded suite works as expected first.

hi @teraßyte - now as i know thet there is no such setting i would try to find out where the magic happens and write a hook or query to change that habit. if i run out of time, i'll contact you, thanks.

To upgrade such an old version you need to:
Switch to PHP 8.0 and check the requirements are all good. (Don't use 8.1 because it causes a few more upgrade errors compared to 8.0. The old upgrade steps were never written for 8.0/8.1 which didn't even exist at the time.) Manually upload the new 4.7 files to your server. Go to /admin/upgrade to start the upgrade process.  
Before doing the upgrade, you also should uninstall any 3rd party applications/plugins that don't have any updated version for 4.x, if not a lot of extra tables/columns/settings (maybe even tasks) will remain in the database.
Considering how old the version is, doing a test upgrade in another location is usually a good idea, especially if you have lots of 3rd party modifications installed.

Yes. You can create a database and disable the add/submit permission for all groups but a few select ones (admins, moderators, news writers, etc).
You can also link/sync every record to a topic in a specific forum for comments. Or you can just keep comments in the record itself.

Because of how the framework works, records can't be in multiple categories. Just like the same topic can't be in multiple forums.
 
What you can do is add a custom select/checkboxset field to the database, and allow users to select categories there (while setting up the database to use a single category for all records in the backend).

Because of how the framework works, records can't be in multiple categories. Just like the same topic can't be in multiple forums.
 
What you can do is add a custom select/checkboxset field to the database, and allow users to select categories there (while setting up the database to use a single category for all records in the backend).

No. Don't enable IN_DEV on a production site. Everything will slow to a crawl since the cache data is rebuilt on each page load, etc.
 
If you really need it, make a test site using a copy of the live site's data (database + files), update conf_global with the test site details, clear the cache in ACP, upload the IN_DEV files, and finally enable the IN_DEV constant in the constants.php file.

No. Don't enable IN_DEV on a production site. Everything will slow to a crawl since the cache data is rebuilt on each page load, etc.
 
If you really need it, make a test site using a copy of the live site's data (database + files), update conf_global with the test site details, clear the cache in ACP, upload the IN_DEV files, and finally enable the IN_DEV constant in the constants.php file.

No. Don't enable IN_DEV on a production site. Everything will slow to a crawl since the cache data is rebuilt on each page load, etc.
 
If you really need it, make a test site using a copy of the live site's data (database + files), update conf_global with the test site details, clear the cache in ACP, upload the IN_DEV files, and finally enable the IN_DEV constant in the constants.php file.

Maybe your hosting is doing something to the file after the upload? Like removing a forbidden function? I've seen it happen a couple of times.
 
Try downloading the file and comparing it to the file from the IPS client area. This might help you find if the server is automatically editing the file after the upload.

I assume there will be no issues with the new Tiptap editor quoting from existing content and tags within the forums?
Regarding "code blocks" and "inline code", what languages will be supported in IC5 and how can we add additional language support? Can we make suggestions now to include for release in IC5?
Edit... and a useful feature will be to have a button to copy to clipboard the code block...
https://www.danielmarkavis.co.uk/blog/copy-to-clipboard-from-a-tiptap-codeblock-component
Ted.

We're discussing this internally still but there should be a way to restrict buttons by user and editor location in the final release
 
That would be managed by the theme's CSS. We ended up keeping the background color the same once because a slightly darker/lighter color tended to look off in at least a few box color and dark/light mode combinations
 
Probably not, but only because markdown code itself is not technically supported, rather we've included markdown style shortcuts. For example, if I pasted in "**some bold text**", it won't get converted to bold, it's only going to be converted after being typed out
 
Yes! It uses color-mix and other CSS tricks to consistently adapt to the different theme colors.

Invision Community 5 has a brand new editing experience powered by a lightweight, fast React text editor built for mobile and modern browsers.
The venerable CKEditor v4 at the core of our current editor is starting to show its age, so we wanted a clean slate with Invision Community v5 with an editor that was optimized for mobile use, easily extensible and had a feature set that would take us into the next era of Invision Community and beyond.
The obvious choice was to consider the latest version of CKEditor, but it didn't fit our needs as it wasn't easily extensible, external plug-ins would no longer be possible, and its large footprint would affect page speed scores and be painful to use with a mobile connection.
After a long search, we settled on Tiptap as the base for our editor. Written in React, loaded in chunks when needed for optimal performance and with many APIs and extensibility options, it was the perfect fit.

Aside from the technical improvements, the editor offers new tools and a great base for writing our own plugins. I'll walk you through the main features throughout this blog. If you want a more technical deep dive, then please see my development blog.
The Toolbar
The toolbar has been redesigned to put the most commonly used styles first, with the least used styles and functions into an ellipses menu. The new paragraph menu contains the header styles, as well as the code block. The plus menu adds lists, boxes and quotes. The benefit of this new compact menu is that it displays just the same on mobile. Currently, there are different editor styles for desktops, tablets and mobiles with some style buttons removed to save space. With Invision Community 5, this is no longer the case. Even the smallest display gets all the functionality.
mobile-toolbar.mp4
 
 
Emojis & Icons
Emojis have become a great way to embellish writing and express emotion. The new emoji picker has been modernized with larger emojis and tooltips to showcase the emoji shortcodes.
The Icons tab, new for Invision Community 5, allows you to add Font Awesome Icons directly to your content.

Lastly, both the emoji selector and the shortcode suggestion dropdown support arrow-key navigation, so you don't have to move your hands from the keyboard to the mouse.
Content Boxes
The feature I'm personally most excited about is boxes.
The concept started as an abstraction of spoilers because sometimes you just want "a box" - a section that stands out from the rest of the content, something we do manually in our documentation and guides on this site. Each box has a tile and the following options:
Expandable - You can mark a box as "expandable" which is functionally the same as a spoiler. One improvement is that expandable boxes use native HTML details and summary elements instead of plain Javascript animated divs. Colors - You can optionally keep it grey on grey like spoilers, but I think that's so boring! The colors automatically adjust to the theme colors, so it will look great in dark and light mode. Float (left/right/none) - You can make the box align to the left or right of other content just like you can for images Width - When the box is floated, you can set the width to big, medium or small. Boxes.mp4
Link Expansion
Invision Community has long expanded some links, such as YouTube, offering more context or even a mini-player where appropriate.
With Invision Community 5, we've added support for embedding dynamic link previews using site metadata. This is a preview of a topic on our forum.

For those unaware, the Open Graph (OG) Protocol is essentially a way webpages can specify a title, image, and description to be dynamically embedded on another platform. This is the underlying technology when you see the link preview in Meta, X, Slack, or iMessage.
Code Blocks and Inline Code
The new editor adds inline, syntax-highlighted code blocks and inline code. Both formats can be applied via the toolbar, or optionally, you can wrap text in a single backtick (`) to convert it to an inline code block or triple backticks (```) to convert it to a code block.

The code blocks also support numerous languages for syntax highlighting, including a new custom highlighter for the Invision HTML Template Syntax (Invision Community theme creators and application developers, you're welcome!)
Semantic Headings and Relative Sizes
Invision Community 5 adds a block selector with headings 1 through 6 in the new editor. It's possibly the most common request I hear so that people can use consistent styling rather than just big bold text in a paragraph tag. Semantic headings are also ideal for SEO and accessibility.
In addition to the block selector, you can create headings with the corresponding markdown shortcut. Consecutive pound signs (#) at the start of a line followed by a space (the number of pounds corresponds to the "level" of the heading). For example ### creates a Heading 3 (<h3/>) creates the heading for you.
Using clear header tags means screen readers and search engines can better understand your content as using absolute font sizes, such as 16px, can make it unclear what type of element is actually being used. Is it a heading or just a paragraph with large bold text?
Furthermore, you may want different sizes depending on the content and device type. Mobile devices may benefit from a large base font size. So we added percent-based font sizes which change the font size based on whatever the default would be for that block.
text-menus.mp4
Further UX Improvements
The new editor in Invision Community 5 has several tangible improvements, including a mobile-first design.
In the current editor, some functionality was hidden behind modals and double clicks, which are either not obvious on mobile devices or not possible at all. The new editor no longer relies on modals and instead uses buttons and dropdown menus that work perfectly with mobile and other touch-based devices.
New Line Arrows
For block content, such as boxes, images and quotes, we've added the ability to create a new line before or after the block with the click of a button. This was an issue of frustration for mobile and touch devices where it was not always clear where the cursor was and a finger is a much less accurate aiming device!

Sticky Toolbar
Anyone who has authored a long piece of content knows the pain of scrolling up and down to get the toolbar in view. To make writing longer content less stressful, we've made the toolbar sticky so that it will always be fixed at the top of the editor after scrolling down.
sticky-toolbar.mp4
Markdown Style Shortcuts
One common request is to support markdown in the editor. While we opted not to include full markdown support, the new editor recognizes many markdown-style formatting shortcuts.
markdown.mp4
Colors
A common challenge with rich text editors on sites with multiple themes is colors often need to consistently look right across all themes. This is even more important with Invision Community 5, as it has a native dark mode feature. For this reason, we opted to offer a reduced set of color options that all adapt dynamically to the theme. I mentioned this about box colors above, but this is also true of the font color. The difference in shade is slight, but it's very noticeable without it. Toggling between light and dark mode will never produce unreadable text.
colors.mp4
We can't wait for you to try the new editor; it has already been very popular with our small testing group. Which feature are you most looking forward to trying?

View full blog entry

This is fixed in 4.7.17 Beta 1. Marking as resolved.

This is fixed in 4.7.17 Beta 1. Marking as resolved.

This issue is reproducible only on a page with 2 editors with each having a different area assigned:
Create a page with 2 editors in it. Let's say the editors use the following keys in the same application: EditorA EditorB  
Case 1: Disable the button ONLY for editor A
The button is disabled for both editors A and B.
 
Case 2: Disable the button ONLY for editor B
The button is visible for both editors A and B.
 
===
If you have 2 editors (A & B) that use 2 different areas on the same page, the cached result of the first editor (A) displayed on the page is always used for the second editor (B) without checking if the button is actually available also for the second area.
 
This issue is caused by the static function \IPS\Text\Parser::canUse( $member, $key, $area ) because it caches the result of each button only using 2 values: member_id and $key:
static::$permissions[ $member->member_id ][ $key ];  
The $area value is only checked if there is no cached result:
/** * Can use plugin? * * @param \IPS\Member $member The member * @param string $key Plugin key * @param string $area The Editor area * @return bool */ public static function canUse( \IPS\Member $member, $key, $area ) { $permissionSettings = json_decode( \IPS\Settings::i()->ckeditor_permissions, TRUE ); if ( !isset( static::$permissions[ $member->member_id ][ $key ] ) ) { if ( !isset( $permissionSettings[ $key ] ) ) { static::$permissions[ $member->member_id ][ $key ] = TRUE; } else { $val = TRUE; if ( $permissionSettings[ $key ]['groups'] !== '*' ) { if ( !$member->inGroup( $permissionSettings[ $key ]['groups'] ) ) { $val = FALSE; } } if ( $permissionSettings[ $key ]['areas'] !== '*' ) { if ( !\in_array( $area, $permissionSettings[ $key ]['areas'] ) ) { $val = FALSE; } } static::$permissions[ $member->member_id ][ $key ] = $val; } } return static::$permissions[ $member->member_id ][ $key ]; }  
 
If you also want to slightly optimize the code, the json_decode() call can be moved inside the first IF since the data isn't used if a cached result is found.

This issue is reproducible only on a page with 2 editors with each having a different area assigned:
Create a page with 2 editors in it. Let's say the editors use the following keys in the same application: EditorA EditorB  
Case 1: Disable the button ONLY for editor A
The button is disabled for both editors A and B.
 
Case 2: Disable the button ONLY for editor B
The button is visible for both editors A and B.
 
===
If you have 2 editors (A & B) that use 2 different areas on the same page, the cached result of the first editor (A) displayed on the page is always used for the second editor (B) without checking if the button is actually available also for the second area.
 
This issue is caused by the static function \IPS\Text\Parser::canUse( $member, $key, $area ) because it caches the result of each button only using 2 values: member_id and $key:
static::$permissions[ $member->member_id ][ $key ];  
The $area value is only checked if there is no cached result:
/** * Can use plugin? * * @param \IPS\Member $member The member * @param string $key Plugin key * @param string $area The Editor area * @return bool */ public static function canUse( \IPS\Member $member, $key, $area ) { $permissionSettings = json_decode( \IPS\Settings::i()->ckeditor_permissions, TRUE ); if ( !isset( static::$permissions[ $member->member_id ][ $key ] ) ) { if ( !isset( $permissionSettings[ $key ] ) ) { static::$permissions[ $member->member_id ][ $key ] = TRUE; } else { $val = TRUE; if ( $permissionSettings[ $key ]['groups'] !== '*' ) { if ( !$member->inGroup( $permissionSettings[ $key ]['groups'] ) ) { $val = FALSE; } } if ( $permissionSettings[ $key ]['areas'] !== '*' ) { if ( !\in_array( $area, $permissionSettings[ $key ]['areas'] ) ) { $val = FALSE; } } static::$permissions[ $member->member_id ][ $key ] = $val; } } return static::$permissions[ $member->member_id ][ $key ]; }  
 
If you also want to slightly optimize the code, the json_decode() call can be moved inside the first IF since the data isn't used if a cached result is found.