13.

Hardcoded widgets are painful to move to desired positions.

Please make them movable, just like other widgets.

For example, the statistics in the topic (which eats a whole column in the topic view by default).

@Matt Finger, again, we're talking only about one region below the entire content (not "every block"), so everything you've mentioned is not relevant to the suggestion.

The implementation of the interactive area exactly as it was described in the suggestion will only improve UX and won't affect anything else in any way.

14 minutes ago, Matt said:

How about adding a line before?

Exactly the same as already implemented. My suggestion is for improvement, not replacement.

The main idea of the interactive area is to prevent people from getting stuck in a state where they are unable to add a new paragraph at all (which happens quite often in CKE now) or are forced to look for unintuitive buttons on other elements (as implemented in IC5).

When they can start typing into a paragraph with just one click in the same intuitive zone, regardless of the contents, they are no longer stuck. They can move blocks wherever they want after adding new paragraphs, etc.

33 minutes ago, David N. said:

• HTML anchors (to add a link to an H2 further down the page)?

Yup, a must-have feature. I implemented it myself in the current CKE, and I hope IC5 will allow doing it too. Or, even better, it will finally include it for all IC5 users 

16 minutes ago, Matt said:

I don't agree that adding newlines before and after each box is a great idea.

It seems you misinterpreted my suggestion. You 'don't agree' with something weird that you came up with yourself because I never said to do that. I would not agree with that either 

I only suggested adding one interactive area, which allows typing in the paragraph only upon interaction, and nothing like what you described. In this implementation, it does not have any of the drawbacks you imagined.

Those elements are not intuitive for inexperienced users (i.e., almost all users).

It would be much more intuitive and easy to use if there were an area where users could click to start writing in a new empty paragraph. This area should always be placed right after the existing content in the editor:

If this is implemented, even inexperienced users won't get stuck in a state where they can't add a new line and don't know where to search for a button to do that.

7 minutes ago, Matt said:

It's worth remembering that the same editor can be used for Pages.

It's worth remembering that its behavior could be adjusted for specific regions such as Pages, while global defaults could follow best practices.

4 minutes ago, Matt said:

Not always the case. I presume you mean for SEO purposes, but we've moved on a lot from the days where a two H1 tags would confuse the billion dollar AI driven company called Google.

It's important not only for SEO but also for accessibility, especially for screen reader users.

The usage of more than one H1 tag is considered a bad practice for a reason, as highlighted even in MDN docs.

By the way, Google isn't the only search engine in the world. I know it's (almost) not the case in the US, but other countries also exist on this planet.

H1 must be removed from this menu. Also, its insertion should not be triggered by just one "#" symbol (Markdown).

Each page must have a unique H1.

At present, shorts are embedded using a 16:9 aspect ratio, which is not ideal since their actual format is 9:16. It would be nice to fix this.

Adjusting the embed settings to match the native 9:16 aspect ratio of shorts will enhance the viewing experience and maintain content integrity.

Now:

Should be:

Transitioning from "Display Name or Email" to solely "Email" logins isn't seamless for users who have stored their login credentials using their Display Name.

They repeatedly click "Sign In" without comprehending the issue when login attempts fail.

Adding a simple tooltip to the login field when the entered value is not an email would greatly improve UX in this case. This way, users can easily see and switch without encountering further problems.

Example:

Also, it would be a good idea to keep the "Sign in" button in this form dusabled until both fields are valid (email is validated and password is not empty), so users won't waste their login attempts with this kind of little mistake.

6 hours ago, WebCMS said:

It would be ideal for the IC Team to add this block to whatever template it is so all clients don't have to add it to their templates redundantly. This is the solution and you just have to add it and test. This small change which belongs in the core would resolve a BIG pain point.

The last thing clients want to do is modify templates and maintain/re-apply the changes across updates.

It's quite a bad approach and should never be used in any reputable software. Unwanted styles/tags should always be stripped immediately when text is pasted into the editor, long before the message is sent to the database, not on the template side as it happens in this example.

This code is a temporary and ineffective workaround, not a solution.

Both AVIF and HEIC have been supported in GD and ImageMagick for quite some time now.

On 4/25/2024 at 12:34 AM, Jim M said:

HEIC is only supported by Safari at this time and minimal at that: https://caniuse.com/?search=heic . If it ever becomes more widely supported, I'm sure, we'd improve how they get embedded.

It is highly unlikely to happen due to the licensing issues surrounding HEIC, and also due to the existence of a comparable or superior free and open-source alternative: AVIF. Therefore, the best way to handle HEIC files is to:

1. Add AVIF support to Invision Community (embedding and quality settings). AVIF is supported by all current browsers and is currently the best format in terms of compression/quality.
2. Convert all uploaded HEIC files to a format selected from the uploader options (AVIF, WEBP, JPEG) in Admin Control Panel, with AVIF as the default choice.

Restricting registration by location is the worst thing you can think of. I say this as someone who travels frequently and is often faced with such ill-conceived restrictions. This causes many more problems for ordinary users than for spammers. There are many other more suitable methods to protect against spam (Cloudflare, for example).

@SeNioR- check the value of this setting in Cloudflare:

5 hours ago, Day_ said:

Default dark mode for IP board with a more intuitive switch than the theme drop down.

iPad app for Whatsapp.

iPad app for Instagram.

Becoming a millionaire.

Marry Margot Robbie

5 things I have accepted will never happen in my lifetime. 

The last four don't seem so impossible 😉

7 hours ago, Randy Calvert said:

They’ve already said it’s on their radar.

How many years ago, could you remind me please?

Imagine if clients could make pull/merge requests with such fixes directly to the IPS repository, without wasting time posting it on the forums, waiting for the manual work of the IPS developers, etc... A lot of little but useful fixes/improvements could be implemented and shipped in hours rather than years (as it now, at best).

Oh dreams.

18 hours ago, Randy Calvert said:

IPS would have to develop some sort of native app for it to authenticate a user

No. Everything needed for this can be done in PWA.

• Why and How: https://web.dev/aspect-ratio/#example-preventing-layout-shift
• MDN Docs: https://developer.mozilla.org/en-US/docs/Web/CSS/aspect-ratio
• Works everywhere: https://caniuse.com/?search=aspect-ratio

This topic is not about that. This topic is about defaults (of editor's link insertion tool) that are more secure and relevant to current and future times. And not all sites use HSTS, btw. And most of them never will.

7 minutes ago, Randy Calvert said:

When you insert it without a protocol, it passes it to the browser without a protocol.  Your browser by default sets to HTTP instead of HTTPS.  If the destination site properly sets HSTS headers (https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security), the browser will transparently use HTTPS even if HTTP is specified.  

This is not an IPS configuration issue but instead a default way links are handled.  

Wrong. It is not related to HSTS or the browser at all. IPS's editor forces HTTP protocol if a protocol is not specified. Just try to do exactly what is shown on the screenshot and see the resulting HTML.

Result: koreanrandom.com (http://koreanrandom.com)

If you insert a link without protocol, it will appear with HTTP in the editor.

In 2022 (even in 2015, to be honest), it would be better to use HTTPS as the default protocol. Those who need HTTP must define it explicitly.

Example:

Result: example.com

JFYI: according to google, almost all websites are using HTTPS: https://transparencyreport.google.com/https/overview

So forcing the HTTP protocol where there is no need is harmful.

7 hours ago, Sirmadsen said:

and introduce a scroll list

And search-filter (see datalist / js example).