A year from now my clients are going to port a relatively complex intranet portal service (scheduling, actual tracking and reporting, and more) to Drupal because the head office says so. Very little effort has been made to determine if this is the right technical choice and it is beyond the control of my client's or even their bosses.

The current portal is an abomination that is in the process of being re-factored and I believe the most cost effective plan will be to bring in a domain model layer via Doctrine 2 and put 99.9% of all business & input validation logic into the models, gutting out the abomination until it is a skeletal view & authentication logic layer.


For any Drupal specialist out there, does this seem like a viable approach? Could Doctrine2 play nice with Drupal or does Drupal higher level logic need a much tighter integration to the data?


We have done a few sites where we have connected outside systems to Drupal where the data had to be kept in the outside system. This is what I spend most of my time working with.

When we do this, we typically create a content type to "stub out" the content in the other system. The content type only contains the node title and a CCK field for the unique identifier in the other system. Along with this are a lot of hook_nodeapi functions. For example, the load hook will call out to the remote system and add the data to the node. You also need to devise a method for getting the outside data into search results. There are a few methods for this, but those are too lengthy to get into here.

While there are some downsides, we find this works well and allows normal Drupal stuff like comments, tags, etc.

| improve this answer | |
  • If it has to be external this is a good approach. – Jeremy French Jun 10 '11 at 16:32

The only sensible thing to do, given the time line, is to build this in Drupal 7. One of the most prominent features of Drupal 7, is entities, DBNTG and fields.

A quick overview

  • Entities is a way of defining a data structure. Examples of entities that is built in with Drupal is, nodes (main content), users, taxonomy terms.
  • Fields is something that can be attached to an entity, which also holds data. Using fields has the advantage of only having one place to handle the data and they can be extending in various ways. An example of a field could be a file attachment, or a reference to another entity.
  • DBTNG (Database the next generation) is what the Drupal community had codenamed the new database abstraction layer. Before this, we used to do queries with placeholders (which is still supported), but now most queries are built with class. A reason for this is also that fields get their database table(s) created based on settings. This helps creating code that will work, even if the field(s) are created with different settings.

This is just some of the features, but this means that unless you want to create a Drupal abomination, you should start thinking about how Drupal works and use that instead of trying to make Drupal work a way it wasn't designed for.

Since Drupal is PHP you could create custom modules and use Doctrine2 to do what you want. But my guess is that you will end up with a site that has very little in common with most Drupal sites.

| improve this answer | |
  • Unfortunately I leave my client in about a month so they're on their own after that. The Abomination is under pretty sizable load/usage with new "Features" being added as we speak. The whole situation is a mess that I have partially failed to steer in a better direction. In my own defense, it went live the week before I was hired on to help bail water. – David Jun 12 '11 at 5:30

This is quite a broad question so I'll give a high level answer, if you have more specific questions please ask them as separate questions.

I would suggest that you map out as much as possible the structure of the current site. What types of things does it do, what workflows are there. What is the content what are the users.

Content types are a handy way of dividing up content. Even the abomination would have had types I thing ( I would have hoped) that map to URLs.

Once you have determined the content types then you can look at migrating the content, to your new site. Then you can look at things like workflows, schedules, users, etc.

I would favor moving wholesale. Having content being managed by more than one system is a huge technical headache. And doubles your maintenance effort.

One thing I would say, is that it may be worth hiring someone in to do it. There have been some very successful Drupal migrations with huge data sets. But if you are not experienced in Drupal you may make several mis steps and cost yourself a lot of time. (I can personally recommend cyrve, I have no current affiliation with them)

| improve this answer | |
  • I will pass on Cyrve to my client; as it stands no one inside my client's department or an ajacent department that is pushing Drupal have any expertise with developing in Drupal, so it should be entertaining to see how this plays out a year from now. – David Jun 12 '11 at 5:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.