Whitelabel - Revision history

WolfgangRosenauer at 09:18, 21 December 2010

2010-12-21T09:18:44Z

← Older revision		Revision as of 09:18, 21 December 2010
Line 5:		Line 5:
	In many hosting environments, it is needed that the OX GUI, especially the LOGIN page is branded/whitelabeled to the reseller/customer corporate identity or domain.		In many hosting environments, it is needed that the OX GUI, especially the LOGIN page is branded/whitelabeled to the reseller/customer corporate identity or domain.

	There are basically 3 ways ~~of achieving~~ this:		There are basically 3 ways to achieve this:

	* Provision the "theme" into each new user via OX APIs like SOAP, RMI or CLT. But then you still need to create a new vhost for each of your ~~reseller~~ and you need to copy the whole GUI. This way, you have to ~~modfiy~~ the provisioning and need to copy the OX GUI after each update.		* Provision the "theme" into each new user via OX APIs like SOAP, RMI or CLT. But then you still need to create a new vhost for each of your resellers and you need to copy the whole GUI. This way, you have to modifiy the provisioning and need to copy the OX GUI after each update.

	* Create a vhost/domain for every customer/reseller like "reseller.domain.com" and copy the whole OX GUI including all themes to that new vhost. After that is done, you have to modify the "default" theme of the OX GUI. The drawback of that solution is, that you now have multiple copies of the OX GUI, which is very bad regarding seamless updates/upgrades. After each update, you have to copy the GUI again for every domain/reseller you have created a vhost for.		* Create a vhost/domain for every customer/reseller like "reseller.domain.com" and copy the whole OX GUI including all themes to that new vhost. After that is done, you have to modify the "default" theme of the OX GUI. The drawback of that solution is, that you now have multiple copies of the OX GUI, which is very bad regarding seamless updates/upgrades. After each update, you have to copy the GUI again for every domain/reseller you have created a vhost for.
Line 13:		Line 13:
	* Use mod_rewrite by Apache to do the work for you based on the domain, the user entered in his browser. With this way, you only have to change the default theme and the GUI will be served from only one directory. This way, you have nearly nothing to do after you have update the OX GUI.		* Use mod_rewrite by Apache to do the work for you based on the domain, the user entered in his browser. With this way, you only have to change the default theme and the GUI will be served from only one directory. This way, you have nearly nothing to do after you have update the OX GUI.

	We recommend that you do it via the mod_rewrite module of Apache. It is less ~~painfull~~ and offers more options for you.		We recommend that you do it via the mod_rewrite module of Apache. It is less painful and offers more options for you.

	=== Configuration ===		=== Configuration ===

	* You have to modify the ox specific vhost of your apache so that the vhost inherits also "mod_rewrite" configurations:		* You have to modify the OX specific vhost of your apache so that the vhost inherits also "mod_rewrite" configurations:

	<pre>		<pre>
Line 24:		Line 24:
	</pre>		</pre>

	On Debian ~~lenny~~ you have to add the above 2 lines to the "<VirtualHost>" section of file:		On Debian Lenny you have to add the above 2 lines to the "<VirtualHost>" section of file:

	<pre>		<pre>
Line 31:		Line 31:


	Now you have to create a new config file to the main ~~apache~~ configuration which will rewrite all requests from "/themes/default" to "/themes/<FQDN>", where "<FQDN>" will be replaced by the ~~Domain~~ the user entered in his browser to access the Open-Xchange GUI.		Now you have to create a new config file to the main Apache configuration which will rewrite all requests from "/themes/default" to "/themes/<FQDN>", where "<FQDN>" will be replaced by the domain the user entered in his browser to access the Open-Xchange GUI.

	For Debian Lenny, create file:		For Debian Lenny, create file:
Line 39:		Line 39:
	</pre>		</pre>

	and add following line to it:		and add the following line to it:

	<pre>		<pre>
Line 45:		Line 45:
	</pre>		</pre>

	Assuming that your users access the OX GUI via "http://webmail.brand.com", you have to copy the "default" theme to "webmail.brand.com" and then modify it, to suit your needs.		Assuming that your users access the OX GUI via "http://webmail.brand.com", you have to copy the "default" theme to "webmail.brand.com" and then modify it to suit your needs.

	<pre>		<pre>
