Migrate drupal 6 to drupal 7 site; a nightmare!

By summit on 1 Apr 2015 at 19:08 UTC

Hi,
I have to migrate 4 sites with allmost the same theme, but with different content to drupal 7 from drupal 6 and it looks like a nightmare, and I am not yet half way true.
I add this topic to get a complete working scenario, and may be some hints or easier stepts for the next sites.
This is great background information: :http://drupalcode.org/project/drupal.git/blob/refs/heads/7.x:/UPGRADE.txt And this is a nice guide with images: www.ostraining.com/blog/drupal/migrate-drupal-6-to-drupal-7/

Ok lets start;
1 ) First backup Drupal 6 code
2) Second backup Drupal 6 database for cycle 1.
Cycle 1
3) Remove non used modules
4) Disable modules which do not have a drupal 7 substitute (Like Nodewords..)
5) Remove modules which do not have a drupal 7 substitute
6) Bring all left D6 modules to the latest releases or dev.'s
7) Backup left code on sites/all/modules and modules/
8) Backup Drupal 6 database for cycle 2
Cycle 2
9) Bring back language to the default language
10) Empty sites/all/modules
11) Empty modules/[profiles]
12) Disable Upload module
13) Set default theme to Garland and
14) copy sites/modules/block/block.tpl.php to Garland theme folder (this one is needed for drupal 7)
15) Get latest D7 versions of your modules. If they are not there you have tough luck. The maintainer has then decided not to go to D7, or is working on D8, or it is not coherent with D7. You are then stucked with the content of that module and have to deal with this. I had this on Drupal 5 with the openresort module...no D6 version...
Cycle 3 Upgrade core to D7
Now the site is ready to Upgrade Core to D7. As in the Guides is stated
16) Get latest Drupal 7 Core version
17) Get latest module version (hopefully you have a module which is also there in D7
18) Upgrade Core to Drupal 7
Cycle 4 Upgrade CCK to Fields in D7
19) Get CCK D7 modules; CCK and CCK migrate
19a) Bring the CCK fields to D7. See for the upgrade guide: http://drupal.org/node/1144136
It is very important to add patch http://drupal.org/files/content_taxonomy-migration-fails-1208164-16.patch Without this patch the D7 Fields are not filled. {LATEST VERSION CCK IS PATCH ENABLED]
20) Next to this I had to use this SQL query to be able to use Taxonomy Fields to the fullest:
http://drupal.org/node/1986696#comment-7376658
With this I could add Term reference fields to my contenttype in Drupal 7 which shows the attached terms again. THIS DIDN"T WORK ANYMORE
Cycle 5 bring Ctools/Panels to D7
21) Now Ctools needs to be enabled again on D7, because lots of modules depend on this like panels
22) Get latest Ctools before you start this
23) Enable ctools and update.php
24) Enable panels https://www.drupal.org/node/1034822
25) If you got the pipeline error you have to save every panel manually or add something like https://www.drupal.org/node/980438 for Undefined index: pipeline in panels_panel_context_render()
Without this error you still need to go through every panel-page and resave them. This is due to a difficulty with panels: http://drupal.org/node/1627698#comment-7373706 Watch out for views or any other errors within the panel-panes.
Cycle 6 bring Views aboard in D7
26) There is not a automated guide to get views upgraded to Drupal 7. First you need to install every available module which you use in views otherwise the Views Handlers will not be available.
27) I needed to install views_php to get custom fields aboard.
28) There is also a problem with the "body" and the "taxonomy/term all terms" field. These fields are changed from Drupal 6 to Drupal 7. I had to manually alter those fields on every view and display. I couldn't see another way. See also https://www.drupal.org/node/1212326
After exporting the view from D6 and importing the view in D7 and changing the Handlers, Displays the views have to be checked and saved again.
Cycle 7, Metatag aboard D7 ,,,ehhh..
29) Metatag. This is still a process not completed. See issue: http://drupal.org/node/1281138#comment-7371092. Also to get then Metatag tokens like I use url-argument tokens is not yet complete.
Cycle 8 Weblinks nodes. Because my sites are full of thousands of weblinks nodes...
30) Weblinks. I make a lot of use of weblinks. Finally thanks to the great help of Gerhard Stegemann: http://drupal.org/node/870846 Weblinks can be used in D7!
31) Not yet there...will fill in when I find something important.
I am trying this module to bring content in D7, but until now unsuccesfull
http://drupal.org/project/data_export_import
Cycle 8 the rest
Between these updates I got lots of errors. Which sometimes have to do with different architecture or order of module enabling. This is so site dependend that it is out of scope of this migration guide.

to be continued..please comment if you like..

Comments

I have found it easier to

nevets commented 1 April 2015 at 19:39

I have found it easier to rebuild the site in Drupal 7 and migrate content and users.

Hi,

