Implement site content language negotiation

2 views
Skip to first unread message

Alexander Obuhovich

unread,
Nov 23, 2009, 9:35:58 AM11/23/09
to In-Portal Development
For now, when user goes to site directly to the site, e.g. http://www.site.com, then site content is shown on default language (same for all users). Of course later user can choose other language later. There is such setting in user browser as preferred languages, where he sets up languages he/she wants to view sites on (by the priority). Such header is called "Accept-Language" and is sent each time user visits the site. I propose we detect default user language based on this header. When no language matches, then we use language, marked as default.

--
Best Regards,

http://www.in-portal.org
http://www.alex-time.com

Dmitry A.

unread,
Dec 16, 2009, 4:10:56 PM12/16/09
to In-Portal Development
I believe this would be very useful feature.

I would also add more robust functionality directly related to this -
ability to manage Domains vs. Themes vs. Languages that are loaded.

And as a one of the options would add ability to auto-detect user
Language. Obviously this is more complex then initially proposed
feature, but I think we should definitely discuss and come up with a
good plan for listed above and then break it on smaller tasks.

What others think?


DA.


On Nov 23, 8:35 am, Alexander Obuhovich <aik.b...@gmail.com> wrote:
> For now, when user goes to site directly to the site, e.g.http://www.site.com, then site content is shown on default language (same

Alexander Obuhovich

unread,
Dec 16, 2009, 4:26:48 PM12/16/09
to in-por...@googlegroups.com
Why not, I've already implemented this whole stuff, even currency/language selection based on domain. By default new table will be empty, so all will work as before. For advanced users there will be ability to define default language, language selection, default countries and so on based on domain gathered from $_SERVER['HTTP_HOST'].

--

You received this message because you are subscribed to the Google Groups "In-Portal Development" group.
To post to this group, send email to in-por...@googlegroups.com.
To unsubscribe from this group, send email to in-portal-de...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/in-portal-dev?hl=en.


Dmitry A.

unread,
Dec 16, 2009, 4:55:24 PM12/16/09
to In-Portal Development
Ok, let try to work out the specs for this then (here):

1. New Section (probably under Configuration->Website) that will allow
to configure multiple Domains that this website is running on.

2. Each domain should have Default and Available for user to select
(change)

- Primary Theme (drop-down)
- Primary Language (drop-down) + Available Languages
- Primary Currency (drop-down) + Available Currencies

3. By Default will be empty and won't make ANY changes to the current
default functionality.

Anything else we can add here which could be domain specific?

ANY thoughts are welcome, Phil, Sergey, Alex, Andrew!


Cheers.

DA.
> > in-portal-de...@googlegroups.com<in-portal-dev%2Bunsubscribe@goog­legroups.com>
> > .

Alexander Obuhovich

unread,
Dec 16, 2009, 4:58:32 PM12/16/09
to in-por...@googlegroups.com
I would add "+ Available Themes" too in case if themes are using skin selector (like language selector).

To unsubscribe from this group, send email to in-portal-de...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/in-portal-dev?hl=en.


Dmitry A.

unread,
Dec 17, 2009, 9:48:44 PM12/17/09
to In-Portal Development
Sure!

Here is another cool things to have.

Besides the ability to specify Site Domains and what Language and
Themes is available for user we can add IP (Network matching).

1. New Section (probably under Configuration->Website) that will allow
to configure multiple Domains that this website is running on.

2. Each domain (sub-domain) should have Default and Available for user
to select
(change)

- Geo-Location Match - by IP or Country (location).
a. List (range) of IP addresses / networks will be entered.
b. List of Countries + somewho we need to match IP to Country.
c. Force redirect for User to this domain if his IP (remote address)
falls.

- Primary Theme (drop-down) + Available Themes


- Primary Language (drop-down) + Available Languages
- Primary Currency (drop-down) + Available Currencies

3. By Default will be empty and won't make ANY changes to the current
default functionality.


DA

> > > > in-portal-de...@googlegroups.com<in-portal-dev%2Bunsu...@googlegroups.com>


> > <in-portal-dev%2Bunsubscribe@goog­legroups.com>
> > > > .
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/in-portal-dev?hl=en.
>
> > > --
> > > Best Regards,
>
> > >http://www.in-portal.orghttp://www.alex-time.com
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "In-Portal Development" group.
> > To post to this group, send email to in-por...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > in-portal-de...@googlegroups.com<in-portal-dev%2Bunsu...@googlegroups.com>

Dmitry A.

unread,
Dec 20, 2009, 1:12:57 AM12/20/09
to In-Portal Development
Alex, Sergey - what are your thoughts on what I described earlier?


