When posting a link to the the feed on our UNA community websites, how do we get the og:image to show up in the feed?

It works here, but not on my Meta-Travel Hub installation.

Are there any settings I need to change?

Day 9, 10 and 11 of the 100 D-Days Challenge

• Detailed instruction for Downloading, Installing and Activating Apps published.
• Overview of Core Apps - intro to Core Apps. Individual pages for each app are coming.
• Overview of Starter Kits - Only Spacenook is currently available and 3 more will be released in coming weeks.
• Spacenook Starter Kit page and the Accounts App updates are WIP.
• All documents a getting interlinked as new updated are coming.

With that we're 10% into the challenge, just ramping up!

If you're on the hunt for the best community software, you may be asking the wrong question. It's not always about features, performance, design, or reputation. The best software is the one that fits your unique needs and idea. And don't be fooled - there are plenty of options to choose from. Basic groups on Facebook or LinkedIn, hosted SaaS platforms, closed-source proprietary enterprise solutions, open-source frameworks - the list goes on.

The real question you need to ask yourself is: what's your long-term vision for your community, and how much control do you want to have while building it? Are you okay with a one-size-fits-all solution? Are you comfortable sharing your members' data with the platform operator? Do you have the time and technical expertise to build on a general-purpose framework? Or do you need a platform that gives you a set of tools you can configure to match your unique idea, with full control and access to support from the core developers?

Open-source configurable software platforms offer several advantages over closed-source SaaS systems. For one, they allow you to choose your own hosting infrastructure, giving you greater control over your data and ensuring that it isn't shared with third parties without your consent. They also allow for unlimited customization and give you full ownership of your data.

On the other hand, closed-source SaaS platforms can be limiting in terms of control over your data, customization options, and dependence on the provider. Creating communities on social media sites like Facebook or LinkedIn can also have its drawbacks, such as lack of ownership, limited control, and lack of privacy.

• One major advantage of open-source configurable software platforms is that they allow users to choose their own hosting infrastructure. This means that you can host your social network on a server that you trust, which is not possible with closed-source SaaS systems. This gives you greater control over your data and ensures that it is not being shared with third parties without your consent.
• Another advantage of open-source configurable software platforms is that they allow users to modify the code without any limitations. This means that you can make changes to the code to meet your specific needs and requirements. With closed-source SaaS systems, you are often limited in terms of the changes you can make to the code, which can be frustrating if you want to customize your social network in a certain way.
• Open-source configurable software platforms also give users full ownership of their data. With closed-source SaaS systems, the data is often owned by the company providing the service, which means that you have limited control over how it is used. With open-source configurable software platforms, you own the data and can use it in any way you see fit.

UNA is one of the best examples of an open-source community software platforms. The UNA platform is highly configurable thanks to its UNA Studio configuration system, which makes it easy to make updates and customize the platform to meet your specific needs. In addition to its configurability, UNA offers several other advantages, including high scalability, a mobile-friendly responsive UI, and over 100 native modules that you can mix and match to create a unique social network.

Some negative aspects of closed-source SaaS platforms include:

1. Lack of control over data: With closed-source SaaS platforms, you do not have control over how your data is used. The company providing the service owns your data and can use it for their own purposes, which may not align with your values or interests.
2. Limited customization: Closed-source SaaS platforms often have limited customization options, which can be frustrating if you want to tailor the platform to your specific needs. With open-source configurable software platforms, you can make changes to the code to meet your unique requirements.
3. Dependence on the provider: With closed-source SaaS platforms, you are dependent on the company providing the service for updates and support. If the company goes out of business or changes its policies, you may be left with no support or access to your data.

Creating communities on social media sites like Facebook or LinkedIn also has its drawbacks:

1. Lack of ownership: With social media sites, you do not own your data or the community that you have built. The social media platform owns the data and can use it for their own purposes, or even delete it if they see fit.
2. Limited control: Social media sites have their own rules and policies that you must follow, and you do not have much control over how your community is managed. This can be frustrating if you want to create a community with a specific focus or purpose.
3. Lack of privacy: Social media sites are known for their lack of privacy, and it can be difficult to ensure that your community members' data is not being shared with third parties without their consent. This can be a major concern for those who value their privacy.

The UNA platform offers several benefits, including:

1. High configurability: The UNA Studio configuration system allows users to easily make updates and customize the platform to meet their specific needs.
2. High scalability: UNA is a scalable platform that can handle large amounts of traffic and data. There are no limits on number of members or technical constrains of backend infrastructure you can deploy.
3. Mobile-friendly responsive UI: UNA has a mobile-friendly responsive user interface that provides a seamless user experience across all devices.
4. Over 100 native modules: UNA comes with over 100 native modules that allow users to add functionality to their social network and hundreds more available from UNA Market.

In addition to these benefits, UNA also has strong community support and has been actively developed for over 20 years. The dedicated UNA development team is constantly working to improve the platform and add new features.

And most importantly - UNA is constantly evolving and we can help your to implement it in a way that suits your idea perfectly.

UNA team is part of the Yasko Studio community development agency, offering tailored implementation and development services with over 100 successful custom projects launched.

Reach out to us via team@una.io to discuss your idea.

"Given everything we know about two of math’s most famous constants, 𝜋 and e, it’s a bit surprising how lost we are when they’re added together."

Yeah... I feel the same about CSS layouts sometimes. 🤨

You'd think that since we've been browsing the web on screens of all sizes for decades now the challenge of responsive layouts would have been solved ages ago. Instead, what we've got is a range of "solutions" that work for some cases and fail miserably for others. Often the simplest task becomes a mix of rational and transcendental considerations, just like the afore-quoted mystery of 𝜋+e, a mind-boggling juggle of numerous "what ifs". In most cases UI developers just give up and fall back on constraints, calling their solution "opinionated", which in this case really means "sorry, couldn't figure it out, so this will do".

That's OK for a website, or an app, but it's not OK for a framework like UNA where containers customisation and responsive layout is the lex terrae. We have to wrestle with it until we win, or die trying. Let me explain...

The Goal

We need to be able to position content cards vertically or horizontally, depending on the width of the parent container. In UNA these may be, say, Posts or People or Groups cards used on main browsing pages. Like so...

Simple, right? If you are familiar with CSS you probably already have a few ideas, hoping for quick and easy solution. Now let's kill those hopes and ideas one by one.

The @media Queries // useless

Parent container has nothing to do with browser viewport. It's not just about desktop vs mobile. While on mobile phone viewport is usually small enough to always default to single-column layout, on other devices we may have more than one "cell". Layouts can have 2-3-4 columns and it may be rearranging between tablet to large desktop viewports. Layouts may have different column size combinations, like the "holy grail" layout with narrow sidebar, wide content area and medium-sized aside on the right.

When you place cards in any of those layout cells the available width may be more like mobile viewport, even though you're opening the page on a large desktop browser. In other words - context is variable and viewport is not the context. This rules out @media queries.

In a very controlled environment when the developer knows exactly what will be the width of the block within each @media breakpoint it may be possible pull it off, but UNA Pages builder allows placing any block into any cell regardless of it's size. The content of the block has to be responsive in context to the width of the cell, not viewport.

NB: @media is not totally useless, of course. We need it for components that are instantiated in context to the viewport, like headers, footers and modals.

Flexbox Wrapping and Growing // and failing

Flex is so cool. It really is. It's everywhere now, and for good reason. You can flex-wrap your cards to stack them into neat rows and flex-grow them to adjust sizes, filling the parent container evenly. You can give your cards min-width to let flex box know when to switch to single column, or how many columns to "add". Gaps are nicely controlled with the gap property. Amazing!

So good in fact, that if your cards were of the same fixed width you're golden. Or, if they were responsive and the multiple of rows and columns perfectly matches the number of cards you have to show. Got 6 cards to show? Looks great with 2 rows of 3 cards, wraps nicely to 3 rows of 2 cards in a smaller container, then comes down to one beautiful column when space gets really tight.

Now, what if our server gave us just 5 cards... oh snap!

What's with those two giant cards? Are they more important than others? Ah, right... flex is growing them too much, and if we want to maintain aspect ratio of any media inside them - it'll be growing waaaay too much.

Maybe we can set max-width to each card? That may make things even worse, because you want to allow smaller cards to grow somewhat to fill the container evenly between switching columns. In the end your last few cards would still grow, just maybe not all the way, so you'd have an even uglier mismatch.

In UNA we can set the number of cards to display on each page and paginate the rest, but sometimes your server simply doesn't have enough content to fit the idea. You can set the count to, say, 12 per page and never show more than 4 cards per row (you need to show at least 60 if you want to show 5 or 6 cards per row), but if you have only, say, 10 Featured Articles or 9 Online People the ugly giants would pop up. So, no... it's an L.

