Optionally unpublish new guestbook entries by default

+1

subscribing

This feature is very necessary on our site. Did you write a custom page to approve guestbook entires Hetta? Any chance you could pass along the code?

-Drew

Is there any other way to moderate guestbook entries without hack the module?

I needed this functionality, too, so I took Hetta's idea of an additional table field and hacked the core to add built-in publish handling instead of using phpMyAdmin.

The field will need to be added to the table manually. I used a tinyint field, not null, default 0, named "published".

The code adds a header reading "UNPUBLISHED ENTRY" and a "Publish entry" link. Actual publishing code is just modified copies of the functions handling delete. I also modified the post-submission message. [As an aside, it would be helpful to have this customizable.]

This is the .module version I built on top of:
// $Id: guestbook.module,v 1.19 2009/03/10 23:14:36 sun Exp $

No, it's not in there. Stable is still from September 2008 and my work-around is from March 2009.

@Tomws: Could You attach whole module with Your patch? Or make some patch for new dev release? Because I cannot find v 1.19 to apply your patch.
I have old one 1.17 and the newest one is 1.3.2.7 and this one is much more different then 1.19 (there was code clean-up meanwhile)

@Josiv: I just tarballed the directory in use on one of my sites. Attached.

THX!, meanwhile I installed Mollom spam service, after few days (had to submit 'my' type of spam :) ) it seams to handle all spam for guest book...for now, but I will use this version.

Yes, see comment #8 above where I mentioned that I manually set up a new field on the database. That could have been included in the module hack/patch, but I didn't do it.

@Tomws:i downloaded your tarballed directory, the module is working absolutely fine except that when i click on "add comment" link it shows me a warning :
warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'theme_guestbook_form_comment_form' was given in C:\Program Files\xampp\htdocs\drupal\includes\theme.inc on line 617.

could you please look into the issue

@varun_chander: That happens even with the unmodified module, so it's an error in the code. Actually, that function doesn't exist. I didn't check to see if a bug report has been filed against it. FYI, you can cheat and make this go away by adding a dummy function:

function theme_guestbook_form_comment_form($form_state) {
  /**
   * placeholder to eliminate error display:
   *     warning: call_user_func_array() [function.call-user-func-array]:
   *     First argument is expected to be a valid callback,
   *     'theme_guestbook_form_comment_form' was given in
   *     /server/path/to/drupal/includes/theme.inc on line 617.
   */
}

This doesn't fix the problem, but it can cover it up.

@I_am_trying_to_...: I just downloaded the latest dev snapshot and it's still not in there.

Here's a patch against the latest dev snapshot. This one also adds in the database field creation, so it should be all automated now.

If others can test this and set the status flag to reviewed and tested (assuming it works for you), then maybe it'll get the attention of the developer and get inserted into the next version.

EDIT:
Additionally, this should probably be extended to include:
1) a modified email body (or even a user-customized email body) in the notification email. Otherwise, it's just the guestbook entry message text and doesn't imply to the recipient that the message needs moderation. I've hacked this on one version but it's not included in the patch.

2) an option to disable prepublish moderation. This should be simply a new variable in the .install along with a few extra wrapping if statements.

3) Maybe move the 'published' field creation to an update function rather than the hook_schema in guestbook.install. I'm not experienced enough to know which way is best. If using an update function, the definition array should probably include a 'initial'=>1 in order to maintain the published status of existing entries.

The patch doesn't use an update function, but rather a modification to the .install hook_schema to create the new db field. So I don't know that I'd replace a module on a live site with it. (Actually, I would, but I do take a risk sometimes.) Your process sounds correct, though. If you do it, take the normal backup precautions.

I tend to stick with stable, too, but I think proper patch procedure "requires" them to be generated against the latest version (which is the dev snapshot).

The Send/Save naming is in the module already, so that should be a separate bug report or feature request. It's an easy fix, but this patch is only aimed at the pre-publish moderation. There are a couple of other minor problems that need patching, too, but they're also separate from this thread/patch.

