Потому что там, должен быть топ товаров, продав которые получится топ бабла.
Т.е. нередки случаи, когда (как и в оффлайне) на сайт "заманивают" покупателей
по одним ключевым словам и товарам, а продают (в идеале) совсем другой товар,
с гораздо более высокой маржинальностью.
Как по мне, так порядок товаров должен задаваться вручную.
Если нет никого, кто в состоянии сказать, какие товары должны быть сверху,
а какие снизу, то лучше... закрываться пока не получили больших убытков.
Все авто-механизмы типа "новые вверху" - это какое-то недоразумение.
Демо-версия так сказать.
Да, именно.
Только давайте расставим акценты иначе.
Я не стал переносить функционал из бэкофиса в интернет-магазин.
Во фронте только статика. В интернет-магазине только статика.
А БД там, где ей место. Там где управление складом, заказами, покупателями итп.
Абсолютно отдельно от интернет-магазина.
А бэкофис в последнем случае уже был давно. Т.к. это был случай разворачивания
интернет-магазина поверх вполне себе "оффлайн-бизнеса".
Честно говоря опять не очень понимаю о каких задачах речь.
Вам нужно больше информации на клиенте о скидках ?
Загрузите на сервер КОПИЮ информации о скидках.
(в любом тонком виде)
Раздавайте оттуда (1 раз в клиента).
Зачем вы хотите в бэкэнд лазить мне непонятно абсолютно...
Вы хотите считать стоимость доставки ?
Это очень сложный алгоритм, который не может быть реализован
на клиентской стороне ? Зачем он такой вообще :) ?
Идея-то, подчеркну, как-раз в том, чтобы не вкорячивать в интернет-магазин лишнего.
Всего того, что зачем-то вкорячивают в бэкэнд. Что сделано отвратительно.
Чем пользоваться самоубийственно. Что, обычно, уже есть у любого оффлайн-магазина.
Дык в массе ничего другое универсально тоже не применимо.
Или в массе применим коробочный интернет-магазин ?
Много знаете тех, кто не закрылся через 2-3 года с убытками из тех,
кто стартовал с коробки ?
(и много ли из них тех, кто не имел "серебряной пули", к примеру не
являлся дочкой крупного вендера и не имел чумовых скидок и отсрочек платежей )
Впрочем... действительно, я немного забылся, в массе действительно это все
не нужно, т.к. задачи сделать <s>хорошо</s> <s>нормально</s> приемлимо нету,
есть задача получить денег с клиента, показать ему красивые картинки "в админке",
на лету отредактировать его номер телефона (и потом каждый раз его из базы выбирать) итд итп.
ЗЫ. Я допилю где-нибудь "на новогодние", и посмотрим, но т.к. у меня уже есть список фич,
то очевидно, что в моем частном случае работать будет. Вообще печально, что пришлось даже
такой мини-функционал пилить самому - неправильно это. Но вся "индустрия" больна такой
гигантоманией, что уж лучше так.
Чьерт... годами всё работает без нареканий. Как теперь жить непонятно...
То, что я не специализируюсь на веб-приложениях ничего в общем-то не значит :).
Именно. Но я что-то не верю, что ненаправленная атака что-то даст.
Хотя бесспорно изучу пакетные сканеры уязвимостей... возможно... позже.
Это в добрый путь... понадобится дверь вскрывать полагаю :).
Он как-бы это сказать... по ряду причин в оффлайне почти (впн итп не в счет) :).
Туда попадает только почта, она обрабатывается префильтром довольно жестким,
поскольку надо забрать очень мало инфы, то нет проблем избавиться от тэгов итп.
Почтовый сервер отдельно.
Собственно нехай ломают, будет интересно "как", повышу свой уровень.
Да не нужно это никому кроме меня, очевидно-же, что средний заказчик хочет
"свистелок и перделок".
Давайте о секьюрити поговорим. Пока у меня на сервер-сайд 1 php файл на 5кб.
Полагаю если приспичит, то с таким объемом кода "чумовым", я смогу ведь найти
реально хорошего специалиста для аудита. Это если представить меня неким овощем,
который не в состоянии почитать рекомендации для создания форм.
Скажем, за 200 евро.
Или не смогу ? За эти вполне указанные бабки ?
Сколько бабла мне придется вложить в аудит "коробки" в которой понаворотили
на десятки мегабайт :) ? При этом я не верю в то, что везде думали головой.
Я вижу как люди простых вещей не продумали, чего уж тут о секьюрити...
Серьезный DDOS забьет каналы.
Однако вы дело говорите, всегда эту статику можно в S3 выложить... если
критично её функционирование.... Т.е. вы можете любые CDN использовать...
без проблем каких-то.
Т.е. свой сервер выходит нужен только для скрипта чекаута...
В этом и смысл. Сложность там, где ей место. В бэкофисе она всё-равно будет.
Бэкофис под это приспособлен изначально.
И сделать бэкофис из интернет-магазина в общем-то можно конечно, но только
если "для дяди", т.е. это неразумное вливание денег и сил.
Именно.
Имеет ли смысл переделывать стоковый магазин, если делаешь не для того, чтобы
высосать из клиентов побольше бабла. Может прям сразу реализовать то, что нужно,
а не переделывать то, что кто-то сделал, причем сделал зачастую откровенно плохо.
Я не дурак, и не подлец. Я не возьму 10 магазинов "на допиливание".
Не надо в рот тянуть больше, чем можешь откусить...
Чё, правда что-ли ?
Кто-то будет взламывать самопис :) ?
Вы правда считаете, что он более уязвим, чем коробочное решение ?
Решение, взломав которое получишь сотни тысяч потенциальных жертв, а не считанные единицы ?
Я всегда очень серьезно отношусь к безопасности. Зарекаться бессмысленно.
Но точек атаки у меня в сотни раз меньше, жертва я в сотни тысяч раз менее привлекательная,
а квалификация... увы, у кодеров стоковых движков похуже моей будет.
Я был бы рад, если бы было наоборот, но увы. Что есть, то есть.
Экономический смысл взлома при всём этом как-то теряется, только если
"назло бабке уши отморожу", но при таком подходе могут и просто на улице
заказать "удар по башке молотком"...
Статика имеет и еще один плюс.
В случае взлома, я просто инициализирую новый инстанц у амазона и перезалью туда статику.
Никакой настройки всё это не требует. Мне пофиг и на версию php и на версию mysql,
мне пофиг на настройки БД, на кеширование, мне вообще на всё пофиг, оно будет работать
в стоковом LAMP без каких-либо модификаций. (хорошоб нгикс настроить, но сразу можно
этого и не делать). Вообще нет никаких нужных нетривиальных сервисов для работы.
И ничего со старой системы мне забирать не надо. Никаких баз, никаких данных.
Всё залью по-новой.
Никак, нет требований.
Но вообще, не вижу проблемы, статику вы можете ведь менять и на клиентской стороне через js.
Опять-таки ОДИН раз забираете информацию с сервера, а потом уже показываете своё "ваша скидка ХХ%".
Да, на сервере надо будет как-то хранить, но опять-таки в очень "тонком" виде.---------- Добавлено 27.12.2016 в 11:46 ----------
Да вот я к таким-же выводам пришел.
Причем "тонкий клиент" "статика" итп позволяет с небольшим бюджетом решить-таки свои проблемы. В том время, как альтернатива требует массы компромиссов. 11 секунд на генерацию страницы не видел, врать не буду, но 300 запросов видел, в теме "из коробки", из них 50 (пятьдесят) на генерацию футера (футера, там всякие адреса магазина из базы выбираются итп).
И как с таким феррари победить :) ?
При этом я его допилил. Он работает. Что надо делает. Едет короче.
Но времени на это ушло вагон + тележка, и делает он это "всё" всё равно не так как надо.
Ей богу, лучше бы сразу выкинул.---------- Добавлено 27.12.2016 в 11:48 ----------
Да как-же так ?
Даже если ляжет mysql на легком фронте, даже если кончится место на диске,
даже если умрет ВСЁ, то статика будет продолжать отдаваться клиентам,
заказы собираться и приходить по email итп. (главное чтобы мейл не лег,
собственно это всё, что нужно, способность запускать 1-2 сервер-сайд скрипта
для отправки почты)
Наоборот - это безотказная система. Сами продажи продолжатся и после
ядерной войны :).
Причем заметьте, вся "точка отказа" у вас "собрана" в момент загрузки новой
информации, т.е. вы в состоянии хоть как-то протестировать, что получилось.
И никакой деградации после этого не бывает даже в принципе.
БД не переполняется, к примеру тут наблюдал, как база выростала на 100-200мб
в день, оказалось туда какая-то статистика профайлинга пишется, это какими-же
имбецилами надо было быть, чтобы писать её не в текстовый файл.
И сколько еще таких шуточек встроено в коробку ?
Там клоудфларе предлагали... не то... меня не устраивает кеширование для второго
клиента, я не хочу, чтобы робот гугла ждал по 11 секунд страницу, если он пришел первым.
---------- Добавлено 27.12.2016 в 11:57 ----------
А в чем сложность-то и затратность в разработке ?
Если вам нужны специфические требования, то разрабатывать 100% придется.
На любом "стоковом" решении вам надо будет изучить обширные и ненужные вам свистелки
и перделки, и заставить их работать (не мешать работать) вашему решению.
Если в "тонком" магазине ничего лишнего нет, то вы экономите на этом геморрое.
Я тут уже "топором навырубался", до последнего терпел, но невозможнож.
Сложность тут может быть только при подходе "хочу какой-то магазин, сам не знаю чего хочу,
и вообще вы спецы - фигачьте, а у меня другие задачи и интересы в жизне".
Тогда да - клиент получает битрикс, и пусть года через три закрывается, всё равно добра не будет.
А если четко понимаешь "как надо", то проще ей богу в вакууме писать, дешевле, быстрее.
И заметьте, я не веб-разработчик, и даже в этой ситуации разобраться и дописать быстрее
и проще, чем настроить якобы готовое. Что они там курят, те кто готовое делают, я не
очень понимаю, но что-то забористое. Исходники "жгут".
Не очень понял о чем речь ?
Обычно структура задается так или иначе либо в складе, либо где-то еще,
где товар УЖЕ учитывается. Надо дублировать.
Не вижу проблем. Хотя допил какой-то будет нужен конечно.
Тоже не очень понял, можно пример ?
Речь о фильтрации товара на основе выбора каких-либо параметров ?
(т.е. фактически поиске). Тут согласен - придется что-то на серверной стороне
писать, что-то лёгкое и быстрое желательно. Возможно да - придется
что-то держать в БД.
Статикаж. Из ERP прям может и браться. По кронтабу крутиться.
Вряд ли чаще раза-другого в сутки всё это меняется.
Допилю сделаю тесты, как быстро рефрешится скажем 100.000
страниц статики, но не думаю, что долго.
Тут не компетентен, врать не буду. Однако полагаю она в ERP должна работать
исходя либо из точки входа, либо из реферрера. И только для оплаченных
заказов, т.е. нужна связь с бухгалтерией. А от магазина нужны только заказы
с меткой.
Да ктоб спорил, особенно если в вашей коробке еще 100500 фич, которые
затрудняют реализацию нужных.
Да так и выходит. Думаю, что поиск я засуну в клиента.
У меня поиск только по названиям нужен, и товаров до 1000 шт.
В принципе, ничто не мешает загрузить один раз список на 20кб в локал сторейдж,
и искать в нём вообще не напрягая сервер. Да и в 10 раз больше можно былоб
сжать, загрузить и распаковать.
Сравнение атрибутов не вижу почему нельзя сделать тоже средствами js.
(но в этот раз задача почти не стоит)
Хуже с валидацией почтового адреса, но тут можно какой-нибудь сторонний сервис
подключить, свою не факт что будет разумно делать. (хотя всякие кладр вроде в наличии)---------- Добавлено 26.12.2016 в 18:45 ----------
А как они вообще существуют ? Этож даже для маленького магазина из <1000 позиций
без нормальной (своей или чужой дописанной) системы смерть.
Небольшой, но заточенной под конкретный бизнес.
Так магазин нифига нормально не делает. "Из коробки".
В результате вместо использования хороших отдельных систем и инвестиции в
их интеграцию друг с другом, люди пишут "модули", которые "кое-как делают хоть что-то".
Но этож самоубийство в условиях конкуренции.
Не очень понятно чем зоопарк качественного специализированного софта хуже, чем
зоопарк некачественных модулей.
Т.е. есть четкое ощущение, что тикет-система "из коробки", склад "из коробки" итп,
будут всё-таки лучше, чем самый навороченный интернет-магазин с 100500
установленных модулей.
Но общую мысль я понял: они думают, что экономят потому, что покупают одно решение,
а не несколько.
Корзины все одинаковые.
Чекаут всё равно переписывают на 70-100%.
А что ёще разное-то ? Такое разное, что в типичном интернет-магазине оно типа "универсальное" ?
Как по мне, так любой магазин состоит из категорий, товаров, и возможно каких-то поисков-сравнений (не у всех).
Первое и второе почти у всех одинаковое. (забудем на минутку об атрибутах, оказалось что их тоже гораздо проще интегрировать с нуля).
Поиск и сравнение тоже приходится переписывать в стоковых движках.
Т.е. мы имеем со стоковыми весь тот-же объем работы, но при этом, как правило, разработать что-то сложнее, т.к. требуется изучение еще 100500 фич, которые пересекают ваше поведение и портят его. Т.е. по факту приходится дофига чего дописать, а потом еще и дофига чего топором вырубить, чтобы дописанное работало. Тройная работа.
Или нам надо, чтобы название организации в БД хранилось, и для генерации каждой страницы десятком запросов оттуда доставалось :) ?
Кхе... кхе... у меня опыт "программирования" 30+ лет.
При этом попробовав третий раз "натянуть" требования на то, что предлагает рынок в качестве заготовок, я ДУМАЮ, что мне этот секс не нужен совсем.
Лучше тонкий простой движок, чем та порнография, которую предлагают как "готовый интернет-магазин из коробки".
ERP доделывать всё-равно, так не проще ли выдавать на её выходе либо сразу статический html, либо ресурсы, которые легко шаблонизатором в такой html превратить. Остается добавить корзину, one page checkout и всё...
ЗЫ. Это все не теория, доделываю уже, нет сомненья, что "взлетит". Фактически осталось подправить верстку итп. В результате "написать всё это с нуля" оказалось даже быстрее, чем заставить хоть как-то работать "изкоробочный" вариант.