Cheers!

DA.

Alexander Obuhovich

unread,
Dec 23, 2009, 3:06:21 AM12/23/09
to in-por...@googlegroups.com
I've create two tasks based on given discussion:

http://tracker.in-portal.org/view.php?id=471 (0000471: Implement site content language negotiation)
http://tracker.in-portal.org/view.php?id=472 (0000472: Domain-based site auto-configuration)


To unsubscribe from this group, send email to in-portal-de...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/in-portal-dev?hl=en.


Dmitry A.

unread,
Jan 21, 2010, 5:44:32 PM1/21/10
to In-Portal Development Team
Hi all,


I'd like to revisit "Domain-based site auto-configuration" discussion
-- http://tracker.in-portal.org/view.php?id=472

We really need to think about Admin email addresses for each sites/
domain. It's kind of odd to use the same Admin Email for all different
domains, isn't it?

It's kind of hard to think of the way to implement it for all Email
Events - there is a lot. We can definitely make it happen for general
Admin address, at the same time keeping SMTP settings section
unchanged.

Let me know your thought.


Cheers!

On Dec 23 2009, 2:06 am, Alexander Obuhovich <aik.b...@gmail.com>
wrote:


> I've create two tasks based on given discussion:
>
> http://tracker.in-portal.org/view.php?id=471(0000471: Implement site

> content language negotiation)http://tracker.in-portal.org/view.php?id=472(0000472: Domain-based site

> > > > > > > in-portal-de...@googlegroups.com<in-portal-dev%2Bunsubscribe@goog legroups.com>
> > <in-portal-dev%2Bunsu...@googlegroups.com<in-portal-dev%252Bunsubscribe @googlegroups.com>


>
> > > > > <in-portal-dev%2Bunsubscribe@goog­legroups.com>
> > > > > > > .
> > > > > > > For more options, visit this group at
> > > > > > >http://groups.google.com/group/in-portal-dev?hl=en.
>
> > > > > > --
> > > > > > Best Regards,
>
> > > > > >http://www.in-portal.orghttp://www.alex-time.com
>
> > > > > --
>
> > > > > You received this message because you are subscribed to the Google
> > Groups
> > > > > "In-Portal Development" group.
> > > > > To post to this group, send email to in-por...@googlegroups.com.
> > > > > To unsubscribe from this group, send email to

> > > > > in-portal-de...@googlegroups.com<in-portal-dev%2Bunsubscribe@goog legroups.com>
> > <in-portal-dev%2Bunsu...@googlegroups.com<in-portal-dev%252Bunsubscribe @googlegroups.com>


>
> > > > > .
> > > > > For more options, visit this group at
> > > > >http://groups.google.com/group/in-portal-dev?hl=en.
>
> > > > --
> > > > Best Regards,
>
> > > >http://www.in-portal.orghttp://www.alex-time.com
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "In-Portal Development" group.
> > To post to this group, send email to in-por...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > in-portal-de...@googlegroups.com<in-portal-dev%2Bunsubscribe@goog legroups.com>

Alexander Obuhovich

unread,
Jan 25, 2010, 1:45:32 PM1/25/10
to in-por...@googlegroups.com
I also propose to make SSL-settings domain-based. So each site can have it's own ssl domain. To implement this we need to centralize SSL_URL configuration variable retrieval and usage of DOMAIN constant so both of them will look for "site-domain" record first.

You received this message because you are subscribed to the Google Groups "In-Portal Development Team" group.
To post to this group, send email to in-por...@googlegroups.com.
To unsubscribe from this group, send email to in-portal-de...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/in-portal-dev?hl=en.




--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

Dmitry Andrejev

unread,
Jan 25, 2010, 1:50:04 PM1/25/10
to in-por...@googlegroups.com
Yes, I agree with SSL.

So to sum up what still needs to be covered for this task is:

1. Email Events FROM Address (or just domain part of it)

2. SSL settings should be Site based too.


Do you have thoughts on Email part?


Thanks.

DA.

Alexander Obuhovich

unread,
Jan 26, 2010, 4:28:42 AM1/26/10
to in-por...@googlegroups.com
Nothing, this is pretty simple.

Phil

unread,
Feb 9, 2010, 11:24:37 AM2/9/10
to In-Portal Development Team
Hi,

this is a really interesting feature, as I have 2 actual customers who
are interested by this, and I was thinking about doing something hand-
made :)

I'll request another features :
- Primary Paiement (drop-down) + Available Paiement modes
- Primary Shipping (drop-down) + Available Shipping modes

