Feature Request - Redirect from old URL when profile addresses are enabled

[DonnaScriptTechs]

From @angelinfante on April 30, 2017 10:20

What are the steps to reproduce this issue?

1. Google indexes a user profile page with the pattern /profile/[id]
2. Admin enables profile addresses and configures a profile address in DB (because there's no way to do it from profile configuration, another nice feature not available)

What happens?

Duplicate page will be indexed in Google, /profile/[id] and /profile/[username]

What were you expecting to happen?

301 redirect from /profile/[id] to /profile/[username] for better SEO

Example: https://orientalisimo.com/profile/482 https://orientalisimo.com/profile/alex-delora

What versions of software are you using?

Operating System: Amazon Linux, PHP7

SocialEngine PHP Version: 4.9.1

Copied from original issue: SocialEngine/phpv4-issues#723

[DonnaScriptTechs]

From @Elshara on April 30, 2017 13:50

Would be nice to just have username.site.com for better seo and be done with it.

On 30/04/2017, Angel Infante notifications@github.com wrote:

What are the steps to reproduce this issue?

1. Google indexes a user profile page with the pattern /profile/[id]
2. Admin enables profile addresses and configures a profile address in DB (because there's no way to do it from profile configuration, another nice feature not available)

What happens?

Duplicate page will be indexed in Google, /profile/[id] and /profile/[username]

What were you expecting to happen?

301 redirect from /profile/[id] to /profile/[username] for better SEO

Example: https://orientalisimo.com/profile/482 https://orientalisimo.com/profile/alex-delora

What versions of software are you using?

Operating System: Amazon Linux, PHP7

SocialEngine PHP Version: 4.9.1

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/SocialEngine/phpv4-issues/issues/723

[DonnaScriptTechs]

From @gsf00001 on April 30, 2017 13:53

@elshara Would that be considered a subdomain?

[DonnaScriptTechs]

From @Elshara on April 30, 2017 13:57

Also, in my opinion, it would be good to have subdomain access for all content. So all users posts belong to their own subdomain depending on the module. So for best seo, you'd have each sub domain represent a part of the content series someone shares, as if it were their own mini site. For instance. profile.domain.com would be for member profiles. Get rid of the userID for the profile and just use their username. If you have profile addresses disabled then just use full name or first and last name which ever was filled out. Browse pages would serve as a separate shared sub domain directory for each module. For blogs, you'd have for the main page, blog.domain.com and then for user blogs you'd have profile.blog.domain.com/blogname as an example. Same for things like photos, videos, music, groups, events, polls, forums, chat, messages, members, etc. Every page would have its own domain essentially. This way, it would make the most sense the way seo currently is designed. To showcase the content name prior to the site wide name, as well as description and tags fields. I think it would work well.

On 30/04/2017, Elshara sourceminded@gmail.com wrote:

Would be nice to just have username.site.com for better seo and be done with it.

On 30/04/2017, Angel Infante notifications@github.com wrote:

What are the steps to reproduce this issue?

1. Google indexes a user profile page with the pattern /profile/[id]
2. Admin enables profile addresses and configures a profile address in DB (because there's no way to do it from profile configuration, another nice feature not available)

What happens?

Duplicate page will be indexed in Google, /profile/[id] and /profile/[username]

What were you expecting to happen?

301 redirect from /profile/[id] to /profile/[username] for better SEO

Example: https://orientalisimo.com/profile/482 https://orientalisimo.com/profile/alex-delora

What versions of software are you using?

Operating System: Amazon Linux, PHP7

SocialEngine PHP Version: 4.9.1

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/SocialEngine/phpv4-issues/issues/723

[DonnaScriptTechs]

From @gsf00001 on April 30, 2017 17:27

Yes, I prefer subdomains as well (for many reasons - especially splitting up into different servers easily) but from my experience, all my 3rd-Party Plugin licensing is for 2 domains (production/development typically) and all folders beneath work, so to use subdomains could get very costly.

[DonnaScriptTechs]

From @Elshara on May 1, 2017 9:25

Sub domains would only involve licensing if the base install was involved. This means if say dev.site.com and just site.com were used, only two sub domains would be applied, because of where the base install is located. It would only use one license regardless of how ever many sub domains the script took care of, as long as it was located per instance as one domain. That is why I suggested sub domain availability be accessible for seo purposes.

On 30/04/2017, gsf00001 notifications@github.com wrote:

Yes, I prefer subdomains as well (for many reasons - especially splitting up into different servers easily) but from my experience, all my 3rd-Party Plugin licensing is for 2 domains (production/development typically) and all folders beneath work, so to use subdomains could get very costly.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/SocialEngine/phpv4-issues/issues/723#issuecomment-298245074

[DonnaScriptTechs]

From @gsf00001 on May 1, 2017 22:16

Based on the info I've received from multiple Devs (and tested with 2 of them), they are basing their licensing on 2 domains and treating a sub-domain as a domain. So, although I may have site.com/live, site.com/stg, site.com/test, site.com/dev all sharing 1 license (which most of my Plugins' Cores check), and may use the other license for a different domain/sub-domain, I can't create live.site.com, stg.site.com, test.site.com, and dev.site.com on 1 license since that's 4 domains/sub-domains (i.e. I would require at least 2 licenses - depending on the license agreement and what I'm actually doing with the licenses). My guess is (based on what I've done in the past as a dev) is that folders off a primary domain/sub-domain are most likely related to the primary 'subject/purpose' of the site, wherease domains/sub-domains are sometimes completely unrelated (hence the license is probably shared among different 'Users/businesses').

It seems that when they check the 'domain' they are treating a domain and 'sub-domain' the same. Many of my other web soutions (such as Incapsula) does this as well - they treat a sub-domain as a domain for licensing purposes. I'm not saying everyone does this, only that all of the 3rd-Party Devs I use have thoroughly explained this to me and I found this out when a host used a sub-domain instead of a folder - it exceeded my existing 2 licenses (one a domain, the other a sub-domain).

I believe that typically sub-domains may also be split off onto separate servers (clustered servers, etc), whereas a folder remains part of the original domain and is managed along with it (but I could be wrong - I'm not a techie, just basing this on my understanding from numerous emails/support tickets on this topic).