summit commented 1 April 2015 at 21:19

Hi,
How do you migrate content and users. Users is not that big a problem. There are only 5 users.
Bit how to migrate weblinks, metatags, terms, views and panels?
greetings, Martijn

Migrate

yelvington commented 2 April 2015 at 00:04

https://www.drupal.org/project/migrate
https://www.drupal.org/project/migrate_d2d

Not the best documented toolkit but once you figure it out, it's pretty amazing.

Your Views and Panels are going to need to be rebuilt, but that should not be difficult.

I thought this over more: I

summit commented 2 April 2015 at 11:33

I thought this over more: I have difficult contenttypes, difficult taxonomy with hierarchical select settings, quite complex views and panels.
Is there a way to also export and import the contenttype settings, the views and panels with gmap settings without having to do this all over agina in the new D7 site?

Will this work with views and panels:
- First get them to D7 on a testsite by upgrading and
- Then export them to the New (Migrate D2D) site?

Do you really mean I start with a fresh D7 install and build up?

greetings, Martijn

_

WorldFallz commented 2 April 2015 at 15:30

Do you really mean I start with a fresh D7 install and build up?

In reality--yes, you'll be better off. It's also likely to be faster and easier though it may not seem like it. I'm in the process of doing this myself for a very complex site that's more of an app than a site. It also allows you take take advantages of thing available in d7 that weren't in d6.

Hi,

summit commented 2 April 2015 at 16:00

Hi,
I am still concerned about contenttypes, views and panels, rules and that sort of things.
I do not want to make those all new? I have 40+ views, 20+ panels, lots of contenttypes!
any solution for this?
greetings, Martijn

_

WorldFallz commented 2 April 2015 at 16:15

I doubt it. one of the biggest changes from d6 to d7 was cck -> fields in core. Your exported views, panels, and content types all likely use cck fields so while you can theoretically upgrade your content types and fields to d7 (though even that is fraught with issues and compatibility problems), your views and panels won't come along for the ride.

I totally sympathize-- I'm looking at upgrading dozens of content types, fields, and views. But in all honesty, I think it will be much faster to just recreate them then fight through the baggage of migration.

Hi,

summit commented 2 April 2015 at 18:16

Hi,
So first get the CCK-values into Fields?
There is a CCK Migrate module. Is that then step 1 after a clean D7 install (https://www.drupal.org/project/cck)?
Which D6 database tables should then temporarily be imported into the clean D7? To use CCK Migrate?
And could after that not a views and panels export - import be done.With for views the following alterations?

I export view from d6, before import into d7 replace (see: https://www.drupal.org/node/1212326#comment-6846466):
  node_data_xxxx will be: field_data_xxxx
  xxxx_text_value will be: xxxx_text
  image_fid will be image
  link_url will be link

table for body field:
  [node_revisions] -> [field_data_body]

Wouldn't this be than the best scenario for now?
greetings, Martijn

_

WorldFallz commented 2 April 2015 at 21:38

I don't know what else to tell you... but no, this wouldn't be 'best' and I wouldn't recommend this route.

You're looking for a shortcut-- there isn't one imo. The forums are littered with upgrade horror stories. Unless you're using core drupal with core cck fields I doubt even upgrading just the fields will work as desired. Plus, who knows what other baggage and bloat will come along for the ride.

In all seriousness, you can probably recreate it faster than preparing for an upgrade, running the upgrade, and remediating all the resulting issues. And that's IF you find the issues right away. What if you don't find issues until weeks or months later when you're trying to use a contributed module that won't work with an upgraded field for some reason.

But who knows-- create a test site and try it.

Hi @WorldFallz...so you are

summit commented 2 April 2015 at 21:56

Hi @WorldFallz...so you are suggesting to start D7 clean and then recreate the contenttypes , fields etc as they are on D6 and then using migrate to fill those fields from the cck-values? Or how do those fields get their values then?
greetings,
Martijn

I'm having trouble importing

Vic96 commented 29 March 2016 at 18:45

I'm having trouble importing files, mainly the images and thumbnails used within the 'articles'. Can you give me some advice on importing them? The import seems to fail. Thanks.

Ditto. Importing CCK fields

mattwmc commented 10 September 2016 at 02:39

Ditto. Importing CCK fields into D7 sucks big time.

It's a fn joke.

Now I'm considering using Word Press.

Hi,

summit commented 4 April 2015 at 17:34

reading all sorts of scenarios...

https://www.drupal.org/node

jaypan

Victoria, BC

commented 2 April 2015 at 21:01

https://www.drupal.org/node/643758

You can move the thread by editing the original post and choosing 'Upgrading Drupal' as the forum.

Thank you.

Contact me to contract me for D7 -> D10 migrations.

Hi @Jaypan, I didn;t know

summit commented 4 April 2015 at 16:07

Hi,
I think this is a good way for views exporting, importing through ctools bulk exporting..
http://www.webwash.net/tutorials/how-export-views-using-bulk-export-and-...
But can it also be used to migrate from D6 to D7?
greetings, Martijn

Information is zo fragmented.

summit commented 4 April 2015 at 16:19

Information is zo fragmented...here is stuff about using feeds for import, export.
http://adellefrank.com/blog/how-to-migrate-content-from-drupal6-to-drupa...

But still no way to copy contenttypes, views and panels etc..easily..
greetings, Martijn

Hi,

summit commented 4 April 2015 at 23:17

Hi,
So I understand now that first I have to mirror the structure in my fresh d7 site of my D6 site, and than use Migrate.
- What comes first? I think taxonomy vocabulary and terms right? What is the best way to mirror my D6 site in this perspective?
- What comes second? I think CCK Fields? Whats the best way to mirror those?
- What comes third? I tkink the nodetypes, right?

I see this: http://drupal.stackexchange.com/questions/76534/preserve-term-associatio..., but than it seems the terms should be their already...grr...how to get the vocabulary and terms migrated..?
Looking forward to response.

EDIT; Connecting the databases seems to come first..http://drupal.stackexchange.com/questions/56385/how-to-set-the-source-co...
Without the ";":)

// Here we add in the connection to our Drupal 6 database.
  'legacy' =>
  array (
    'default' =>
    array (
      'database' => 'db_drupal6',
      'username' => 'drupal6_user',
      'password' => '',
      'host' => 'localhost',
      'port' => '',
      'driver' => 'mysql',
      'prefix' => '',
    ),
  ),
);