As when we think about website geolocalized, it means we could have
different way to pay and ship orders.

This multi-sites feature can also be used by customers to open their
own competitor, that's why it's really interesting, and you ever
though about "Email Events FROM Address", cool !

I hope it'll be ready for 510.

Phil.


On Jan 26, 10:28 am, Alexander Obuhovich <aik.b...@gmail.com> wrote:
> Nothing, this is pretty simple.
>

> On Mon, Jan 25, 2010 at 8:50 PM, Dmitry Andrejev <dandre...@gmail.com>wrote:
>
> > Yes, I agree with SSL.
>
> > So to sum up what still needs to be covered for this task is:
>
> > 1. Email Events FROM Address (or just domain part of it)
>
> > 2. SSL settings should be Site based too.
>
> > Do you have thoughts on Email part?
>
> > Thanks.
>
> > DA.
>

> > On Mon, Jan 25, 2010 at 12:45 PM, Alexander Obuhovich <aik.b...@gmail.com>wrote:
>
> >> I also propose to make SSL-settings domain-based. So each site can have
> >> it's own ssl domain. To implement this we need to centralize SSL_URL
> >> configuration variable retrieval and usage of DOMAIN constant so both of
> >> them will look for "site-domain" record first.
>

> >> On Fri, Jan 22, 2010 at 12:44 AM, Dmitry A. <dandre...@gmail.com> wrote:
>
> >>> Hi all,
>
> >>> I'd like to revisit "Domain-based site auto-configuration" discussion

> >>> --http://tracker.in-portal.org/view.php?id=472


>
> >>> We really need to think about Admin email addresses for each sites/
> >>> domain. It's kind of odd to use the same Admin Email for all different
> >>> domains, isn't it?
>
> >>> It's kind of hard to think of the way to implement it for all Email
> >>> Events - there is a lot. We can definitely make it happen for general
> >>> Admin address, at the same time  keeping SMTP settings section
> >>> unchanged.
>
> >>> Let me know your thought.
>
> >>> Cheers!
>
> >>> On Dec 23 2009, 2:06 am, Alexander Obuhovich <aik.b...@gmail.com>
> >>> wrote:
> >>> > I've create two tasks based on given discussion:
>

> >>> >http://tracker.in-portal.org/view.php?id=471(0000471<http://tracker.in-portal.org/view.php?id=471%280000471>:


> >>> Implement site
> >>> > content language negotiation)

> >>>http://tracker.in-portal.org/view.php?id=472(0000472<http://tracker.in-portal.org/view.php?id=472%280000472>:

> >>> > > > > > > > in-portal-de...@googlegroups.com<in-portal-dev%2Bunsu...@googlegroups.com>
> >>> <in-portal-dev%2Bunsubscribe@goog legroups.com>
> >>> > > <in-portal-dev%2Bunsu...@googlegroups.com<in-portal-dev%252Buns...@googlegroups.com><in-portal-dev%252Bunsubscribe


> >>> @googlegroups.com>
>
> >>> > > > > > <in-portal-dev%2Bunsubscribe@goog­legroups.com>
> >>> > > > > > > > .
> >>> > > > > > > > For more options, visit this group at
> >>> > > > > > > >http://groups.google.com/group/in-portal-dev?hl=en.
>
> >>> > > > > > > --
> >>> > > > > > > Best Regards,
>
> >>> > > > > > >http://www.in-portal.orghttp://www.alex-time.com
>
> >>> > > > > > --
>
> >>> > > > > > You received this message because you are subscribed to the
> >>> Google
> >>> > > Groups
> >>> > > > > > "In-Portal Development" group.
> >>> > > > > > To post to this group, send email to
> >>> in-por...@googlegroups.com.
> >>> > > > > > To unsubscribe from this group, send email to

> >>> > > > > > in-portal-de...@googlegroups.com<in-portal-dev%2Bunsu...@googlegroups.com>
> >>> <in-portal-dev%2Bunsubscribe@goog legroups.com>
> >>> > > <in-portal-dev%2Bunsu...@googlegroups.com<in-portal-dev%252Buns...@googlegroups.com><in-portal-dev%252Bunsubscribe


> >>> @googlegroups.com>
>
> >>> > > > > > .
> >>> > > > > > For more options, visit this group at
> >>> > > > > >http://groups.google.com/group/in-portal-dev?hl=en.
>
> >>> > > > > --
> >>> > > > > Best Regards,
>
> >>> > > > >http://www.in-portal.orghttp://www.alex-time.com
>
> >>> > > --
>
> >>> > > You received this message because you are subscribed to the Google
> >>> Groups
> >>> > > "In-Portal Development" group.
> >>> > > To post to this group, send email to in-por...@googlegroups.com.
> >>> > > To unsubscribe from this group, send email to

