Я працюю в університеті, а минулого року минарешті відірвався від нашого статичного HTML-сайту на кілька тисяч сторінок і перейшов на сайт Drupal. Очевидно, це тягне за собою величезні обсяги введення даних.
Що робити, якщо ви вже використовуєте CMS і єперехід на інший, який більше відповідає вашим потребам? Як мінімізувати гору введення даних під час таких величезних змін? Чи створені для цього інструменти, чи слід дотримуватися деяких найкращих практик?
Відповіді:
5 за відповідь № 1Очікуйте, що доведеться як попередньо обробити, так іпісля обробки даних вручну, що б не сталося. Рано визнайте, що ваші дані можуть бути в гіршому стані, ніж ви думаєте: поля будуть неправильно використані; посилання «запис на запис» (зовнішні ключі) можуть бути реалізовані неправильно або взагалі; вміст, ймовірно, потребує прополювання, а іноді - просто поганий або неправильний.
Перевірте кодування бази даних.У старих базах даних не буде кодування Unicode, і вони стануть сварливими, якщо вам доведеться експортувати дампи даних та імпортувати їх в інше місце. Навіть тоді припустимо, що у ваших даних будуть якісь ненормативні недруковані символи: програми, як Word, здається, якось вводять їх скрізь, і я бачив ... кодові точки ... ви, люди, не повірите. Подумайте над тим, як замінити ваші дані ще до того, як ви навіть запустите (або навіть зміте дамп бази даних) для цих символів. Вирішіть, чи не сміти їх, чи спробувати перетворити у випадку, наприклад Слово "розумні" розділові знаки.
Створити явні дані дуже важкоспоруд із прихованої. Якщо ваші вхідні дані мають окреме поле дати, ви можете зіставити це з полем дати; якщо він має дату як частину великої групи HTML, навіть якщо ця дата міститься в тезі з атрибутом id, прості сценарії не працюють. Ви можете використовувати офлайн-сценарії з BeautifulSoup або (якщо ваш HTML - трохи приємніший ) швидше lxml попередньо обробляє ваш набір даних, витягує ці неявні поля та зберігає їх у неявному форматі. Подумайте про те, щоб створити проміжну базу даних, куди збираються йти ці виправлення.
Модуль Migrate чудовий, але його можна отриматидійсно хороша достовірність даних і грати в розумніші трюки, можливо, вам доведеться дізнатись про її систему підключень (термінологія Drupal для функцій, що слідують певній схемі іменування) та основи написання модуля для розміщення цих гачків (модуль загалом просто PHP-файл, де всі функції починаються з одного і того ж тексту, ім'я файлу модуля.)
Весь імпортований вміст має бути позначений якпринаймні побіжна перевірка. Ви можете зробити це, імпортувавши його зі статусом = 0, тобто неопублікованим, а потім створити представлення за допомогою модуля Views, щоб переглянути вміст і відкрити його в інших вкладках для перевірки. Масові операції переглядів дозволяють встановити прапорці поруч із елементами перегляду, щоб ви могли затвердити багато вузлів одночасно.
Очікуйте запуску та повторного запуску та повторного запуску імпорту,щоразу фіксуючи нові речі. Перевірте десять або двадцять предметів якомога раніше. Якщо є якісь проблеми, перевірте ще десять чи двадцять. Виправте та повторіть імпорт.
Виміряйте, як довго може йти один цикл імпортуприймати. Будьте песимістичними: у нас був імпорт, який, як ми очікували, зайняв би десять годин, коли ми експонували повний набір даних; поки ми нарешті не виправили повільні запити, передбачалось, що це займе два тижні.
Якщо ви сумніваєтесь, або якщо ви вважаєте технічнимаспекти вищезазначеного просто забирають більше часу, ніж сама робота, а потім просто наймайте тимчасових спеціалістів для обробки даних. Але вам все-таки потрібен гідний контроль якості, якомога раніше під час їх роботи. Розробники Drupal також найняті: спробуйте відповідний IRC-канал вашої країни або розмістіть нотатку у відповідній групі groups.drupal.org. Вони дорожчі, ніж temps, але зазвичай пишуть кращий PHP ...! Розгляньте можливість найму агенції: це безсоромна робота, оскільки я працюю на неї, але іноді найкраще залучити експертів для цих конкретних робіт.
Дійсно хороший імпорт завжди важкий, важчий, ніж ви очікуєте. Не дозволяйте, щоб це вас збило!
7 для відповіді № 2
The Мігрувати модуль для Drupal надав би велику допомогу. Міграція даних Economist.com на Drupal дасть вам огляд процесу.
The відео від Міграція: не лише для птахів презентація на Drupalcon DC 2009, можливо, дещо застаріла, але також дає гарне введення.
2 для відповіді № 3
Майстер переміщення + таблиці (і схеми + подання) - це шлях. За допомогою майстра таблиць ви можете виставити будь-яку таблицю в drupal та відповідно відобразити поля за допомогою міграції.
Шукайте тут детальну інструкцію: http://www.lullabot.com/articles/drupal-data-imports-migrate-and-table-wizard
2 для відповіді № 4
Ви хочете отримати доступ до існуючих даних з django. Це дуже допомагає мені при міграції: http://docs.djangoproject.com/en/1.2/howto/legacy-databases/ . З правильними визначеннями моделі у вас буде повноdjango, включаючи адміністратора. Насправді я використовую django просто як бекенд адміністратора для декількох застарілих php-проектів - адміністратор django може легко отримати багато власних рукописних скриптів адміністратора.
Авторизація повинна залишатися незмінною.Користувачі повинні мати можливість входити зі своїми обліковими даними, але важко написати сценарій міграції для даних автентифікації, оскільки схеми хешування паролів можуть бути різними, і неможливо здійснити конвертацію між ними, не знаючи простих паролів. Django надає спосіб підтримувати різні джерела авторизації, щоб ви могли писати серверну інформацію про Drupal: http://docs.djangoproject.com/en/1.2/topics/auth/#writing-an-authentication-backend
Не потрібно повністю переписувати.Якщо деякі деталі працюють нормально, вони все ще можуть працювати від Drupal. Новий код можна писати за допомогою Django з тим самим інтерфейсом. Маршрутизація між старими та новими частинами може здійснюватися за допомогою переписування URL-адрес веб-сервера. Як частини django, так і drupal можуть працювати на одній БД.