STEP 1: Migrating VOCABULARIES EN TERMS
here some old migrate user modules: http://cgit.drupalcode.org/sandbox-frjo-1332996/tree/
and code with explanation, but I can't read it completely as I am not a professional programmer..
http://btmash.com/article/2012-02-16/migrate-more-less-or-how-i-learned-...
does the peace after

class MigrationTaxonomyTermMigration extends DynamicMigration {
 ...
}

Must come within the ... ?

Greetings, Martijn

I agree it's a nightmare

HJulien commented 4 April 2015 at 18:26

Migrating a platform with 70+ content types, 500+ fields, hundreds of complex views, 300+ views, 150+ rules and the best advice is to build it from scratch?

There aren't enough swear words for me to express my anger at the core Drupal team for not thinking about the problem they've created for all us Drupal users.

Hélène

Hi,

summit commented 5 April 2015 at 19:51

Hi,
STEP ONE CONTENTTYPES, FIELDS, VIEWS in (MANUALLY!!)
I have my fields and views now in clean D7 site...took me f..&^% all day to get there....I hope Drupal is not moving the Joomla way with this...
And one view will not work because of Hierarchical Select Views is not in D7 yet.

Order:
1) Add fields in
2) Add Vocabulary in
2) Add contenttypes in
3) Add views in because they relate to fields, vocabulary and contenttypes.
EDIT:
4) I forgot menu's. I use menu's in panels...I will use this..https://www.drupal.org/project/menu_import
Of course this is not easy....I need first to define all menu's again in the new clean site..The import is not with the menu itself..
Argghh....I have menu's with terms in it..so I now need to import vocabulary and terms first....

STEP TWO will be to get PANELS in...this will also be a Manually step.
After that Content Migration...still looking for working submodules for vocabulary/term with node id respectation and Node migration of custom nodetypes.
And of course Metatags..but I saw someone did this.

greetings for now, Martijn

Hi,

summit commented 5 April 2015 at 23:44

Hi,
So the first real challenge is to get terms in..
Anyone have a working Migrate D-D submodule for terms migration from Drupal 6 to Drupal 7?
Thanks in advance,
greetings, Martijn

Ok got some working..but also lots of errors. What do those errors mean by migrating my terms and nodes on http://www.campingcontent.nl/admin/content/migrate/new/migrated2dwizard