Line 51:		Line 51:
	</pre>		</pre>

	To make it even more ~~usefull~~, you could now try to modify the mod_rewrite configuration to only rewrite some URls the UI is requesting, like the LOGIN logo or the main logo , which is used in the GUI after logging in etc. This way, you only need to modify 3-4 files and the main part of the GUI will be loaded by the "default" theme.		To make it even more useful, you could now try to modify the mod_rewrite configuration to only rewrite some URls the UI is requesting, like the LOGIN logo or the main logo , which is used in the GUI after logging in etc. This way, you only need to modify 3-4 files and the main part of the GUI will be loaded by the "default" theme.

Cutmasta: /* Whitelabeling the Open-Xchange Gui */

2010-12-21T09:15:52Z

Whitelabeling the Open-Xchange Gui

← Older revision		Revision as of 09:15, 21 December 2010
Line 1:		Line 1:
	= ~~Whitelabeling~~ the Open-Xchange Gui =		= White-labeling the Open-Xchange Gui =

	=== Introduction ===		=== Introduction ===

Cutmasta: /* Configuration */

2010-12-21T09:05:30Z

Configuration

← Older revision		Revision as of 09:05, 21 December 2010
Line 50:		Line 50:
	cp -r /var/www/ox6/themes/default /var/www/ox6/themes/webmail.brand.com		cp -r /var/www/ox6/themes/default /var/www/ox6/themes/webmail.brand.com
	</pre>		</pre>

			To make it even more usefull, you could now try to modify the mod_rewrite configuration to only rewrite some URls the UI is requesting, like the LOGIN logo or the main logo , which is used in the GUI after logging in etc. This way, you only need to modify 3-4 files and the main part of the GUI will be loaded by the "default" theme.

Cutmasta: /* Introduction */

2010-12-21T09:02:18Z

Introduction

← Older revision		Revision as of 09:02, 21 December 2010
Line 11:		Line 11:
	* Create a vhost/domain for every customer/reseller like "reseller.domain.com" and copy the whole OX GUI including all themes to that new vhost. After that is done, you have to modify the "default" theme of the OX GUI. The drawback of that solution is, that you now have multiple copies of the OX GUI, which is very bad regarding seamless updates/upgrades. After each update, you have to copy the GUI again for every domain/reseller you have created a vhost for.		* Create a vhost/domain for every customer/reseller like "reseller.domain.com" and copy the whole OX GUI including all themes to that new vhost. After that is done, you have to modify the "default" theme of the OX GUI. The drawback of that solution is, that you now have multiple copies of the OX GUI, which is very bad regarding seamless updates/upgrades. After each update, you have to copy the GUI again for every domain/reseller you have created a vhost for.

	* Use mod_rewrite by Apache to do the work for you based on the domain, the user entered in ~~this~~ browser. With this way, you only have to change the default theme and the GUI will be served from only one directory. This way, you have nearly nothing to do after you have update the OX GUI.		* Use mod_rewrite by Apache to do the work for you based on the domain, the user entered in his browser. With this way, you only have to change the default theme and the GUI will be served from only one directory. This way, you have nearly nothing to do after you have update the OX GUI.

	We recommend that you do it via the mod_rewrite module of Apache. It is less painfull and offers more options for you.		We recommend that you do it via the mod_rewrite module of Apache. It is less painfull and offers more options for you.

Cutmasta: /* Introduction */

2010-12-21T09:01:18Z

Introduction

← Older revision		Revision as of 09:01, 21 December 2010
Line 5:		Line 5:
	In many hosting environments, it is needed that the OX GUI, especially the LOGIN page is branded/whitelabeled to the reseller/customer corporate identity or domain.		In many hosting environments, it is needed that the OX GUI, especially the LOGIN page is branded/whitelabeled to the reseller/customer corporate identity or domain.

	There are 2 ways of achieving this:		There are basically 3 ways of achieving this:

			* Provision the "theme" into each new user via OX APIs like SOAP, RMI or CLT. But then you still need to create a new vhost for each of your reseller and you need to copy the whole GUI. This way, you have to modfiy the provisioning and need to copy the OX GUI after each update.

	* Create a vhost/domain for every customer/reseller like "reseller.domain.com" and copy the whole OX GUI including all themes to that new vhost. After that is done, you have to modify the "default" theme of the OX GUI. The drawback of that solution is, that you now have multiple copies of the OX GUI, which is very bad regarding seamless updates/upgrades. After each update, you have to copy the GUI again for every domain/reseller you have created a vhost for.		* Create a vhost/domain for every customer/reseller like "reseller.domain.com" and copy the whole OX GUI including all themes to that new vhost. After that is done, you have to modify the "default" theme of the OX GUI. The drawback of that solution is, that you now have multiple copies of the OX GUI, which is very bad regarding seamless updates/upgrades. After each update, you have to copy the GUI again for every domain/reseller you have created a vhost for.
