Движок для интернет магазина
4767
22
Уважаемые господа. Подскажите пожалуйста на какой системевозможно продвинуть следующую тему. Вообщем нужен сайт с возможностью работы по нескольким городам. Возьмем допустим сайт связного. Чтобы было автоматичесоке определение города, для разного города была возможность разной цены. Была возможность дать разным городам доступ только к своей базе данных. У разных городов была возможность устраивать разные акции проводить опросники и т.п. если есть такая возможность посоветуйте на какой версии можно это продвинуть? Все ли запрашиваемые функции будут работать? Нужно ли для каждого города покупать свою лицензию или будет достаточно одной? Примеры какие-нибудь… И еще подскажите юзеру как это правильно называется многосайтовость или многодоменность. Или вообще что-то третье Заранее спасибо за ответ.
Что-то мне подсказывает, что вам стоит обратиться в любую контору, предлагающую услуги сайто-строения и интернет-магазино-строения.
Ну т.е. раз уж вы замахнулись на разные города, цены и проч. - то должны понимать, что это не 20 и не 30 тыр, потому самому делать (не владея даже техническими знаниями, это видно) - смысла нет.
Ну а в конторе вам уже на все эти вопросы компетентно ответят, с вариантами решения и ценами.
Ну т.е. раз уж вы замахнулись на разные города, цены и проч. - то должны понимать, что это не 20 и не 30 тыр, потому самому делать (не владея даже техническими знаниями, это видно) - смысла нет.
Ну а в конторе вам уже на все эти вопросы компетентно ответят, с вариантами решения и ценами.
Имхо, правильное решение лежит вне CMS
называется .htaccess - позволяет переопределить соответствующий запросу файл на веб-сервере, исходя из большой кучи параметров.
Есть хостеры, которые не позволяют его использовать.
однако, 100% определения региона по IP не даст, посетитель может пользоваться, например, анонимным прокси (процентов на 95 можно рассчитывать, полагаю, лучше уточнить).
Использовать ли несколько сайтов или несколько доменов / субдоменов или просто папки внутри сайта - будет зависеть от того:
- что должен видеть в строке браузера посетитель
- какие возможности предоставляет хостер
- какие возможности у выбранной CMS
- как разработчик поделит структуру данных
называется .htaccess - позволяет переопределить соответствующий запросу файл на веб-сервере, исходя из большой кучи параметров.
Есть хостеры, которые не позволяют его использовать.
однако, 100% определения региона по IP не даст, посетитель может пользоваться, например, анонимным прокси (процентов на 95 можно рассчитывать, полагаю, лучше уточнить).
Использовать ли несколько сайтов или несколько доменов / субдоменов или просто папки внутри сайта - будет зависеть от того:
- что должен видеть в строке браузера посетитель
- какие возможности предоставляет хостер
- какие возможности у выбранной CMS
- как разработчик поделит структуру данных
Имхо, правильное решение лежит вне CMSАга, определился неправильный регион по IP - и буду смотреть на цены урюпинска без возможности выбрать свой регион, так получается?
называется .htaccess - позволяет
Зачем глупости говорить?
И потом, все эти внешние фенечки типа "разные цены по регионам", "домены" - фигня. Для примера (как работающую модель) можно посмотреть тот же ДНС как у них сделано. Вполне себе работают люди.
Основной объем работ - это подерживать актуальность даных по разным регионам, отследивать наличие на складах, актуализировать информацию согласно наличию на складах в разных регионах. Вот где действительно огромный объем работ.
Если же реально склад один и разные цены для разных регионов определятся по сути лишь ценой доставки - так просто так честно и написать: "цена - такая, доставка в ваш регион - столько-то".
Мон шер, я надеюсь денег за свои консультации в областиИмхо, правильное решение лежит вне CMSАга, определился неправильный регион по IP - и буду смотреть на цены урюпинска без возможности выбрать свой регион, так получается?
называется .htaccess - позволяет
Зачем глупости говорить?
[...]
- Учетных систем
- Информационных технологий
- Организации бизнеса
Вы НЕ берёте
может неудобно получиться
Мон шер, я надеюсь денег за свои консультацииВы на что намекаете?
Я лично поддержу предущего оратора - складывать подобную логику в htaccess - это очень негибкое решение.
А обосновать свою точку зрения Вы можете?
Странная ситуация получилась:
- для предложенного метода, вы придумали систему работы. (исходя из своего опыта)
- увидели недостатки вашей системы
- сделали вывод о непригодности метода
- сделали вывод о моём уровне развития
- предложили заказчику переделывать все бизнес процессы
это как я бы рассказал что есть бензиновые двигатели и это круто (допустим в начале 20-го века), а мне бы возразили: "бензин закончится и ехать нельзя будет. Метода нерабочая. Используйте лодки"
Странная ситуация получилась:
- для предложенного метода, вы придумали систему работы. (исходя из своего опыта)
- увидели недостатки вашей системы
- сделали вывод о непригодности метода
- сделали вывод о моём уровне развития
- предложили заказчику переделывать все бизнес процессы
это как я бы рассказал что есть бензиновые двигатели и это круто (допустим в начале 20-го века), а мне бы возразили: "бензин закончится и ехать нельзя будет. Метода нерабочая. Используйте лодки"
Сейчас читают
Просветление.
252801
1000
"Битвы экстрасенсов" на ТВ
131042
327
Как отвязаться от мысли?
9940
54
Тогда быть может расшифруете свою точку зрения и методику применения в данном случае относительно .htaccess?
Существуют некие принципы подхода к программированию и вопросу о том, где размещать программную логику. В данном случае прописывать выбор региона в htaccess не лучшее решение хотя бы потому, что в программе просто необходимо будет предусмотреть возможность смены региона пользователем, то есть от программирования регионов в коде все равно никуда не деться.
Тут Вы отчасти правы 
- Надо дать пользователю выбирать регион на страницах, иначе "не поедет"
В htaccess
- Если регион из "необслуживаемых" - переводить на центральный регион
- Если переход идёт со своих страниц - переброс не делать
Размещение логики выбора страницы по IP в htaccess позволит
1. заметно ускорить время открытия нужной страницы - эти действия выполняются сервером до пересылки страницы .
2. НЕ усложнять логику магазина и использовать "всё типовое", или независимые наборы "типовых решений"
Вот вроде и всё
- Надо дать пользователю выбирать регион на страницах, иначе "не поедет"
В htaccess
- Если регион из "необслуживаемых" - переводить на центральный регион
- Если переход идёт со своих страниц - переброс не делать
Размещение логики выбора страницы по IP в htaccess позволит
1. заметно ускорить время открытия нужной страницы - эти действия выполняются сервером до пересылки страницы .
2. НЕ усложнять логику магазина и использовать "всё типовое", или независимые наборы "типовых решений"
Вот вроде и всё
Тут Вы отчасти правыПочему только "отчасти"?
- Надо дать пользователю выбирать регион на страницах
В htaccessЯ так понимаю, что этим вы пытаетесь поддержать логику "если регион пользователь выбрал сам - то оставлять его в этом регионе", так?
- Если переход идёт со своих страниц - переброс не делать
А если я сохранил ссылку на региональный сайт и зашел по ней завтра или отправил соседу?
Размещение логики выбора страницы по IP в htaccess позволитЗдесь все сводится только к тому, кто отрабатывает логику переброса страницы - веб-сервер или сервер приложений. Веб-сервер действительно будет немного быстрее. Но если страницы магазина у нас - динамические CMS, а не статические HTML, выигрыш в скорости будет нужно будет искать с лупой.
1. заметно ускорить время открытия нужной страницы - эти действия выполняются сервером до пересылки страницы .
...А если ещё руками что-то поменял?
А если я сохранил ссылку на региональный сайт и зашел по ней завтра или отправил соседу?
А если при этом ошибся ?!
"Пилите, Шура, пилите - она золотая" (с) Паниковский
...
Веб-сервер действительно будет немного быстрее. Но если страницы магазина у нас - динамические CMS, а не статические HTML, выигрыш в скорости будет нужно будет искать с лупой.
От наворотов переадресующей страницы будет зависеть, свободных ресурсов сервера и т.п.
Спорить тут не о чем,
надо на живом сервере тесты делать.А если зачем передергивания?А если я сохранил ссылку на региональный сайтА если ещё руками что-то поменял?
А если при этом ошибся ?!
Я описал вполне реалистичный сценарий: переслал ссылку знакомому "как думаешь, брать или нет?"
Хотелось бы пояснений как в описанной вами схеме это будет работать, т.к. это как раз тот момент, котрый в предложенной вами схеме видится проблематичным. Или он остался недодуманным?
Спорить тут не о чем,На самом деле все это уже сделано, до нас и без нас
Замолчал что-то специалист по .htaccess файлу. Жаль.
Ну что ж, остается лишь надеяться, что он, так же как и я, не берет денег за свои консультации в области, Учетных систем, Информационных технологий, Организации бизнеса. А то ведь и в самом деле, "может неудобно получиться".
Ну что ж, остается лишь надеяться, что он, так же как и я, не берет денег за свои консультации в области, Учетных систем, Информационных технологий, Организации бизнеса. А то ведь и в самом деле, "может неудобно получиться".
п.9
А чем Вам "верти март" не угодил, работает на джумле, бесплатен, и удобен в упралении???
А чем Вам "верти март" не угодил, работает на джумле, бесплатен, и удобен в упралении???
Имхо, правильное решение лежит вне CMSв целом, поддержу - это, скорее, наиболее естественный и простой способ "тиражирования" готового решения
называется .htacces
Однако, лезть в CMS вероятно всё-таки придется - к примеру, этот способ недостаточен, когда незарегистрированый пользователь, чья корзина еще хранится в куках(?), кладет товар в корзину, уходит, а затем возвращается на сайт другого региона (по внешней ссылке) - такие варианты при разработке CMSки, ессэсно, не учитывались и их разрешение может потребовать усилий
2ТС
пс. KSergey - это я не Вам - корректировал предыдущее, не знаю, как так случилось
как это правильно называется многосайтовость или многодоменностьтак и называется. о стОитмости и возможности применения нужно справляться в лицензии на конкретный продукт... старые версии часто не нормировали этот параметр, новые - нормируют. Поэтому, если фришный джумловский воробей окажется дорабатываемым и приемлемым с точки зрения организации бизнеса - это может стать решением, позволяющим достаточно сэкономить
пс. KSergey - это я не Вам - корректировал предыдущее, не знаю, как так случилось
Чтобы было автоматичесоке определение города, для разного города была возможность разной цены. Была возможность дать разным городам доступ только к своей базе данных.Я бы не заморачивался с гео-определеннием посетителя. Вопрос "географии" я бы вынес за пределы сайта. Прибилизительно вот так:
Рекламный баннер на НГС будет вести на страницу "Новосибирск" сайта интернет-магазина, а рекламный баннер с Бабр.ру - на страницу "Иркутск". Рекламное объявление в Яндекс.Директе "Купить слона в Кемерово" будет вести на страницу "Кемерово", а "Обезьяны оптом. Томск" - сами-знаете-куда. Т.е. сама ссылка перехода по рекламе будет направлять юзера в нужный регион каталога.
И никакой "угадывалки" географической принадлежности юзера на сайте.
Андрей Первый
veteran
Я бы не заморачивался с гео-определеннием посетителя.на самом деле штука очень удобная для посетителя и как маркетинговый инструмент должна иметь значение.
только котлеты от мух нужно отделить
автоопределение и перенаправление - это одно, ручное переключение - это другое
а вот механизм отображения данных для того или иного города - он один