SQLSTATE[HY000]: General error: 1366 Incorrect integer value: 'field_bijzonderheden' for column 'delta' at row 1: INSERT INTO {field_data_field_bijzonderheden} (entity_type, entity_id, revision_id, bundle, delta, language, field_bijzonderheden_tid) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6); Array ( [:db_insert_placeholder_0] => node [:db_insert_placeholder_1] => 1 [:db_insert_placeholder_2] => 1 [:db_insert_placeholder_3] => over_introductie [:db_insert_placeholder_4] => field_bijzonderheden [:db_insert_placeholder_5] => und [:db_insert_placeholder_6] => ) (/modules/field/modules/field_sql_storage/field_sql_storage.module:494)
SQLSTATE[HY000]: General error: 1366 Incorrect integer value: 'field_regio' for column 'delta' at row 1: INSERT INTO {field_data_field_regio} (entity_type, entity_id, revision_id, bundle, delta, language, field_regio_tid) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6); Array ( [:db_insert_placeholder_0] => node [:db_insert_placeholder_1] => 12 [:db_insert_placeholder_2] => 12 [:db_insert_placeholder_3] => regionale_introductie [:db_insert_placeholder_4] => field_regio [:db_insert_placeholder_5] => und [:db_insert_placeholder_6] => ) (/modules/field/modules/field_sql_storage/field_sql_storage.module:494)
---
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'tid' cannot be null: INSERT INTO {taxonomy_index} (nid, tid, sticky, created) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3); Array ( [:db_insert_placeholder_0] => 87 [:db_insert_placeholder_1] => [:db_insert_placeholder_2] => 0 [:db_insert_placeholder_3] => 1341320923 ) (/modules/taxonomy/taxonomy.module:1981)
---

Hi Somebody answers something like this on first error...It seems you added the field XX to your content type challenge after you created some content for this type.
The previously created content do not have any value for this field, causing this error. You may define a default value for this field, such as 0 to get rid of this error.
But it is a migration, so the delta value should be correct, right?
Looking forward to response..what a struggle this is..
Greetings, Martijn

I hope there are also enough

cilefen commented 6 April 2015 at 18:56

@HJulien I hope there are also enough words of praise for creating and maintaining Drupal in the first place!

