NickH
Khoros Alumni (Retired)
Joined 8 years ago
User Profile
User Widgets
Contributions
Re: Khoros Communities: Aurora 25.02 Release Notes
The primary goal of making the search page a configurable template is to enable communities to integrate third-party systems by passing search queries and filters to external sites or applications. With support for custom endpoints and React components, the search page can display results from one or more integrated sources, making it a flexible hub for cross-platform search experiences. sloth2073 wrote: Move Places above Users. (This is still puzzling to me. Wouldn't 99% of search be about finding content or the right place, rather then another user. Only use case I can see is moderation staff) We agree and missed this change in the default template. We will plan to change the default order of these components. sloth2073 wrote: Modify filters available or change order of filters Because the filters are part of the search query, these wouldn't be moved into their own widget separate from the query box, however we can add additional configurability for the search query filters to support enabling, ordering, or even something like a sidebar view in the future. sloth2073 wrote: Pre-set constrain/location (e.g. if I have a community with 9 locales, I want the Global Search to be preset to only search in my current language top-category, not all of them). I get that this is phase 1 of this page template, but why even include it in the release notes, when we seemingly can't do anything useful with it yet? We have this story filed and work is starting on it soon. The plan will be to adjust the scope of search to the top level category when you are in a top level category.Re: Driving Growth in Community with Banners & Content Gates
Custom tags are supported in Aurora but called custom fields. They are implemented for users, nodes, and discussions and we’re working this quarter to finish them for kb,blog,ideas, events. Custom fields are part of the native graphql APIs so they are easy to set when creating objects without custom endpoints and to query / filter messsge lists or users by. We’ve also fully incorporated them into firehose event feeds and they will be part of the upcoming automaton rules and role assignment in registration.Re: Driving Growth in Community with Banners & Content Gates
Most recent mimicks an activity stream where discussions with new active replies or solutions will bump back up to the top. Generally it’s good for discussion boards where there is often more value in the replies / discussion than in the root post. For kb and blog boards - unless you are really trying to drive collaboration and 2 way dialog, it likely makes sense to use newest topics - or now KB chapters as a way to browse and organize, maybe relegating the recent content list to the sidebar titled recent activity or recent comments. Ultimately all the options should be there or configure different boards for their use cases based on volume, activity, etc.Re: Using LiQL or SQL on Aurora instead of GraphQL?
SheenaK see my response above, if you developers want to send over their query I'd be happy to review it. There wouldn't be any way for them to be making direct SQL queries against our database, so they are most likely making LiQL queries from the java class. If it's a liQL query its also very likely they are communicating over HTTP requests. GraphQL is a more industry standardized query language than LiQL, which is specific to Lithium Classic communities, both of which are wrapped around REST / HTTP queries to execute. Let me know if I can help review what is in use today and advise on mapping it over when the time is right (assuming the existing LiQL calls are working fine for now).Re: Using LiQL or SQL on Aurora instead of GraphQL?
I'm 99% sure they are using LiQL as we don't allow direct SQL queries even from Java in the application. LiQL looks deceptively like SQL even to the point of security teams raising concerns about direct SQL queries which should not be allowed that ended up being LiQL. LiQL was created as a Lithium query language used to make it easier to query specific data fields from a REST endpoint. It was modeled after SQL queries but wrapped and limited queries to safe query parameters. GraphQL is a more industry standardized API query language rather than a proprietary Lithium capability. GraphQL queries are still passed through typical HTTP requests and are basically wrapped REST API calls not all that different than anyone using REST/LiQL. In your case, it sounds like the query is being made from a Java class. I assume this is a Java class you own and I assume it runs outside of the community application, so it should still be able to leverage LiQL for the time being and graphql in the future with minimal effort to update the query.Re: Using LiQL or SQL on Aurora instead of GraphQL?
The other thing to check with be how they are authenticating. Most likley they are doing a proper auth flow, but classic also allowed the session id cookie to be used for API auth which was not recommended but possible in older instances of classic. To further protect the API and data, Aurora does not allow this to be used to authenticate APIs requests.Re: Atlas displays too large on mobile at first
We were using an svg for the Atlas header that did not have width or height properties, resulting in the initial load being off until you zoomed to trigger a responsive refresh. We are uploading a new svg with the right parameters and that should fix the issue. We are also adding validation in the Theme tool to reject SVG logos that don't have proper width and height properties. Please let me know if this doesn't fix your initial mobile view.Re: Using LiQL or SQL on Aurora instead of GraphQL?
Aurora still supports the legacy REST APIs, although the url path needs to be updated to append /t5/s to hit those legacy REST endpoints. I assume your developers aren't directly using LiQL or SQL rather that they are using REST endpoints where they pass LiQL to execute a query and get a response. While the REST APIs are still available today with that URL change, they will be deprecated in a future release with plenty of prior notice given. GraphQL is a query language but it still works through basic HTTP commands (post), the difference is you are passing along GraphQL queries in the request, often to a single endpoint, to request exactly the data you want returned. It's a more standardize structure to our proprietary LiQL queries. Outside of some helper libraries that making caching and state management easier, if any 3rd party app is making REST API calls, the transition to GraphQL API can use similar web/http requests. This can be experimented with basic web tools like Postman or even javascript fetch commands, curl etc.Re: Aurora: Text/HTML widget configuration
If you want to create a list of recommended documents you could look at using the featured content widget which can be configured per node. You'd simply add the featured content widget to the template, and then each node admin could edit the list and control their own list of recommended documents. We had a similar idea for the HTML widget, right now we only support static HTML widgets, but we have a concept where you could place an empty html widget on the template and allow each group owner / node owner to edit the HTML themselves. They couldn't change the template or where the widget appears but they could have control to edit the text for group specific announcements, etc. This could kind of be done today using node specific page templates but that would be burdonsome to do for each and every place, which is why this dynamic html widget idea was introduced. The featured content and places widget works this way today. We still need to develop the dynamic HTML option.