> >>> > > in-portal-de...@googlegroups.com<in-portal-dev%2Bunsu...@googlegroups.com>


> >>> <in-portal-dev%2Bunsubscribe@goog legroups.com>
> >>> > > .
> >>> > > For more options, visit this group at
> >>> > >http://groups.google.com/group/in-portal-dev?hl=en.
>
> >>> > --
> >>> > Best Regards,
>
> >>> >http://www.in-portal.orghttp://www.alex-time.com
>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups
> >>> "In-Portal Development Team" group.
> >>> To post to this group, send email to in-por...@googlegroups.com.
> >>> To unsubscribe from this group, send email to

> >>> in-portal-de...@googlegroups.com<in-portal-dev%2Bunsu...@googlegroups.com>


> >>> .
> >>> For more options, visit this group at
>

> ...
>
> read more »

Alexander Obuhovich

unread,
Feb 9, 2010, 11:48:06 AM2/9/10
to in-por...@googlegroups.com
- Primary Payment (drop-down) + Available Payment modes is already implemented as part of this feature.
- Primary Shipping (drop-down) + Available Shipping modes whole shipping mode configuration is stuff is pretty advanced already, so you can define zones based on country and we though it's no need to complicate it by placing global override in site domain section domain-based.

To unsubscribe from this group, send email to in-portal-de...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/in-portal-dev?hl=en.




--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

Phil

unread,
Feb 10, 2010, 5:27:44 AM2/10/10
to In-Portal Development Team
Hello,

about shipping, this was in the idea of running multisite in 1
country, with the need to separate things depending on originating
orders.

Also, could it be possible to have a field in Admin Orders to know
where does the order was originating?

Phil.

On Feb 9, 5:48 pm, Alexander Obuhovich <aik.b...@gmail.com> wrote:
> *- Primary Payment (drop-down) + Available Payment* *modes *is already


> implemented as part of this feature.

> * - Primary Shipping (drop-down) + Available Shipping modes* whole shipping


> mode configuration is stuff is pretty advanced already, so you can define
> zones based on country and we though it's no need to complicate it by
> placing global override in site domain section domain-based.
>

> > <in-portal-dev%2Bunsu...@googlegroups.com<in-portal-dev%252Buns...@googlegroups.com>
>
> > > >>> <in-portal-dev%2Bunsubscribe@goog legroups.com>
> > > >>> > > <in-portal-dev%2Bunsu...@googlegroups.com<in-portal-dev%252Buns...@googlegroups.com>
> > <in-portal-dev%252Buns...@googlegroups.com<in-portal-dev%25252Bun...@googlegroups.com>


> > ><in-portal-dev%252Bunsubscribe
> > > >>> @googlegroups.com>
>
> > > >>> > > > > > <in-portal-dev%2Bunsubscribe@goog­legroups.com>
> > > >>> > > > > > > > .
>

> ...
>
> read more »

Alexander Obuhovich

unread,
Feb 10, 2010, 5:31:49 AM2/10/10
to in-por...@googlegroups.com
Forgot that, yes, we need to add this: field in order, that will hold domain, where order was originally created, also order should feature language, that user used on site, when order was created. This all would ensure, that he will receive order-related emails on it's language and not on admin's language.

> ...
>
> read more »

--
You received this message because you are subscribed to the Google Groups "In-Portal Development Team" group.

To post to this group, send email to in-por...@googlegroups.com.
To unsubscribe from this group, send email to in-portal-de...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/in-portal-dev?hl=en.

Dmitry Andrejev

unread,
Feb 10, 2010, 1:36:45 PM2/10/10
to in-por...@googlegroups.com
Hi guys,


Just to sum up and add something, here is what I have all together:


