FAQ module

Thanks Alan. I tried the link and played around with the books module but it doesn't seem to be very user-friendly. Do you know any page using the book module for a FAQ? I'd be curious to know how people handle it.

No personal experience with this

alanburke commented 11 March 2006 at 12:47

Maybe somebody else can help you out...

_{Drupal development and themeing, Galway, Ireland}

Couild U tell me...

sangamreddi commented 11 March 2006 at 13:16

What are you looking for in a FAQ module? If you understand how book module works, you can create the faq pages with book module.

Sunny
www.gleez.com | www.sandeepone.com

What I am looking for in a FAQ module

zeitenflug commented 11 March 2006 at 14:09

I only need basic functionality. For me, this means it should be possible to

- click on the category and see all questions asked so far

- click on the question and see the answer

- see the top 5 questions (general and the category you are in)

The problem I have with the book module is that it uses the table node to save answers.

Also, using the taxonomy module to categorize the FAQ doesn't work for me. Because the faq terms are only for use in the FAQ. If I output a term_tree I don't want to see the FAQ terms.

All I want to have is a very simple FAQ module that uses its own tables and doesn't interfere with any other module.

Everything is a node, and taxonomy will work fine

laken commented 15 March 2006 at 14:41

"..uses its own tables and doesn't interfere with any other module."

First, pretty much all content in Drupal, regardless of what kind of content it is, is stored as a node. This generality allows for enormous flexibility and modularity, because you don't have developers adding a new table every time they want to add a new content type. So you will find that the node table is where _all_ the content lives, whether it's a blog entry, story, image upload, audio file, book page, event listing, etc. Don't start off with Drupal fighting against this or you will be miserable - instead learn about it and see why it's so elegant and powerful.

See http://drupal.org/node/21947

Second, the taxonomy system is very flexible, and you can define multiple taxonomies (called vocabularies). So you can have one vocabulary of terms that is just for your FAQ and nothing else, and on the page you want your term_tree to be listed you can specify exactly which vocabularies are displayed.

See http://drupal.org/handbook/modules/taxonomy

good luck!

No taxonomy

zeitenflug commented 15 March 2006 at 19:57

I can't use the taxonomy, I really need it for my site, believe it.:-) I get a few thousand directory categories from four other websites and I NEED to save it as a node with exact the number I get for it as well as with taxonomy terms that have exact the numbers that I get. If I change these numbers, it's more complicated to reference back to the other sites and their categories. If I put other stuff in the node table or the term_data table, it may block a number I need for the site. The FAQ has about three hundred entries. If I have to move around the numbers to free them for my site, the users can't bookmark a FAQ entry. So, I need a different table for my faq and a different taxonomy. But if I understand the system of drupal correctly, it would be the best option to use the multisite option, put the faq on a subdomain and use other prefixes for the faq subdomain.

Errrr...

eaton commented 15 March 2006 at 20:02

I'm confused by what you're suggesting. Are you saying that you're depending on specific nodes having specific primary keys before you start populating the database?

This seems like an unfortunate design flaw -- if you're merging data from four other sites, won't there be collisions between them? Path aliasing might be a better solution.

Taxonomies can be restricted to specific node types (a FAQ node, for example).

--
Jeff Eaton | I heart Drupal.

--
Eaton — Partner at Autogram

Design flaw?

zeitenflug commented 15 March 2006 at 20:15

Well, to be honest, if I ask how to achieve a certain task with drupal, I don't want to hear that the task itself is a design flaw. You can see my site as a kind of dmoz directory. There are website entries (i.e. nodes). Those entries have specific primary keys. If I want to update the information on a page, I can do so by contacting the directory server, give him the node key and get the latest information on it. I COULD make another table and map those ID keys to the actual node keys, but I don't see why, honestly. Because a table more means one more source for trouble. The same with the taxonomy. Let's say, there's a term like "Toys" with ID 12218. I can contact the directory server once a day and keep the taxonomy on track. If there are new children for the term, I can fetch them; if old terms died, I can delete them. Also, I can look for new websites connected to this node. For me, this is not a design flaw, but a feature.

Simple.

eaton commented 15 March 2006 at 20:59

I COULD make another table and map those ID keys to the actual node keys, but I don't see why, honestly.

Simple answer? You're using someone else's data as your own primary key. That's a bad idea, no matter how you cut it. If one of the sites you point to restructures its data, or uses alphanumeric keys, or one of their records uses the same ID as someone else's record, or something along those lines, you're SOL. That's why mapping tables are useful.

