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.
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
> 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.
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'].
On Wed, Dec 16, 2009 at 11:10 PM, Dmitry A. <dandre...@gmail.com> wrote:
> 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
> > 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.
> 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-portal-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> in-portal-dev+unsubscribe@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.
> 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'].
> On Wed, Dec 16, 2009 at 11:10 PM, Dmitry A. <dandre...@gmail.com> wrote:
> > 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
> > > 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.
> > 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-portal-dev@googlegroups.com.
> > To unsubscribe from this group, send email to
> > in-portal-dev+unsubscribe@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.
On Wed, Dec 16, 2009 at 11:55 PM, Dmitry A. <dandre...@gmail.com> wrote:
> 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.
> On Dec 16, 3:26 pm, Alexander Obuhovich <aik.b...@gmail.com> wrote:
> > 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'].
> > On Wed, Dec 16, 2009 at 11:10 PM, Dmitry A. <dandre...@gmail.com> wrote:
> > > 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
> > > > 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.
> > > 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-portal-dev@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > in-portal-dev+unsubscribe@googlegroups.com<in-portal-dev%2Bunsubscribe@goog legroups.com>
> <in-portal-dev%2Bunsubscribe@googlegroups.com>
> > > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/in-portal-dev?hl=en.
> 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-portal-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> in-portal-dev+unsubscribe@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.
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
On Dec 16, 3:58 pm, Alexander Obuhovich <aik.b...@gmail.com> wrote:
> I would add "+ Available Themes" too in case if themes are using skin > selector (like language selector).
> On Wed, Dec 16, 2009 at 11:55 PM, Dmitry A. <dandre...@gmail.com> wrote: > > 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.
> > On Dec 16, 3:26 pm, Alexander Obuhovich <aik.b...@gmail.com> wrote: > > > 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'].
> > > On Wed, Dec 16, 2009 at 11:10 PM, Dmitry A. <dandre...@gmail.com> wrote: > > > > 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 > > > > > 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.
> > > > 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-portal-dev@googlegroups.com. > > > > To unsubscribe from this group, send email to > > > > in-portal-dev+unsubscribe@googlegroups.com<in-portal-dev%2Bunsubscribe@goog legroups.com> > > <in-portal-dev%2Bunsubscribe@googlegroups.com> > > > > . > > > > For more options, visit this group at > > > >http://groups.google.com/group/in-portal-dev?hl=en.
> > 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-portal-dev@googlegroups.com. > > To unsubscribe from this group, send email to > > in-portal-dev+unsubscribe@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.
> 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
> On Dec 16, 3:58 pm, Alexander Obuhovich <aik.b...@gmail.com> wrote:
> > I would add "+ Available Themes" too in case if themes are using skin > > selector (like language selector).
> > On Wed, Dec 16, 2009 at 11:55 PM, Dmitry A. <dandre...@gmail.com> wrote: > > > 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.
> > > On Dec 16, 3:26 pm, Alexander Obuhovich <aik.b...@gmail.com> wrote: > > > > 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'].
> > > > On Wed, Dec 16, 2009 at 11:10 PM, Dmitry A. <dandre...@gmail.com> wrote: > > > > > 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 > > > > > > 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.
> > > > > 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-portal-dev@googlegroups.com. > > > > > To unsubscribe from this group, send email to > > > > > in-portal-dev+unsubscribe@googlegroups.com<in-portal-dev%2Bunsubscribe@goog legroups.com> > > > <in-portal-dev%2Bunsubscribe@googlegroups.com> > > > > > . > > > > > For more options, visit this group at > > > > >http://groups.google.com/group/in-portal-dev?hl=en.
> > > 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-portal-dev@googlegroups.com. > > > To unsubscribe from this group, send email to > > > in-portal-dev+unsubscribe@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.
On Sun, Dec 20, 2009 at 8:12 AM, Dmitry A. <dandre...@gmail.com> wrote: > Alex, Sergey - what are your thoughts on what I described earlier?
> Cheers!
> DA.
> On Dec 17, 8:48 pm, "Dmitry A." <dandre...@gmail.com> wrote: > > 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
> > On Dec 16, 3:58 pm, Alexander Obuhovich <aik.b...@gmail.com> wrote:
> > > I would add "+ Available Themes" too in case if themes are using skin > > > selector (like language selector).
> > > On Wed, Dec 16, 2009 at 11:55 PM, Dmitry A. <dandre...@gmail.com> > wrote: > > > > 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.
> > > > On Dec 16, 3:26 pm, Alexander Obuhovich <aik.b...@gmail.com> wrote: > > > > > 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'].
> > > > > On Wed, Dec 16, 2009 at 11:10 PM, Dmitry A. <dandre...@gmail.com> > wrote: > > > > > > 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 > > > > > > > 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.
> > > > > > 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-portal-dev@googlegroups.com. > > > > > > To unsubscribe from this group, send email to > > > > > > in-portal-dev+unsubscribe@googlegroups.com<in-portal-dev%2Bunsubscribe@goog legroups.com> > <in-portal-dev%2Bunsubscribe@googlegroups.com<in-portal-dev%252Bunsubscribe @googlegroups.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-portal-dev@googlegroups.com. > > > > To unsubscribe from this group, send email to > > > > in-portal-dev+unsubscribe@googlegroups.com<in-portal-dev%2Bunsubscribe@goog legroups.com> > <in-portal-dev%2Bunsubscribe@googlegroups.com<in-portal-dev%252Bunsubscribe @googlegroups.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-portal-dev@googlegroups.com. > To unsubscribe from this group, send email to > in-portal-dev+unsubscribe@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.
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:
> On Sun, Dec 20, 2009 at 8:12 AM, Dmitry A. <dandre...@gmail.com> wrote: > > Alex, Sergey - what are your thoughts on what I described earlier?
> > Cheers!
> > DA.
> > On Dec 17, 8:48 pm, "Dmitry A." <dandre...@gmail.com> wrote: > > > 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
> > > On Dec 16, 3:58 pm, Alexander Obuhovich <aik.b...@gmail.com> wrote:
> > > > I would add "+ Available Themes" too in case if themes are using skin > > > > selector (like language selector).
> > > > On Wed, Dec 16, 2009 at 11:55 PM, Dmitry A. <dandre...@gmail.com> > > wrote: > > > > > 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.
> > > > > On Dec 16, 3:26 pm, Alexander Obuhovich <aik.b...@gmail.com> wrote: > > > > > > 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'].
> > > > > > On Wed, Dec 16, 2009 at 11:10 PM, Dmitry A. <dandre...@gmail.com> > > wrote: > > > > > > > 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 > > > > > > > > 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.
> > > > > > > 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-portal-dev@googlegroups.com. > > > > > > > To unsubscribe from this group, send email to > > > > > > > in-portal-dev+unsubscribe@googlegroups.com<in-portal-dev%2Bunsubscribe@goog legroups.com> > > <in-portal-dev%2Bunsubscribe@googlegroups.com<in-portal-dev%252Bunsubscribe @googlegroups.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-portal-dev@googlegroups.com. > > > > > To unsubscribe from this group, send email to > > > > > in-portal-dev+unsubscribe@googlegroups.com<in-portal-dev%2Bunsubscribe@goog legroups.com> > > <in-portal-dev%2Bunsubscribe@googlegroups.com<in-portal-dev%252Bunsubscribe @googlegroups.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-portal-dev@googlegroups.com. > > To unsubscribe from this group, send email to > > in-portal-dev+unsubscribe@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.
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.
> 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:
> > On Sun, Dec 20, 2009 at 8:12 AM, Dmitry A. <dandre...@gmail.com> wrote: > > > Alex, Sergey - what are your thoughts on what I described earlier?
> > > Cheers!
> > > DA.
> > > On Dec 17, 8:48 pm, "Dmitry A." <dandre...@gmail.com> wrote: > > > > 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
> > > > On Dec 16, 3:58 pm, Alexander Obuhovich <aik.b...@gmail.com> wrote:
> > > > > I would add "+ Available Themes" too in case if themes are using > skin > > > > > selector (like language selector).
> > > > > On Wed, Dec 16, 2009 at 11:55 PM, Dmitry A. <dandre...@gmail.com> > > > wrote: > > > > > > 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.
> > > > > > On Dec 16, 3:26 pm, Alexander Obuhovich <aik.b...@gmail.com> > wrote: > > > > > > > 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'].
> > > > > > > On Wed, Dec 16, 2009 at 11:10 PM, Dmitry A. < > dandre...@gmail.com> > > > wrote: > > > > > > > > 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 > > > > > > > > > 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.
> > > > > > 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-portal-dev@googlegroups.com. > > > > > > To unsubscribe from this group, send email to > > > > > > in-portal-dev+unsubscribe@googlegroups.com<in-portal-dev%2Bunsubscribe@goog legroups.com> > <in-portal-dev%2Bunsubscribe@goog legroups.com> > > > <in-portal-dev%2Bunsubscribe@googlegroups.com<in-portal-dev%252Bunsubscribe @googlegroups.com><in-portal-dev%252Bunsubscribe > @googlegroups.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-portal-dev@googlegroups.com. > > > To unsubscribe from this group, send email to > > > in-portal-dev+unsubscribe@googlegroups.com<in-portal-dev%2Bunsubscribe@goog legroups.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.
> -- > 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-portal-dev@googlegroups.com. > To unsubscribe from this group, send email to > in-portal-dev+unsubscribe@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.
> 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:
>> 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:
>> > On Sun, Dec 20, 2009 at 8:12 AM, Dmitry A. <dandre...@gmail.com> wrote: >> > > Alex, Sergey - what are your thoughts on what I described earlier?
>> > > Cheers!
>> > > DA.
>> > > On Dec 17, 8:48 pm, "Dmitry A." <dandre...@gmail.com> wrote: >> > > > 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
>> > > > On Dec 16, 3:58 pm, Alexander Obuhovich <aik.b...@gmail.com> wrote:
>> > > > > I would add "+ Available Themes" too in case if themes are using >> skin >> > > > > selector (like language selector).
>> > > > > On Wed, Dec 16, 2009 at 11:55 PM, Dmitry A. <dandre...@gmail.com> >> > > wrote: >> > > > > > 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.
>> > > > > > On Dec 16, 3:26 pm, Alexander Obuhovich <aik.b...@gmail.com> >> wrote: >> > > > > > > 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'].
>> > > > > > > On Wed, Dec 16, 2009 at 11:10 PM, Dmitry A. < >> dandre...@gmail.com> >> > > wrote: >> > > > > > > > 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 >> > > > > > > > > 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.
>> > > > > > 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-portal-dev@googlegroups.com. >> > > > > > To unsubscribe from this group, send email to >> > > > > > in-portal-dev+unsubscribe@googlegroups.com<in-portal-dev%2Bunsubscribe@goog legroups.com> >> <in-portal-dev%2Bunsubscribe@goog legroups.com> >> > > <in-portal-dev%2Bunsubscribe@googlegroups.com<in-portal-dev%252Bunsubscribe @googlegroups.com><in-portal-dev%252Bunsubscribe >> @googlegroups.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-portal-dev@googlegroups.com. >> > > To unsubscribe from this group, send email to >> > > in-portal-dev+unsubscribe@googlegroups.com<in-portal-dev%2Bunsubscribe@goog legroups.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.
>> -- >> 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-portal-dev@googlegroups.com. >> To unsubscribe from this group, send email to >> in-portal-dev+unsubscribe@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.
> -- > 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-portal-dev@googlegroups.com. > To unsubscribe from this group, send email to
> 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:
>>> 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:
>>> > On Sun, Dec 20, 2009 at 8:12 AM, Dmitry A. <dandre...@gmail.com> >>> wrote: >>> > > Alex, Sergey - what are your thoughts on what I described earlier?
>>> > > Cheers!
>>> > > DA.
>>> > > On Dec 17, 8:48 pm, "Dmitry A." <dandre...@gmail.com> wrote: >>> > > > 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
>>> > > > On Dec 16, 3:58 pm, Alexander Obuhovich <aik.b...@gmail.com> >>> wrote:
>>> > > > > I would add "+ Available Themes" too in case if themes are using >>> skin >>> > > > > selector (like language selector).
>>> > > > > On Wed, Dec 16, 2009 at 11:55 PM, Dmitry A. <dandre...@gmail.com
>>> > > wrote: >>> > > > > > 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.
>>> > > > > > On Dec 16, 3:26 pm, Alexander Obuhovich <aik.b...@gmail.com> >>> wrote: >>> > > > > > > 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'].
>>> > > > > > > On Wed, Dec 16, 2009 at 11:10 PM, Dmitry A. < >>> dandre...@gmail.com> >>> > > wrote: >>> > > > > > > > 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 >>> > > > > > > > > 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.
>>> > > > > > 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-portal-dev@googlegroups.com. >>> > > > > > To unsubscribe from this group, send email to >>> > > > > > in-portal-dev+unsubscribe@googlegroups.com<in-portal-dev%2Bunsubscribe@goog legroups.com> >>> <in-portal-dev%2Bunsubscribe@goog legroups.com> >>> > > <in-portal-dev%2Bunsubscribe@googlegroups.com<in-portal-dev%252Bunsubscribe @googlegroups.com><in-portal-dev%252Bunsubscribe >>> @googlegroups.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-portal-dev@googlegroups.com. >>> > > To unsubscribe from this group, send email to >>> > > in-portal-dev+unsubscribe@googlegroups.com<in-portal-dev%2Bunsubscribe@goog legroups.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.
>>> -- >>> 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-portal-dev@googlegroups.com. >>> To unsubscribe from this group, send email to >>> in-portal-dev+unsubscribe@googlegroups.com<in-portal-dev%2Bunsubscribe@goog legroups.com> >>> . >>> For more options, visit this group at
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:
> 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:
> >>> 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:
> >>> > On Sun, Dec 20, 2009 at 8:12 AM, Dmitry A. <dandre...@gmail.com> > >>> wrote: > >>> > > Alex, Sergey - what are your thoughts on what I described earlier?
> >>> > > Cheers!
> >>> > > DA.
> >>> > > On Dec 17, 8:48 pm, "Dmitry A." <dandre...@gmail.com> wrote: > >>> > > > 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
> >>> > > > On Dec 16, 3:58 pm, Alexander Obuhovich <aik.b...@gmail.com> > >>> wrote:
> >>> > > > > I would add "+ Available Themes" too in case if themes are using > >>> skin > >>> > > > > selector (like language selector).
> >>> > > > > On Wed, Dec 16, 2009 at 11:55 PM, Dmitry A. <dandre...@gmail.com
> >>> > > wrote: > >>> > > > > > 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.
> >>> > > > > > On Dec 16, 3:26 pm, Alexander Obuhovich <aik.b...@gmail.com> > >>> wrote: > >>> > > > > > > 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'].
> >>> > > > > > > On Wed, Dec 16, 2009 at 11:10 PM, Dmitry A. < > >>> dandre...@gmail.com> > >>> > > wrote: > >>> > > > > > > > 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 > >>> > > > > > > > > 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.
> >>> > > > > > 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-portal-dev@googlegroups.com. > >>> > > > > > To unsubscribe from this group, send email to > >>> > > > > > in-portal-dev+unsubscribe@googlegroups.com<in-portal-dev%2Bunsubscribe@goog legroups.com> > >>> <in-portal-dev%2Bunsubscribe@goog legroups.com> > >>> > > <in-portal-dev%2Bunsubscribe@googlegroups.com<in-portal-dev%252Bunsubscribe @googlegroups.com><in-portal-dev%252Bunsubscribe > >>> @googlegroups.com>
> >>> > > You received this message because you are subscribed to the Google > >>> Groups > >>> > > "In-Portal Development" group. > >>> > > To post to this
*- 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.
On Tue, Feb 9, 2010 at 6:24 PM, Phil <p...@domicilis.biz> wrote: > 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:
> > >>> 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:
> > >>> > On Sun, Dec 20, 2009 at 8:12 AM, Dmitry A. <dandre...@gmail.com> > > >>> wrote: > > >>> > > Alex, Sergey - what are your thoughts on what I described > earlier?
> > >>> > > > 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
> > >>> > > > On Dec 16, 3:58 pm, Alexander Obuhovich <aik.b...@gmail.com> > > >>> wrote:
> > >>> > > > > I would add "+ Available Themes" too in case if themes are > using > > >>> skin > > >>> > > > > selector (like language selector).
> > >>> > > > > On Wed, Dec 16, 2009 at 11:55 PM, Dmitry A. < > dandre...@gmail.com
> > >>> > > wrote: > > >>> > > > > > 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)
> > >>> > > > > > 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.
> > >>> > > > > > On Dec 16, 3:26 pm, Alexander Obuhovich < > aik.b...@gmail.com> > > >>> wrote: > > >>> > > > > > > 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'].
> > >>> > > > > > > On Wed, Dec 16, 2009 at 11:10 PM, Dmitry A. < > > >>> dandre...@gmail.com> > > >>> > > wrote: > > >>> > > > > > > > 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 > > >>> > > > > > > > > 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.
> *- 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.
> On Tue, Feb 9, 2010 at 6:24 PM, Phil <p...@domicilis.biz> wrote: > > 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:
> > > >>> 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:
> > > >>> > On Sun, Dec 20, 2009 at 8:12 AM, Dmitry A. <dandre...@gmail.com> > > > >>> wrote: > > > >>> > > Alex, Sergey - what are your thoughts on what I described > > earlier?
> > > >>> > > > 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
> > > >>> > > > On Dec 16, 3:58 pm, Alexander Obuhovich <aik.b...@gmail.com> > > > >>> wrote:
> > > >>> > > > > I would add "+ Available Themes" too in case if themes are > > using > > > >>> skin > > > >>> > > > > selector (like language selector).
> > > >>> > > > > On Wed, Dec 16, 2009 at 11:55 PM, Dmitry A. < > > dandre...@gmail.com
> > > >>> > > wrote: > > > >>> > > > > > 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)
> > > >>> > > > > > 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.
> > > >>> > > > > > On Dec 16, 3:26 pm, Alexander Obuhovich < > > aik.b...@gmail.com> > > > >>> wrote: > > > >>> > > > > > > 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'].
> > > >>> > > > > > > On Wed, Dec 16, 2009 at 11:10 PM, Dmitry A. < > > > >>> dandre...@gmail.com> > > > >>> > > wrote: > > > >>> > > > > > > > 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 > > > >>> > > > > > > > > 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.
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.
On Wed, Feb 10, 2010 at 12:27 PM, Phil <p...@domicilis.biz> wrote: > 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.
> > On Tue, Feb 9, 2010 at 6:24 PM, Phil <p...@domicilis.biz> wrote: > > > 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:
> > > > >>> 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:
> > > > >>> > On Sun, Dec 20, 2009 at 8:12 AM, Dmitry A. < > dandre...@gmail.com> > > > > >>> wrote: > > > > >>> > > Alex, Sergey - what are your thoughts on what I described > > > earlier?
> > > > >>> > > > 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
> > > > >>> > > > On Dec 16, 3:58 pm, Alexander Obuhovich < > aik.b...@gmail.com> > > > > >>> wrote:
> > > > >>> > > > > I would add "+ Available Themes" too in case if themes > are > > > using > > > > >>> skin > > > > >>> > > > > selector (like language selector).
> > > > >>> > > > > On Wed, Dec 16, 2009 at 11:55 PM, Dmitry A. < > > > dandre...@gmail.com
> > > > >>> > > wrote: > > > > >>> > > > > > 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)
> > > > >>> > > > > > 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.
> > > > >>> > > > > > On Dec 16, 3:26 pm, Alexander Obuhovich < > > > aik.b...@gmail.com> > > > > >>> wrote: > > > > >>> > > > > > > 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'].
> > > > >>> > > > > > > On Wed, Dec 16, 2009 at 11:10 PM, Dmitry A. < > > > > >>> dandre...@gmail.com> > > > > >>> > > wrote: > > > > >>> > > > > > > > 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 > > > > >>> > > > > > > > > for all users). Of course later user can choose > other > > > > >>> language > > > > >>> > > later. > > > > >>> > > > > > > > There > > > > >>> > > > > > > > > is such setting in user browser as preferred > > > languages, > > > > >>> where
> 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.
> On Wed, Feb 10, 2010 at 12:27 PM, Phil <p...@domicilis.biz> wrote:
>> 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.
>> > On Tue, Feb 9, 2010 at 6:24 PM, Phil <p...@domicilis.biz> wrote: >> > > 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
>> > > > >>> 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:
>> > > > >>> > On Sun, Dec 20, 2009 at 8:12 AM, Dmitry A. < >> dandre...@gmail.com> >> > > > >>> wrote: >> > > > >>> > > Alex, Sergey - what are your thoughts on what I described >> > > earlier?
>> > > > >>> > > > 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
>> > > > >>> > > > On Dec 16, 3:58 pm, Alexander Obuhovich < >> aik.b...@gmail.com> >> > > > >>> wrote:
>> > > > >>> > > > > I would add "+ Available Themes" too in case if themes >> are >> > > using >> > > > >>> skin >> > > > >>> > > > > selector (like language selector).
>> > > > >>> > > > > On Wed, Dec 16, 2009 at 11:55 PM, Dmitry A. < >> > > dandre...@gmail.com
>> > > > >>> > > wrote: >> > > > >>> > > > > > 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)
>> > > > >>> > > > > > 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.
>> > > > >>> > > > > > On Dec 16, 3:26 pm, Alexander Obuhovich < >> > > aik.b...@gmail.com> >> > > > >>> wrote: >> > > > >>> > > > > > > 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'].
>> > > > >>> > > > > > > On Wed, Dec 16, 2009 at 11:10 PM, Dmitry A. < >> > > > >>> dandre...@gmail.com> >> > > > >>> > > wrote: >> > > > >>> > > > > > > > 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
> 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.
>> On Wed, Feb 10, 2010 at 12:27 PM, Phil <p...@domicilis.biz> wrote:
>>> 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.
>>> > On Tue, Feb 9, 2010 at 6:24 PM, Phil <p...@domicilis.biz> wrote: >>> > > 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:
>>> > > > >>> 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:
>>> > > > >>> > On Sun, Dec 20, 2009 at 8:12 AM, Dmitry A. < >>> dandre...@gmail.com> >>> > > > >>> wrote: >>> > > > >>> > > Alex, Sergey - what are your thoughts on what I described >>> > > earlier?
>>> > > > >>> > > > 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
>>> > > > >>> > > > On Dec 16, 3:58 pm, Alexander Obuhovich < >>> aik.b...@gmail.com> >>> > > > >>> wrote:
>>> > > > >>> > > > > I would add "+ Available Themes" too in case if themes >>> are >>> > > using >>> > > > >>> skin >>> > > > >>> > > > > selector (like language selector).
>>> > > > >>> > > > > On Wed, Dec 16, 2009 at 11:55 PM, Dmitry A. < >>> > > dandre...@gmail.com
>>> > > > >>> > > wrote: >>> > > > >>> > > > > > 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)
>>> > > > >>> > > > > > 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.
>>> > > > >>> > > > > > On Dec 16, 3:26 pm, Alexander Obuhovich < >>> > > aik.b...@gmail.com> >>> > > > >>> wrote: >>> > > > >>> > > > > > > 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'].
>>> > > > >>> > > > > > > On Wed, Dec 16, 2009 at 11:10 PM, Dmitry A. < >>> > > > >>> dandre...@gmail.com> >>> > > > >>> > > wrote: >>> > > > >>> > > > > > > > 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.
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.
> >> On Wed, Feb 10, 2010 at 12:27 PM, Phil <p...@domicilis.biz> wrote:
> >>> 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.
> >>> > On Tue, Feb 9, 2010 at 6:24 PM, Phil <p...@domicilis.biz> wrote: > >>> > > 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:
> >>> > > > >>> 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:
> >>> > > > >>> > On Sun, Dec 20, 2009 at 8:12 AM, Dmitry A. < > >>> dandre...@gmail.com> > >>> > > > >>> wrote: > >>> > > > >>> > > Alex, Sergey - what are your thoughts on what I described > >>> > > earlier?
> >>> > > > >>> > > > 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
> >>> > > > >>> > > > On Dec 16, 3:58 pm, Alexander Obuhovich < > >>> aik.b...@gmail.com> > >>> > > > >>> wrote:
> >>> > > > >>> > > > > I would add "+ Available Themes" too in case if themes > >>> are > >>> > > using > >>> > > > >>> skin > >>> > > > >>> > > > > selector (like language selector).
> >>> > > > >>> > > > > On Wed, Dec 16, 2009 at 11:55 PM, Dmitry A. < > >>> > > dandre...@gmail.com
> >>> > > > >>> > > wrote: > >>> > > > >>> > > > > > 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)
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.
On Feb 11, 4:54 am, Phil <p...@domicilis.biz> wrote:
> 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.
> > >> On Wed, Feb 10, 2010 at 12:27 PM, Phil <p...@domicilis.biz> wrote:
> > >>> 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.
> > >>> > On Tue, Feb 9, 2010 at 6:24 PM, Phil <p...@domicilis.biz> wrote: > > >>> > > 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:
> > >>> > > > >>> 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:
> > >>> > > > >>> > > > 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.
> 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.
> On Feb 11, 4:54 am, Phil <p...@domicilis.biz> wrote:
> > 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.
> > > >> On Wed, Feb 10, 2010 at 12:27 PM, Phil <p...@domicilis.biz> wrote:
> > > >>> 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.
> > > >>> > On Tue, Feb 9, 2010 at 6:24 PM, Phil <p...@domicilis.biz> wrote: > > > >>> > > 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:
> > > >>> > > > >>> 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:
> > > >>> > > > >>> > > > 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.
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 Feb 11, 5:04 pm, "Dmitry A." <dandre...@gmail.com> wrote: > > 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.
> > On Feb 11, 4:54 am, Phil <p...@domicilis.biz> wrote:
> > > 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.
> > > > >> On Wed, Feb 10, 2010 at 12:27 PM, Phil <p...@domicilis.biz> > wrote:
> > > > >>> 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.
> > > > >>> > On Tue, Feb 9, 2010 at 6:24 PM, Phil <p...@domicilis.biz> > wrote: > > > > >>> > > 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 :)
> > > > >>> > > 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.
> > > > >>> > > > > 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:
> > > > >>> > > > >>> 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:
> > > > >>> > > > >>> > > > 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.
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:
> > On Feb 11, 5:04 pm, "Dmitry A." <dandre...@gmail.com> wrote: > > > 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.
> > > On Feb 11, 4:54 am, Phil <p...@domicilis.biz> wrote:
> > > > 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.
> > > > > >> On Wed, Feb 10, 2010 at 12:27 PM, Phil <p...@domicilis.biz> > > wrote:
> > > > > >>> 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.
> > > > > >>> > On Tue, Feb 9, 2010 at 6:24 PM, Phil <p...@domicilis.biz> > > wrote: > > > > > >>> > > 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 :)
> > > > > >>> > > 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.
> > > > > >>> > > > >>> 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:
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 > 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:
> > > On Feb 11, 5:04 pm, "Dmitry A." <dandre...@gmail.com> wrote: > > > > 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.
> > > > On Feb 11, 4:54 am, Phil <p...@domicilis.biz> wrote:
> > > > > 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.
> > > > > > >> On Wed, Feb 10, 2010 at 12:27 PM, Phil <p...@domicilis.biz> > > > wrote:
> > > > > > >>> Hello,
> > > > > > >>> about shipping, this was in the idea of runningmultisitein 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.
> > > > > > >>> > On Tue, Feb 9, 2010 at 6:24 PM, Phil <p...@domicilis.biz> > > > wrote: > > > > > > >>> > > 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 :)
> > > > > > >>> > > 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.
> > > > > > >>> > > > >>> 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:
On Wed, Mar 3, 2010 at 2:58 PM, Phil <p...@domicilis.biz> wrote: > 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 > > 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:
> > > > On Feb 11, 5:04 pm, "Dmitry A." <dandre...@gmail.com> wrote: > > > > > 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.
> > > > > On Feb 11, 4:54 am, Phil <p...@domicilis.biz> wrote:
> > > > > > 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.
> > > > > > > >> On Wed, Feb 10, 2010 at 12:27 PM, Phil <p...@domicilis.biz> > > > > wrote:
> > > > > > > >>> Hello,
> > > > > > > >>> about shipping, this was in the idea of runningmultisitein > 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.
> > > > > > > >>> > On Tue, Feb 9, 2010 at 6:24 PM, Phil <p...@domicilis.biz
> > > > wrote: > > > > > > > >>> > > 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 :)
> > > > > > > >>> > > 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.
