Everade

Does the team test the layout according to these indicators?

There's currently no option to set icons being maskable or not.
And IPB, by default doesn't set the maskable attribute.

Google Lighthouse Audit as such doesn't rate the PWA setup as optimized.

Would be great to either set it by default in the manifest file, or add an option for us to set the maskable attritbute ourselfs.

https://web.dev/maskable-icon-audit/?utm_source=lighthouse&utm_medium=devtools
 
Of course, this isn't just about Google Lighthouse Rating improvement, but it also allows us to mask the icon 😉

You forgot: "In 5 years from now." 
And yes, i mean it.
 
Maybe they do, but they don't care. There are hundreds of community posts screaming for improvements but they couldn't care less. You're better off preparing for your funeral than waiting for a patch that adresses long standing issues. They simply don't have a big enough team to work on whatever they want + plus community requests.
5.x may address some issues, but you're better off not betting on it. Never take their word, there's still a ~3 years waiting list of other promises.
But what you can expect is another new re-design as usual. Because new looks and marketing sells best. Let's just cross our fingers that at least some of the underlying ancient code gets updated a long the way.
 

You forgot: "In 5 years from now." 
And yes, i mean it.
 
Maybe they do, but they don't care. There are hundreds of community posts screaming for improvements but they couldn't care less. You're better off preparing for your funeral than waiting for a patch that adresses long standing issues. They simply don't have a big enough team to work on whatever they want + plus community requests.
5.x may address some issues, but you're better off not betting on it. Never take their word, there's still a ~3 years waiting list of other promises.
But what you can expect is another new re-design as usual. Because new looks and marketing sells best. Let's just cross our fingers that at least some of the underlying ancient code gets updated a long the way.
 

Removing the ability for file authors to upload new versions while the file is pending is an awful solution to a very rare issue. This drastically changes how the application works, and will require websites like mine to completely re-invent the uploading process.
I wished we would have been given a heads up... Or at least some mention in the change notes. How can you change something so big and not even include it in the change notes? Something has to change here. You cannot expect websites to have to force users to re-submit the file entirely just to release a new update post-approval. 

Currently we can report only content items, but sometimes it would be useful to report a user, for example in cases when user account was made is only in order to leave links in it's profile and "About me" section, like this.

You forgot: "In 5 years from now." 
And yes, i mean it.
 
Maybe they do, but they don't care. There are hundreds of community posts screaming for improvements but they couldn't care less. You're better off preparing for your funeral than waiting for a patch that adresses long standing issues. They simply don't have a big enough team to work on whatever they want + plus community requests.
5.x may address some issues, but you're better off not betting on it. Never take their word, there's still a ~3 years waiting list of other promises.
But what you can expect is another new re-design as usual. Because new looks and marketing sells best. Let's just cross our fingers that at least some of the underlying ancient code gets updated a long the way.
 

Because there are smart people out there who can get easy faeces done in a matter of minutes or even seconds, unlike some other devs around here.
If you've ever worked in an open source git project then you would be aware how well it works. But that's an entirely different story.
 
This has nothing to do with customization, but with getting their faeces together and offering a proper product.
Customizations only require additional overhead for months on end on the customer (or a plugin which is lots of additional work), rather than getting something so trivial done within 1 or 2 patch time-frames by invision.
They have a subscription based model and ask for a substantional amount of money from each customer.
So it's not too much to expect a decent patch policy rather than a "fix it yourself" mindset.
And it can't get any easier than this. (There are many similiar topics that would be benefitial and easy to fix that are sitting ducks for years)
It would be fixed faster than reading through this nonsense topic that would not have been required if it would have been implemented properly in the first place.

I guess i'll miss out on the next year of the subscription.
It's just not worth it looking at the micro patch notes and still missing out on all the community requests.
I assume they fired most of their devs years back, because updates have been stagnating in the past 4 years.

There's currently no option to set icons being maskable or not.
And IPB, by default doesn't set the maskable attribute.

Google Lighthouse Audit as such doesn't rate the PWA setup as optimized.

Would be great to either set it by default in the manifest file, or add an option for us to set the maskable attritbute ourselfs.

