Cs-Cart 4.5.1 Уже Здесь!


#41

Надо отдать ТП должное. Нашли решение. Смотрите в тут.

:) общими усилиями )


#42

Успокаиваться рано, возможно есть еще другие косяки :) Ищите внимательнее!


#43

Успокаиваться рано, возможно есть еще другие косяки :) Ищите внимательнее!

Рано, конечно.

Пропали банеры с главной и накак не возвращаются....

Тоже жду решения. Я так понимаю, в этой проблеме я одинок?


#44

Всем привет,

Мы выпустили сегодня обновления до 4.5.1SP1 - там эта проблема исправлена.

Апгрейд должен быть доступен тем у кого 4.5.1.

Если вы обновляетесь с 4.4.3 то сразу обновляйтесь до 4.5.1SP1.


#45

Рано, конечно.

Пропали банеры с главной и накак не возвращаются....

Тоже жду решения. Я так понимаю, в этой проблеме я одинок?

Да, это именно в связи с проблемами при откате.

А что за ошибка возникла при откате обновления?

Нам надо бы посмотреть в чем дело, чтобы исключить в дальнейшем.


#46

Да, это именно в связи с проблемами при откате.

А что за ошибка возникла при откате обновления?

Нам надо бы посмотреть в чем дело, чтобы исключить в дальнейшем.

Дело в том, что на моей стороне все прошло штатно. Репортов об ошибках не было.

Я расскажу цепочку действий, м.б. это как-то поможет:

Обновился с 4.4.3 до 4.5.1. Ошибку обнаружил только через несколько дней, т.е. простой откат уже не помог бы, поскольку в базе уже были существенные изменения.

Сделал бэкап штатными средствами. Сделал экспорт всех данных, потом откатил назад (до 4.4.3), сделал импорт. Обнаружил проблему "Способы оплаты" (писал выше - страница не работала). Загрузил сделанный ранее бэкап 4.5.1.

Всё делал только штатными средствами. Только из админки cs-cart. Ошибок в процессе не было. Думаю, какая-то из вышеперечисленных операций отрабатывает некорректно.

Повторюсь: косяки выявлены в двух местах: "Администрирование - способы оплаты" и "пропали банеры". Может быть еще где-то. На глаза не попалось.


#47

Если у вас остались тексты - попробуйте поиск с текстом по базе таблица bm_blocks_content и отсюда уже танцевать. У меня после многочисленных обновлений (время от времени блоки вдруг берут и дублируются сами собой) штук по 10 а то и 15 блоков корзин, хлебных крошек, блоков меню, итп итп. Посмотрите как с этим у вас.

вот кстати у меня тоже этих блоков накопилось прилично, самое неприятное непонятно как их отличать и угадывать какой из них рабочий. Как Вы решили эту проблему?


#48

...при создании накладных отправки в модуле СДЭК цена доставки включается по умолчанию в накладную, хотя клиент уже расплатился за доставку, оплатив заказ. Если не удалить вручную это поле, при формировании накладной для СДЭК, то с клиента по накладной потребуют оплатить доставку при получении второй раз.


#49

...при создании накладных отправки в модуле СДЭК цена доставки включается по умолчанию в накладную, хотя клиент уже расплатился за доставку, оплатив заказ. Если не удалить вручную это поле, при формировании накладной для СДЭК, то с клиента по накладной потребуют оплатить доставку при получении второй раз.

А как Вы его вообще заставили работать ? У меня не работает, при попытке сделать тестовый расчет выдает :

Ошибка: Не задан город-получатель

и вот как угадать где и что не настроено, не понятно


#50

вот кстати у меня тоже этих блоков накопилось прилично, самое неприятное непонятно как их отличать и угадывать какой из них рабочий. Как Вы решили эту проблему?

Да никак. Как-то просил ТП перенести базу (только связку товары-покупатели-заказы плюс корзины с отложенными) на чистую установку, так как store import переносит вместе с блоками, с записями в базе и файлах, в итоге плюс ещё и все накопленные баги тянутся, а я наоборот от всего дерьма хотел избавиться. В результате ТП сделала мне Store import за 30 кредитов, что я и сам от большой лени мог сделать совершенно бесплатно, и я плюнул на это дело (store import ещё этих блоков добавил кучку с маленькой тележкой). Посвободнее время будет - перенесу вручную, там везде вручную надо отслеживать айдишники товаров и покупателей в заказах, и перезаписывать


#51

Спасибо за ответ. Теперь число людей, которые не доверяют встроенному резервному копированию увеличилось на одного пользователя.

Да, встроенный бэкап - Гавно! И именно с большой буквы! У меня каждое восстановление восстанавливает по разному. Одно - не все заказы, второе - забыл макеты, третье - доставка рухнула и т.д.

Пришел ответ из техподдержки...... проблема не обнаружена

Получается для одного человека проблемы нет, а как еще обратились, то проблема нашлась. Скорее всего даже не искали.


#52

Да, встроенный бэкап - Гавно! И именно с большой буквы! У меня каждое восстановление восстанавливает по разному. Одно - не все заказы, второе - забыл макеты, третье - доставка рухнула и т.д.

Хорошо бы, разработчики обратили внимание на эту критику... Получается, что функционал бэкапа в движке есть, но пользоваться им просто опасно.

После таких бэкапов приходится обращаться в ТП и платить кредитами, а это не есть хорошо.

Вот бы услышать комментарий представителя разработчиков относительно этой претензии.


#53

Вот бы услышать комментарий представителя разработчиков относительно этой претензии.

вероятно будет:

