The id cannot be removed because it is an identifier to these items. However, we do have an url shortener plugin which can help you remove the id but this is only for profile urls only.

There is a reason behind not removing the id from the permalink and one of the biggest issue for not removing the id is performance issues. Without an id, the system needs to fire additional queries to obtain the id of the item

Hi Mark -

Please know first and foremost I respect your work and rationale here (especially as a somewhat reformed former database guy), however may i please respectfully disagree? this isn't meant to be argumentative in any way, just a general open discussion here

I always (at least try) to keep comments like this to fully respect that not every customer wish is in the best interest of the product itself globally for all users (heh, that's what paid-for customizations are for, right?!), or even from a reasonable development-to-production standpoint, but I think this issue (IDs showing in URLs) is beyond any mere cosmetic or customer wish-list type stuff.

You might wanna pour a big pot of coffee for this one, I have a bit to say on it ...

TL;DR

• Security.
  
• Indiscernible Performance hits.
  
• Everyone else is doing it!
  

The War & Peace Novella over URL ID Wrangling:


1. Exposed User IDs: Joomla begin purposely randomizing the default Super User ID back in v2.5 (methinks... it was certainly randomized by 3.1); this was strategically done to alleviate nefarious characters (and machines!) on the interwebs from already knowing exactly what the ID was for your site's Super User. I certainly don't claim to be a security expert so I have no clue what could actually be done with this information (outside of having the single most important identifier of Joomla's SU), but I'm pretty certain joomla's move here was legitimately strategic and singularly focused on overall, total security. Right now, EasySocial shows to the global Internet your site's Super User ID, Administrator's ID and every other User on the site's ID. ALL Users IDs are being exposed. Again, I don't know that this ultimately is a major security problem without some super-aggressive algorithms running a password-cracker, and I certainly don't mind being educated on this otherwise, but my uber-paranoid security-first mindset has red flags going off all over the place for me on the issue of IDs showing, over any other point being made, but since there are some...

2. Performance vs Return: I absolutely commend SI on their work and predisposition on performance load with your entire product suite - it is certainly one of the more attractive parts of deciding to purchase it as all of us are working for ways to "lighten-the-load" on our sites. There is always a balancing act here deciding on performance vs "fill-in-the-blank" that all of us have to consider: from the developers, to the customers/site-administrators right down to the ultimate benefactor, the site's end-users. Given what I know about you guys, SI is smart, thorough and highly knowledgeable about the intricacies of their products; I'd be willing to bet you even have some quality metrics on the performance hits related to additional ID queries here (i was totally blown away at the depth of analytics you had recently related for performance on the upcoming Komento 3.0 product - great stuff man!!). My balancing comment here is that I professionally sit in the very hot seated intersection of balancing developer implementation and what users actually require (devops, if you will) - production level environments that deliver real-world results are ultimately all that matters. From a performance perspective it is "technically" indisputable on the extra query calls, but in practical user experience (at least in our early experience), we notice no real gain on performance on IDs vs no-IDs in a URL. Again, I actually appreciate the learning process here so please coach me differently, but we do not see any discernible performance-related issues especially when directly comared with our other joomla components that do not expose IDs in urls, which brings me to...

3. The Other Kids Are Doing It: Simply put, other Joomla Components are OoB with clean SEF URLs. Joomla leaves url rendering up to the individual 3rd Party Component's own internal router. In our own experience, IDs in URLs is something we've haven't really seen out of our other joomla components for a good 3 years now (i'm not talking about the entire joomla marketplace, just the ones we are using here for our sites routinely). If you don't mind me using another component as a point of reference (yes, I DO know that components are written differently from a programming perspective and typically make for an "apples-to-oranges" comparison), but I think JReviews provides a decent example here: JReviews strategically removed all IDs from their URLs back in 2013. I think the underlying point here isn't "how" they did this (getting into a default conversation about languages etc. that platforms are written on), but instead "why" they delivered this. IMHO, this has just become standard best-practice now for "out of box" clean urls - we haven't used any component in several years now where we had to use yet another component (talk about load/performance hits!) to rewrite the URLs cleanly. My main point here is that I don't see other component's opting to leave URLs "dirty" with IDs over "performance hits" - using JReviews again, "speed and performance" are still one of their hallmarks and primary advantage over their competitors in the market, all without leaving any unnecessary IDs in their URLs.

4. Poorly Managed Expectations?!: The silly-customer/end-user, totally cosmetic argument: cmon, admit! It just looks better every minute of the day not only to see, but to share on social networks:

/my-community-profile/jjohnson/my-article-has-clean-urls
vs.
/my-community-profile/72-jjohnson/4-my-article-has-dirty-urls

* End-All, Be-All: What I sure as heck don't wanna see, is:
/my-community-profile/69-thisismysuperuseridforanyonetodobadstuffwith

Hoping this all just to be taken purely as an open conversation (and not as any outright objection). I am genuinely interested in hearing SI's full take on this issue and not simply as a "technical-intellectual" exercise - gaining your knowledge and perspective is highly beneficial to us so that we ultimately make the best business decisions and align a semblance of best-practices that we all are working towards. At the end of the day, it is in ALL our best interests to make SI's products the predominant market leader that we know it can be!

Thx for all that you guys do, Mark/SI - it's very much appreciated.

* i think i might need a nap...

Thanks for your insights on this John, here's our side to your

1. Exposed User IDs: Joomla begin purposely randomizing the default Super User ID back in v2.5 (methinks... it was certainly ...

Exposing the id doesn't pose a security risk. Why? You are already exposing the person's name when you view the person's profile. If a hacker want's to identify a record from the database, hiding the id would not help.

The ideal way is to hide admin's from appearing from listings and this is also why we have the ability (in the settings) to exclude admin's from appearing in EasySocial.

2. Performance vs Return: I absolutely commend SI on their work and predisposition on performance load with your entire product...

There is only so much that you can see on the front end when you use the extension but adding additional queries adds more load time to the page. You might not see the difference but as your user base grows, you will feel the pinch. I will just give you a simple breakdown of what goes behind the scenes when an id is removed from the permalink,

1. The router needs to first check if there is an id in the permalink
2. If it doesn't have an id, and the user did not set a permalink, it will then query the server to check if it uses real name / user name for the permalink
3. We need to break down the query string and start checking segment by segment. For instance, if EasySocial is configured to use username as permalink and assuming that the username is "hello my name is_test"

- The resulting url would be hello-my-name-is-test
- When we need to restore this to the correct username, there is no way to know when these special characters are used.
- In order to parse it, you need to try with all possibilities to query the database
- The script will then check against the following possible values:
- hello my name is test
- hello-my-name-is-test
- hello_my_name_is_test
- hello my-name is test
and so on...
- The query above, needs to guess all possible username value

4. You might not see how does impact your view of the page but we can see it hogging up resources when you have more users.

3. The Other Kids Are Doing It: Simply put, other Joomla Components are OoB with clean SEF URLs. Joomla leaves url rendering up

If you are taking JReviews into this context, I think you need to look at the bigger picture. You can't compare JReviews with EasySocial because EasySocial is a social network while JReviews is a listing / review system. In EasySocial we are rendering stream items with very complex privacy rules. Having said that, take a look at the comparison on both pages:

http://take.ms/spdgf
http://take.ms/GKEq9

4. Poorly Managed Expectations?!: The silly-customer/end-user, totally cosmetic argument: cmon, admit! It just looks better every minute of the day not only to see, but to share on social networks:

Exactly and this is why we still allow these flexibility should you decide to sacrifice a little of your server's performance. If you prefer more beautiful urls against performance, you could always opt to get the URL shortener plugin. We are leaving these decisions on your hand should you need it. But at least by default, EasySocial is much optimized out of the box

Thx, Mark -

Let me just firstly say that using permalinks is definitely something we are considering, just haven't wrapped our heads around a best-practice with it yet (aligning with Registration process + allowed user settings as well).

On the point by point comparison:

1) I do realize that ID, username, etc. are all usable pieces to a puzzle for any brute force effort but the only unique identifier is always that User ID. I'd rather not just throw up in there. To me all we are doing here in deciding to opt certain members of our network "out" of the activity stream so their details aren't being shown is a workaround instead of a solution. I think we are probably just going to agree to disagree on this one but for me? I don't want any user's ID exposed, but I admit i'm aggressively paranoid over security (and am probably insecure as heck on sites without knowing how or why, so there's that too!).

