Надежнее в том плане, что я, как привыкший всё трогать ручками (видать с младенчества привычка осталась :) ) доверяю только тому, что сам ощупал. Во встроенном бэкапе мне только приходится доверять, что всё сделано правильно. Через терминал я же что укажу - то и забэкаплю. И так, как я захочу и посчитаю правильным )) Здесь вопрос только в этом ))
Надежнее в том плане, что я, как привыкший всё трогать ручками (видать с младенчества привычка осталась :) ) доверяю только тому, что сам ощупал. Во встроенном бэкапе мне только приходится доверять, что всё сделано правильно. Через терминал я же что укажу - то и забэкаплю. И так, как я захочу и посчитаю правильным )) Здесь вопрос только в этом ))
Я как раз не силен в матчасти (и особой правильностью заточки рук похвастаться не могу) и наличие встроенного инструмента бэкапа в том числе повлияло на покупку лицензии.
Но, как выяснилось, в полной мере положиться на него нельзя. Жаль... Жаль, что узнал об этом, пробежавшись по граблям... Как обычно...
Всё хвалю да хвалю, что нормально бэкап устроен. А вот вам: сейчас экспортировал товары из магазина, и импортировал их в чистую базу на 4.5.1 SP1
Повторюсь - база пустая!
Импорт сообщил, что шесть с лишним тысяч товаров создано и один (!) обновлен!
При этом все категории были созданы, а один товар (который в рабочем магазине имеет основную и притом одну категорию, назовем "категория") в новом эта категория встала как дополнительная, а сам товар помещен в категорию "Products", что автоматом создается для товаров без категорий. У части товаров вместо выключенного статуса проставился включенный. Далее. При экспорте выгрузил товары в директорию exim/backup/images/1/
При импорте тоже стоит поле, откуда брать изображения...... но зачем оно? я перенес в новую установку изображения в папку exim/backup/images/ и оставил это значение (что и стоит по умолчанию) но вне зависимости от этого значения, скрипт ищет именно в exim/backup/images/1/ - так как этот путь полностью пишется в файле
Мелочи, на которые со временем перестаешь обращать внимание, но когда сталкиваешься впервые - вводят в замешательство...
PS
Бог с ней, с админкой, дай бог, чтоб с лица не глючило )))
Характеристики.
Новая таблица характеристик, где всё скопом... И прпи этом даже сортировки по группем нет. Ну не знаю... Старая таблица, где визуально сразу всё по группам было разделено, и когда не надо было входить в каждую характеристику, а прямо в таблице расставить позиции - моё имхо - было гораздо удобнее
вот кстати у меня тоже этих блоков накопилось прилично, самое неприятное непонятно как их отличать и угадывать какой из них рабочий. Как Вы решили эту проблему?
Ну вот, кстати, у меня времечко появилось, и я начал чистить базу. Алгоритм удаления лишних блоков. (На моем примере блока "Строка навигации", коих у меня уже 19 :) )
1. Надо узнать ИД блока, который показывается на сайте. Два пути
а) открываем лицо сайта и смотрим в коде (ПКМ по строке навигации, Посмотреть код):
б) открываем макеты, правой кнопкой по нужному блоку и в Просмотре кода ищем ИД блока:
2. Открываем блоки, ПКМ по нужному блоку, Просмотр кода, и ищем блок с найденным ИД (у меня это оказался 26). Все остальные могу смело удалять.
PS: На всякий случай можно пролистать все локации и посмотреть, нет ли там этого блока с другим ИД, У меня например в локации блога Главное содержимое с другим ИД образовалось
Ну и бэкап базы на всякий случай. Если случайно не тот блок удалите.
вероятно будет:
Это ж наверное у меня одного такое.
Вообщем для меня лучше, чем phpmyadmin или бэкап функционал хостера ничего нету.
Я еще при выборе движка два года назад читал по форумам, что тех.поддержка никакая и на нее не расчитывал. Один раз обратился и убедился в этом лично.
eComLabs на форуме - ВОТ ЭТО НАСТОЯЩАЯ ПОДДЕРЖКА!
Ваше обращение в тех поддержку это основной механизм по улучшению CS-Cart. Тех поддержка меняется, сейчас вы можете оценивать качество каждого обращения, что в свою очередь привлекает внимание руководителя. Прочитайте пожалуйста этот пост: http://forum.cs-cart.com/topic/46952-%D1%8F%D0%BC%D0%B0%D1%80%D0%BA%D0%B5%D1%82-%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5-%D0%B8-%D0%B2%D1%8B%D0%B3%D1%80%D1%83%D0%B7%D0%BA%D0%B0-yml/?view=findpost&p=271069
Встроенный бэкап и обновления - это функционал с генератором случайного результата. Может получится, может нет, может с первого раза, может с третьего.
Я заметил, что при восстановлении БД размером около 22Мб, таблицы какие успеют восстановится, те и будут. Причем кол-во таблиц при каждом восстановлении - разное. Ну чем не функционал с генератором случайного результата?
Хорошо бы, разработчики обратили внимание на эту критику... Получается, что функционал бэкапа в движке есть, но пользоваться им просто опасно.
После таких бэкапов приходится обращаться в ТП и платить кредитами, а это не есть хорошо.
Вот бы услышать комментарий представителя разработчиков относительно этой претензии.
Привет,
Я сначала постараюсь описать зачем нужен бекап по задумке разработчиков, а потому как мы можем улучшить.
Итак, средства автоматического бекапа предназначены для решения двух основных задач:
- слепок текущего состояния системы, для того чтобы в любой момент его можно было восстановить. Обычно используется при апгрейде, либо перед применением серьезных модификаций.
- копия текущего магазина, для того чтобы перенести его на другой хостинг
Львиная часть проблем с бекапом вызывается серверными настройками, обычное это тайм лимит.
Я хочу сделать так чтобы бекап работал корректно, и был удобен в использовании. Если вы готовы помочь мне в этом, то пожалуйста напишите о своих проблемах, с детализацией следующих моментов:
- с какой целью делался бекап
- какой хостинг вы используете
- какой получился результат (какие возникли проблемы, какая разница в данных, потеряли ли что-то и т.д. - т.е. детальное описание самой проблемы)
Буду благодарен за подробный ответ. Либо можем лично пообщаться по этому поводу в скайпе например, или в slack.
Еще раз напишу, что пользуюсь для бэкапа БД тем же supexdumper - потому что он на порядок если не на два быстрее, плюс задание на крон позволяет вешать, да ещё и с ротацией. ОДНАКО. Никогда не забываю делать бэкап из админки, потому как пару раз у меня отказались восстанавливать базу из бэкапа и phpmyadmin, и SD. И только Резервное копирование в админке без вопросов развернуло обратно сделанный бэкап.
Как удалить ненужные блоки
Ничего нового не появилось. Выискивать по id жутко муторно, особенно если блок на разных макетах. Наверняка есть один запрос к БД, чтобы, хотя бы вывести номера неиспользуемых. Кто состряпает?
Ну или по хорошему. запретить удалять блоки, если они есть в макете. Мол, сначала удалите в макете.