drupal way to display a directory of names/phone numbers/etc

By professor_b on 7 May 2015 at 12:34 UTC

Hello
I'n new to Drupal but handy with PHP, MySQL, jQuery etc.

I am migrating my organization's public site to Drupal. Among the hand-crafted MySQL/PHP stuff is a page that displays rows of data from a database, basically a list of names and contact info for a some people. The data is and will continue to be maintained elsewhere (outside of Drupal), in an independent application hosted internally. My users need not and should not update this via Drupal.

So I'm trying to decide on a strategy. There's a temptation to override the default template and just write PHP to fetch and display what I need from another db, perhaps sqlite, which db I would update periodically from the master data source via cron. But I want to learn the Drupal way of doing things, so I figured maybe I should

(1) create a custom content type for the people in this directory

(2) create a view

(3) update these people-nodes periodically via the Feeds module. I suppose that would involve exporting from MySQL to CSV and importing from CSV into Drupal's backend.

So I started playing with this approach and the first issue I encountered was Drupal's insistence that there be a 'title' field which really does not fit my use case. I got around this with the auto_nodetitle module.

The next issue I encountered was that when my site editors go to admin/content they will be presented with a whole slew of instances of a content type that they should not touch, so why even see them? It's just clutter. The answer I found was this:

http://stackoverflow.com/questions/6056382/alter-admin-content-hide-cont...

i.e., use the Views Bulk Operations and Admin Views modules.

The question: is this the correct approach, even though it seem to this noob rather a lot of hoop-jumping for something that ought to be straightforward? Or is there another drupalista method I should consider? I guess I want to be convinced I should trust the program, so to speak, before investing the time and effort. Thanks.

Comments

_

WorldFallz commented 7 May 2015 at 14:15

i do exactly this. My list of people comes directly from active directory and is not editable. I refresh the data nightly via feeds and do not allow editing for that content type.

The only thing I would recommend differently than what you describe is to avoid import via csv/spreadsheet if at all possible. I usually use https://www.drupal.org/project/wsclient whenever possible. There's also https://www.drupal.org/project/feeds_sql.

In the cases where I simply can't avoid file imports, I use https://www.drupal.org/project/feeds_xls which is much more user friendly than CSVs. Feeds is quite unforgiving of CSVs-- if they're not exactly right the import will fail, sometimes for the entire file an not just the problematic rows/cells. Since switching to feeds_xls I've had nearly flawless imports.

OK thanks for the feedback.

professor_b commented 7 May 2015 at 14:50

OK thanks for the feedback. Since our master database is behind a firewall, my public Drupal site will not be able to fetch anything from it. Somehow it has to be a two-step process where my internal site puts the data somewhere Drupal can consume it.

I already experimented with CSV for importing some Smarty templates into Basic Pages, where the body content had to be one pretty big field with all kinds of arbitrary html and punctuation and stuff to escape, and PHP's native fputcsv() along with the Feeds module did handle it. But I will keep your warnings in mind.

Maybe I'll be back for more advice in the near future (-: but for now the way forward is to learn more Drupal and start doing sexy things with Views and such.

Thanks again.

_

WorldFallz commented 7 May 2015 at 15:05

if your CSVs are system generated then you should be fine. I was referring to CSVs that had to be touched by human hands at some point. Any time a human has to modify a CSV you can almost be 100% sure there will be a problem with it some where (missing quotes, extra white space, wrong encoding, etc).