27 мая 2009 в 17:47
может кто-то встречался с таким бредом
Обновился на свою голову друпал до 5.18 и СКК до 1.10
Не могу добавить поле в материал page
При добавлении нового нового поля
user warning: Table 'content_' already exists query: CREATE TABLE content_ ( vid int unsigned NOT NULL default '0', nid int unsigned NOT NULL default '0', PRIMARY KEY (vid), KEY nid (nid) ) /*!40100 DEFAULT CHARACTER SET utf8 */ in /home/web/htdocs/idgroup/idgroup.in.ua/includes/database.mysql.inc on line 174.
user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1 query: ALTER TABLE content_ ADD COLUMN _default in /home/web/htdocs/idgroup/idgroup.in.ua/includes/database.mysql.inc on line 174.
Создано поле vves.
Нет групп, настроенных для этого типа содержимого.
Нет полей, настроенных для этого типа содержимого.
после этого нет поля не в списке полей "управлять полями нет в списке показать поля
при создании же нового типа материала не вообще закладок(табов)
Управлять полями, Показать поля, Добавить поле, Добавить группу, Шаблон
Комментарии
update.php запускали?
конечно после каждого обновления
А ССК поля русскими букавами называли? если да то все понятно.
а скорее всего так и есть у Вас в БД есть чудо таблица content_ ее быть не должно. Просто удалите ее или тип материала который либо никак не называется либо русскими буквами. (очень на это похоже).
да таблица была сontent_ была я ее удалил и попробовал создать поле ves на англ.(по русски я и раньше не называл)
но это не помогло т.е. произошло следующее исчез один варнинг остался
только
user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1 query: ALTER TABLE content_ ADD COLUMN _default in /home/web/htdocs/idgroup/idgroup.in.ua/includes/database.mysql.inc on line 174.
и внимание! появилась таблица сontent_ !
да я еще нашел в базе таблицу content_type_ я так понимаю это мой новый тип материала который не работает
Значит что-то криво проапдейтили, я с такой ерундой не встречался. Попробуйте откатиться назад и повторить операцию.
а можно как-то повторить процедуру апдейта
откатился на неделю назад уже плохо 900 нод потерял но глюк остался следующий бекап месяц назад совсем плохо
или как-то сравнить базы и влить данные из битой базы в нормальную ?
ТАкая же фигня. Грешу на модуль. Напиши, что именно установлено. Да и еще. У кого хостишься?
Хостинг data-xata.net
Установлено много всего
даже не знаю как все и перечислить
проблему не поборол пришлось откатится назад
правда я может не правильно апдейтился сразу с 5.11 на 5.18
Я заметил эту ошибку после какой-то версии. Кажется 5.17 Но не могу сказать точно от версии это зависит или нет.
есть сайт 5.11 Тестовый который можно пропдейтить последовательно до 5.17
единственно если написано как в официальной инструкции все модули отключать включать со всеми зависимостями очень муторно neochif считает что это не обязательно можно найти после какой версии не будет работать это что-то даст ?
Я не знаю можно ли сразу. Но думаю, что можно. модули можно не отключать. По моему с 5.11 до 5.17 только безопасность обновлялась, без дополнительного функционала.
вопрос не в том что сразу или нет , вопрос даст ли это что-то для поиска проблемы
я говорил что могу последовательно с 5.11 до 5.17
а не подряд если в 5.17 уже есть ошибка значит надо искать раньше
вопрос как его правильно отловить может быть еще какие действия подготовительные сделать
я просто не очень понимаю как его отловить баг
кроме как обновился попробовал создать поле
А проблема возникает именно при обновлении ядра, или ядра с модулем ССК?
а дальше попробуем придумать что с этим делать.
Попробуйте сначала обновить только ядро, или только модуль и на основании этого уже сделать какие либо выводы, кто виноват
CКК не обновлялся стоит последняя версия 5.10 обновлялось только ядро
таблица 'content_' это только CCK и никак не ядро.
т.е. Вы хотите сказать что при друпале 5.10 и ССК 1.10 у Вас все работает хорошо, без ошибок и эта таблица 'content_' присутствует, а когда начинаете обновлять ядро, то появляется ошибка?
у меня в 5.10 такой таблицы нет (я имею виду такой которая так называется 'content_' таблицы 'content_(название типа материала или название поля) ' у меня есть
да именно 5.10 все работало и после отката с 5.18 на 5.10 работает т.е. создаются типы материала и новые поля
если 5.18 удалить эту таблицу то в первый раз при создании поля оно создает эту 'content_' при этом поле в списке полей не появляется, а на второй раз ругается что есть уже такая таблица 'content_'.
Повторюсь за создание таблицы с именем контент_ отвечает только модуль ССК и кто иной, для чистоты эксперимента можете поставить голый друпал 5.10 с модулем ССК и обновить его до версии 5.18 причем сразу.
Грешить только на то что обновляли ССК модуль и обновили его как-то криво, у меня больше вариантов к сожалению нету.
А у тебя только эти таблицы в ошибке? У меня много чего еще.
У меня вообще никогда не возникало проблем с обновлением :). Во всяком случае внутри одной ветки. Я обновляюсь обычно следующим образом:
1. Бэкап изначально работающего проекта.
2. Обновление только самого движка. если все нормально прошло то опять бекап.
3. Обновление модулей по группам т.е. если я обновляю ССК то все сопутствующие ему модули типа imagefield filefield data и т.д. тоже обновляю в одно пачке (бекап желательно после каждого удачного обновления пачки модулей).
4. Обновление единичных модулей (независимых).
А вот такое количество бэкапов оправдано ли? Ведь, например, как у человека, ошибка с полем вылезла не сразу, а по ходу эксплуатации, у меня аналогично, после обновления с 6.12 до 6.13 все прошло гладко, а потом оказалось, что не могу больше менять права доступа (http://drupal.ru/node/31954). Т.е. Вы сразу после обновления не можете предвидеть, что пойдет не так, ошибок не выскочило - это ещё не значит, что их нет. Или у Вас есть ещё и схема прогнозирования ошибок, которую Вы запускаете перед бэкапом в момент обновления?
Такое количество бэкапов вы можете и не делать
я их делаю чтоб можно было максимально близко откатиться на то состояние когда ошибок не было. После удачного обновления и перехода на след шаг предыдущие бекапы просто удаляются.
Опять же по Вашей (http://drupal.ru/node/31954) ситуации могу сказать что если боков изначально нету и Вы ничего не дописывали в код и ничего не патчили в ядре то и ошибок и недоразумений всяческих не будет. (за ооочень редким исключением случаются при использовании dev модулей).
Ошибка не может вылезти потом она или есть сразу (но Вы ее не заметили или не смогли воспроизвести) или ее нету априори.
"Файл setup.php дописал руками" этот файл вообще трогать не надо
после обновления запускается файл update.php который тоже не надо трогать его достаточно просто запустить в браузере http://site_name/update.php все остальное сделается само (причем если что-то прошло не по нужному сценарию Вы увидите это в сообщениях).
Есть несколько правил соблюдая которые вы избавитесь от проблем с обновлением:
1. Не править код ядра.
2. Не править код не Ваших модулей (за очень редким исключением), а если правите то ставьте метки чтоб при замене файла видеть расхождения (есть спец программы мержилки файлов "Beyond Compare").
3. При написании собственных модулей если необходима связь с другими модулями пользоваться только системами хуков и указывать зависимости Вашего модуля от сторонних модулей.
4. Не править что-то руками в БД если не уверены что это не вызовет никаких осложнений в дальнейшей работе (для правки необходимо хорошо знать и ориентироваться в структуре БД друпала и связях между таблицами).