My site is growing and so also the user wishes.
one main is the returned question about the lak off Fancy url.
now we got this
https://nlsociaal.nl/group/1180/
but is look nicer with this https://nlsociaal.nl/group/Prive_groep_voorbeeld
long time ago there was an thread about groups, but still no solution.
for the Group, forum and business pages would this be an great solution.
Meta eat your hart out
Markus , profiles already have /u/ for groups you can use https://www.opensource-socialnetwork.org/component/view/7564/groupusername or Eric component anything you prefer.
Hi all,
we’ve been experimenting a bit with vanity URLs in OSSN and wanted to share some notes from our testing. We’re still quite new to OSSN, so this is more of a learning log than a finished solution.
One thing we found is that generating the slug right at the moment of group creation is easier to manage. If you try to recalculate or update slugs later, there’s always the risk of breaking old links or causing duplicate entries. Having it stored once and used consistently avoids a lot of that confusion.
Another point is character handling. While OSSN itself can handle UTF-8, we noticed that browsers and especially external services (like when people share links on social media) sometimes don’t deal well with special characters, umlauts, or spaces. So it feels safer to normalize everything down to simple ASCII-friendly slugs.
On the performance side, we tried both direct DB alterations and just adding a metadata field. Honestly, the cleanest solution seems to be adding a field that stores the slug, and then handling routing via a hook. That way you don’t mess with the OSSN core too much and can still keep things update-safe.
From a user perspective, vanity URLs feel more trustworthy. When you send someone a link that looks like /group/music or /g/myproject, it simply looks more professional than /group/1180. It’s also easier to remember, which makes sense if you want communities to grow more organically.
We also discussed the SEO angle a bit. While OSSN isn’t primarily a CMS for search engines, having clearer URLs might help if you’re running a public-facing community. Search engines tend to reward descriptive slugs, and even for internal use it makes analytics and reporting a bit nicer. Example
Still figuring things out, but overall vanity URLs feel like one of those small details that can have a big impact on usability and perception. If anyone has more technical insight or has already implemented this in production, we’d love to hear about your experience too.
Update!!! I have revoked my module User group and merged it with this module. It works. Next to making slugs it generates user group overview with Vanity url.
okay. thank Michael, great feedback and support.
Now in action for stress test https://shadow.nlsociaal.nl/u/admin/groups
i merged my module UserGroups with the Slug one.
That workers better
The extra query using ossngetgroupbyguid($groups[0]->ownerguid) is necessary because ossngetentities() returns a generic entity object, not an actual OssnGroup object. Although the entity has the correct ownerguid, it lacks all group-specific methods and properties (like $group->title, $group->description, etc.).
Yeah, basically not wrong, but hey
all you want is redirecting to /group/some group guid
so the only part of interest is in fact just the group's guid (stored as entities owner_guid) and not the complete group object. The entire group object will be fetched AFTER the redirection by OssnGroups default routines anyway and automatically. That's why your extra query makes no sense at all and is just swallowing server resources.
Maybe it's worth to mention, that ALL entities of a specific group will be deleted AUTOMATICALLY when the group get's deleted. Thus, even more it makes no sense to make your code do an extra check if that group still exists. You can rely on: No group = no group entities.
update so far
https://github.com/compie67/ossn-GroupSlugRouter
before adding my enable i am no testing it all good
just look int t this with my coworker(also friend)
The extra query using ossn_get_group_by_guid($groups[0]->owner_guid) is necessary because ossn_get_entities() returns a generic entity object, not an actual OssnGroup object. Although the entity has the correct owner_guid, it lacks all group-specific methods and properties (like $group->title, $group->description, etc.).
By explicitly fetching the group again via ossn_get_group_by_guid(), we ensure the result is a full OssnGroup object, suitable for redirection and display in OSSN.
As we speak now making first activation for old existing groups,
Hmm ... can you explain why you were adding that extra database query?
return ossn_get_group_by_guid($groups[0]->owner_guid);
found, and thank you. just add the credit in the code.
It works and i am now firmly testing it
Eh sorry ?!? What more can I do than publishing my changes at https://github.com/compie67/ossn-GroupSlugRouter
Due to the many requests in the past for additonal features and components we have decided to develope a premium version. Features like Hashtags, Videos, Polls, Events, Stories, Link Preview, etc included in it.
$199 (Life Time)