Your task -- keeping local and remote data in sync -- is perfectly legitimate but the particular solution you're looking at is, if not flawed, at least VERY limiting, VERY brittle, and VERY prone to unhappy explosions down the line. By keeping your own primary keys private, and your associate sites' keys in a separate lookup table, you can leverage the flexibility of a relational database.

Again, you're perfectly able to do what you want to -- it's your Drupal site, after all -- but consider this a warning from someone who's made similar database design mistakes in the past.

--
Jeff Eaton | I heart Drupal.

--
Eaton — Partner at Autogram

Mapping table

zeitenflug commented 15 March 2006 at 21:13

I see where you're getting at. However, if the data provider decides that I'm not getting his data anymore, I'm not allowed to further use it, and if I'm not allowed to use the data, it doesn't matter if I COULD use it because there is no site anymore. For fetching data and making it my own, you're right. But this is not what I'm doing. I'm merely re-arranging it and providing what I hope is a much better interface to the data than other interfaces.

You probably want to...

dopry commented 15 March 2006 at 21:26

For your case since you're looking to replicate another site you probably want to create a new node type...

In the hook_load and update, etc you can load and save data in a foreign table like
table foreign_categories(
nid -> points to node.nid
category
original_url
)

A good example woudl be aggregator 2, or node_aggregator.

Working with foreign tables

zeitenflug commented 16 March 2006 at 07:37

Mmm, neat to know, thanks dopry. This can prove useful for my FAQ, although I'm not replicating the FAQ, it's my own. Anyway, this could help me avoid a lot of trouble.

Hmmm...

eaton commented 15 March 2006 at 21:28

A data provider shutting off access is only one scenerio. I may be misunderstanding what you're trying to do, but this is what I'm hearing:

You want to make a single site that aggregates web directory listings from a variety of other directory sites
You want to keep a strong association between the record on your site, and the record on the source site, to maintain updates, etc
You plan to do this by taking the ID of the site and the category from the source site, and using it directly as a node ID and taxoomy Term ID on your site.

It's possible that this will work. But ONLY if the following are also true:

Every site you interface with uses positive integers as IDs for their content - if they don't, the IDs won't work as primary keys for the node and term tables.
Every site you interface with uses different sets of IDs for their content, and these IDs will NEVER overlap

The latter is a really, really huge issue. It's major. It's a show-stopper. That's why I say it could be a flawed implementation.

--
Jeff Eaton | I heart Drupal.

--
Eaton — Partner at Autogram

What I want to do

zeitenflug commented 16 March 2006 at 07:53

What I want to do, is to implement a FAQ module that does not use nodes. As for the nodes: It is not like amazon or dmoz. The provider of the data is my boss, I develop an interface that provides a better access to the data. I don't have to care about the data structure much, really. That's not my job. Before drupal I used PostNuke for about two years for the same task. However, PostNuke has some design flaws (some really bad design flaws) and a lot of security holes that loomed a couple of times and really costed a lot of work to fix. So I was looking for a better designed CMS and think I found one with drupal. Now I'm trying to implement a FAQ module that doesn't interfere with my key task but at the same time works pretty much in a drupal way.

One more thing: If I map the nodes and I'm on holiday there may be a lot of hassle, because the main admin is using a perl script to administer important updates. I think we'd be cross in no time if my site in contrast to the other sites would need some extra lines in his precious perl script in case he has to update nodes very quickly. As for me, it's better to use the same IDs as the others and not to vamoose too far from the common architecture.

...

eaton commented 16 March 2006 at 18:35

Your desire to implement a FAQ without using nodes isn't particularly bad. It's the other architectural aspects of your project that came to light DURING the discussion about the FAQ that raise many many red flags.

Your latest post raises yet another -- if you're looking to do direct updates of the nodes table from a perl script, you're already in trouble. The data you're likely to want to update will actually be stored in the revisions table. The cross-joins necessary to get THERE are no worse than the cross-joins necessary to store a separate content id in a lookup table.

But it sounds like the decisions are not yours to make in thise regard. Best of luck solving the variety of fascinating technical hurdles that await you. :)

--
Jeff Eaton | I heart Drupal.

--
Eaton — Partner at Autogram

Possible problems

zeitenflug commented 17 March 2006 at 17:47

