Перейти к содержанию
Официальный форум поддержки Simpla

phukortsin

Фрилансер
  • Публикаций

    1412
  • Зарегистрирован

  • Посещение

Весь контент phukortsin

  1. 1. Присланный материал датирован 2015 годом, с большой вероятностью в нем не все актуально. 2. В присланном материале сказано: Авторизационные данные могут быть переданы в запросе несколькими способами (способы указаны в порядке приоритета): в HTTP-заголовке Authorization, в параметрах URL запроса. То есть даже в 2015 году приоритетно было использование HTTP-заголовка. Весьма вероятно, что к настоящему моменту второй метод устарел и не действует. 3. Текущий online справочник Ямаркета явно более актуален, нежели индивидуально присланный материал. Если еще окажется, что Вам
  2. На стр https://yandex.ru/dev/market/partner-marketplace-cd/doc/dg/concepts/authorization.html сказано "Авторизационные данные передаются в HTTP-заголовке". Не нахожу, где говорится про два способа, можете ссылочку дать?
  3. На стр https://yandex.ru/dev/market/partner-dsbs/doc/dg/reference/put-campaigns-id-orders-id-status.html сказано: Авторизационные данные передаются в HTTP-заголовке Authorization: Если ресурс API вызван без авторизационных данных, сервер Маркета возвратит HTTP-статус 401 Unauthorized. Похоже, тут Ваш случай точно описан. Вы почему-то эти авторизационные данные пихаете в URL, а не туда, куда инструкцией велено...
  4. Если "Тип остается старый", то, видимо, что-то делаете неправильно. Угадать, в чем ошибка, практически нереально, если подробности держатся в глубоком секрете...
  5. Это не слабое место, именно так и задумано. А если Вам это не нравится, Вы легко можете изменить пару строк в ProductsView.php. Но только простенькое изменение в запросе - IN(33) вместо IN(33,5,15,35,83) существенной экономии не даст. Проблемы с тормозами в Simpla приходилось решать неоднократно, но не встречал случай, чтобы именно это место было причиной.
  6. Если "не использовать" как сделано сейчас, а "просто указывать category_id как число", возникнут недостатки весьма серьезные. А вообще непонятно, зачем придираться к этому месту, ибо сделано оно довольно хорошо и добротно.
  7. Потому что если в фильтре НЕТ параметра category_id, то в запросе нет INNER JOIN, и повторение товаров в результатах и так не возникнет.
  8. Чтобы один товар в результатах запроса не возникал два или более раз. Если убрать группировку, то товар, которому в админке задано несколько категорий, может появиться в результате запроса несколько раз...
  9. 3. Ресайз загруженных файлов name.jpg, name.gif, name.png создавать в формате webp. 70$
  10. 2. При загрузке для товаров файлов name.jpg, name.gif, name.png: 2.1. преобразовывать загружаемый файл в webp и записывать в originals/name.webp, 2.2. проводить ресайз файлов name.webp, 100$
  11. Стоимость - от точного задания. При текущей небрежной формулировке, в зависимости от ее понимания, - тысячи, а, может, миллионы $. Реально задача может пониматься минимум в двух более-менее разумных вариантах. 1. При загрузке изображений к товарам принимать вместе с текущими форматами также формат webp и проводить ресайз также с этим форматом. 2. При загрузке для товара файла name.jpg создавать на сайте original/name.webp и по нему делать ресайз. 50-100$
  12. Потому что функция в параметре ожидает ID категории, а у Вас что-то постороннее...
  13. Примерно так: foreach($purchases as $purchase) { $variants_ids[] = $purchase->variant_id; } $temps = $this->variants->get_variants(array('id'=>$variants_ids)); $variants = array(); foreach($temps as $temp) { $variants[$temp->id] = $temp; } foreach($purchases as &$purchase) { $purchase->variant = $variants[$purchase->variant_id]; } После этого в шаблоне можно использовать
  14. Обычно такое делается проще. Образцов в Simpla много. Смотрите, например, стандартный OrderAdmin.php, строки 145-180.
  15. Смотря как действовать. Можно и сохранить вывод по выделенным брендам...
  16. Что с ним не так, надо определять на Вашем сервере, проверяя нагрузку выполнения, время и прочее. На вид запрос почти типовой для Simpla, разве что можно было бы упростить его, убрав "LEFT JOIN s_brands b".
  17. Попробуйте эту строку удалить или закомментировать.
  18. Ужас как интересно: 1. Что за метод имеется в виду (я в теме не вижу особо никакого метода, только вопрос и ответ с парой маленьких строк кода)? 2. Как именно нарушает? 3. Как надо правильно решать задачу ТС, чтобы не нарушать разные методологии?
  19. Примерно так: $u=$this->users->get_user($id); $email=$u->email; И надо учесть, что это надо делать в цикле, а не "после"... А еще лучше делать это в Users::update_user. Тогда не придется делать добавки в UserAdmin.php
  20. Задача неопределенная, поэтому может варьироваться (когда выяснятся детали) от очень простой до очень сложной. Самый простой способ уже подсказал Kosjak76. Если оба сайта на одном хостинге, то просто подключаете их к одной базе. Надо всего лишь изменить четыре строки в config.php. А если будут расти аппетиты и хотелки, то вырастут и трудозатраты...
  21. Самое простое - ОДНА база вообще. Добавки: 1. У товаров в админке две галочки Показывать в магазине 1 и Показывать в магазине 2. 2. У категорий в админке две галочки Показывать в магазине 1 и Показывать в магазине 2. 3. При оформлении заказа заполнять поле Магазин, в котором указывать одно их двух значений. "бюджет небольшой" - серьезное препятствие. Если бизнесмену мало одного магазина и он завел два, но не может на программирование нужного функционала выделить сотню $, что тут сказать? А бывает, потом бизнесмен скажет - хочу еще что-то, например, метки заказов разн
  22. Непонятно, что же там много править, кроме параметров доступа к базе. И что за кастомизацию с какими ограничениями имеете в виду?
  23. В файлах конфигурации у разных сайтов магазинов указать одну и ту же базу. Тогда у Вас будет единый список заказов. Если захотите знать, из какого магазина пришел тот или иной заказ, для этого уже поработать программисту надо. Можно. Но возникнут немалые сложности, так эти таблицы связаны с другими. Если готовы оплачивать, то любой каприз за Ваши деньги...
×
×
  • Создать...