baarseek
-
Публикаций
45 -
Зарегистрирован
-
Посещение
Весь контент baarseek
-
В общем, тему можно закрывать. Я нашел проблему, и она оказалась в Ростелекоме. Они без моего ведома залезли в код сайта и переписали три файла в api добавив в запрос лимит на 20 позиций. Так как у них сервер не справлялся. Мне ничего не сообщили, а я весь день голову ломал что за дела.
-
Спасибо, уже выбираю что-то нормальное. У меня сейчас хостинг в Ростелекоме, там он вообще, похоже, просто остался со старых времен и они его не развивают, я даже сейчас такой услуги у них на сайте не нашел ;( Т.е. там некуда выше переходить по тарифу, так как разница между тарифами только в свободном месте :)
-
На одном сайте 48 категорий (в сумме, вместе с вложенными), 25к товаров. На втором 70 категорий в сумме, но 5к товаров. Не думал, что это много. Используются все, удалять не вариант ;(
-
Вот немного конкретики: похоже, что это хостер ограничил мне что-то ;( Я связался с поддержкой и они сказали, дословно: Пару дней назад на сервере возникли проблемы с базой данных. Выяснилось, что ваши сайты делают огромные и неоптимальные sql-запросы, которые исполняются несколько минут и используют несколько гигабайт оперативки. Один запрос во вложении. Похоже, нужно вмешательство программиста с вашей стороны, т.к. подобные sql-запросы к базе недопустимы. К кому можно обратиться, чтобы разобраться с запросами в Симпле? Не могу добавить файл, но запрос вот такой: SELE
-
Привет. Столкнулся со странной проблемой: внезапно на сайте (и в админке, и на самом сайте) заметил, что в категории корректно отображается только первые 20 товаров в категории, на странице, в поиске (короче в любом выводе). Товары с 21-го включительно отображаются как "нет в наличии", хотя если по нему кликнуть - то попадаешь в карточку где всё окей. В админке это выглядит не менее странно, 20 товаров ок, а остальные без картинки, без цены, без количества. Причем я исключаю вероятность того, что это я поломал всё, так как проблема случилась на двух сайтах сразу, второй я не трогал вообще
-
Тоже достали кучи спам-комментариев?)
-
Ну вот, за пять дней набил удаленное количество заказов и проблема вернулась. Неужели решение только одно - ждать возможного обновления движка?
-
Привет. Вот такую проблему увидел сегодня с утра на сайте: Разбираться было некогда, поэтому я взял и удалил пару сотен заказов из удаленных, да и просто почистил немного их количество. Ошибка пропала. Что это может быть? Встречалась ли вам такая проблема при большом количестве заказов в базе?
-
Только в функции лучше, мне кажется, указать: ->setFrom(array('john@doe.com' => 'John Doe')) Чтобы в почте адрес выглядел красивее.
-
https://yadi.sk/d/2khn0wyhrCF5d
-
Прошу прощения, не то написал. Модифицированный запрос у меня один в один как в теме: $id_filter $date_from $date_to $status_filter $user_filter $keyword_filter $period_filter $date_filter $label_filter $modified_since_filter GROUP BY o.id $order_by $sql_limit", "%Y-%m-%d");
-
Благодаря помощи в соседней теме удалось убрать ошибки, но ситуация следующая: с стандартным запросом из симплы $id_filter $status_filter $user_filter $keyword_filter $label_filter $modified_from_filter GROUP BY o.id ORDER BY status, id DESC $sql_limit", "%Y-%m-%d"); в эксель выгружаются не все заказы, зато по вкладкам заказов переходит очень шустро, и по страницам внутри вкладок тоже (даже там, где их больше тысячи). С модифицированным запросом из доработки $id_filter $date_from $date_to $status_filter $user_filter $keyword_filter $label_filter $modified_from_filter ORDER BY status, id DE
-
Понимаю. Буду выяснять, что не так.
-
Спасибо, такой запрос до выборки решает проблему. Но я так и не понял, откуда она возникла. Буду разбираться. Еще раз спасибо.
-
Ошибку я первым делом погуглил, но у меня нет доступа к настройкам mysql, хостер не дает. Еще обратил внимание на странный эффект, у меня постранично получается 1092 страницы заказов. Если перейти на 1091 страницу - все окей, ошибка возникает только на 1092 странице.
-
C выводом через $id_filter $status_filter $user_filter $keyword_filter $label_filter $modified_since_filter GROUP BY o.id ORDER BY status, id DESC $sql_limit", "%Y-%m-%d"); ошибки нет, но грузится страница невероятно долго, иногда падая в ошибку 500. С выводом через $id_filter $status_filter $user_filter $keyword_filter $label_filter $modified_from_filter ORDER BY status, id DESC $sql_limit", "%Y-%m-%d"); описанная выше проблема с переходом по страницам, но грузится быстрее.
-
При попытке перехода по страницам, на вкладке "все заказы" - выпадает ошибка: Warning: The SELECT would examine more than MAX_JOIN_SIZE rows; check your WHERE and use SET SQL_BIG_SELECTS=1 or SET SQL_MAX_JOIN_SIZE=# if the SELECT is okay [SELECT o.id, o.delivery_id, o.delivery_price, o.separate_delivery, o.payment_method_id, o.paid, o.payment_date, o.closed, o.discount, o.coupon_discount, o.date, o.user_id, o.name, o.address, o.phone, o.email, o.comment, o.status, o.url, o.total_price, o.note FROM s_orders AS o LEFT JOIN s_orders_labels AS ol ON o.id=ol.order_id WHERE 1 ORDER BY status, id DE
-
Кажется, доработка просто усугубляет проблему с количеством заказов. Вкладка "все заказы" теперь открывается, однако очень медленно, а переход на последнюю страницу на вкладке "все заказы" - не работает. Похоже, что это уже новая проблема, сейчас создам отдельную тему.
-
Проверил. Точно, дело в доработке. Если меняю код в api/orders.php на старый - все окей. Всего заказов 9500 тысяч, примерно. $id_filter $status_filter $user_filter $keyword_filter $label_filter $modified_from_filter GROUP BY o.id ORDER BY status, id DESC $sql_limit", "%Y-%m-%d");
-
Появилась еще одна проблема, кажется, прямое следствие этой доработки: Warning: The SELECT would examine more than MAX_JOIN_SIZE rows; check your WHERE and use SET SQL_BIG_SELECTS=1 or SET SQL_MAX_JOIN_SIZE=# if the SELECT is okay [SELECT o.id, o.delivery_id, o.delivery_price, o.separate_delivery, o.payment_method_id, o.paid, o.payment_date, o.closed, o.discount, o.coupon_code, o.coupon_discount, o.date, o.user_id, o.name, o.address, o.phone, o.email, o.comment, o.status, o.url, o.total_price, o.note, o.track FROM s_orders AS o LEFT JOIN s_orders_labels AS ol ON o.id=ol.order_id WHERE 1 AND o
-
Спасибо, работает.
-
Да, это должно решить проблему. Спасибо за экспорт, в остальном все отлично, осталось только допилить под себя вывод.
-
Прошу прощения, что-то я очень мнительный сегодня Да, я уже так и сделал. Однако, проблема, похоже, в том, что их очень много. При попытке экспорта сыплются варнинги: Warning: The SELECT would examine more than MAX_JOIN_SIZE rows; check your WHERE and use SET SQL_BIG_SELECTS=1 or SET SQL_MAX_JOIN_SIZE=# if the SELECT is okay [SELECT o.id, o.delivery_id, o.delivery_price, o.separate_delivery, o.payment_method_id, o.paid, o.payment_date, o.closed, o.discount, o.coupon_code, o.coupon_discount, o.date, o.user_id, o.name, o.address, o.phone, o.email, o.comment, o.status, o.url, o.total_price, o.n
-
Не нападайте на меня, я просто пытаюсь разобраться. "Обычно существуют" в любом магазине на Симпле, адаптированном для реальной работы. У себя я все подогнал под рабочий макет, правда есть сложности с "все заказы" и "выполненные" - но это, скорее всего, какие-то косяки со статусами у меня в базе. Про форму - это очевидно, даже для меня, так что я и писать не стал.
-
А для чего вот этот фрагмент в ExportXLAdmin.php: if($status<4) $filter['status'] = $status; Он запрещает выгружать заказы со статусом больше 4, но кроме базовых "все заказы, новый, принят, выполнен, удален", обычно существуют и дополнительные статусы.