As with many open-source software projects ,Drupal contributors are mostly volunteers who work to improve Drupal on their own time and without pay. Those unsatisfied with the result could donate money to the Drupal Association (https://assoc.drupal.org The Association is currently awarding grants to accelerate improvements.) or, volunteer themselves to help improve Drupal. There are many opportunities for volunteering. The core mentoring hours are a good place to start https://www.drupal.org/core-office-hours.

Indeed - the core team is

pwolanin commented 6 April 2015 at 19:07

Indeed - the core team is everyone who stepped forward to volunteer.

Note that the pain of trying to support major version updates is why Drupal 8.0.x will only support content migrating.

Also note that CCK came into core for 7.x, Views came into core for 8.0.x, because of their popularity and importance to site building, but they were contributed projets prior to that without any direct input from Dries or core committers.

---
Work: BioRAFT

Hi,

summit commented 6 April 2015 at 21:53

Hi,
I understand, but for the sake of future it is so necessary to take drupalsite owners of D6 and D7 very serious. You know what happened to the very much used Joomla system after a major update without good migration support for earlier versions...where is Joomla nowadays?

Back to content...I am in the process to migrate my drupal 6, and with this post I want to support the not so professionals programmers like myself to support the migrate.

Ok I want to migrate my D6 weblinks with taxonomy reference as clean term reference and other Content Taxonomy Fields references. Using Migrate drupal to drupal I only get the terms AND weblinks, but NOT the most important thing! The taxonomy term LINKS in the Weblinks.
I have 500 weblinks with lots of regional and category references...but they are not coming true...
I found this old post..but no working migrate script yet: https://www.drupal.org/node/2019719 Anyone?
greetings, Martijn

Hi, the story continues. I

summit commented 8 April 2015 at 11:09

Hi, the story continues. I succeeded in getting term/references in!
I had to select the term-migrations in the node migration. I will make screenshorts somewhere next week.
But the migrate story is not over. I used the Weblinks module a lot. I need to Migrate 500+ Weblinks Nodes...but Weblinks is not compatible with Migrate....I updated an issue about this: https://www.drupal.org/node/2210683
And made a post about it within Migrate: https://www.drupal.org/node/2467371

But I think scenario will certainly be; start with clean D7 site, bring in panels, views etc.. as in D6.
This is shamelessly a mostly manualtask. Then use Migrate to get terms, nodes and references in.
Now hopefully soon a Weblinks solution. Please respond if you did Migrate Weblinks nodes or have a working scenario to get them may be converted to Link (while link-field is the default in D8).
Greetings, Martijn

No coding required ... ...?

DocMartin commented 15 April 2015 at 08:15

At times, I wonder about migrating from Drupal 6 site - partly for mobile friendliness google so desires.

I've taken site or two from mambo to joomla, to Drupal 5 and Drupal 6 [also shifting a forum from one software to another at least once], but now looks amazingly daunting to go anywhere from Drupal 6 [even to Wordpress].

So yes, great there are volunteers working away.
But also seen there seems a shift away from Drupal's original starting point, to enterprises and high falutin language.

Note that this is still in understanding Drupal info: "Drupal is a content management system which allows you to create and maintain many different types of websites without needing to know any coding languages."
- yet look at this thread, when it comes to moving on from Drupal 6, or being left marooned. Seems a whole lot scarier than D5 to D6, say.
Focus on enterprises all very well, but perhaps disingeneous to imply you can readily build [and maintain] a site without knowing code.

I had naively anticipated a shift towards being more user friendly, but instead see guff about object oriented, entities and so forth. To me, coderspeak should be less prominent. But, not the way things have gone.
So, I'll check this and other threads, and wonder about what to do; keep fingers crossed there may be some sudden breakthrough in plans for enabling relatively simple migration to Drupal 8.

____________________________
DocMartin and Hong Kong Outdoors

_

WorldFallz commented 15 April 2015 at 13:18

But also seen there seems a shift away from Drupal's original starting point, to enterprises and high falutin language.

No question. And from what I've read this was a purposeful move based on the needs of the larger drupal businesses and venture capitalized firms. The part-timer/hobbiest is being left behind.

Thus the birth of backdrop.

Which will be more successful, or even equally successful, remains to be seen. imo the more successful one will be the one that attracts and keeps a large and vibrant community of contrib maintainers--- the thing that enables so much to be accomplished with drupal without writing a single line of code.

I have to say, I'm pretty impressed with the amount of work going on with backdrop contrib so far-- it's much further along than I expected.

let the race begin!

Hi, I am now in the mindset

summit commented 15 April 2015 at 21:18

Hi, I am now in the mindset that migration now is better than upgrading. Also almost their with my own migration from drupal 6 to drupal 7.
Yes you have to build the site completely up with a lot of manual work. That can still be better automated. The modules themself are responsible for their migration strategy is reported by the migrate project team.
Let's see where it brings me. It is very time consuming, but on the other hand you can migrate at any time, while with upgrading you can't hold the strategy of building the site up on another domain, because then those sites are inconsistent and every content renewal has to be done on both sites until the new site really can go live!!!

The shift you are noticing (

bojanz commented 16 April 2015 at 21:07

The shift you are noticing ("enterprise", whatever that means; entities; OOP) started happening in 2008, and was official with the release of D7.
We need to stop pretending to be shocked about it.

for enterprises not small sites

DocMartin commented 17 April 2015 at 01:43

Not so much re being shocked about move to enterprises, but it's also time to end the hubris re being able to "Use Drupal to build everything from personal blogs to enterprise applications." [a claim on front page!] without any need for coding.

And perhaps note that many people have surely taken to Drupal, only to be abandoned w the shift to enterprises. I think this is what's shocking.

I hope the fork to Backdrop can indeed prove successful.

____________________________
DocMartin and Hong Kong Outdoors

_

WorldFallz commented 17 April 2015 at 13:41

doc captured it better than I did. It's not that trying to meet the needs of the enterprise is shocking/disturbing/whatever. It's the purposeful leaving behind of everyone else-- precisely those who helped make drupal what it is and what caught the attention of big enterprises and venture capital firms in the first place, that is causing the rift. Sort of like 'thanks for all your hard work, we can take it from here, don't let the door hit you on the way out'.

Let's also not pretend that drupal would have become what it is today without the massive participation of the varied and vibrant contrib community. There's plenty of awesome frameworks (some would say technically superior to drupal) out there with awesome professional developer communities-- that go no where because they're inaccessible to the average coder and therefore don't have the massive contrib ecosystem we do.

And lest anyone think I'm biased, I work for an enterprise that will likely be very happy to move to drupal 8 and keep me gainfully employed for some time to come. Its just that I came to that through the hobbiest/part time route that is being decimated that causes me to be sad.

But how is D8 leaving you

bojanz commented 21 April 2015 at 13:42

But how is D8 leaving you behind? I've yet to hear a single concrete argument for this.

For a site builder D8 is 10 times more powerful, you can build a site with just core for the first time in history.
And all of the contrib that's been added to core (views, entityreference, ckeditor, etc) is more stable than it ever was in D7 contrib (added tests, many refactorings, etc).

Yes, if you're writing code you need to learn the way PHP has been written for the past 6 years, but that had to happen at some point.
Saying "No D7 coder can learn modern development practices" feels almost patronising, especially taking into account how tricky D7 can actually be.
(Note that I'm not putting words in your mouth, it's just a general sentiment I've heard elsewhere)

_

WorldFallz commented 21 April 2015 at 14:21

I'm definitely NOT saying 'no d7 coder can learn modern development practices' (and no worries-- I didn't take it that you put words in my mouth).

I'm not even talking about d7 coders really. I'm talking about potential coders that might be out there that may never even try to become drupal coders now.

Like it or not OOP can be severely daunting for people when they first dip a toe in the coding water. It was for me-- i have no problem admitting it. It took me quite a while (training, books, articles, videos, etc) to get over the hump. Once the light bulb went off I finally realized what all the hubbub was about. I still take issue with anyone positing that OOP is always better in every circumstance but OOP used properly is awesome.

My point is, if I had to learn OOP and dependency injection and composer and etc etc just to create my first module I'm not sure I would have bothered. Procedural coding, even drupal's idiosyncratic hook version of it, is more accessible to beginners. Being able to create a module that actually does something you need it to do with a few lines of procedural code that you can follow line by line using a simple text editor is unbelievably empowering and confidence building.

Banging your head against a wall because you can't figure out how to properly override an object, method, or property or being told to obtain and learn a full fledged IDE or having to take courses in OOP just to make a seemingly small change is exceedingly off-putting. How many 'hobbiests' (aka potential future drupal developers) will bother?

Does that mean that same person can't learn 'modern development practices'? Of course not. But neither they or we will ever know if they find the entrance barrier too high and move on to something else.

Many people come to drupal by simply using it to create something they need that couldn't be done with any other CMS with minimal or no code and then TURN INTO drupalists when their needs become more complex. These folks already complain about the learning curve. And now it's been bumped even higher.

Clearly there is a sizable number of users taking issue with the current architectural direction, or backdrop wouldn't exist.

Ok, that is a fair point, and

bojanz commented 21 April 2015 at 15:14

Ok, that is a fair point, and one definitely worth discussing.

You need to keep in mind that for most new PHP developers, Composer will actually be one of the first things they learn.
Aside from Wordpress, there is no project that hasn't adopted it fully, it's the Drush of PHP.

Outside of Drupal, the framework of choice for hobbyists seems to be Laravel. While Laravel is object oriented, it is also perceived as easy to use and discover.
I think this is caused by two things: 1) sensible defaults, minimizing the amount of needed boilerplate 2) great documentation and learning resources (especially Laracasts).