Пришел ответ из техподдержки...... проблема не обнаружена

Это ж наверное у меня одного такое.

Вообщем для меня лучше, чем phpmyadmin или бэкап функционал хостера ничего нету.

Я еще при выборе движка два года назад читал по форумам, что тех.поддержка никакая и на нее не расчитывал. Один раз обратился и убедился в этом лично.

eComLabs на форуме - ВОТ ЭТО НАСТОЯЩАЯ ПОДДЕРЖКА!


#54

Получается, что функционал бэкапа в движке есть, но пользоваться им просто опасно.

Встроенный бэкап и обновления - это функционал с генератором случайного результата. Может получится, может нет, может с первого раза, может с третьего.

Я заметил, что при восстановлении БД размером около 22Мб, таблицы какие успеют восстановится, те и будут. Причем кол-во таблиц при каждом восстановлении - разное. Ну чем не функционал с генератором случайного результата?


#55

Встроенный бэкап и обновления - это функционал с генератором случайного результата. Может получится, может нет, может с первого раза, может с третьего.

Я заметил, что при восстановлении БД размером около 22Мб, таблицы какие успеют восстановится, те и будут. Причем кол-во таблиц при каждом восстановлении - разное. Ну чем не функционал с генератором случайного результата?

База в сто с лишним мегабайт. Вы посмотрите на настройки сервера, php и mysql - раз у вас так срабатывает. Я вас скажу, почему делаю три бэкапа - из phpmyadmin, supexdumper и встроенный бэкап. потому как supexdumper работает быстро, phpmyadmin я полностью настраиваю процесс и контролирую... но пару раз было что обратно и там и там у меня процесс восстановления зависал из за коллизий в самих таблицах (типа задвоения записей или ключей, потом вручную выискивал) - так вот в этом случае именно встроенный бэкап вставал на место без каких либо проблем и спасал меня от краха :)


#56

База в сто с лишним мегабайт. Вы посмотрите на настройки сервера, php и mysql - раз у вас так срабатывает. Я вас скажу, почему делаю три бэкапа - из phpmyadmin, supexdumper и встроенный бэкап. потому как supexdumper работает быстро, phpmyadmin я полностью настраиваю процесс и контролирую... но пару раз было что обратно и там и там у меня процесс восстановления зависал из за коллизий в самих таблицах (типа задвоения записей или ключей, потом вручную выискивал) - так вот в этом случае именно встроенный бэкап вставал на место без каких либо проблем и спасал меня от краха :)

Я, конечно, не программист, но уверен, что в процесс бэкапа штатными средствами можно и нужно встроить процесс проверки До/После. Т.е. сверять то, что фактически в базе с тем, что вошло в резервную копию и то же самое при восстановлении из резервной копии и в зависимости от результата предложить переделать копию/перезалить бэкап.

Как-то так... Иначе какой смысл в процессе, результат которого никто не может гарантировать?...


#57

Я, конечно, не программист, но уверен, что в процесс бэкапа штатными средствами можно и нужно встроить процесс проверки До/После. Т.е. сверять то, что фактически в базе с тем, что вошло в резервную копию и то же самое при восстановлении из резервной копии и в зависимости от результата предложить переделать копию/перезалить бэкап.

Как-то так... Иначе какой смысл в процессе, результат которого никто не может гарантировать?...

смысл встроенного бэкапа - создать полную копию бд (по желанию с файловой системой) и в случае непредвиденных результатов откатиться обратно: drop table - cteate table - insert, то есть очистить базу и залить в нее данные из бэкапа, что логично и достаточно. То, что вы хотите, конечно круто... Но это отдельный инструмент, сам по себе полагаю такой аддон будет в разработке по объему и стоимости мало отличим от движка магазина ))


#58

смысл встроенного бэкапа - создать полную копию бд (по желанию с файловой системой) и в случае непредвиденных результатов откатиться обратно: drop table - cteate table - insert, то есть очистить базу и залить в нее данные из бэкапа, что логично и достаточно. То, что вы хотите, конечно круто... Но это отдельный инструмент, сам по себе полагаю такой аддон будет в разработке по объему и стоимости мало отличим от движка магазина ))

На самом деле почти любая индивидуальная разработка для CS-CART соизмерима по стоимости со стоимостью движка... А вот "допиливание" такого функционала докинуло бы нехилый плюс в карму разработчикам.... Ну и инструмент такого уровня был бы серьезным конкурентным преимуществом.


#59

сверять то, что фактически в базе с тем, что вошло в резервную копию

скачиваете файл бэкапа до и файл бэкапа после, любая программа сравнения файлов покажет различия. Даже Тотал Коммандер (Файл - Сравнить по содержимому). Или WinMerge

В linux с этим ещё проще и красивее - Meld например


#60

скачиваете файл бэкапа до и файл бэкапа после, любая программа сравнения файлов покажет различия. Даже Тотал Коммандер (Файл - Сравнить по содержимому). Или WinMerge

В linux с этим ещё проще и красивее - Meld например

Только сравнивать надо не только 2 файла, а еще и файл бэкапа с содержимым базы. Только так будет реально найти косяки...

Я так понял, что поля в базе в результате таких операций частенько "теряются".

Ну или (при невозможности такого сравнения) разворачивать полученный бэкап в отдельную (резервную) базу и как-то автоматически сверять с последующим выводом результатов сравнения или заменой полей...

В любом случае, это фантазия... Я так понял, что пока бэкап средствами хостинга всё же в разы надежнее, чем штатный бэкап CMS. Как бы нам не хотелось иного...