The Delete and Edit functions are still available even after publishing an unpublished entry, just like in the unmodified module, so you should be okay to test that fully. It doesn't offer just an Unpublish function, though.

@tomws
exactly as u mentioned it has fixed the problem ....thanx buddy ...cheers life rocks ..!!
another request i would like to put in here ...is that guest book entry form is not getting displayed in another page although i changed in the settings page also ...but each time i select the "Location of entry submission form: " as "separate page " it displays the form below the entries instead of displaying it on separate page ...

could u look into the isssue ...tons of thanx before hand

very nice patch tomws

thanks a lot for this usefull one

-drub4n

@tomws
Hi, your patch is working well except when i am selecting (Location of entry submission form:='separate page'). guestbook module still displaying it in same page instead of new page.

Please help me

@anilbhatt: I just installed the latest dev version without applying the patch and that problem is also present there, so I don't think it's a problem with the patch code. Try opening a new bug report.

Hi,

Actuall i am fresher in drupal, but as a know guestbook module have problem with 'Location of entry submission form:='separate page' , its not working , i try it.

Please help me out.

@anilbhatt: That bug is unrelated to the original feature request. You should file a new bug report rather than modifying an existing request.

Can you please send the patched file as zip file.

Just FYI to anyone who tries the patch from #20.

It works fine if you are installing the Guestbook module for the first time, but if you are updating an existing instance of Guestbook, the DB field and index will not be added. You will have to do it manually in the DB, using something like phpMySQLAdmin or mysql from the command line.

Your two options are:

- Disable AND uninstall Guestbook, reinstall using patched version (WARNING! You will lose ALL your guestbook posts and settings if you do this!)

- Add the 'published' field and index to the database yourself. Just look in the patch for the field settings.

I don't know if it is my editor or what but the line numbers don't take me down to the database loop. Can you give me the first line of code that would appear after, just so I am not confused.. *yeah right like that would help..lol

Edited to say, got that figured all out.

Actually could you just export your Guestbook entries and then import after upgrade to patched?

FEEDBACK:
Words of warning: I am a risk taker and I did this on live site. If you are not a risk taker DO NOT do this

I used Tom's patch in the following way. It cut the carp out of all of this confusion. Note: The first steps are to preserve data just in case ...motto "first do no harm"

1) I copied and pasted my guestbook entries into a WYSIWYG to save display integrity in case I had to manually put them back in. This would give me a visual on how folks posted

2) I exported the guestbook table through PHPAdmin so I would have that in case I needed to import after upgrade. I added the database field.

3) With module still enabled I took his directory contents (in the .tar above) and overwrote my contents in the guestbook folder. via FTP.

I have some small font issue which look CSS related but the programming works smooth and beautifully. I did not lose any of my content and all of my entries were set to UNPUBLISHED, so that gave me lots of practice for the future.

Thanks so much Tom!

Since the patches above did not correctly apply itself....

I've written a patch from the ground up, which creates a little publishing system in your guestbook. Please note that this is my first patch and did some funky things with my commits, so I'm not sure if this patch applies itself correctly. It's based on the Guestbook 6.x.1.1 Also this patch does NOT update your database, if you want to apply this patch on a existing Guestbook module you should create a new column in your database as following:

'published' => array(
'type' => 'int',
'length' => '1',
'unsigned' => TRUE,
'not null' => TRUE,
'default' => 0,
)

APPLY THIS PATCH AT OWN RISK!

This patch is made by www.10uur.nl

Please review the patch...

Edit: Do not use this patch, this one was generated the wrong way around, see my next message for the correct patch.

Sorry! The above patch was generated the wrong way around... Here should be the correct patch.

That last patch doesn't work either.