JavaScript - ResizeObserver // it's complicated

Now this one is actually pretty good. Read ResizeObserver: it’s like document.onresize for elements or Quick guide to Resize Observer to get an idea of what it does. It's possible to set breakpoints and to watch the element size independent of the viewport. The problem is that it's in JavaScript, not CSS, which means that there are some significant issues:

• Cross-origin limitations: If you're observing an element that's in a different origin (i.e., a different domain, port, or protocol) from your JavaScript code, ResizeObserver may fail due to cross-origin security restrictions.
• Timing issues: If you try to observe an element before it has been added to the DOM, ResizeObserver may fail. Similarly, if you try to observe an element after it has been removed from the DOM, it may also fail.
• Element visibility: If you're observing an element that's not visible (i.e., has a display of "none"), ResizeObserver will not work.
• CSS styles: If an element's size is being controlled by a CSS stylesheet, changes to the stylesheet may not trigger a ResizeObserver callback.

There is more! Now that we are building ReactJS apps for UNA, using NextJS, we need to consider:

• Server-side rendering: Since Next.js performs server-side rendering, the JavaScript that runs on the server may not have access to the ResizeObserver API, causing it to fail. To work around this, we have to use ResizeObserver on the client side.
• Re-rendering: In React, whenever a component re-renders, it unmounts and then remounts, causing the ResizeObserver to stop observing and then start observing again. This can result in the ResizeObserver callback being called multiple times. So, we need to use a stateful component or a state management library, such as Redux or MobX, to ensure that the ResizeObserver only runs once.
• Virtual DOM: React uses a virtual DOM to update the actual DOM. As a result, changes to an element's size may not be immediately reflected in the virtual DOM, causing the ResizeObserver callback to be delayed or not run at all. So, gotta add a useEffect hook to manually update the virtual DOM after the ResizeObserver callback has run.

Enough? Not enough? Let's do more... There are some absolute limitations of ResizeObserver when it comes to using it for responsive layouts:

• Only element size: ResizeObserver can only detect changes to an element's size. It cannot detect changes to other layout-related properties, such as the position or visibility of an element. This means that if you need to respond to changes in these properties, you'll need to use other APIs or techniques.
• Performance overhead: Observing changes to an element's size using ResizeObserver can have a performance impact, especially if you're observing many elements at once (which we do, big time). This is because ResizeObserver runs a layout calculation for each observed element, which can be expensive.
• Potential for missed updates: ResizeObserver updates asynchronously - there's a small window of time between when an element's size changes and when the ResizeObserver callback is called. This means that there's a possibility that the ResizeObserver callback could miss an update if it's executed too quickly.

You get the point. There must be an easier way.

Container Queries //so close, but not there yet

CSS container queries allow you to apply styles based on the size of a containing element, rather than the size of the viewport. The idea behind container queries is to make it easier to create more flexible and modular layouts, especially in responsive design. That's right, our problem is acknowledge and the solution has been built, but container queries require the browser to perform layout calculations for each and every element on the page, rather than just the viewport. This can quickly become a performance bottleneck, especially for complex pages with many elements.

So, we need to use container queries sparingly, at least until all browsers learn how to deal with them efficiently. But we can user them, right!? Right!? Well, not always. 🤷‍♂️ There is one annoying issue with container queries that we found. It's not documented and is hardly discussed, perhaps because container queries are still relatively new.

The problem is with position:fixed for anything within the @container. Turns out that when you apply @container property to parent element, all its children will treat it as a viewport. That makes some sense, but still is very unfortunate.

In situations when you need to show a modal, or a fixed nav-bar, or a sticky form field that comes from the same element that you styled with @container there is no way to "opt out". Sometimes you can work around it, and sometimes it's a dealbreaker.

Let's Complicate The Problem //we need more pain

Before getting to the solution, let's strong-arm the problem a bit. In UNA we need to do a bit more than children elements positioning based parent size. We also need to change styles (such as margins, paddings, corner radius) of the children elements themselves, as well as change the layout of the content within them. 🤯

For example, a card may need no margins and no rounded corners on mobile viewport inside narrow parent, but still have margins and rounded corners on desktop viewport within narrow parent. We should be able to use the (not so useless anymore) @media queries, of course. Still, it's worth mentioning that making adjustments based only on parent container size may not be enough in some cases.