There is no problem. The problems may seem to be there when telling in a summarized form about the project. If some script runs a MYSQL UPDATE SET body=X WHERE node=ID LIMIT 1, there is no problem, neither with the table, nor with drupal. Drupal doesn't even realize this. I mean, that's what scripts are for, putting data into tables. My drupal install just fetches the data from the table - scripts take care of the integrity of the data - and displays it. Why should there be a problem when I don't enter the nodes by hand? If the script is programmed in a clean way, it will do the job without getting tired and accidentally click on a link it should not click. I have no problem with getting the data into the table, updating the data or whatever. This was only a minor modification to the scripts I'm working with for two years. It's a clean solution because I'm not fiddling around with drupal's code. My problem is not how I get data into the table or out of the table. My problem is that I did not find a FAQ module for drupal.

:)

eaton commented 17 March 2006 at 17:52

I wish you the best. It sounds like your project is an interesting one!

--
Jeff Eaton | I heart Drupal.

--
Eaton — Partner at Autogram

Fair enough

dman commented 17 March 2006 at 21:26

If you've already got a system in place that's doing this, and it works, that's cool.

Your UPDATE will work fine, yes, and I guess there's no reason not to continue using the nid as the identifier accross systems.
... unless you want to actually create content using Drupal.

I've battled problems with site sychronization arising from the way it keeps its ID key table somewhere else - not using true autoincrement.
If I've created nodes using direct SQL injection (like from a script, which I did a few times) the next time Drupal wants to make a page it will attempt to overwrite my data with its data, due to pointers being out of synch.

So if you choose to enter all nodes by script, you have to choose not to enter any by hand (or by any other script) unless you are really clever and careful.
So I appreciate why you wouldn't want any solution that stores its FAQ data in a node!
I built one recently using taxonomy to group all answers under their own topic, and made a rendering page similar to /taxonomy/term/n that pumps them out in FAQ format (all titles, then all bodies linked on the page).
But, yes, the answers themselves, each a paragraph or two, are nodes of their own.

.dan.

http://www.coders.co.nz/

_{.dan. is the New Zealand Drupal Developer working on Government Web Standards}

WTF

dman commented 16 March 2006 at 10:43

There are ways to do FAQs, I've hacked at a couple, but yes, I'm disappointed there is no "FAQ Module" per se to aim at.
Someone with initiative could always try and construct one, but the attempts I've seen (including my own) seem to have different goals.

But your post here, sorry, reads like gibberish.

As has been mentioned, all meaningful content is stored in Drupal keyed on a node, one way or another.
It's conceivable to construct a cross-reference table that referred external data to external data without adding any content from Drupal itself, but it would be (as mentioned) brittle, and of dubious real value.

If you don't want to create nodes, it sorta means you don't want to create information.
Split your dependance on external IDs from your internal node IDs.
Set up each external data source as a vocabulary or some otherwise indexed table, then associate your local node with them to bring it all together. Do not trust or care about their numbers. They may be cannonic within their own realm, and should be remembered, but they cannot dictate your own internal data structure, especially your internal node IDs. You just gotta draw up a lookup table to interface with them.

OK, that post may also have sounded like gibberish, I'll admit, but you have not stated your actual problem clearly. I'll bet there's a better solution.

Or, for $70PH I'll solve it for you.

.dan.

http://www.coders.co.nz/

_{.dan. is the New Zealand Drupal Developer working on Government Web Standards}

Again the problem

zeitenflug commented 17 March 2006 at 17:55

Hi dman, thanks for replying. Since the discussion grew a bit in size, you don't seem to have followed it from the beginning. But that's no problem, I'll summarize:

1. I asked if there is a FAQ module.

2. People suggested I use the book module.

3. I said this does not work for me, because if I put something into the main_node table, it interferes with my primary use of the table. If I change the behaviour of my site, I will run into trouble with other admins within the project, because I will have a different ID system than they have and it will be a bit harder to synchronize data between the systems.

4. I discovered the multisite feature and decided I can use it to point the book module to a table like faq_node instead of main_node, including using faq_taxonomy instead of main_taxonomy (same with terms).

5. Since I know now how to use the book module in a way that does not interfere with my primary use of the site, I want to know how to use it as a FAQ. This means, I would like to know where to save questions, how to handle answers, how to show the top five questions.

book module as a FAQ

zeitenflug commented 15 March 2006 at 20:06

I don't quite get how to use the book module as a FAQ. I played around with it, but it seems to pretty bulky for a FAQ. Am I supposed to put a question on every book page? Or can I retrieve a single entry if I put several questions on one page?