2) I'm an old database guy so I totally get the performance drain on the backend (and certainly as one's user-base begins to grow). I think more is being made of performance over some IDs in urls than is meaningful (but that's also a gut-feel and not based in any sound-science), but one thing that really stands out to me about SI is your being keen on performance so I will concede this one directly. Heck, I can only hope right now that the current project we are working on has such problems to begin with (an amass of users hogging resources and causing performance latency).

3) I likely didn't make this clear enough but I wasn't trying to make a direct compare between a listing component to a social networking one (indicating already that was an "apples-to-oranges" comparison) - i was more pointing out that IDs can be and have been removed, so much so that until now i'd started accepting it as almost a foregone. I'm coming to the SI suite from being an Easy Profile user for a brief minute - which is also a Social Network. EasySocial is far superior to Easy Profile in nearly every way (my own opinion, I don't like bashing anyone's products... unless maybe it's google's haha!), but... there were no IDs in their URLs. Community Builder's router also translates Joomla userID into username on urls (haven't used jomsocial since 2012 so not sure).

4) At the end of the day a part of this is being accustomed to having clean urls on our sites for a few years now. This is all splitting hairs now at this point so will try and concentrate more on working solutions.

Thx for this feedback, etc. - like i said it is actually quite useful for me to know and understand what the limitations are, advantages and all else so as to best make business decisions on our sites and developing best-practices.

