Clover13

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.
 

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

We have released a patch to address this issue. Please go to AdminCP > System > Support and apply the patch from the first/top left box. If you do not see an option to install the patch, you already have the latest release.

We have released a patch to address this issue. Please go to AdminCP > System > Support and apply the patch from the first/top left box. If you do not see an option to install the patch, you already have the latest release.

What my colleague is saying, is we hit them. Not that we fixed it 🙂

I got it, thanks @Ryan Ashbrook
Whitelisted the server IP at:  Security → WAF → Tools → IP Access Rules

Most likely - on their site, the Pro account advertises that they have blocking / challenging of automated traffic. In most cases, this is simply detecting that the request is coming from an IP from a data center and not an actual ISP (I should know, our corporate VPN gets hit by this all. the. time.).

You don’t for a VPN.  IPS would not  control the Cloudflare site they are visiting to adjust the settings. They would have to tell their customers to turn off cloudflare for their site while troubleshooting. 

For what can you do as the site owner?  Turn off all bot related protections. That will help you confirm it is a bot issue. Once confirmed, you could whitelist your server’s IP. If other third party servers are also accessing the IP, you might have to whitelist those IPs as well. 

It's likely that Cloudflare is detecting that the IP the request is coming from is from a server / data center, and is blocking it as automated traffic.
When the Admin CP tests for these things, it makes an HTTP request to https://example.com/login/ for FURLs, and to https://example.com/api/core/hello for the API.

CloudFlare Pro has managed firewall rules and improved bot filtering. You would need to review it. I'm afraid, it is outside our scope of support so you would need to contact CloudFlare if you have any questions.

Sure, send me a PM and we'll take a look.

@Clover13 To reproduce the bug, the database must have the Store revisions option enabled. Most likely the test was made on a database with it disabled.
I initially thought too the error was coming from saving the record to the database, only after re-checking your last screenshot I noticed it was a revision instead. 😅

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.
 

Looking again at the screenshot, the error is being thrown when a revision for the record is added to the database, not when the record itself is added. If you're adding a new record, it shouldn't store a revision. A revision should be saved only when you edit a record.
 
The problem is in /applications/cms/api/records.php in the _createOrUpdate() function (lines 424-443):
/* Store a revision before we change any values */ if ( $item::database()->revisions ) { $revision = new \IPS\cms\Records\Revisions; $revision->database_id = $item::$customDatabaseId; $revision->record_id = $item->_id; $revision->data = $item->fieldValues( TRUE ); if ( $this->member ) { $memberId = $this->member->member_id; } else { $memberId = $item->author()->member_id; } $revision->member_id = $memberId; $revision->save(); }  
The IF check should also check if you're editing a record because when adding a new one there is no record ID available yet (thus the column NULL error):
if ( $type == 'edit' AND $item::database()->revisions )

