Two years into the development of Drupal 8, Dries Buytaert announced that Drupal 8.0 might ship without an upgrade path.
This unorthodox decision was made to support substantial improvements in Drupal’s major version upgrade process by introducing a robust new sub-system based on the popular contributed modules Migrate and Migrate D2D. The sub-system includes the Migrate module, which provides the basic framework and API, and the Migrate Drupal module, which provides the upgrade paths and framework to enable other Drupal-to-Drupal use cases in contrib.
The substantial wins with this new approach include the ability to move directly from Drupal 6 to Drupal 8 – as well as the possibility of providing more fine-grained control over the process – and the option of continuous content migration.
The migration team is working extraordinarily hard to be ready by the time that D8 is ready for beta. As of March 31, Migrate API has been committed to core. The last blocking issues for Migrate Drupal were resolved during the DevDays sprint, and the team will begin submitting patches for the D6 to D8 migration path to the core queue any day now.
Without the new API, an abbreviated move from Drupal 6 to Drupal 8 would have looked something like:
For Drush users, the 'drush up' command would vastly simplify this, but two full upgrades — from 6 to 7, then 7 to 8 — would still have been required, inevitably losing data in each step.
As of Drupal 8, update.php will no longer be used for the two distinctly different purposes of minor version updates and major version upgrades. Update.php will continue to be used for updates within the same version, but Migrate will handle moving between major versions.
This will substantially change the way upgrades function. The first key difference when using Migrate is that instead of working within a single site, you'll have two: a source and a destination. In a D6 to D8 migration, for example, your D6 site will be the source and a fresh Drupal 8 install will be the destination. The abbreviated process will look more like:
You won't need to do anything with your source site; no disabling modules, no maintenance mode. Migrate strictly reads data from the source database, and any module with a migration path – whether core or contributed – will be migrated, provided that:
If you don't want to migrate a module's data, you can disable it on the destination site before running Migrate. It’s clear, though, that many sites need more sophisticated or fine-grained control than that. At this point, it hasn’t been fully determined how much complexity will ultimately be supported by core’s user interface.
The current plan is to limit the core interface to the two-button process outlined above and to supply a more complex user interface for taking advantage of advanced API functionality in a contributed module. The core API itself includes the framework to enable implementation of the following features in contrib:
To access any of that functionality, at least initially, you’d either use Drush or Migrate Plus. As the user interface matures and new source plug-ins are written, functionality will be evaluated for inclusion in core on a case-by-case basis.
Previously, site upgrades were essentially a one-time thing. You might have had to try repeatedly to succeed, but ultimately, there came the point where you ran the entire upgrade and that was it.
Configuration migrations will still work that way. You’ll run the configuration migration once, and afterward, you’ll make additional adjustments manually. Where content is concerned, however, the API allows for a continuous approach. The vision is that using either Migrate Plus or Drush, each time you migrate content, anything new will be imported and content that’s been updated since the last run will be re-imported, making it possible to keep your D6 site in production, with users adding and editing content while you refine and QA your new D8 site.
The move from Update.php to Migrate API promises greater power, flexibility, accuracy, and ease for site administrators. A basic site will use the 2-button core-supplied user interface. Sites of moderate to intermediate complexity will be able to do considerable configuration through the Migrate Plus interface. Most complex sites, however, will likely require the creation of custom code to fully migrate a site, but the straightforward syntax and loosely coupled API is intended to support that inevitability. Complex sites with large datasets may also prefer using Drush to perform migrations due to its ability to manage memory and split large tasks among multiple batches in order to avoid resource exhaustion.
Migrate is still under heavy development at the time of this writing. So far, the overall vision has been consistent over the six months of the project, but exactly which features will be split into core, Drush, or Migrate Plus may vary. Join the Drupal Group at http://wdog.it/4/1/imp for the current status.
An individual migration consists of a source plugin, a process plugin, and a destination plugin.
The three plugins are defined in a YAML configuration entity, which also describes groups and dependencies.
Drupal Developer having 9+ year experience, implementation and having strong knowledge of technical specifications, workflow development. Ability to perform effectively and efficiently in team and individually. Always enthusiastic and interseted to study new technologies
We believe Drupal is similar or superior to what TYPO3 and others can accomplish, but it's not easy to convince others about it.
Trong hình SharedCloud là thư mục dùng chung của hệ điều hành của bạn và Ubuntu. Ubuntu sẽ tìm thấy folder SharedCloud trong /mnt/hgfs/
Mới ra mắt hơn 3 tháng tại thị trường Việt Nam, chiếc máy ảnh Galaxy Camera của Samsung đã sụt giá gần 1/3, từ 12,8 triệu đồng xuống còn 8,8 triệu đồng.