** Hmmmm very interesting, looking into this URL shortener plugin now - does the shortener work globally across ES+EB+ED? (i.e., I want something to remove all IDs globally, not just in easy social)

Thanks for your insights on this John. The URL Shortener plugin only shortens urls for profile and it doesn't shorten anything else.

For EasyBlog, and EasyDiscuss you could turn off the id in the permalink. You just need to disable the option for unicode urls. When unicode urls are used, we need to have the id in the query string.

omg OK, darn... our current project utilizes unicode heavily (it's kindof an underlying premise). I promise i'm really not trying to nitpick this issue to death here but our other components also don't have any issues with unicode "on" and removing IDs in urls...

- we've got a really big decision here now i guess and... i dunno... for our Blog piece in particular (not to lessen the issue imo globally) we are trying to compete for market share with some heavy hitters that all have uber clean, professional looking urls.

I respect your work; thx, Mark

1. The router needs to first check if there is an id in the permalink
2. If it doesn't have an id, and the user did not set a permalink, it will then query the server to check if it uses real name / user name for the permalink
3. We need to break down the query string and start checking segment by segment. For instance, if EasySocial is configured to use username as permalink and assuming that the username is "hello my name is_test"

- The resulting url would be hello-my-name-is-test
- When we need to restore this to the correct username, there is no way to know when these special characters are used.
- In order to parse it, you need to try with all possibilities to query the database
- The script will then check against the following possible values:
- hello my name is test
- hello-my-name-is-test
- hello_my_name_is_test
- hello my-name is test
and so on...
- The query above, needs to guess all possible username value

A few important points I'd like to bring light to:

ES 1.4 used the table #__social_users and utilized the alias column for the simple URL. PHP/JS validation would cover the integrity of the alias. If the plugin went this route (checking for the alias column from #__social_users), we could bypass step 3 (query the database of all possibilities for the username). If we simply accessed the alias we would not need to do this for id-less URLs. I tested both ES 1.4 and ES 2.0 while typing this to confirm that ES still adds data to the alias column.

Regarding the entire component of ES ids:
Joomla 3.7 will be getting a new router system that will be id-less (expected March of 2017). Developers of course can optionally use the old one. Supposedly Joomla 4 will have the new router faster without ids than the current router. So eventually if all goes well perhaps then we could consider going without the IDs if it doesn't hurt the performance.

ES 1.4 used the table #__social_users and utilized the alias column for the simple URL. PHP/JS validation would cover the integrity of the alias. If the plugin went this route (checking for the alias column from #__social_users), we could bypass step 3 (query the database of all possibilities for the username). If we simply accessed the alias we would not need to do this for id-less URLs. I tested both ES 1.4 and ES 2.0 while typing this to confirm that ES still adds data to the alias column.

This is under the assumption that all users have set a permalink (alias). Not everyone made this a compulsory field

Joomla 3.7 will be getting a new router system that will be id-less (expected March of 2017). Developers of course can optionally use the old one. Supposedly Joomla 4 will have the new router faster without ids than the current router. So eventually if all goes well perhaps then we could consider going without the IDs if it doesn't hurt the performance.

If Joomla improves their performance of routing, I am sure we'll definitely lean towards id-less permalinks

This is under the assumption that all users have set a permalink (alias). Not everyone made this a compulsory field

As of ES 2.0.6 it records to the alias column regardless to a permalink. In other words the new user has no permalink but does have a record in the alias column. This means that if no permalink exists, the alias can work as the fallback. hence forgoing the need for doing all those scenario based queries. I suggest making the plugin use the alias column.

I recall users created before ES 1.3 (or something like that) did not get populated in the alias column. So to prevent issues from long term supporters there could be a maintenance script that loads missing alias's to users who do not yet have a record in the alias field. I think this would make the routing of site/username take a much smaller hit on performance. Having it as a plugin in this scenario still makes a lot of sense due to support.

If Joomla improves their performance of routing, I am sure we'll definitely lean towards id-less permalinks

J3.7's router might have roughly the same performance, however J4.0 supposedly will be better. I was mostly aiming at things like groups, photos, videos, apps, ect when things are at their prime for Joomla with the new router. Notification/Private message IDs however will still make a lot of sense keeping those as standard IDs.

The alias field was only introduced midway of 1.3 - 1.4 I believe. We cannot assume that all site already has these values.

The alias field was only introduced midway of 1.3 - 1.4 I believe. We cannot assume that all site already has these values.

Indeed. More specifically we cannot assume all users have this. Users created before ES 1.3 typically don't have an alias. So what I'm proposing is a little script to execute (similar to the maintenance scripts that get included in the Maintenance section) that creates an alias for all users missing the alias data. This would ensure that all users have an alias from the already existing column. New users already get an alias, hence everyone would have one.

There are a lot of other things to consider rather than just writing a script to fill this column

Not to be unnecessarily backtracking upwards into this thread but just for the edification of others that have somehow gotten thru this diatribe/might also be heading down this same-to-similar path

[*] Permalinks as a Required Field: that is the route we've taken right now in trying to eradicate ES UserIDs from being public-facing, making the permalink a required/compulsory field used in conjunction with SI's nice URL Shortener Plugin (although as Josh points out, without a permalink it defaults nicely to username alias), however:
[*] just note that in spite of the quite excellent results (e.g. /sitename/permalink) you will still have userids exposed in urls all-elsewhere - any other links to a user's profile (from modules, etc) will still result in exposing the userID (/sitename/69-username)

* one other random point here is something i didn't bother getting into earlier: in some prior projects we've used exposed UserIDs to spy/scope on a competitor's userbase size - i won't articulate how useful that info was in that given market's nature from a competitive business advantage but, " 'Tis"...

[*] just note that in spite of the quite excellent results (e.g. /sitename/permalink) you will still have userids exposed in urls all-elsewhere - any other links to a user's profile (from modules, etc) will still result in exposing the userID (/sitename/69-username)

Depending on the extension producer it seems they generally use the routing ES uses. It should use the "permalink routing" (which doesn't necessary use a permalink). Most if not all ES modules support the simple URL just fine. Kunena and many other extensions support it well. Even an extension that I haven't updated in a few years points to the simple URL! This was well before it existed in ES 1.4. My point being that in most cases I think it's likely that modules will use the simple URLs.

The only cases that IDs are exposed when removing IDs via the option is when looking into the source code and finding data attributes that mention an ID as well as the avatar image. Everything else is pretty well concealed. While I take semantics and best practices seriously, I wouldn't lose any sleep over the hard to find IDs that likely don't pose any security thread.

I am going to move this thread to the feature requests section as it is distracting our support. Since feature requests threads doesn't appear on our "MUST FIX" support list, it would be ideal to allow community conversations

Understood, Mark -

* Josh, I'm missing something here but am also painfully sleep-deprived - links to profiles from ES's own modules are all kicking me back to /sitename/69-username urls (same for profile links within activity streams, etc.). I'll try and figure what gives on tomorrow - nighty-night!

Hey John,

When you enable the plugin and disabled the "Append user id" option, then the id shouldn't be prefixed on the user's permalink. If you are still having this issue, please start a new thread on our forums so that we could look into this