Надо отдать ТП должное. Нашли решение. Смотрите в тут.
:) общими усилиями )
Успокаиваться рано, возможно есть еще другие косяки :) Ищите внимательнее!
Успокаиваться рано, возможно есть еще другие косяки :) Ищите внимательнее!
Рано, конечно.
Пропали банеры с главной и накак не возвращаются....
Тоже жду решения. Я так понимаю, в этой проблеме я одинок?
Всем привет,
Мы выпустили сегодня обновления до 4.5.1SP1 - там эта проблема исправлена.
Апгрейд должен быть доступен тем у кого 4.5.1.
Если вы обновляетесь с 4.4.3 то сразу обновляйтесь до 4.5.1SP1.
Рано, конечно.
Пропали банеры с главной и накак не возвращаются....
Тоже жду решения. Я так понимаю, в этой проблеме я одинок?
Да, это именно в связи с проблемами при откате.
А что за ошибка возникла при откате обновления?
Нам надо бы посмотреть в чем дело, чтобы исключить в дальнейшем.
Да, это именно в связи с проблемами при откате.
А что за ошибка возникла при откате обновления?
Нам надо бы посмотреть в чем дело, чтобы исключить в дальнейшем.
Дело в том, что на моей стороне все прошло штатно. Репортов об ошибках не было.
Я расскажу цепочку действий, м.б. это как-то поможет:
Обновился с 4.4.3 до 4.5.1. Ошибку обнаружил только через несколько дней, т.е. простой откат уже не помог бы, поскольку в базе уже были существенные изменения.
Сделал бэкап штатными средствами. Сделал экспорт всех данных, потом откатил назад (до 4.4.3), сделал импорт. Обнаружил проблему "Способы оплаты" (писал выше - страница не работала). Загрузил сделанный ранее бэкап 4.5.1.
Всё делал только штатными средствами. Только из админки cs-cart. Ошибок в процессе не было. Думаю, какая-то из вышеперечисленных операций отрабатывает некорректно.
Повторюсь: косяки выявлены в двух местах: "Администрирование - способы оплаты" и "пропали банеры". Может быть еще где-то. На глаза не попалось.
Если у вас остались тексты - попробуйте поиск с текстом по базе таблица bm_blocks_content и отсюда уже танцевать. У меня после многочисленных обновлений (время от времени блоки вдруг берут и дублируются сами собой) штук по 10 а то и 15 блоков корзин, хлебных крошек, блоков меню, итп итп. Посмотрите как с этим у вас.
вот кстати у меня тоже этих блоков накопилось прилично, самое неприятное непонятно как их отличать и угадывать какой из них рабочий. Как Вы решили эту проблему?
...при создании накладных отправки в модуле СДЭК цена доставки включается по умолчанию в накладную, хотя клиент уже расплатился за доставку, оплатив заказ. Если не удалить вручную это поле, при формировании накладной для СДЭК, то с клиента по накладной потребуют оплатить доставку при получении второй раз.
...при создании накладных отправки в модуле СДЭК цена доставки включается по умолчанию в накладную, хотя клиент уже расплатился за доставку, оплатив заказ. Если не удалить вручную это поле, при формировании накладной для СДЭК, то с клиента по накладной потребуют оплатить доставку при получении второй раз.
А как Вы его вообще заставили работать ? У меня не работает, при попытке сделать тестовый расчет выдает :
Ошибка: Не задан город-получатель
и вот как угадать где и что не настроено, не понятно
вот кстати у меня тоже этих блоков накопилось прилично, самое неприятное непонятно как их отличать и угадывать какой из них рабочий. Как Вы решили эту проблему?
Да никак. Как-то просил ТП перенести базу (только связку товары-покупатели-заказы плюс корзины с отложенными) на чистую установку, так как store import переносит вместе с блоками, с записями в базе и файлах, в итоге плюс ещё и все накопленные баги тянутся, а я наоборот от всего дерьма хотел избавиться. В результате ТП сделала мне Store import за 30 кредитов, что я и сам от большой лени мог сделать совершенно бесплатно, и я плюнул на это дело (store import ещё этих блоков добавил кучку с маленькой тележкой). Посвободнее время будет - перенесу вручную, там везде вручную надо отслеживать айдишники товаров и покупателей в заказах, и перезаписывать
Спасибо за ответ. Теперь число людей, которые не доверяют встроенному резервному копированию увеличилось на одного пользователя.
Да, встроенный бэкап - Гавно! И именно с большой буквы! У меня каждое восстановление восстанавливает по разному. Одно - не все заказы, второе - забыл макеты, третье - доставка рухнула и т.д.
Пришел ответ из техподдержки...... проблема не обнаружена
Получается для одного человека проблемы нет, а как еще обратились, то проблема нашлась. Скорее всего даже не искали.
Да, встроенный бэкап - Гавно! И именно с большой буквы! У меня каждое восстановление восстанавливает по разному. Одно - не все заказы, второе - забыл макеты, третье - доставка рухнула и т.д.
Хорошо бы, разработчики обратили внимание на эту критику... Получается, что функционал бэкапа в движке есть, но пользоваться им просто опасно.
После таких бэкапов приходится обращаться в ТП и платить кредитами, а это не есть хорошо.
Вот бы услышать комментарий представителя разработчиков относительно этой претензии.
Вот бы услышать комментарий представителя разработчиков относительно этой претензии.
вероятно будет:
Пришел ответ из техподдержки...... проблема не обнаружена
Это ж наверное у меня одного такое.
Вообщем для меня лучше, чем phpmyadmin или бэкап функционал хостера ничего нету.
Я еще при выборе движка два года назад читал по форумам, что тех.поддержка никакая и на нее не расчитывал. Один раз обратился и убедился в этом лично.
eComLabs на форуме - ВОТ ЭТО НАСТОЯЩАЯ ПОДДЕРЖКА!
Получается, что функционал бэкапа в движке есть, но пользоваться им просто опасно.
Встроенный бэкап и обновления - это функционал с генератором случайного результата. Может получится, может нет, может с первого раза, может с третьего.
Я заметил, что при восстановлении БД размером около 22Мб, таблицы какие успеют восстановится, те и будут. Причем кол-во таблиц при каждом восстановлении - разное. Ну чем не функционал с генератором случайного результата?
Встроенный бэкап и обновления - это функционал с генератором случайного результата. Может получится, может нет, может с первого раза, может с третьего.
Я заметил, что при восстановлении БД размером около 22Мб, таблицы какие успеют восстановится, те и будут. Причем кол-во таблиц при каждом восстановлении - разное. Ну чем не функционал с генератором случайного результата?
База в сто с лишним мегабайт. Вы посмотрите на настройки сервера, php и mysql - раз у вас так срабатывает. Я вас скажу, почему делаю три бэкапа - из phpmyadmin, supexdumper и встроенный бэкап. потому как supexdumper работает быстро, phpmyadmin я полностью настраиваю процесс и контролирую... но пару раз было что обратно и там и там у меня процесс восстановления зависал из за коллизий в самих таблицах (типа задвоения записей или ключей, потом вручную выискивал) - так вот в этом случае именно встроенный бэкап вставал на место без каких либо проблем и спасал меня от краха :)
База в сто с лишним мегабайт. Вы посмотрите на настройки сервера, php и mysql - раз у вас так срабатывает. Я вас скажу, почему делаю три бэкапа - из phpmyadmin, supexdumper и встроенный бэкап. потому как supexdumper работает быстро, phpmyadmin я полностью настраиваю процесс и контролирую... но пару раз было что обратно и там и там у меня процесс восстановления зависал из за коллизий в самих таблицах (типа задвоения записей или ключей, потом вручную выискивал) - так вот в этом случае именно встроенный бэкап вставал на место без каких либо проблем и спасал меня от краха :)
Я, конечно, не программист, но уверен, что в процесс бэкапа штатными средствами можно и нужно встроить процесс проверки До/После. Т.е. сверять то, что фактически в базе с тем, что вошло в резервную копию и то же самое при восстановлении из резервной копии и в зависимости от результата предложить переделать копию/перезалить бэкап.
Как-то так... Иначе какой смысл в процессе, результат которого никто не может гарантировать?...
Я, конечно, не программист, но уверен, что в процесс бэкапа штатными средствами можно и нужно встроить процесс проверки До/После. Т.е. сверять то, что фактически в базе с тем, что вошло в резервную копию и то же самое при восстановлении из резервной копии и в зависимости от результата предложить переделать копию/перезалить бэкап.
Как-то так... Иначе какой смысл в процессе, результат которого никто не может гарантировать?...
смысл встроенного бэкапа - создать полную копию бд (по желанию с файловой системой) и в случае непредвиденных результатов откатиться обратно: drop table - cteate table - insert, то есть очистить базу и залить в нее данные из бэкапа, что логично и достаточно. То, что вы хотите, конечно круто... Но это отдельный инструмент, сам по себе полагаю такой аддон будет в разработке по объему и стоимости мало отличим от движка магазина ))
смысл встроенного бэкапа - создать полную копию бд (по желанию с файловой системой) и в случае непредвиденных результатов откатиться обратно: drop table - cteate table - insert, то есть очистить базу и залить в нее данные из бэкапа, что логично и достаточно. То, что вы хотите, конечно круто... Но это отдельный инструмент, сам по себе полагаю такой аддон будет в разработке по объему и стоимости мало отличим от движка магазина ))
На самом деле почти любая индивидуальная разработка для CS-CART соизмерима по стоимости со стоимостью движка... А вот "допиливание" такого функционала докинуло бы нехилый плюс в карму разработчикам.... Ну и инструмент такого уровня был бы серьезным конкурентным преимуществом.
сверять то, что фактически в базе с тем, что вошло в резервную копию
скачиваете файл бэкапа до и файл бэкапа после, любая программа сравнения файлов покажет различия. Даже Тотал Коммандер (Файл - Сравнить по содержимому). Или WinMerge
В linux с этим ещё проще и красивее - Meld например
скачиваете файл бэкапа до и файл бэкапа после, любая программа сравнения файлов покажет различия. Даже Тотал Коммандер (Файл - Сравнить по содержимому). Или WinMerge
В linux с этим ещё проще и красивее - Meld например
Только сравнивать надо не только 2 файла, а еще и файл бэкапа с содержимым базы. Только так будет реально найти косяки...
Я так понял, что поля в базе в результате таких операций частенько "теряются".
Ну или (при невозможности такого сравнения) разворачивать полученный бэкап в отдельную (резервную) базу и как-то автоматически сверять с последующим выводом результатов сравнения или заменой полей...
В любом случае, это фантазия... Я так понял, что пока бэкап средствами хостинга всё же в разы надежнее, чем штатный бэкап CMS. Как бы нам не хотелось иного...