Fancy url instead of /86

eric redegeld Posted in Component Development 11 months ago

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

Replies
Indonesian Arsalan Shah Replied 6 months ago

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.

German Markus Weber Replied 6 months ago

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.

Dutch Eric redegeld Replied 10 months ago

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.

Dutch Eric redegeld Replied 10 months ago

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

German Michael Zülsdorff Replied 10 months ago

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.

Dutch Eric redegeld Replied 10 months ago

update so far
https://github.com/compie67/ossn-GroupSlugRouter

before adding my enable i am no testing it all good

Dutch Eric redegeld Replied 10 months ago

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,

German Michael Zülsdorff Replied 10 months ago

Hmm ... can you explain why you were adding that extra database query?

return ossn_get_group_by_guid($groups[0]->owner_guid);
Dutch Eric redegeld Replied 10 months ago

found, and thank you. just add the credit in the code.
It works and i am now firmly testing it

German Michael Zülsdorff Replied 10 months ago

Eh sorry ?!? What more can I do than publishing my changes at https://github.com/compie67/ossn-GroupSlugRouter