Line 11:		Line 13:
	* Use mod_rewrite by Apache to do the work for you based on the domain, the user entered in this browser. With this way, you only have to change the default theme and the GUI will be served from only one directory. This way, you have nearly nothing to do after you have update the OX GUI.		* Use mod_rewrite by Apache to do the work for you based on the domain, the user entered in this browser. With this way, you only have to change the default theme and the GUI will be served from only one directory. This way, you have nearly nothing to do after you have update the OX GUI.

	We recommend that you do it via the mod_rewrite module of Apache. It is less painfull and offers more options for ~~updates~~.		We recommend that you do it via the mod_rewrite module of Apache. It is less painfull and offers more options for you.

	=== Configuration ===		=== Configuration ===

Cutmasta: /* Introduction */

2010-12-21T08:59:31Z

Introduction

← Older revision		Revision as of 08:59, 21 December 2010
Line 7:		Line 7:
	There are 2 ways of achieving this:		There are 2 ways of achieving this:

	* Create a vhost/domain for every customer/reseller like "reseller.domain.com" and copy the whole OX GUI to that new vhost. After that is done, you have to modify the "default" theme of the OX GUI. The drawback of that solution is, that you now have multiple copies of the OX GUI, which is very bad regarding seamless updates/upgrades. After each update, you have to copy the GUI again for every domain/reseller you have created a vhost for.		* Create a vhost/domain for every customer/reseller like "reseller.domain.com" and copy the whole OX GUI including all themes to that new vhost. After that is done, you have to modify the "default" theme of the OX GUI. The drawback of that solution is, that you now have multiple copies of the OX GUI, which is very bad regarding seamless updates/upgrades. After each update, you have to copy the GUI again for every domain/reseller you have created a vhost for.

	* Use mod_rewrite by Apache to do the work for you based on the domain, the user entered in this browser. With this way, you only have to change the default theme and the GUI will be served from only one directory. This way, you have nearly nothing to do after you have update the OX GUI.		* Use mod_rewrite by Apache to do the work for you based on the domain, the user entered in this browser. With this way, you only have to change the default theme and the GUI will be served from only one directory. This way, you have nearly nothing to do after you have update the OX GUI.

	We recommend that you do it via the mod_rewrite module of Apache. It is less painfull and offers more options for updates.		We recommend that you do it via the mod_rewrite module of Apache. It is less painfull and offers more options for updates.

	=== Configuration ===		=== Configuration ===

Cutmasta at 08:59, 21 December 2010

2010-12-21T08:59:11Z

← Older revision		Revision as of 08:59, 21 December 2010
Line 12:		Line 12:

	We recommend that you do it via the mod_rewrite module of Apache. It is less painfull and offers more options for updates.		We recommend that you do it via the mod_rewrite module of Apache. It is less painfull and offers more options for updates.


	=== Configuration ===		=== Configuration ===
Line 32:		Line 31:
	Now you have to create a new config file to the main apache configuration which will rewrite all requests from "/themes/default" to "/themes/<FQDN>", where "<FQDN>" will be replaced by the Domain the user entered in his browser to access the Open-Xchange GUI.		Now you have to create a new config file to the main apache configuration which will rewrite all requests from "/themes/default" to "/themes/<FQDN>", where "<FQDN>" will be replaced by the Domain the user entered in his browser to access the Open-Xchange GUI.

	For Debian Lenny, ~~please~~ create file:		For Debian Lenny, create file:

	<pre>		<pre>
Line 42:		Line 41:
	<pre>		<pre>
	RewriteRule v=\w+/themes/default(.*)$ /themes/%{HTTP_HOST}/$1		RewriteRule v=\w+/themes/default(.*)$ /themes/%{HTTP_HOST}/$1
			</pre>

			Assuming that your users access the OX GUI via "http://webmail.brand.com", you have to copy the "default" theme to "webmail.brand.com" and then modify it, to suit your needs.

			<pre>
			cp -r /var/www/ox6/themes/default /var/www/ox6/themes/webmail.brand.com
	</pre>		</pre>