Furthermore, when we switch breakpoints we sometimes need to reposition elements inside of the child element. For example...

Flex-col on mobile, flex-row when it's inside a wide parent on desktop, flex-col again when it's inside of narrow parent on desktop.

🚀 The Flexbox Holy Albatross Reincarnated

Ultimately the solution for us is based on the ingenious Flexbox trick, known as The Flexbox Holy Albatross - the "reincarnated" version, discovered by Heydon Pickering. 

The Flexbox Holy Albatross technique is a way of using flexbox to create equal height columns that are adaptable to different screen sizes. This technique involves nesting a flex container within another flex container, where the inner container has a flex direction of column and the outer container has a flex direction of row. By doing this, the columns will automatically take up equal height within the row, regardless of their content.

Additionally, the technique is useful for manipulating containers based on the size of the parent container, rather than relying on @container queries or @media queries. By changing the flex direction of the outer container, it's possible to switch between a row of columns and a column of rows at different breakpoints, while still maintaining the same width for each column. This ensures that the columns remain equal in height even when wrapped onto a new row.

Here is the playground link of the DEMO implementation

This approach is a perfect fit for UNA, where page layouts include various cell sizes and adapt responsively to various viewports. Operators can place blocks into any cells, so all blocks need to look good no matter where they show up. More of this approach will manifest in future updates!

The next challenge is to implement it as part of ReactNative apps and NextJS web app universally. Stay tuned!

In UNA 13.1 we are focusing on improving general user experience, server performance and expanding UNA core API for the upcoming release of the new React/ReactNative frontend app.

System Enhancements:

• Extended core and module API - #4148

The API is extended significantly, providing new endpoints to securely share date with external apps. Over 250 commits dedicated to the API alone, covering everything from core settings, authentication and modules to design, navigation and languages.

• PUSH/Sockets server integration #4369

The new WebSockets server based on https://soketi.app providing highly performant (under 100ms) message delivery for web socket events. For example in UNA+NEO pairing we use it to update reaction counts in the feed without reloading the page or polling the server. In the Messenger we use it to exchange messages at scale.

• Service worker & site manifest file settings #4480

Improved site manifest and caching mechanism enabling shipping UNA as a Progressive Web App.

• Icons for info fields in profile #4389

Support for customisable icons for profile info fields.

• Connections page #4365

The new Connections section with Friends Suggestions, Friends, Friend Requests, Requested Friendship, Who to follow, Followers and Following pages. Actions in cards for each section adapted to the context of the page.

• Comments: partially hide long comments #4471
• Counters in connection menu items #4550
• New setting: to change number of results in profiles search auto-suggestion #4537
• New setting: viewport metatag value setting in Developer module #4383
• New setting: number of results count in Live search #4359
• Meta title in Pages builder separately from page heading #4548
• Custom placeholder text for empty blocks instead of the default 'Empty' string #4370
• Custom cover title #4407
• “Updates” tab in Apps Market in Studio now requires authorization #4464
• Developer debug mode in header.inc.php #4544
• Forms: check for unsubmitted data before leaving the page #4442 #4518
• New placeholder images for different file types #4398
• Quill editor: clear copy&pasted content from HTML #4349
• member.php (and other pages with login form) now using "/login" page layout #4381
• ACL: Use lang key for Price field #4347
• New UNA badge in bottom menu #4379
• Removed '#dpr' from URL when site is initially loaded on retina screen #4382
• Menus: Allow to filter out items depending on context #4340
• Iframely API #4335

Modules Enhancements:

• Accounts: export account language #4552
• Timeline: New 'Copy to clipboard' item in share menu #4536
• Timeline: labels field support #4469
• Timeline: block form submit while media is uploading #4447
• Timeline: show content with specific media types (audio, video, photo) #4422
• Timeline: allow to change visibility while editing timeline update #4411
• Timeline: new 'For you' feed with mixed Account + Hot feed content #4384
• Timeline: performance optimization #4367
• Market: Separate pages for each category #4492
• Notifications: default notification lifetime set ti 3 months with daily pruning #4541
• Notifications: subjects of email notifications are more descriptive now #4432
• Groups & Events: "Followed" page #4488
• Invitations: various enhancements #4543
• Tasks: profile icons in tasks list #4463
• Developer: Export/import for builders and settings states #4515

📦 The 31.1 package, update script, cumulative update script and the Spacenook Starter Kit are available for download at https://github.com/unaio/una/releases/tag/13.1.0