patching file guestbook.module
Hunk #1 FAILED at 143.
Hunk #2 succeeded at 285 (offset -2 lines).
Hunk #3 succeeded at 304 (offset -2 lines).
Hunk #4 succeeded at 323 (offset -2 lines).
Hunk #5 FAILED at 549.
Hunk #6 succeeded at 633 (offset -2 lines).
Hunk #7 FAILED at 709.
Hunk #8 FAILED at 726.
Hunk #9 FAILED at 748.
Hunk #10 FAILED at 763.
Hunk #11 FAILED at 966.
7 out of 11 hunks FAILED -- saving rejects to file guestbook.module.rej

Okay, this one SHOULD work. ;) Please let me know!

Resetting the issue, in my next post I'll re-submit the patch to be reviewed.

Here is the patch again, this time to be reviewed for submission. Sorry for the additional clutter in this issue.

Edit:
Some explanation about the features the patch gives you:

- Some improved (I think) semantic buildup.
- Enable / disable the publishing system on the config page.
- Publish / unpublish guestbook entries

Something the patch does NOT do, is that it won't update your existing db structure. So please, when using this patch on an already installed guestbook, create the extra column manually like described in the above post. When this patch and functions are tested and approved, I´ll dive into an updater for this patch.

If you're creating a new guestbook, you can ignore the above. The install file does create the new collumn.

We already have moderation permissions in 2.x, so I don't see a need for separate un/publish permissions.

Let's focus on the publishing status for entries instead.

Hio Eric_A

you posted a Patch that I think whould solve my problem as well, but I have not experience on installing patches.
When I click on the .patch file, the browser shows me the code of the patch.

Supposing I'm able to download it, how can I install it please?

Sorry for my question but otherwise I cannot go further

best regards

First of all, here is a patch that does not break inserting new entries.
While this new version of the patch makes it possible to unpublish an entry, you will find that it's harder to republish. (User interface problem, no data loss) The patch needs work, I'll look into it and do some actual testing now.

@Tiziano: See http://drupal.org/patch/apply
Might not be easy for you if you've never done anything like this before. Let us know.

This one actually succeeds in showing unpublished entries to moderators.

At least one more thing to do: some text to indicate the status to moderators, because since no stylesheet is shipped, the added html class won't do much for guestbook out of the box.

Added the status as text when displaying an unpublished entry in the list.
Also changed class name 'guestbook-unpublished' to 'guestbook-entry-unpublished'.

To make reviewing and testing as easy as possible I tried to add the basic functionality and nothing more. The default behaviour is not changed. The added UI text is kept to a minimum. For instance if an entry is unpublished by default the message still says nothing more than the old: "Your message has been added." We can always do more in follow-up issues.

-      db_query("UPDATE {guestbook} SET message = '%s' WHERE id = %d", $form_state['values']['message'], $form_state['values']['entry_id']); 
+      db_query("UPDATE {guestbook} SET message = '%s', status = %d WHERE id = %d", $form_state['values']['message'], $form_state['values']['status'], $form_state['values']['entry_id']); 

Let's not re-add that old trailing whitespace...

@Eric_A

I've been reading "how to apply a patch" but it seems that everything I must do, it should done by command line.
That's for me impossible.

My server provider doesn't give this facility ...

This patch looks lovely. I'm just not sure whether it's a good idea to commit to 6.x-2.x first. Normally (in overall Drupal), we do it the other way around (i.e., HEAD/7.x first), so that (any kind of) improvements are never going to miss in later versions (for any kind of reason). Therefore, I'm tempted to move this issue to 7.x-2.x and come back to the 6.x patch later on.

@-Tiziano-
apply patch in terminal on local computer then upload to server.

so is this development request on hold or will this happen soon?

For me this is now material for the next branch, i.e. postponed. Still, it would be very nice if travisimo or somebody else would give the patch in #48 a test drive. (And then maybe provide Tiziano with a ZIP?) Now that would motivate me to come right back to this when an official 7.x release is done ;-)