1. Site Domain user registered on under User Account (so it's accessible in User Management). Not sure as text or option (id).

2. Site Domain for Order where it placed.

3. User Language for Order when it was placed.


What you think?


Thanks.

DA.

Alexander Obuhovich

unread,
Feb 10, 2010, 2:59:45 PM2/10/10
to in-por...@googlegroups.com
Maybe there are other places where site domain could be useful?

Phil

unread,
Feb 11, 2010, 5:54:47 AM2/11/10
to In-Portal Development Team
1. Site Domain user registered on under User Account (so it's
accessible in
User Management). Not sure as text or option (id).
2. Site Domain for Order where it placed.
3. User Language for Order when it was placed.

+

4. e-mails and SSL via originating domain

5. shipping, payement & theme specific for each domain (for shipping
and payemen, this could be like we actually select groups for payement
modes)

Phil.

On Feb 10, 8:59 pm, Alexander Obuhovich <aik.b...@gmail.com> wrote:
> Maybe there are other places where site domain could be useful?
>

> On Wed, Feb 10, 2010 at 8:36 PM, Dmitry Andrejev <dandre...@gmail.com>wrote:
>
> > Hi guys,
>
> > Just to sum up and add something, here is what I have all together:
>
> > 1. Site Domain user registered on under User Account (so it's accessible in
> > User Management). Not sure as text or option (id).
>
> > 2. Site Domain for Order where it placed.
>
> > 3. User Language for Order when it was placed.
>
> > What you think?
>
> > Thanks.
>
> > DA.
>

> > On Wed, Feb 10, 2010 at 4:31 AM, Alexander Obuhovich <aik.b...@gmail.com>wrote:
>
> >> Forgot that, yes, we need to add this: field in order, that will hold
> >> domain, where order was originally created, also order should feature
> >> language, that user used on site, when order was created. This all would
> >> ensure, that he will receive order-related emails on it's language and not
> >> on admin's language.
>

> ...
>
> read more »

Dmitry A.

unread,
Feb 11, 2010, 11:04:45 AM2/11/10
to In-Portal Development Team
Thanks Phil,

This is all listed and most of it done already.

I would say that we are only missing:

1. Site Domain user registered on under User Account (so it's
accessible in
User Management). Not sure as text or option (id).
2. Site Domain for Order where it placed.
3. User Language for Order when it was placed.

4. Shipping Types - which wasn't intended to by included, but more I
think about - more I understand it might be a good idea to have.

Alex what you think - is the above time consuming for 5.1.0?

DA.

> ...
>
> read more »

Phil

unread,
Feb 12, 2010, 6:01:19 AM2/12/10
to In-Portal Development Team
for your info and to keep in touch with competitors:

http://www.magentocommerce.com/knowledge-base/entry/overview-how-multiple-websites-stores-work

P.

> ...
>
> read more »

Alexander Obuhovich

unread,
Feb 12, 2010, 9:55:29 AM2/12/10
to in-por...@googlegroups.com
Seems similar, but still our has some features, that their doesn't have. As of configuration point our implementation seems very simple related to theirs. There is one interesting point, that we don't have:
  • ability to specify module root categories on domain basis

Phil

unread,
Feb 13, 2010, 4:02:49 PM2/13/10
to In-Portal Development Team
It would great to be able to specify the root folder for each module.
This way we could select for each multisite if they display all or
part of product catalog, for example.

I like to look around what's allready done, and make the best of all
ideas :)


On Feb 12, 3:55 pm, Alexander Obuhovich <aik.b...@gmail.com> wrote:
> Seems similar, but still our has some features, that their doesn't have. As
> of configuration point our implementation seems very simple related to
> theirs. There is one interesting point, that we don't have:
>

>    - ability to specify module root categories on domain basis


>
> On Fri, Feb 12, 2010 at 1:01 PM, Phil <p...@domicilis.biz> wrote:
> > for your info and to keep in touch with competitors:
>

> >http://www.magentocommerce.com/knowledge-base/entry/overview-how-mult...

> ...
>
> read more »

Phil

unread,
Mar 3, 2010, 7:58:59 AM3/3/10
to In-Portal Development Team
I'd like to follow the coding details, about .htaccess and redirects,
as there 2 types of multisites that could be done:

a- setting domain aliases in the same hosting - we just have to
receive the info about domain name

b- another domain is sending request, acting as a proxy (mainly
because users cannot know that it's hosted in another place, and e-
mails can be setup separatly) - can we handle this too?

additionaly, will the new function will write the correct htaccess by
itself ?

thanks
Phil.

On 13 fév, 22:02, Phil <p...@domicilis.biz> wrote:
> It would great to be able to specify the root folder for each module.

> This way we could select for eachmultisiteif they display all or

> > > > > > >>> about shipping, this was in the idea of runningmultisitein 1

> ...
>
> plus de détails »

Alexander Obuhovich

unread,
Mar 3, 2010, 8:02:11 AM3/3/10
to in-por...@googlegroups.com
This discussion/task is about displaying (possibly with proper domain redirect) site on correct language based on language given by user's browser.

I don't really understand why you need .htaccess for that. Please provide examples.

