eZ Community » Forums » Setup & design » One subdomain per each user blog?
expandshrink

One subdomain per each user blog?

One subdomain per each user blog?

Saturday 25 October 2008 4:38:09 pm - 8 replies

Hi.

We're working in a community site. Registered users can create a blog by themselves.
When the blog is created, blog can be reached at http://www.domain.com/Blogs/username.

But customer wants these blogs can be reached at http://username.domain.com.

I don't really know if this can be suitable with eZ.

I'm working with hostmatchtype=map for this site, so solution here could be like this...

- there's an extension to create blogs.
- when a user creates another one, we need to created a new siteaccess for this blog (?)
in this new siteaccess we will need to setup db connection and also root node for it (pointing to the new blog node created at the content tree...)
we will also need to add lines to HostMatchMapItems setting. Something like
HostMatchMapItems[]=user1;user1

but now my doubts.
i don't think the best option is modifying settings/override file... i'm afraid that something could fail and maybe settings/override could became empty or something. we'll get the ez installation process then...

i don't think that having a siteacces per user could be the best option. suppose we have 10.000 users and a blog per each... we will have 10.000 siteaccess... that could be crazy...

Do you have any other ideas here?
Thank you

Modified on Saturday 25 October 2008 4:39:32 pm by Carlos Revillo

Saturday 25 October 2008 8:18:28 pm

Hi Carlos,

It depends whether each new blog receives it's own database, or whether you are happy to house all content objects within your instance and use roles and privileges to lock down what they can edit.

If everyone needs separate databases, then custom siteaccesses is the only way forward. In which case check out HostMatchType, you can do element, text and regular expression matching to prevent making changes to override.ini. It's probably safer to match than having some automated process editing your override file.

If you don't need separate databases, then you could do some server side redirection using apache rewrite rules to map subdomains to the appropriate path. The rest can then be taken care of with roles and policies.

Regards,
Andrew.

Saturday 25 October 2008 9:07:21 pm

Thank you Andrew.

i don't need separate databases for the blogs. I've tried some rewrite rules... d
if i do something like

RewriteCond %{HTTP_HOST} ^(www\.)?username\.domain\.com
RewriteRule .* /Blogs/username [L] 

it works perfectly, but if the user types in browser http://username.domain.com he will be redirected to http://www.domain.com/Blogs/username. You will get this in browser. customer doesn't want that the url changes. he always wants to see username.domain.com/blablalb in browser.

If i do the "reverse way", like

redirectMatch 301 ^/Blogs/username(.+)$ http://username.domain.com

then, when visitor goes to a blog user he will be redirected to http://userdomain.domain.com as expected, but i need to add a hostMatchItem line to map default page of this userdomain.com to a node. and also i will need to create a siteaccess for this domain...

am i missing something here?
thanks again.

Saturday 25 October 2008 9:55:37 pm

Hi Carlos,

You should be able to get it working with mod_rewrite, provided you only use relative urls for the blog templates. Absolute urls generated inside templates would not be aware of your mod_rewrite implementation.

Another alternative, and perhaps more solid would be to look at the mod_proxy implementation in Apache.

Saturday 25 October 2008 10:17:08 pm

thanks Andrew.

i'm not really an expert with apache. i think i would try with mod_rewrite... but i don't completely understand you with "provided you only use relative urls for the blog templates. "...
could you please clarify me this?
thanks for your time.

Sunday 26 October 2008 7:54:38 am

Absolute urls will include the domain name in the href tag, which would introduce complexity as it would likely point to mydomain.com rather than username.mydomain.com, which pushes you back to the wrong style of URL.

I haven't had chance to sit down and try it out, but I imagine you could:

Catch incoming request for "username.mydomain.com", rewrite it is mydomain.com/Blogs/username, without a redirect. This should preserve the original requested URL "username.mydomain.com" in the browser address bar.

The issue you run into now is that you have to catch the links to blog posts, and ensure they are properly handled. If they are in the format "mydomain.com/Blogs/username/my-post" then you need to rewrite your templates. You have two options.

1. You could try and use the template language to evaluate the HTTP_HOST and provide the appropriate domain in an absolute URL, OR

2. You could use relative urls, ie "/Blogs/username/my-post" (preferred I think)

At that point when you click on a link it should request "username.mydomain.com/Blogs/username/my-post" which you can catch with your rewrite rule.

One thing you likely cannot do with the above system, is force a redirect on an incoming request for "mydomain.com/Blogs/username" and redirect it to "username.mydomain.com" or you will end up in an endless loop of redirects with a nice 500 error from Apache.

You will have to live with the fact that mydomain.com/Blogs/username/my-post is accessible, it has to be to handle requests for your rewrite rule anyway, but your subdomains should work for the blog and deeper links.

Sunday 26 October 2008 11:31:04 am

Andrew, thanks a lot for your wonderful explanation.

I'm not really an expert in apache, so i'm going to do some searching for getting redirects from username.domain to domain/Blogs/username preserving the url.

If we have to live with also urls like /Blogs/username we'll do like this. anyway, i'll need to talk with our seo people because maybe we'll get duplicate content for Google, and it seems Google doesn't like this...

But this is other part.

If customer doesn't want like this, i'll tell about the dander of writing the settings/override/site.ini.append.php from a php file...

thank you again.

Sunday 26 October 2008 11:55:29 am

Duplicate content could be an unwanted side effect, not sure how subdomains play into that space.

I wouldn't advise automatically writing to your override/site.ini.append.php, but with HostMatchType it isn't necessary. Use text, element or regular expression matching instead of map.

It still leaves you with potentially 10,000 siteaccesses, but you don't have 10,000 entries in override/site.ini.append.php which is nice.

If you head down that path, you can of course work with IndexPage to set relative content tree roots for your blog siteaccesses which is a nicer way to work, but I haven't tested out the performance of element of regular expression matching against 10,000 siteaccesses and a large number of concurrent users. It is definitely something I would encourage you simulate before pushing too far into development to ensure you don't hit scalability or performance issues.

Friday 18 September 2015 10:10:05 pm

The reply has been removed because of violation of forum rules.

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from