Cutmasta at 08:55, 21 December 2010

2010-12-21T08:55:14Z

← Older revision		Revision as of 08:55, 21 December 2010
Line 3:		Line 3:
	=== Introduction ===		=== Introduction ===

	~~Within~~ many environments, it is needed that the OX GUI, especially the LOGIN page is branded to the ~~customers~~/~~resellers~~ corporate identity or domain.		In many hosting environments, it is needed that the OX GUI, especially the LOGIN page is branded/whitelabeled to the reseller/customer corporate identity or domain.

	There are 2 ways of achieving this:		There are 2 ways of achieving this:
Line 9:		Line 9:
	* Create a vhost/domain for every customer/reseller like "reseller.domain.com" and copy the whole OX GUI to that new vhost. After that is done, you have to modify the "default" theme of the OX GUI. The drawback of that solution is, that you now have multiple copies of the OX GUI, which is very bad regarding seamless updates/upgrades. After each update, you have to copy the GUI again for every domain/reseller you have created a vhost for.		* Create a vhost/domain for every customer/reseller like "reseller.domain.com" and copy the whole OX GUI to that new vhost. After that is done, you have to modify the "default" theme of the OX GUI. The drawback of that solution is, that you now have multiple copies of the OX GUI, which is very bad regarding seamless updates/upgrades. After each update, you have to copy the GUI again for every domain/reseller you have created a vhost for.

	* Use mod_rewrite to ~~let apache~~ do the work for you based on the domain, the user entered in this browser.		* Use mod_rewrite by Apache to do the work for you based on the domain, the user entered in this browser. With this way, you only have to change the default theme and the GUI will be served from only one directory. This way, you have nearly nothing to do after you have update the OX GUI.

	~~Here are 2 screenshots~~ of ~~same docroot but with different themes/login pages~~.		We recommend that you do it via the mod_rewrite module of Apache. It is less painfull and offers more options for updates.

	~~[[File:upsell.png\|290px\|thumb\|left\|Upsell Layer Mobility]]~~
	~~[[File:Upsell_infostore.png\|290px\|thumb\|left\|Upsell Layer Infostore]]~~
	~~[[File:upsell_calendar.png\|290px\|thumb\|left\|Upsell Layer Calendar]]~~

			=== Configuration ===

	We have ~~implemented 3 different types how~~ to ~~process~~ the ~~upsell an user is requesting in~~ the ~~hosters backend~~:		* You have to modify the ox specific vhost of your apache so that the vhost inherits also "mod_rewrite" configurations:

	* Show the Upsell Layer window and trigger the upgrade via a generated email to an email address after user clicked "buy" or "trial".		<pre>
			RewriteEngine On
			RewriteOptions Inherit
			</pre>

	~~In this email there is~~ the ~~information which user from which contaxt wants to upgrade~~ to ~~which package. After receiving the email the hoster's sales team can put~~ the ~~customer into billing.~~		On Debian lenny you have to add the above 2 lines to the "<VirtualHost>" section of file:

	* Show the Upsell Layer window and open a configurable URL including all needed parameters after the user clicked "buy" or "trial.		<pre>
			/etc/apache2/sites-available/default
	~~This is the perfect automated way if the hoster wants to have a full automated upsell which he can easily integrate into his existing provisioning & billing system.~~		</pre>

	* Directly display a configurable URL/~~Online SHOP (systemwide or~~/~~and per context configurable) within the upsell Layer window instead of standard OX upsell content.~~

	~~This is the perfect automated way for all hosters which have an online shop in place and wants to use it for the upsell, too.~~


	~~The upsell layer has full i18n (EN and DE are included) support integrated and offers following components for advertisement:~~

	* Text
	* Video
	* Screenshots

	~~to promote a certain feature for Open-Xchange.~~

	~~The important part of~~ the ~~upsell layer is the ability to pass~~ all ~~needed parameters~~ from ~~users session like username~~,~~id,cid etc. +~~ the ~~feature he wants to buy, to a third party online shop system or send these parameters via email~~ in ~~machine readable (configurable) format~~ to ~~a dedicated mailsystem which can process it via procmail or similar to trigger the upgrade process via~~ the Open-Xchange ~~API´s (SOAP,RMI,CLT)~~.		Now you have to create a new config file to the main apache configuration which will rewrite all requests from "/themes/default" to "/themes/<FQDN>", where "<FQDN>" will be replaced by the Domain the user entered in his browser to access the Open-Xchange GUI.

	~~=== Configuration ===~~		For Debian Lenny, please create file:

	* You have to modify the ox specific vhost of your apache so that the vhost inherits also "mod_rewrite" configurations:

	<pre>		<pre>
	~~RewriteEngine On~~		/etc/apache2/conf.d/rewrite_default_theme.conf
	~~RewriteOptions Inherit~~
	</pre>		</pre>

	~~On Debian lenny you have to~~ add ~~the above 2 lines~~ to ~~the "<VirtualHost>" section of file~~:		and add following line to it:

	<pre>		<pre>
	/~~etc~~/~~apache2~~/~~sites-available~~/~~default~~		RewriteRule v=\w+/themes/default(.*)$ /themes/%{HTTP_HOST}/$1
	</pre>		</pre>