https://web.dev/maskable-icon-audit/?utm_source=lighthouse&utm_medium=devtools
 
Of course, this isn't just about Google Lighthouse Rating improvement, but it also allows us to mask the icon 😉

One single line is all it needs my fellow devs:
"purpose": "any maskable"

I just tested the page in PageSpeed Insights and Google suggested to add lazy loading to category icons.
<img src="{file="$forum->icon" extension="forums_Icons"}" alt='' class='ipsItemStatus ipsItemStatus_custom {{if !\IPS\forums\Topic::containerUnread( $forum ) && !$forum->redirect_on}}ipsItemStatus_read{{endif}}'> The icons also don't have width and height attributes.
What do you think about it?

One single line is all it needs my fellow devs:
"purpose": "any maskable"

There's currently no option to set icons being maskable or not.
And IPB, by default doesn't set the maskable attribute.

Google Lighthouse Audit as such doesn't rate the PWA setup as optimized.

Would be great to either set it by default in the manifest file, or add an option for us to set the maskable attritbute ourselfs.

https://web.dev/maskable-icon-audit/?utm_source=lighthouse&utm_medium=devtools
 
Of course, this isn't just about Google Lighthouse Rating improvement, but it also allows us to mask the icon 😉

It would be amazing to have a tool to remove broken images.

I used SEO tools to identify all pages with broken images and fixed them manually.
IPB has removed image fixing tools a long time ago. I doubt they bother giving us these back in a timely manner.

There should be better possibilities to retrieve certain data within an RSS feed for Pages.
Yes, there's now the possibility to generate custom RSS feeds, but it still lacks lots of options as its an extremely basic filter.
What it currently generates:
<item> <title>Topic_Title</title> <link>https://mysite.com/community/announcements/topic_title/</link> <description>Actual text content</description> <enclosure url="https://mysite.com/community/uploads/image.png" length="11111" type="image/png"/> <pubDate>Wed, 09 Jun 2021 01:12:00 +0200</pubDate> </item>  
There's currently no possbility to include any of the additionaly added fields.
I haven't tested all of them, but i'm pretty certain that none of them are included in any feed.

These are just examples, to outline what's not possible with any RSS feed feature given by IPB:
Category [Type: Select Box]      (To define articles in the RSS feed) Summary [Type: Text Area]       (Text field, for proper news summaries) Thumbnail [Type: Upload]        (Additional image upload for smaller image versions) Here's are the example setup fields:

 
It would be great, if we could define which additional fields are included in the RSS feed.
Or at least include all fields by default.
 
So we can achieve something like this:
<item> <title>Topic_Title</title> <link>https://mysite.com/community/announcements/topic_title/</link> <description>Actual text content, lorum ipsum its a lot.</description> <enclosure url="https://mysite.com/community/uploads/image.png" length="11111" type="image/png"/> <pubDate>Wed, 09 Jun 2021 01:12:00 +0200</pubDate> <thumbnail>https://mysite.com/community/uploads/thumbnail.png</thumbnail> <summary>This is a quick summary.</summary> <category>Event</category> </item>  

There's currently no option to set icons being maskable or not.
And IPB, by default doesn't set the maskable attribute.

Google Lighthouse Audit as such doesn't rate the PWA setup as optimized.

Would be great to either set it by default in the manifest file, or add an option for us to set the maskable attritbute ourselfs.

https://web.dev/maskable-icon-audit/?utm_source=lighthouse&utm_medium=devtools
 
Of course, this isn't just about Google Lighthouse Rating improvement, but it also allows us to mask the icon 😉

Yes, layer shifting still happens without specifing the size, that's why you should always specify the size. But layer shift is a whole different story. 😉
However even without specifications, it would still gain a big performance boost because the important content can be loaded before images are starting to show up.
Which is the main purpose of lazy loading.
On top of that, the current system blocks the entire text to be loaded when scrolling, which is most likely the worst case scenario for a forum.
 
Test it and see it for yourself.
It's technically not possible to make it slower, that's not how any of this works.
You don't want to enable lazy load in every case, critical images should be loaded directly of course, but that's basically not existant in a topic and/or post.
 