From the js file (line 61):
ips.createModule('ips.ui.uploader', function(){  
To create a new one you need to copy/paste the file in your app, change the name, update the names/references, edit the code you need, and call the new module's name in the HTML.
 
This is the code that registers the module (I'll use the dialog one which is more used):
ips.ui.registerWidget('dialog', ips.ui.dialog, [ 'url', 'modal', 'draggable', 'size', 'title', 'close', 'fixed', 'destructOnClose', 'extraClass', 'callback', 'content', 'forceReload' , 'flashMessage', 'flashMessageTimeout', 'flashMessageEscape', 'showFrom', 'remoteVerify', 'remoteSubmit' ], { lazyLoad: true, lazyEvents: 'click' } ); You need to change the dialog name (maybe dialogbis) which registers the widget. All the other values in the array are the options you can use inline.
 
This is how the code would be with the original dialog module:
<div data-ipsDialog data-ipsDialog-title="TITLE" data-ipsDialog-remoteSubmit data-ipsDialog-flashMessage="ITEM SUBMITTED"> This is how it would look with your updated dialogbis module:
<div data-ipsDialogbis data-ipsDialogbis-title="TITLE" data-ipsDialogbis-remoteSubmit data-ipsDialogbis-flashMessage="ITEM SUBMITTED">  

This has now been resolved in the 4.7.16 release. Please update if you are seeing this issue. If you are then still seeing the issue, please let us know.

🤔-Thinking about the bug
👀-Looking for the solution to the bug
📰-Writing the fix for the bug
➡️-Exiting when he realised the bug fix didnt work
👤-Hiding in the shadow to see if anyone notices
 

New feature blog early next week. 🤔👀📰➡️👤

Just six short weeks ago, Ehren hit record on a video that changed everything for Invision Community.
The blog was called "Introducing a fresh new vision for Invision Community 5," and it ripped up the rule book on what forums should look like and revealed a slick new look featuring a new forum home feed view and sidebar navigation.
A lot has been discussed, but we're not even close to done!
Before we bring you news of more features after Thanksgiving, I wanted to take a mid-season break to recap what we've seen so far.
First up was the introduction video, which gave a broad overview of the new UI Invision Community 5 would be sporting. Ehren takes us through many new elements, including the sidebar navigation, forum feed view, simplified post view and more.
 
 
Up next was a focus on dark mode, accessibility and mobile views. Invision Community 5 features the ability to have native dark mode without additional themes or complex variables to set up. Our aim with Invision Community 5 is to hide the complexities and technology and just let you focus on creating a great community experience for your audience.
 
 
Bringing complex theming to everyone was the message in the blog talking about the new theme editor. Now, you can make wide-ranging changes to your theme without the need to edit CSS or manage HTML templates, all driven by a smart and simple interface.
 
 
Next, it was my turn to talk about a new feature. I introduced two new features designed to help those who run support-based communities. Finding the most helpful answers and identifying community experts help your members do more with less time and frustration.
 
 
Last week, Ehren demonstrated our new icon and badge builder, which is an amazingly powerful tool to produce slick and professional badges along with the ability to customize your community further with emojis and icons for menus, reactions and more. Building ways to reduce the barrier to customization has been a strong theme for Invision Community 5.
 
 
Phew!
We can all agree that we've showcased a lot of impressive functionality coming with Invision Community 5 already.
But what does the future hold?
Lots! We have a lot of new functionality that we're putting the finishing touches on, and we can't wait to show you more. These new features further help to reduce noise in topics, make the community feel alive and bring long-needed updates to core components such as the editor. Not to mention, there is a significant update to Pages underway.
We also have a lot of less flashy updates, such as the new consolidated Feature/Our Picks feature, which is now a single feature.
 
Feature-window.mp4
 
An improved Moderators Control Panel brings a more uniform experience across deleted, hidden, and content waiting to be approved.
 

We're still on course for a release of Invision Community in early 2024 and can't wait for you to experience the future of forums.
What has been your favourite feature so far? I'd love to know; drop a comment below!

View full blog entry

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.

The problem is, without the current IPS scan/approval process of apps/plugins, any new development is a risk.  We also don't know how many iterations of scan/approval a given version of a given app had to go through to get final IPS approval, nor what those rulesets/barriers were for good practice per IPS standards.  We just know the end product from the Marketplace dev.  Now clients are subject to the intermediate iterations and any issues they expose.  This is particularly concerning when we get into PII and any level of security risk to our sites (which we had a confidence level IPS was protecting us from with their scan/approval process).

Right, so this bodes well for well known and established devs as they have already created a foundational trust model with clients.  For new devs, that's a barrier they'd have to create over time.  Meanwhile, clients either have no way to validate new devs work like IPS previously did to guarantee the safety of the app/plugin.
I think this greatly elevates the risk for clients and subsequently harms the potential for developers to grow the product.  Hobbyist sites will suffer the most as they simply don't have the resources to invest in robust security evaluation.
Perhaps another opportunity for a dev to provide some level of AppSec and InfoSec scanning of applications to lower the risk.  

As a general opinion on "Pages DB"...
They are not really "databases" in SQL terms -- but SQL "tables" in the Invision database.
When you are considering which sort of SQL table to use (within Invision) you have two choices:
"Pages DB" (as you have mentioned) SQL tables as defined under the 'Database Schema' tab for an Application Pages DB works well for:
Where you only need a single table for all your data - for example, in the classic database design if you only need a "products" table then it will work well. If you actually need a "products" table and a "suppliers" table with cross references then it does not work so well - and in any case you would need two Pages DB (one for products and one for suppliers)
  Where the solution involves a human adding and editing records it works well - for example, where you have a human adding products (descriptions, part numbers, prices, etc.) to a product table. We probably use between 5 and 10 Pages DB for various unrelated things such as "news articles", "places to go" and so on.
  Using Pages DB automatically gives you various widgets such as "Database filters" which is good.
  I would strongly recommend that you use the standard display templates wherever possible. If you create your own display templates based on the standard display templates then that effectively bases your template on a snapshot of the standard template - you don't benefit from future improvements and bug fixes to the standard. We have some of our own templates from 6 or 8 years ago and regret not putting more effort into display formatting for individual fields. With some clever display formats you can combine fields to produce complex output (for example, latitude and longitude fields to display a map) and if you need to do conditional display of some fields dependent upon the contents of others then you can add a dummy field (with a non-blank default value so it triggers display) and you can write custom code to display the contents of several other fields according to the rules that you want to apply. Do the fancy stuff in a field display rather than a template wherever possible.
  When you write a scheduled task (for example) to update the data in a Pages DB there are a couple of (minor) extra steps that you need to take in order to write the data. Firstly, you need to know the classname that will be used to write to the correct table and this will be something like \IPS\cms|\Records23 where 23 is the database number. So, you have to look up the database number from your database key (I recommend against hard coding the 23 😉 ). Secondly, if you have fields for name, address, region, country, phone, etc. then the names in the table will be something like field_91, field_92, field_93, field_94, etc so you have to 'map' from the field key to the real field name in the database. Not difficult, but that's what you have to do.
  Pages DB will work OK where you have a scheduled task to update the data once per day (for example - it could obviously be much more frequently if you wanted). A scheduled task will work fine where nearly all the data items/records are accessed every day - but what about a scenario where only 5% of records are accessed each day? Doing a daily scheduled update of all records means that 95% of what you retrieve is not going to be used in the next 24 hours. I rather liked Nathan's suggestion of retrieving data on demand (i.e. every record has a lifetime field that you add so if you want the record but the lifetime has expired then you retrieve the data through the API). That would mean that you would not waste resources retrieving data that is not being used. Unfortunately, "retrieval on demand" would be extremely difficult or impossible to implement using Pages DB - unless you write your own very fancy templates and in that case you could do better to write an Application to do the entire job. Updating Pages DB from a scheduled job would work easily. Application tables will work well for:
You need several tables with relationships between them (e.g. products and suppliers)
  You need an application that does a lot of processing of records (rather than simple human entry of records as indicated previously)
  Access to records is more intuitive - field names are what you want to call them rather than being 'mapped'. Also, access to the correct table is very simple as you need to create a sub-class of \IPS\Patterns\ActiveRecord that will get you to the correct table plus a whole load more stuff.
  If you have hierarchical data (for example, categories and records) then you should consider using the Node/Model/Item/Content model although that gets a lot more complicated it does give you access to many of the features that you see time and again in Invision.
  You have complete control so retrieving data on demand is much more simple than it would be using Pages DB. Regards,
John
 

This one?
https://developer.chrome.com/docs/web-platform/deprecating-unload
If so, Ending with 100% of users by the end of Q3 2024
Assuming that means anyone on v4 won't be able to use Chrome after the deprecation?

First mention of filtering there, so wasn't aware it was a requirement. If it is then crack on with a Pages DB - you then have to figure out how to keep that data up to date, and when to do it. Alternatively, look at IPS\Helpers\Table\Custom to allow you to create an table based on an array datasource instead of a DB table.
With all this in mind, I'd now advise you to look into developing an application to do all this instead...
You can design your own table to store the data You can create a module/controller that will display that data, and add filtering on there easily. You can create a task that runs on a schedule to retrieve/store/update the data. Not much more to add really - if I knew what this mysterious API was, and where it was getting the data from, and what the data looked like then I might even get bored and throw together a POC of it.