Yes, getting started with a D7 module is fairly easy. However, once that initial success is achieved, it becomes fairly easy to get stuck (I think Summit here has spent years in the issue queues and forums asking for help on problem after problem). "Easy to use and discover" was never something we completely managed (or at all, depending on who you ask).

So, what I'm saying is that I don't believe that being object oriented needs to imply "hard for hobbyists". There are plenty of things we can and should do to make D8 coding approachable, while still following the zeitgeist of the PHP community. I have big respect for the Backdrop team, but "let's pretend it's 2008" is not a viable long-term strategy.

Hi Bojanz,

summit commented 21 April 2015 at 14:50

Hi Bojanz,

I think that Drupal 8 is way improved above Drupal 7.But for me as an end-user and ICT-architect and not programmer...it is beyond my skills.

Drupal D7 is well evaluated and is working ok as core, but more important; lots of custom modules are migrated to Drupal7. Like Location, Metatag, Weblinks and Panels in my situation. The module maintainers are having a hard time following up D6 and D7 issues, and most of them are just not there related to D8!

Next to that themes are not so wide spread for Drupal 8, and on D7 they are there more.

The problem with Drupal 8 for me as individual user is that I am dependent on the work of others and they are most of the time busy with D7, which I completely understand. I am having a hard time to migrate my sites to D7, and some modules are not having Migration strategies (yet) to comply with this.

So do you understand that D8 for me is a seven mile step now? I am starting to become happy that may be the coming weeks I am able to use Migrate to move my content from D6 to D7. There are not yet automated modules to Migrate views and panels and I understand this, because the architecture of Contenttypes etc..are changed for D7.

I would not know where to begin using D8 and have to wait for lots of module-maintainers to make the step to D8.

My personal opinion is that Drupal is moving away from the larger amount of Drupal users with Drupal 8. The module maintainers are still very busy with D7 and lots of module maintainers are not coping with the D8 architecture. D7 is really a way forward, but may be D8 too much.

May be when D8 core team is going to assist module maintainers of modules which are heavy used...this can move the whole community forward!
So a little break on moving core only to D8 and getting more modules up to spead.

Next to this using Migrate to get content from D6 to D7 is I think, always good, while this is the main strategy to go from D7 to D8 also.
So getting my site now to D7 using Migrate hopefully makes it easier to get (in a year or so) my site from D7 to D8 using the same Migrate!

Greetings, Martijn

Adopting D8 today would be

bojanz commented 21 April 2015 at 15:18

Adopting D8 today would be the same as adopting D7 in late 2010. I'm guessing you probably waited for a while for modules and tutorials to catch up.

Keep in mind that Drupal modules are ported and maintained when client work requires it. Since there's very little client work happening around D8 at the moment, the amount of modules is minimal. This is the same reason why nobody has maintained Drupal 6 modules for the past few years. All of this is a natural cycle that happened for D7 and D6 before that, I don't see anything unique to D8 about it.

Hi Bojonz, I do not see

summit commented 21 April 2015 at 15:40

Hi Bojonz, I do not see anything unique about this also, but the fact is that I am dependent on the module maintainers to move...so when they stay with D7 and having a hard time to catch up...I stay on D7...and on D7 thank god! I have now the most of functionality needed for my D6 sites after more than a couple of years indeed.
Now getting through the Migrate nightmare...and then I am ok for the coming year I think...and then may be the story recycles...

