I'm working on converting my old site to my first Drupal (6.3) site. What I had in the old one and need in the new is a way to search a separate database and display the results in various forms.
I have a list of table of contents from various volumes of magazines which can be queried through a webpage and the result shows information on the item as well as a picture of the cover of the respective magazine.
I'd like to have this functionality in the new site as well.
I could create a specific content type, but it's a pain to fill them by hand (I have more than 25 years of magazines). So I'm thinking of creating a separate table in MySQL and do a batch import using phpMyAdmin, but how do I connect to that table through Drupal? Is there a module available that let's me do that or do I need to write my own?
Does Drupal have an easy way of converting a page or query result into something else, e.g. a CSV file?
Thanks.
Comments
Have you tried the Import /
Have you tried the Import / Export Api module? If I remember correctly you can import nodes from a CSV file. So if you create the required content type and define the fields needed, you can then import the records you already have.
Thanks for the info. It
Thanks for the info. It sounds like a good idea. Unfortunately, the module is for Drupal 5.x and I'm on Drupal 6.3 and it seems the module is no longer supported.
Maybe you have other ideas?
I didn't notice your
I didn't notice your question being for D6 - my apologies.
But you COULD use D5 instead of D6 :) After all, the choice of contributed modules is much wider now for D5.
Well..... when I started I
Well..... when I started I got the impression that D5 was end-of-life and D6 was the way to go. I also read a lot of 'and this is much improved in D6' messages. So I decided that I could best start with D6. I figure I'm halfway through now, so I don't think switching to D5 is an option now. I did come across some modules that I'd like to use, but aren't available for D6, so I'm tempted.
OTOH the project you mentioned is dead and I have no idea in which state it is. So, as much as I'm thinking of switching, I think that's a showstopper.
But if I understand your suggestion correctly, I would create a special content type and use this module to do a batch upload. I have some questions then:
- as said I have 25 years of magazines, that amounts to thousands of items. How will Drupal perform with such an amount of tiny nodes, both overall and in searching these nodes specifically?
- the information on an item is best captured in special fields, rather than a general body of text. So I guess CCK fields would do the work, but how can I create a template for displaying such an item in a sensible way (not just a vertical list of fields)? Is there something like a 'page'-dependent way of 'theming'? E.g. a standard page would follow the general theme layout, but a page built from search results would look different.
Thanks.
No guarantees available I am
No guarantees available I am afraid - you have to experiment and try out each module. That aside I can give you the info I have for Drupal5.
Import: create the content type and a couple of fields just to be able to try the import if it works. If it does work experiment with a more complete implementation. Even if the project is not currently active all you want is to be able to use it once to do the import, right?
For the import you should check out this as well:
http://drupal.org/project/node_import - I believe this is the module to do the work for you
Performance: Drupal is scalable.(check out this on-line book currently in its infancy: http://tag1consulting.com/Online_Performance_and_Scalability_Book) But if you have a dedicated server I believe there will be no problem with performance.
CCK Presentation: try the content templates module
Hmm, this node import sounds
Hmm, this node import sounds like an interesting option. I'm going to try that. I need to do the bulk import once, but it would be great if I could use the same import for the new magazines. Creating each ToC-item by hand is quite tedious.
As for the performance, I'm going to have a look into that as well.
Thanks.
just generic search?
http://drupal.org/project/apachesolr <-- maybe?
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
This sounds like a great
This sounds like a great option, especially since one of the Solr developers is a friend. :-)
However, I'm on a shared server environment and last time I tried to get my old (java-based) site working, I failed. Maybe I have more luck this time. I'm going to look into it.
Thanks.