Port to 6.x

A port to Drupal 6 should be done as quick as possible.

Anyone willing to co-sponsor this?

This is a cleaned-up patch of hba's code for 6.x. Code in hook_menu() still needs some fixes, and it does not yet adhere to Forms API changes.

To teach myself a bit more in Drupal 6 I've taken this up.
Attached is one patch against current DRUPAL-5, and another against current HEAD.

Almost everything works. However, the site guestbook can't be accessed if user guestbooks are enabled. This is because of the placeholder %user_current in hook_menu(). It automatically loads the corresponding user id, which should be '0' for the site guestbook, but user 0 is the Anonymous user.

Replacing %user_current with %user does not work somehow. For whatever reason, the menu item does not appear in the menu then. Seems like we've to talk to chx on this... or implement a different solution.
For example, the current guestbook overview page could be moved to a menu path 'guestbooks' (plural) while keeping user guestbooks on the same paths like now. I've already tested that and it would work out.

Thanks sun. I committed your work-in-progress patch to HEAD.

@hba: Any input regarding the last known bug I explained in #5 ?

The use of guestbook/0 isn't really all that nice. Maybe we should use something like guestbook/list, guestbook/site and guestbook/user/%user instead?

Well, if we really consider to alter the paths for 6.x, I'd propose the following changes:

Guestbook overview page

guestbook -> guestbooks

Site guestbook

guestbook -> guestbook [currently if user guestbooks are disabled]
guestbook/0 -> guestbook

User guestbook

guestbook/# -> user/#/guestbook

Separate entry form

guestbook/0/form -> guestbook/add-entry
guestbook/#/form -> user/#/guestbook/add-entry

IMHO especially the change for paths of user guestbooks is overdue and makes sense.
Let me know what you think.

Good idea, but I would rather keep the guestbook name space:

Guestbook overview:
- guestbook/list

Site guestbook
- guestbook/site

User guestbook
- guestbook/user/#
- guestbook (same as guestbook/user/%current_user)

Separate entry form
- guestbook/site/add-entry
- guestbook/user/#/add-entry

As Invite is also moving to integrating user-specific pages (invite tracking) into the user's profile (as new tab, consequently), my vote goes to sun's proposal in #9. Or exists a specific use case why we don't want to keep user related stuff together at a determined location?
And since http://www.example.com/guestbook(s) are actually perfectly clean urls, why stick another /(site|list) to it?

But you are the maintainer of Invite in addition to being related to sun (I guess?). Your vote surely cannot count? :p

Jokes aside, my proposal still keeps the (perfectly clean?) /guestbook for the user's personal guestbook. On the other hand, having the guestbook as a tab in the user profile sounds like a good idea.

Anyway, I'll give your proposal some more thought

Actually, http://drupal.org/node/218059 is a bug report that is caused by the current paths.

Today I patched guestbook-DRUPAL-5_0.patch into guestbook-5.x-1.x-dev.tar.gz and succesfully enabled the module in my 6.1 installation.

In a response to forschi I present my patched version of guestbook. Hopefully this gets you started using the module again.

Furthermore I have been testing the patch and I have come across some errors.

• After adding a test entry I received the following error:
  "Unable to send e-mail. Please contact the site admin, if the problem persists."
• Next to that I tried to delete the test entry by using the delete link. Unfortunately the link was tainted (in some form) and thus wasn't able to run. It seems all links, both replying and deleting aren't working.

  http://www.example.com/guestbook/%252Fdelete/346
  http://www.example.com/guestbook/%252Fcomment/345#comment-entry

  The links comes with a %252F character. It seems to be a hex code for Unicode Character 'BOX DRAWINGS DOWN LIGHT AND HORIZONTAL HEAVY' (U+252F) according to fileformat.info. I don't know where it comes from or whatever it means. I did look for it in the module code, but I couldn't find anything.

  Removing the %252F character is sufficient, for the function does work when called directly at the url bar.

I hope to see an official released module soon. I'm not a coder, but I can test, I suppose :-)

I met the same problem with page not foune error. I have a workaround;

Make URL alias for guestbook/{ID} and use the alias for

You're welcome forschi, I'm new to patching and although people here are naturally expected to patch themselves, I'm sincerely interested in guidelines when one can expect a release. I'll have to look them up soon. And next time I might "release" properly ;)

URL aliasses are handled by the drupal software, not the mod_rewrite function. To test this, assume you alias node/1 to welcome, you should be able to access the node via ?q=welcome. Now if you would use the workaround to alias guestbook/0 to guestbook/foo it should be accessable via ?q=guestbook/foo. Then again, when I try to access guestbook/0 I don't get the page not found error, but instead am redirected to the site guestbook. Since my site is in production state, I will need to setup a test-site for further testing.

Make sure you enable the optional core module named Path. After enabling URL aliasses should appear in the Site-construction administration pages.

Since there has been no negative feedback on the proposed guestbook paths, I have implemented them and created the first release candidate (RC) for Drupal 6.x.

The new path layout is:

guestbook => Site guestbook
guestbook/sign => Sign site guestbook form

guestbooks => User guestbooks overview page
user/#/guestbook => User guestbook
user/#/guestbook/sign => Sign user guestbook form

If you find a bug in RC1, please file a new issue for it. Thanks.