Cutmasta: Created page with "= Whitelabeling the Open-Xchange Gui = === Introduction === Within many environments, it is needed that the OX GUI, especially the LOGIN page is branded to the customers/resell..."

2010-12-21T08:46:38Z

Created page with "= Whitelabeling the Open-Xchange Gui = === Introduction === Within many environments, it is needed that the OX GUI, especially the LOGIN page is branded to the customers/resell..."

New page

= Whitelabeling the Open-Xchange Gui =

=== Introduction ===

Within many environments, it is needed that the OX GUI, especially the LOGIN page is branded to the customers/resellers corporate identity or domain.

There are 2 ways of achieving this:

* Create a vhost/domain for every customer/reseller like "reseller.domain.com" and copy the whole OX GUI to that new vhost. After that is done, you have to modify the "default" theme of the OX GUI. The drawback of that solution is, that you now have multiple copies of the OX GUI, which is very bad regarding seamless updates/upgrades. After each update, you have to copy the GUI again for every domain/reseller you have created a vhost for.

* Use mod_rewrite to let apache do the work for you based on the domain, the user entered in this browser.

Here are 2 screenshots of same docroot but with different themes/login pages.

[[File:upsell.png|290px|thumb|left|Upsell Layer Mobility]]
[[File:Upsell_infostore.png|290px|thumb|left|Upsell Layer Infostore]]
[[File:upsell_calendar.png|290px|thumb|left|Upsell Layer Calendar]]

We have implemented 3 different types how to process the upsell an user is requesting in the hosters backend:

* Show the Upsell Layer window and trigger the upgrade via a generated email to an email address after user clicked "buy" or "trial".

In this email there is the information which user from which contaxt wants to upgrade to which package. After receiving the email the hoster's sales team can put the customer into billing.

* Show the Upsell Layer window and open a configurable URL including all needed parameters after the user clicked "buy" or "trial.

This is the perfect automated way if the hoster wants to have a full automated upsell which he can easily integrate into his existing provisioning & billing system.

* Directly display a configurable URL/Online SHOP (systemwide or/and per context configurable) within the upsell Layer window instead of standard OX upsell content.

This is the perfect automated way for all hosters which have an online shop in place and wants to use it for the upsell, too.

The upsell layer has full i18n (EN and DE are included) support integrated and offers following components for advertisement:

* Text
* Video
* Screenshots

to promote a certain feature for Open-Xchange.

The important part of the upsell layer is the ability to pass all needed parameters from users session like username,id,cid etc. + the feature he wants to buy, to a third party online shop system or send these parameters via email in machine readable (configurable) format to a dedicated mailsystem which can process it via procmail or similar to trigger the upgrade process via the Open-Xchange API´s (SOAP,RMI,CLT).

=== Configuration ===

* You have to modify the ox specific vhost of your apache so that the vhost inherits also "mod_rewrite" configurations:

<pre>
RewriteEngine On
RewriteOptions Inherit
</pre>

On Debian lenny you have to add the above 2 lines to the "<VirtualHost>" section of file:

<pre>
/etc/apache2/sites-available/default
</pre>