So how can we stop this story from recycling? I think with every cycle...drupal community will look further for other solutions...like backdrop stuff I hear about..
Remember the Joomla problems coming from version 1,2 to 3...Where are the Joomla users now?

I am absolutely in favor of Drupal, but I am dependent and sometimes frustrated about directions away from the small users and to the big companies. I do not know the future, but I am having a hell of a time to get my D6 site to migrate to D7 with most modules fit for D7, I really would not know how long it would take to get to D8 keeping the functionality.
May be I set a counter from this day forward...21 april..the day that Google announced that Mobile sites will be favored ...

greetings, Martijn

Migrating has to get easier, there is no work around

Faichi commented 5 October 2015 at 13:25

Hi Martijn,

I completely agree with you that migration process of a Drupal site from, for instance from D6 to D7, has not been a smooth ride; not a night mare as well though.

But the matter of the fact is that as and when the newer version will be released, the older versions, slowly are going to fade away as the security updates would stop, the modules would go unsupported, no new development would take place but then that is the normal life cycle for the technology and hence there is no work around to it.

We had been facing the same issues and especially because there have been a significant number of sites that had to be migrated from D6 to D7. We finally sat and decided to create an automation script for the migration process to try and automate most of the repetitive tasks and steps that need to be carried out to take the site from D6 to D7.
I would be more than happy to the details with you and see if the script I built can help you in any way.

how is Drupal leaving many users behind?!

DocMartin commented 27 April 2015 at 02:51

"how is D8 leaving you behind?"

