Billmel

BTW: I noticed there are new templates for 1.6; I’m trying them now. I should have known that the templates change from release to release.

In my template I added a check for empty record prior to the sort() call, and the warning errors are gone. Please consider doing this in your template example code.

On the second issue, if I remove the reference to my template for the pdb_record short code, the page works correctly. If I use the default record template without any changes, I get the same behavior. I need to make some changes to what’s displayed and what’s read only, so perhaps I need a new default record template?

Thanks.

I switched back to 1.6; I want to work through the problems, not be stuck on the old version.

WP_DEBUG is and has always been set to false.

I’m going to try to test the input value to sort() in your template example, and see if that removes the warnings; all of the places the warnings show up, the field is blank.

I still don’t understand why after the submit button I’m sent to a page with
“[pdb_record template=edit]”, rather than the page having just been updated. Is there something I can do to provide more information on this?

Oh, and after the restore, the “manage database fields” tab no longer works.

I decided to restore the previous version, in order to confirm the problems.

I found that the signup form notification is broken on the older version as well, so that is a different problrem.

In running the older version, I find that if I update the plugin settings page with ANY change, all of the drop drop selections for single entry, record update, etc, all disappear, and the site stops working, requiring that I restore it again.

Does reverting to the 1.5 code not work properly, and is there some reason that the information saved from the settings page would be broken?

Have you updated the example templates? That’s what I used as a baseline.

How does one turn off the PHP error messages? I’m running version 5.3 of PHP.

The saving changes issue comes up when updating an existing record. The update occurs, as the same URL is displayed, ending with ?pid=xxxx, but instead of re displaying the information, it shows “[pdb_record template=edit]”

I haven’t changed anything in notifications.

Also, my signup form no longer sends email to the notification alias, and doesn’t return to the designated page after pressing the save changes button in the front end; the changes are saved.

That’s it! The back end sees all fields in the record, while the front end was configured to show only certain groups, none of which had the field in it. Moving the field to a group that the front end can edit, even though the field is hidden, allows it to be updated. Conversely, if it isn’t in the group being displayed, it doesn’t get updated.

This is actually a very handy mechanism once you understand it, since it allows you to for example collect different information depending on what group of fields is being edited, and only updating the information relevant to the group. I hope you can create a useful demonstration that shows off this capability; I think it will prove to be very handy.

Mahalo,

Bill

Even weirder; If I include the echo statement above with the username, it displays correctly after updating a record from the front end page, but does not actually update the record, while when I do the same from the back end, I get the “Warning: Cannot modify header information” error, but the record DOES correctly update. Clearly, there are two different code paths, one works, one doesn’t.

On further investigation, it looks as though this code does the right thing when the record is edited in the back end editor, but for some reason does not update the record when the edit is done from a front end page. They are obviously different code paths; do I need a different method for handling front end edits?

Mahalo,

Bill

Looks like the above error (Thanks Google) was from whitespace in my functions.php file. Removing the echo statement fixed that problem.

I have a new problem though; if a record has no value in the “updated_by” field, then this code updates it. If it already has a value, it apparently doesn’t overwrite that field with the new information. Seems odd..

Here’s what I have so far:

<?php

function update_user($post) {

   global $current_user;
   get_currentuserinfo();

      echo 'Username: ' . $current_user->user_login . "\n";

   $post['updated_by'] = $current_user->user_login;
   return $post;
}

add_filter('pdb-before_submit_update','update_user');

?>

When I do an update, I get the following:

Username: <name of the user who is doing the updating>
Warning: Cannot modify header information – headers already sent by (output started at <path to functions file>/functions.php:10) in /home/content/81/9947681/html/sb/wp-includes/pluggable.php on line 1121

So it looks like there was an error that I couldn’t see until I enabled the debugging. Question is, why am I getting the Cannot modify header information error?

Mahalo

I deleted the entry which was a Text-line and then re-created it as a Hidden field, but it is still not being updated. Does it need to have an initial value, or need to be marked Read only?

Well, I added the following to my functions.php:

<?php

function update_user($post) {

   global $current_user;
   $post['updated_by'] = $current_user->user_name;
   return $post;
}

add_filter('pdb-before_submit_update','update_user');

?>

and added the field updated_by to my database as a type “Text-line”. I do not see anything updated in the record when I make a change to the record.
I also tried just assigning a static value above, and it also didn’t record anything in the database entry.

What am I missing?

Mahalo,

Bill

The issue I’m concerned with is that a user gets the private link in email, and then uses it repeatedly versus going back to the site to request the link each time. Many of the current two factor systems provide an email/text that works as a one time “password”, so people understand that model versus trying to explain to them that they must protect or really delete (think Gmail) the email sent to them as though it was their password.

The email feature meets a lot of my requirements for monitoring changes; is it possible to record other variables, like the logged in username of the person doing the update, in the email? That would help a lot if I find an update that has bad data in it and I want to contact the person who made the update, as each person using the front end in my application has a WordPress username.

Bill