Lazy loading reduces initial load time due to reduced page weight, which is one of the most important things for a website.
It's also a bandwith conservation as it only loads content on request.
And a system resource conservation, as it conserves both server and client resources.
Which is similiar to what we have right now, but WITHOUT the mentioned drawbacks in my original post.
As long as you're not running it on Netscape with a last century potato on dial up that doesn't support lazy loading of course.
 

One more dark theme issue are answer ratings:

Thanks for the update.
However there are still some leftover issues.

In mobile view, social icons are displayed instead of hidden:
Please hide them just live in the official design.

 
Dark mode also has still several issues such as:
Topics Widget for the ipsCommentCount is invisible.

 
Manage Promoted Items Page:

 
Not all Field Labels for Pages are not optimized for dark mode.
Some are barely visible, if at all.
This is just an example of some of the listing view formats:

Date of Incident is almost invisible:


For example your Legend News uses this black label as well.
The category is almost invisible:

These are defined on Page Field Settings and can be picked as shown here:
They look fine in the dark mode of the admin panel though.

 
Also the addEventListener error  that i reported to you still perists in the plugins.js
However this time around you duplicated the warning and error with the addition of the new function, which by the way also refers to fontBtn which is for sure a copy/paste mistake.

Would be great if you could resolve these errors soon.

Why are invisioncommunity devs so blind for webp?

It's not like it requires any other extra work, since the compression of webp is already existant by nature.
Simply allowing webp by default shouldn't be the biggest deal, or is it?
It's already widely accepted by all major browsers, so there's no excuse on that anymore, especially not since you dropped IE support yourselfs.
But still, every request and any conversation about webp have either been put down, or ignored.

Could we please get an explanation why you're so anti-fast-web?
I'm honestly wondering why is that.
 
I'm also wondering if the spacer.png image load implementation is still best practice either.
Wouldn't it make more sense to add native lazy loading instead?
Really keen to live up to todays SEO standards and performance requirements.

I've heard of tools that allow designers to design badges.
Could be a solution to fit your taste, whatever that might be.

Getting school flashbacks where you have to wait to move on because the stupid kids still don't get 1 + 1.
 
Fallback like @13. mentioned please.
Your product's main feature should be prioritzed above 2 bad browsers that form a minority.
Altough yes, safari is the 2nd most used browser, it's still only 18% of the world market (and declining).
So a fallback for these should do until it can be removed eventualy.
https://gs.statcounter.com/
 
It's not just a simple scrolling issue but an overall performance killer.

This is what scrolling topics with images in IPB looks like:
(Tested with 1gbit/s internet connection <10ms latency)

Why is this bad?
Text + Images + Scrolling = Forum
And this affects 3/3 of your product. (quickmath 😛)
What i'm trying to say is that, new features are cool, we love them.
But don't forget your roots, they need some love too.


Reason for the scrolling/loading issues:
IPB preloads the spacer.png file instead of the actual image, then it goes for the image itself.

This blocks all content from being rendered, because that's how browsers handle it, which results in a truly awful scrolling experience.
It's normal for community members to sometimes come up with a great piece of topic or post, which consists of many images to make it look nice and clean.
So it's not uncommon, i see this problem on my board all the time.
Todays browsers all feature native lazy loading.
 
Spacers' death shall be imminent. 
 

This is what scrolling topics with images in IPB looks like:
(Tested with 1gbit/s internet connection <10ms latency)

Why is this bad?
Text + Images + Scrolling = Forum
And this affects 3/3 of your product. (quickmath 😛)
What i'm trying to say is that, new features are cool, we love them.
But don't forget your roots, they need some love too.


Reason for the scrolling/loading issues:
IPB preloads the spacer.png file instead of the actual image, then it goes for the image itself.

This blocks all content from being rendered, because that's how browsers handle it, which results in a truly awful scrolling experience.
It's normal for community members to sometimes come up with a great piece of topic or post, which consists of many images to make it look nice and clean.
So it's not uncommon, i see this problem on my board all the time.
Todays browsers all feature native lazy loading.
 
Spacers' death shall be imminent.