- the sheer difficulty of upgrades, even from Drupal 6 to Drupal 7, let alone the leap to Drupal 8.
The shift to enterprise focus, leaving behind folk who don't write code and don't want to [notice the Drupal info claiming there's no need to be a coder, and Drupal is fine for blogs et]

Notice, too, I have moved from mambo to joomla, and to Drupal 5 and then to Drupal 6.
Doing so, believed using Drupal would be made easier, that the non-coding user base would be properly considered and deftly handled.

Seems there's plenty of info around about such leaving behind.
But expert coders can't seem to understand this; or just couldn't care less. [A few might; but Dries nowadays, say?]

____________________________
DocMartin and Hong Kong Outdoors

I think it's a bit of a

jaypan

Victoria, BC

commented 27 April 2015 at 03:35

I think it's a bit of a disservice to try to market Drupal as not needing any coding whatsoever. All Drupal sites need some coding, and most need a fair bit.

Contact me to contract me for D7 -> D10 migrations.

Yes, I've been saying for

bojanz commented 27 April 2015 at 08:48

Yes, I've been saying for years that Drupal can be very painful to non-coders. But that hasn't changed since D6, so I dislike the attempt to paint D8 as the bringer of doom.

In general, I must say that coding for non-coders is very hard. Each use case has a 100 edge cases. A module can provide a good API and a way to handle those edge cases via short code snippets, but for non-coders the only thing you can do is add endless checkboxes and additional code until the module is declared to be too complex or buggy. This happens over and over in Drupal land.

The next chapter of the

summit commented 28 April 2015 at 08:31

The next chapter of the nightmare begins, to get on topic again..
I got now my content in thanks to the great help of the Weblinks module maintainers Gerhard and Jonathan!
Now it is time to bring my views and panels in! And that is a chapter on itself.
I got all views and panels in by manual exporting and importing them, and than altering the body and some other handlers, because their architecture has changed between D6 and D7/8.
Wandering why, because views is in core now, there is no migration possibility which does this automatically.
but they work...at least for the data.

I use Gmap and Location to fill in lat/Lon in D6 site and show the Google maps through Gmap views. back then I had hard time to bring the markers, markerclustering manager and info bubbles in....and this story continues.

I got markerclustering manager working by copying my D6 marker clustering manager JavaScript to the third party folder within the gmap folder in D7...but no info Bubbles showing on the Gmap views. On the standard map/node Google map it is showing..but then when I click on it, it only says 'loading' ...I made issues for these two things within the Gmap module project; https://www.drupal.org/node/2478309 and https://www.drupal.org/node/2478267

Sometimes I think why all that hard work on D8 when regular used modules on D7 are still buggy and not working out of the box as they nowadays do on D6?
Sometimes I think that drupal doesn't see what a major problem can arise when the majority of D6 users and D7 users move to solutions like Wordpress?

Off course for big companies it is great if the drupal framework will give them more efficiency and better software using the D8 improvements...,but what about the core, the heart, the soul of drupal and its nowadays large users how can't pay in time or money for this shift and became drupal users because of the friendly atmosphere, helping each other and learning from each other experiences with all sort of custom modules...

So my on topic question is what Google Maps solution WITH migrate_d2d destination handler is the one to move to which also will be there in D8? And if there is no destination handler yet, will somebody help to bring this in for the community to not having the same nightmare I am having with this.

My soul question is how can we bring the powers at hand to get out of the nightmare and into the wet dream of drupal again?
Greetings, Martijn

No responses on this? What is

summit commented 4 May 2015 at 23:54

No responses on this? What is the best mapping solution to have multiple markers on a map, and a nice info bubble with name, image and url through views, besides Gmap/Location combination?
The good part about Migrating instead of Upgrading is that you can query the content with views using other more standard modules in D7, but what are the more standards now for mapping?
greetings, Martijn

It's not likely most people

jaypan

Victoria, BC

commented 5 May 2015 at 01:55

It's not likely most people are still reading this deep in the thread, as it has essentially become a blog about your migration experience.

You're probably best off starting a new thread asking how to achieve that functionality in D7.

Contact me to contract me for D7 -> D10 migrations.

Hi,

summit commented 5 May 2015 at 10:28

Hi,
I think you are correct, I made a new issue for the mapping..https://www.drupal.org/node/2483139
Thanks for your remark!
Greetings, Martijn

After waiting and wondering,

DocMartin commented 5 May 2016 at 02:14

After waiting and wondering, looking at perhaps shift to Wordpress [harder for multisite it seems], and seeing Backdrop could be an "escape" from Drupal after D7, finally made shift to Drupal 7.

Overall, not as terrible as I'd anticipated.
Heck, I was even trying to steel myself for entire sites just not working...

No programming, no Drush etc etc; just via things like Update php, adding back modules that had been ported to D7.

Basic content worked fine.
Various issues though; pathauto a bit startling but there's advice on tokens to use.
I'd used Views Gallery: as I expected, proved about dead since this is Abandonware. But figured files still present, and Drupal kind of knows about them; and found Juicebox could display them even though Drupal "system" not recognising as images.
Took quite some time

Bootstrap proving excellent for responsiveness - something I'd found hard in D6

Still laughable Drupal can boast of aiming to be friendly or somesuch for folks who are content creators not coders.

____________________________
DocMartin and Hong Kong Outdoors

I'm involved in a D6 to D7

andy inman commented 2 October 2015 at 08:12

I'm involved in a D6 to D7 conversion now. It went like this:

* Back in 2014, site updated via Drupal's own update process. Mostly worked.
* Other stuff (CCK etc) brought in via Migrate. Mostly worked.
* Now it gets interesting :) ... the project was postponed by the client for various reasons, and delayed the best part of a year. In that time the D6 site changed - new content, users, forum posts. New content and other changes had also been added to the D7 site. The solution - I wrote lots of custom code, including direct communication between the D7 and D6 sites to resynchronize the two. A spin off from the inter-site communication part, I created my CodeServer module. We're now in the happy position of being able to parallel run the two sites, so have a beta phase for the D7 site without taking the D6 site down yet. We can resynchronize content (and comments, users, path aliases, etc) at any time. I don't *think* the same would be possible with Migrate alone, but maybe I'm wrong about that.

That is indeed an interesting solution

Faichi commented 5 October 2015 at 13:16

I completely agree that it is not possible to achieve the resynchronization of the content among the two sites i.e. the D6 and D7 one. I will be exploring your module to know more about it.
Also, there have been so many issues and repetitive tasks involved around taking a site from D6 to D7 that we finally decide to create an automation script that would automate most of the repetitive steps involved in migrating a site from D6 to D7. This helped in saving a significant time and effort.
The migration process now does not seem that time taking.
PS: We also ensure that the existing site is untouched and available for the users while we carry out the migration process.

Hi,

summit commented 5 October 2015 at 14:14

Hi,

As not being a programmer, migrating from D6 to D7 is still very difficult.
Finally for my constellation I have almost everything through migrate migrated.
A couple of things missing
- custom metatags are not able to migrate...they are in D7 context based..how to import multiple context?
- google maps is not working well. But Leaflet is good alternative
- other small things...
Still in the process..
greetings, Martijn

Hi,

summit commented 22 October 2015 at 18:04

Hi,
Finally migrated my site www.hotels-onderweg.nl to Drupal 7! Better responsive theme, more functionality and flexibility.
Happy that it is accomplished. Thanks for the great Drupal community who helped me a lot with this; especially Rik and Gerhard.
Thanks, and please have a look at www.hotels-onderweg.nl. Very much based on views and panels Drupal 7 site now!
Greetings, Martijn

Did you find CodeServer useful

andy inman commented 5 May 2016 at 13:23

@Faichi Did you find CodeServer useful in the end? Just curious!

Migrate drupal 6 to drupal 7 site; a nightmare!

Comments

New forum topics