I'd say that the 2.x branch is feature frozen with an exception for the Mollom feature that is in 7.x-2.x and existed in the old 6.x CVS HEAD, but is not in 6.x-2.0 and the 6.x-2.x git branch.

Backwards compatible features like this can be added anytime. The default would remain published, so no impact on existing sites.

in http://drupal.org/node/1124672 you say it's a duplicate of this thread.
actually after upgrading to 2.0 i lost the option to comment, delete (existing and new) guestbook entries so is there an issue with backwards compatibility or does the patch need to be applied?

EDIT: problem was related to a themable function. we checked for "administer" rights in the older version but the module changed permission to "moderate"...

Hello to all,

my sites guestbook is flooded with pills ads every day since some weeks. Captcha is active. I use 2.0 version.
Which patch should I use to get the published/unpublished feature?
And which version to apply to? 2.0 or 2.x?

Thanks for helping!
Cheers
Mark

Edit:
another question: Does 2.x contains this feature already? Will not try it cause I do not know if it is possible to switch back to 2.0 again

The patch in #48 has not made it in yet, neither in D7 nor D6 Guestbook. It was rolled against 6.x-2.x-dev and still applies fine -but with warnings- against the current snapshot. It will however change your database schema.
(The Mollom solution is the smallest possible change to your code (a little) and database (no change), so you might want to check out the two latest D6 patches (in #21 en #32) in #717040: Mollom support.)

Alright, forward-ported to D7, with a couple of adjustments and additions.

(The D6 patch should be backported from scratch, based on the final patch that will be committed.)

@Eric_A: If you're happy with this, please feel free to commit :)

@sun: Thanks!

@@ -378,6 +383,9 @@ function guestbook_page($account, $op = NULL, $op_id = NULL, $page = TRUE) {
         break;
     }
   }
+  elseif (!_guestbook_access('moderate', $account->uid)) {
+    $sql_where = ' AND g.status = 1';
+  }
 
   // Fetch guestbook entries
   $limit = variable_get('guestbook_entries_per_page', 20);

This needs fixing. Haven't had the time yet to really look into these D7 lines, so anybody feel free if you have ;-)

ah, yes. Not much simpler than that :)

(might even mean the elseif was also in the wrong location in the D6 patch)

Thanks!

Pushed to 7.x-2.x.

A new development snapshot will be available within the next 12 hours.

Hello,