Phil ..:: domicilis.biz ::..

unread,
Mar 3, 2010, 6:03:52 PM3/3/10
to in-por...@googlegroups.com
well, despite the original subject, we went on setting up the task http://tracker.in-portal.org/view.php?id=472 "to configure multiple Domains that this website is running on".

All the technical details about how to do it in admin is done, but how will In-Portal detect which domain it's coming from? Maybe it's a dumb question, and answer is obvious :-$


2010/3/3 Alexander Obuhovich <aik....@gmail.com>

Dmitry A.

unread,
Mar 3, 2010, 6:07:54 PM3/3/10
to In-Portal Development Team
Hi Phil,


It's not In-Portal it's apache (or other web-server) will pupulat
_SERVER['HOST'] or similar variable which already in use since day one
of In-Portal.

Let me know if this answers your question.


DA.


On Mar 3, 5:03 pm, "Phil ..:: domicilis.biz ::.." <p...@domicilis.biz>
wrote:
> well, despite the original subject, we went on setting up the taskhttp://tracker.in-portal.org/view.php?id=472"to configure multiple Domains


> that this website is running on".
>
> All the technical details about how to do it in admin is done, but how will
> In-Portal detect which domain it's coming from? Maybe it's a dumb question,
> and answer is obvious :-$
>

> 2010/3/3 Alexander Obuhovich <aik.b...@gmail.com>


>
>
>
> > This discussion/task is about displaying (possibly with proper domain
> > redirect) site on correct language based on language given by user's
> > browser.
>
> > I don't really understand why you need .htaccess for that. Please provide
> > examples.
>

Phil ..:: domicilis.biz ::..

unread,
Mar 4, 2010, 4:52:54 AM3/4/10
to in-por...@googlegroups.com
Hi Dmitry,

thanks for your answer, I'll perform my own test and let you know the results :)

Phil.

2010/3/4 Dmitry A. <dand...@gmail.com>

Alexander Obuhovich

unread,
Mar 9, 2010, 5:45:40 AM3/9/10
to in-por...@googlegroups.com
We miss "alt" on checkboxes, that allow to enter regular expression in domain names

Alexander Obuhovich

unread,
Mar 18, 2010, 6:53:44 AM3/18/10
to in-por...@googlegroups.com
It seems, that Payment Type list based on site domain isn't a useful feature at all. Actually payment type list based on user's billing country will be more appropriate.

Phil ..:: domicilis.biz ::..

unread,
Mar 18, 2010, 8:42:40 AM3/18/10
to in-por...@googlegroups.com
well, the idea is to create different websites, offering partial or
entire content from the main website, while being appearing "not
linked" to the main one.

If payment modes are the same, we lost all of this:
- paypal address would be the same
- popup window for credit card gateway would display the main
"merchant website address", confusing for customer
- Address to send check or money order would be the same
- account details would be the same for bank transfert

The feature isn't usefull in a test env., but in a commercial and
professionnal use, this is of main interest, don't you think so?


2010/3/18 Alexander Obuhovich <aik....@gmail.com>:

Alexander Obuhovich

unread,
Mar 19, 2010, 6:28:48 AM3/19/10
to in-por...@googlegroups.com
Do you really think, that there would be a setup, where need to different site based paypal email or store address? Payment method is same among all sites, since they all end up on same order list.

Dmitry Andrejev

unread,
Mar 19, 2010, 10:39:49 AM3/19/10
to in-por...@googlegroups.com
I agree with Phil here.

1. I have cases with website being used different PayPal accounts or payment Gateways... it's a real case scenario for online store. I want to be able to have different look and different payment options (accounts) for different stores - image if they are country specific and what's supported in USA is not necessarily supported in Europe (Latvia or France).

Alex, do you see my point here?


DA.

To unsubscribe from this group, send email to in-portal-dev+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Alexander Obuhovich

unread,
Mar 19, 2010, 10:52:44 AM3/19/10
to in-por...@googlegroups.com
See point, don't see this on interface. We should move payment type management section under site domain?

Dmitry Andrejev

unread,
Mar 19, 2010, 10:58:42 AM3/19/10
to in-por...@googlegroups.com
Yes, I believe so!

Similar as we do with Languages?!

In my opinion it will make it more practical for e-commerce websites when you can select the Payment types that are available for Site domains (if used of course).


Thanks.

DA.

Alexander Obuhovich

unread,
Mar 19, 2010, 11:09:17 AM3/19/10
to in-por...@googlegroups.com
It seems, that you have forgotten, that with languages we only select if it's available or not in a small control, but with payment types we need to select whole stuff, from name to allowed currencies to group based payment types and all 3 tabs.

