Implement site content language negotiation

[Alexander Obuhovich]

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.]

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]

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.]

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]

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.]

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.]

Alex, Sergey - what are your thoughts on what I described earlier?

Cheers!

DA.

[Alexander Obuhovich]

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.]

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]

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]

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]

Nothing, this is pretty simple.

[Phil]

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]

- 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]

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]

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]

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]

Maybe there are other places where site domain could be useful?

[Phil]

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.]

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]

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]

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]

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]

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]

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 ::..]

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.]

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 ::..]

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]

We miss "alt" on checkboxes, that allow to enter regular expression in domain names

[Alexander Obuhovich]

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 ::..]

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]

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]

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]

See point, don't see this on interface. We should move payment type management section under site domain?

[Dmitry Andrejev]

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]

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 ::..]

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]

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]

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 ::..]

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]

You mean save current site name on affiliate record and use it later somehow.

[Phil ..:: domicilis.biz ::..]

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]

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 ::..]

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]

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]

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 ::..]

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]

Yes, we should do User as options (not text).

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

DA.

[Phil ..:: domicilis.biz ::..]

Ok for users, and what about groups?

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

[Alexander Obuhovich]

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 ::..]

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]

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 ::..]

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]

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 ::..]

allright for me anyway :)

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

> ...
>
> [Message tronqué]

[Dmitry Andrejev]

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 ::..]

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é]