Jump to content

Drake777

Пользователь
  • Content Count

    50
  • Joined

  • Last visited

Everything posted by Drake777

  1. если у вас уже работает с ?discounted=1, то возможно будет достаточно добавить правило в .htaccess
  2. конечно, можно. Можно практически все сделать. Надо понимать как это должно работать логически, тогда можно будет оценивать проект и сравнивать подобный проект с интеграцией и абоненткой за другие CRM. Везде свои плюсы и минусы
  3. если в поисках платных доработок - пишите в личку. если нужно бесплатно помочь, то по такому описанию без конкретики вряд ли кто-то поможет.
  4. А не проще сделать на основе той же симплы некую общую админку, куда будут все заказы улетать? А при смене статусов будут обновляться на сайтах с которых прилетели Т.е схема следующая: - клиент сделал заказ на сайте1. заказ остался на сайте1 и продублировался в "simpla-crm-сайте" - менеджер обновил статус в в "simpla-crm-сайте". Данные обновились на сайте1 ... дублируем на N сайтов. Правда для того, чтобы остатки вести придется связки товаров делать, не знаю насколько это будет реально в вашем случае. Но в целом схема рабочая. А диалоги действ
  5. интегрировал сайты с bitrix24 и retail crm. По ссылке вариант рабочий, но повозиться все равно придется. Да и потом допиливать надо будет, тк запросы появляются в процессе эксплуатации. Понятие "добротно" очень абстрактное. Нужна конкретика: какие данные куда и в какой момент передавать. Но по деньгам в любом случае дешево не получится, тысяч от 15 минимум. Официальные партнеры того же retail crm года два назад озвучивали ценники в 30-50-80 тыс рублей в зависимости от пафосности фирмы и базового функционала.
  6. вопрос ради доколебаться? если очень хочется, то можно и print, но в обоих случаях желаемый результат будет один. Скорость выполнения в обоих случаях будет одинаковая
  7. Опять же смотря как и что реализовывать, мне попадались проекты, которые в конечном итоге проще было сделать на 2 разных базах. Поэтому и прикидываю объем правок исходя из личного опыта изменений. Видимо у вас другой опыт, когда изменений было минимум. По кастомизации - обычно на начальном этапе хотелок минимум, а потом всплывают в большом количестве. Дизайн нужен разный, способы оплаты/доставки могут отличаться вплоть до разных юр.лиц внутри одной компании, свои категории, доступы к заказам для разных менеджеров на разных сайтах и т.д
  8. я про другой способ писал. При котором базы разные Подкорректировал, чтобы было понятней
  9. Простота предложенного варианта зависит от необходимой реализации. Может быть простая реализация с разными базами , а может быть довольно объемной, включая обратную синхронизацию статусов заказов, синхронизации товаров и т.д При этом лично на мой взгляд подключение нескольких магазинов к одной базе не проще, там тоже много все придется править. А в плане кастомизации такой вариант имеет больше ограничений
  10. в самом простом варианте правим CartView на сайтах-донорах и в момент создания заказа отправляем курлом данные на сайт-реципиент. В зависимости от данных можем проставлять заказам метки (с какого сайта пришел заказ) можно это делать непосредственно в момент заказа, можно по крону раз в период Но есть ряд нюансов: товары одинаковые или разные? если одинаковые - можно ли сопоставить по ид, артикулу или названию? надо ли менять количество на магазине куда попадают заказы или достаточно информации о заказе, а остатки будут на других магазинах?
  11. Можно еще на вотсап настроить. Либо через официальное апи (там все сложно и долго), либо через неофициальное, например https://chat-api.com/ru/ под неофициальное есть готовое решение
  12. судя по всему нужны подкатегории? если да, то так: {foreach $category->subcategories as $c} {if $c->visible} <li> {if $c->image}<img src="{$config->categories_images_dir}{$c->image}" alt="{$c->name|escape}">{/if} <a {if $category->id == $c->id}class="selected"{/if} href="catalog/{$c->url}" data-category="{$c->id}">{$c->name|escape}</a> </li>
  13. есть вариант сделать по следующей схеме: 1) один из магазинов будет "донором товаров". Либо можно в качестве донора товаров вообще отдельный домен использовать. на доноре допиливаем постраничную выгрузку товаров в json (постраничная имеет смысл, если товаров в дальнейшем будет много), либо делаем на одной странице, если товаров мало также даем возможность выбирать на какие сайты отдавать товары (чекбоксами в карточке товара в админке) 2) делаем отдельно выгрузку цен и остатков. Отдельно - для ускорения обмена, чтобы не гонять лишние данные. Добавление новых товаров на
  14. Если вы хотите, чтобы каждый вариант товара индексировался, то имеет смысл попробовать их сделать разными товарами. Когда варианты внутри одного товара, то они обычно не индексируются Для турбо проще всего сделать отдельный фид, скопировав yandex.php и назвав его иначе. Далее в этом файле уберите ?variant= можно также добавить группировку не по вариантам, а по ид товара. Тогда все будет как проиндексировано.
  15. можно попробовать включить отображение ошибок через ini_set('display_errors', 1);
  16. отвечать или нет - дело сугубо ваше. Но если уж вам и Нокстеру не особо нравится Симпла в том виде как она есть, то логично предположить, что есть некий другой движок который нравится. Но этой темы вы почему-то избегаете. Лично мне было бы интересно посмотреть не только на ваше творение на гитхабе, тем более, что там реализовано далеко не все из запланированного вами же, но и уже проверенный на практике готовый движок.
  17. похоже, что я не так понял проблему. Ранее у контент-менеджера была похожая проблема, это ее решило.
  18. Давинчи, в отличие от слившегося Noxter-a, довольно понятно разъяснил, что он хочет от симплы. Что считает обязательным юнит тесты и т.д При этом так и не ответил на вопрос какой движок считает максимально приближенным к идеалу. a13x же вполне придерживается концепции симплы. Псевдо MVC логика + комментарии в коде. Если в движке это допустимо, то странно требовать разработчиков на нем другого подхода. Если же не нравится движок, то как минимум странно сидеть на его форуме. Да и сама по себе дискуссия довольно странная, нежели интересная. Денис уже года 2, если не бол
  19. так если невозможно, то в чем смысл утверждения про обязательность тестов в сообщении выше? с точки зрения бизнеса не всегда имеет смысл идеальное решение. Это не значит, что надо лепить код из говна и палок. Но и в другую крайность вдаваться тоже не стоит. Хотя если вы нашли высокооплачиваемую работу с возможностью написания идеального кода пусть и за более длительное время, постоянными код-ревью от более опытных коллег и возможностью развития - могу только порадоваться за вас. Что касается отказов работать с чужим корявым кодом - так ведь это не только от движка зависит.
  20. никак. Есть речь о небольшом магазине, то такие гарантии как правило и не нужны, достаточно внимательности при разработке. Полноценное тестирование стоит денег. А небольшие магазины далеко не всегда готовы их платить. Даже с учетом того, что потеря работоспособности будет стоить дороже.
  21. что подразумевается под масштабированием? если добавить кеширование, нормальные фильтры, города на поддоменах, различные отчеты по продажам, формирование закупок, складской и фин.учет, rest api - это уже масштабирование? опять же речь о масштабировании функционала или самого проекта? понятно, что для условного wildberries симпла не подойдет, но для проекта даже на 100 тыс товаров - вполне. И тогда какой движок на ваш взгляд привлекателен для разработчиков? Спрашиваю без сарказма/иронии, на самом деле интересно. Noxter заявил про болячки и слился. Вы тоже сказали про ограниченно
  22. В данном случае не он заявлял про болячки Симплы, а вы. Стрелки не надо переводить) Меня не интересует окей, меня интересуют заявленные вами болячки симплы, которые даже на окей перебрались. Не костыли, неудобства и т.д, а именно болячки, про которые вы заикнулись.
×
×
  • Create New...