Phil ..:: domicilis.biz ::..

unread,
Mar 19, 2010, 11:14:14 AM3/19/10
to in-por...@googlegroups.com
Dmitry gave another interesting case, and I resume with mine:

- for commercial need, we sometime need to have 2 differents website,
for a simple idea : creating your own competitor ! then we need to
avoid any evident link with primary website, like payment method

- as Dmitry said, if you are running business for example in euro zone
and outside EU, for example with Switzerland, we would need euro based
payment mode and swiss based payement mode if we don't want customer
to pay foreign transaction fees

- and finally, if we use multisite for selling to different countries,
we need to adapt the offer: I wouldn't want to use credit card payment
if I sell to Africa, while I'll accept it for western Europe ^-^

About coding, should it be possible to do it the way we do for groups?


2010/3/19 Alexander Obuhovich <aik....@gmail.com>:

Dmitry Andrejev

unread,
Mar 19, 2010, 11:14:41 AM3/19/10
to in-por...@googlegroups.com
No, we make it simpler!

We still define all Payment types as we where before. I would probably have another Admin Note field shows next to the Payment Type so it's easy to distinguish if I have multiple Authorize.net or PayPal accounts. Example, PayPal (france) where france would be that Admin comment) or short comment (if we have comment field already.

On Site Domain definition we are selecting the ones we need to me available when that site domain is in affect.

Make sense now?


DA.

Alexander Obuhovich

unread,
Mar 19, 2010, 11:19:31 AM3/19/10
to in-por...@googlegroups.com
About Phil Note:


- and finally, if we use multisite for selling to different countries,
we need to adapt the offer: I wouldn't want to use credit card payment
if I sell to Africa, while I'll accept it for western Europe ^-^

We already have something alike in development, when for each payment type (when appropriate) I specify countries, where it will available (matching by billing country from order).

About Dmitry node:


On Site Domain definition we are selecting the ones we need to me available when that site domain is in affect.

This is already implemented to have site domain based payment types.

So it seems it's almost done. Dmitry made important note to have all possible payment types defined in "Payment Types" section and select proper ones for each site domain. I also agree.

Phil ..:: domicilis.biz ::..

unread,
Mar 19, 2010, 11:35:24 AM3/19/10
to in-por...@googlegroups.com
Good idea Dmitry, we can simply use the payment mode ID or the actual
"admin note" that I never used before.

Please note that payment country-related isn't the same as
site-related. If you run your own competitor, you'll sell in the same
countries, but with different payement types.

Last thing I thought yesterday evening when I was about to sleep: can
we also have a system where an affiliate is proprietary of a
multisite? Just by adding it's affiliate code in theme's header?
Just by adding this we'll have a brand new feature: ability to open
affiliates store !

Don't your think it could be great?

2010/3/19 Alexander Obuhovich <aik....@gmail.com>:

Alexander Obuhovich

unread,
Mar 19, 2010, 12:18:55 PM3/19/10
to in-por...@googlegroups.com
You mean save current site name on affiliate record and use it later somehow.

Phil ..:: domicilis.biz ::..

unread,
Mar 19, 2010, 12:50:09 PM3/19/10
to in-por...@googlegroups.com
I mean considering all sales made on selected website to belong to an
affiliate, wherever we setup this.

2010/3/19 Alexander Obuhovich <aik....@gmail.com>:

Dmitry Andrejev

unread,
Mar 19, 2010, 12:52:44 PM3/19/10
to in-por...@googlegroups.com
I would leave Affiliates out of this for now, and would consider it as improvement in the round two for this feature.

DA.

Phil ..:: domicilis.biz ::..

unread,
Mar 19, 2010, 1:09:40 PM3/19/10
to in-por...@googlegroups.com
It was another idea, I think that implementing affiliate code
somewhere in cart for example would do the trick.


2010/3/19 Dmitry Andrejev <dand...@gmail.com>:

Dmitry Andrejev

unread,
Mar 20, 2010, 12:35:32 AM3/20/10
to in-por...@googlegroups.com
Hi Alex,

Would you please put a clear list of what we have to do here yet considering quite a lot is already done.

Cheers!

DA.

Alexander Obuhovich