hopefully someone will make a version for 6.x also.
My skillz are not suitable :-(

I would really appreciate it!
And for sure I will act as a test person and provide feedback.

Cheers

Here's a patch based on the ones in #60 and #48, with a count query hunk added as well. This and the part discussed in #59 and #60 really need reviewing and testing. The code in guestbook_page() isn't getting any prettier, but it might be good enough for now.

+++ b/guestbook.module
@@ -345,6 +350,12 @@ function guestbook_page($account, $op = NULL, $op_id = NULL, $page = TRUE) {
+  if (empty($comment_entry)) {
+    if (!_guestbook_access('moderate', $account->uid)) {

Is the empty() required here?

I don't think non-moderators can view or edit their unpublished entries, or can they?

Aside from that, this looks ready to fly for me. I didn't actually test it though.

Hello Eric_A!

Just started testing.

my test scenario is drupal 6.24 with guestbook 2.0

Just loaded 6.x dev and applied your patch.
Patch applied fine.
So I installed module and run update.php
Database has updated with no errors.

Now I started a different browser to write new anonymous guest book entry.
After sending following message showed up in red background:
"user warning: Unknown column 'g.status' in 'where clause' query: SELECT COUNT(*) FROM guestbook WHERE recipient = 0 AND g.status = 1 in /usr/www/users/rakekn/drupal/sites/all/modules/guestbook/guestbook.module on line 372."

As administrative user I see all entries and I am able to publish/unpulblish them.

Cheers

edit:
Just used phpMyAdmin to check database. There is a field "status" in table "guestbook" and values are filled in. Maybe this helps

+++ b/guestbook.module
@@ -358,7 +369,7 @@ function guestbook_page($account, $op = NULL, $op_id = NULL, $page = TRUE) {
+    $result = pager_query($sql, $limit, 0, "SELECT COUNT(*) FROM {guestbook} WHERE recipient = %d". (_guestbook_access('moderate', $account->uid) ? '' : ' AND g.status = 1'), $account->uid);

yes, this count query does not use a table alias for the guestbook table. For consistency, we should simply add the alias.

Fixed the count query. No time now to test though.
Thank you so much rakekniven for helping out!

As for the remarks made in #64. I'll look into that later but if there's a problem here, I'd say it's very likely that there's a problem in the D7 branch as well, and we may have to move this issue back to 7.x-2.x.

Just tried your latest patch from #67 and it works like a charme :-)

Thumbs up, guys!

Back to 7.x-2.x, because a little more discussion on the subject of access control for unpublished entries would be helpful. Consider the case of the user guestbook with the owner not having the "moderate own guestbook" permission.
So here's a patch for discussion.

1) A comment on an unpublished entry should not be available for non-moderators to edit.
2) Unpublished entries should not be available for non-moderators.

Hey,

I still run 6.x here and both, A and B, works like described without applying your patch.

Cheers

@rakekniven,

I'll describe my setup a bit more accurate.
My testing use case for #71 is a normal user looking at unpublished entries posted by anonymous users in his own user guestbook. And user 1 posting a comment to one of those unpublished entries.
Before #71 a user without any moderator permissions, i.e. no "moderate own guestbook", no "moderate all guestbooks" sees those unpublished entries and is able to edit the comment.
If you have different results, we'll need to find differences in our setup.

@Eric_A
Understood.
My setup is different in one point.
My site offers only a website guestbook. No user guestbook.

Anybody else can test it? Otherwise I have to play around a little.

Cheers

Pushed #71 to 7.x-2.x. Here's an updated patch from #67 for 6.x-2.x.

yay, let's go ahead with this. People can follow up on this issue if they find any bugs pertaining to the new status.

Eagerly pushed #75 to 6.x-2.x, looked it over, and followed up for the count query.

diff --git a/guestbook.module b/guestbook.module
index 0287bb6..59b2e3c 100644
--- a/guestbook.module
+++ b/guestbook.module
@@ -367,7 +367,7 @@ function guestbook_page($account, $op = NULL, $op_id = NULL, $page = TRUE) {
     $result = db_query($sql, $account->uid, $comment_entry);
   }
   else {
-    $result = pager_query($sql, $limit, 0, "SELECT COUNT(*) FROM {guestbook} g WHERE g.recipient = %d". (_guestbook_access('moderate', $account->uid) ? '' : ' AND g.status = 1'), $account->uid);
+    $result = pager_query($sql, $limit, 0, "SELECT COUNT(*) FROM {guestbook} g WHERE g.recipient = %d". (_guestbook_access('moderate', $account->uid) && (user_access('moderate own guestbook') || user_access('moderate all guestbooks')) ? '' : ' AND g.status = 1'), $account->uid);
   }
   $entries = array();
   while ($entry = db_fetch_array($result)) {

Well, I'd say it's done. Yay!

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

(Untagging.)

It's ok and best practice to keep all tags on issues. :) Some are useful for filtering, some others can be used for simple statistical overviews. So in general, we commonly just ensure that issue tags are correct (e.g., new/unfamiliar users and contributors often add a plethora of tags, possibly even with invalid syntax [spaces instead of commas], whereas almost all issues on d.o are mainly using tags out of the set of special issue tags), but we normally don't remove the special issue tags after they've been added.

When backporting the forward port that was started in #58 I ended up adding the checkbox element last (like in the original patch). In the D7 patch it is first. Quick fix.

Because this checkbox has no label the patch from #81 makes it look like it belongs to the guestbook entry text format settings (which are absent from D7).

Pushed #82 to 6.x-2.x.

Thanks! :)