unread,
Mar 20, 2010, 3:09:27 PM3/20/10
to in-por...@googlegroups.com
Seems this is it, since what we talked about payment types is already implemented in patch.
    1. Site Domain user registered on under User Account (so it's accessible in User Management). Not sure as text or option (id).
    1. Site Domain for Order where it placed.
    1. User Language for Order when it was placed.

    Phil ..:: domicilis.biz ::..

    unread,
    Mar 20, 2010, 6:30:51 PM3/20/10
    to in-por...@googlegroups.com
    For User account, I'd suggest an option using ID, as for everyday use
    it'd be very usefull to display users belonging only to a single
    domain.

    Based on this, could we have group containing only users from a
    domain? I imagine the everyday life of a multisite, and it'd be
    necessary to mail/export users from a given multisite.

    I'd like to say here that all these features make In-Portal playing in
    the next level of merchants softwares, as such fonctionnality can be
    involved in big merchant projects!


    2010/3/20 Alexander Obuhovich <aik....@gmail.com>:

    Dmitry Andrejev

    unread,
    Mar 21, 2010, 12:48:54 AM3/21/10
    to in-por...@googlegroups.com
    Yes, we should do User as options (not text).

    Phil, there will be a options filter in User Management grid.

    DA.

    Phil ..:: domicilis.biz ::..

    unread,
    Mar 21, 2010, 7:27:56 AM3/21/10
    to in-por...@googlegroups.com
    Ok for users, and what about groups?

    2010/3/21 Dmitry Andrejev <dand...@gmail.com>:

    Alexander Obuhovich

    unread,
    Mar 21, 2010, 8:25:04 AM3/21/10
    to in-por...@googlegroups.com
    No need for groups, since as Dmitry said there will be new column "Site Domain" in users list (dropdown), where you can filter only users, that have registered via specific domain only.

    Phil ..:: domicilis.biz ::..

    unread,
    Mar 21, 2010, 9:53:17 AM3/21/10
    to in-por...@googlegroups.com
    Group was about everyday living of website, for marketing purposes.

    How to send an e-mail to users belonging of one particular website? ;-)


    2010/3/21 Alexander Obuhovich <aik....@gmail.com>:

    Dmitry Andrejev

    unread,
    Mar 23, 2010, 2:58:25 AM3/23/10
    to in-por...@googlegroups.com
    Phil,

    All this is moving into direction of let me run multiple websites using the same Database and Admin...

    Believe me I can list so many things if we are going in this direction - we'll never complete them soon enough.

    While I am NOT again all these new things - we need to prioritize. I can recommend stopping now with adding more features to this, but Phil can take a solid responsibility of putting together initial specification and then leading the discussion for Multi-website module or project - whatever we call it. 

    DA.

    Phil ..:: domicilis.biz ::..

    unread,
    Mar 23, 2010, 7:16:53 AM3/23/10
    to in-por...@googlegroups.com
    I can take this responsabilty, in my last night I thougth that
    feature, used for multiste as well as same site with many domain
    lang-related names could be a module itself, called "Multisite gears".
    It could be a module because it adds a lot of setup things, and thus
    couldn't be usefull for average user.

    This module permit to run bigger projects, to create more sales, to
    improve web presence, better SEO... It could deserve its own
    presentation.


    2010/3/23 Dmitry Andrejev <dand...@gmail.com>:

    Alexander Obuhovich

    unread,
    Mar 23, 2010, 7:38:13 AM3/23/10
    to in-por...@googlegroups.com
    Due the deep system integration we can't move it to module, since parts, that module will override can't be overridden by "Custom" module later and that's bad. That's problem of PHP inability to extend same class twice.

    Phil ..:: domicilis.biz ::..

    unread,
    Mar 23, 2010, 8:07:37 AM3/23/10
    to in-por...@googlegroups.com
    allright for me anyway :)

    2010/3/23 Alexander Obuhovich <aik....@gmail.com>:

    > ...
    >
    > [Message tronqué]

    Dmitry Andrejev

    unread,
    Mar 23, 2010, 11:49:16 AM3/23/10
    to in-por...@googlegroups.com
    Phil, I recommend you start a new discussion for Multi site support and work out specs there.

    Of course will be helping with this, but until we have all aspects (and there is a LOT) covered, we can't create a task. I think you should go section by section to review how it will be affected by Multi-Site and what it needs to do.

    DA.

    Phil ..:: domicilis.biz ::..

    unread,
    Mar 23, 2010, 6:20:31 PM3/23/10
    to in-por...@googlegroups.com
    well, I'll first test and evaluate all the job done or on the way to be done, as we have launched many things about this.

    Let me see what we have before requesting something else, I'm not a compulsive demander :-)


    2010/3/23 Dmitry Andrejev <dand...@gmail.com>
    ...

    [Message tronqué]  

    Reply all
    Reply to author
    Forward
    0 new messages