pdb-before_submit_update

The pdb-before_submit_update filter is used for both front-and back-end record updates. There is perhaps some other reason the filter is not getting used in a frontend context? Have you tried placing an error_log statement in your function to see if it is getting called and the expected fields are getting passed in?

Thanks for the fast reply! I did, and should have mentioned that. My mileage_totals() does run when a member submits the form in the front end. I printed out $values at the top of the function before my logic and after to confirm that my tweaks are correctly applied in the variable. My code seems to do exactly what I want–the values are what I expect. However, the fields I tweaked don’t get saved in the database.

Important to note that the other fields (the fields that are not read-only) do get saved. For example, I can change bike_1_current_end_miles as a member in the front-end and the value is updated in the database.

Again, this logic does work if making the same change in the admin.

OK, read only fields cannot be saved that way to prevent someone spoofing the form to save values in fields they shouldn’t have access to. If you want to save a read only value in that context, you need to do it directly to the database as a separate operation, like this:

<?php
global $wpdb;
$wpdb->update( 
   Participants_Db::$participants_table, 
   array( 'total_miles' => $values['total_miles'] ), 
   array( 'id' => $values['id'] ) 
);
?>

Hmmmm…so trying to take a step back to solve this problem in a smart, efficient way.

Let me describe the “problem”. We want members to be able to enter starting and ending miles for up to 5 motorcycles. We want to calculate the total miles per motorcycle as well as the total overall miles per member. We’d like to get at least the overall total per member included in the CSV export and/or reporting, but I guess we can calculate these numbers after export just as easily. We are using the PDb List to show a “leader board”, so the total_miles field comes into play there as well.

We tried solving this with read-only fields and a bit of custom logic in pdb-before_submit_update. As this thread describes, it almost works.

I tried the $wpdb->update() method, but it seemed not to make a difference. (No errors, either.) My guess is that it makes the update, but then my pdb-before_submit_update logic returns $values, and the original read-only values get stomped over my freshly-updated values? If this is the case, I don’t know how to make that manual db update “out of band” of my pdb-before_submit_update logic.

I guess another angle would be to create custom templates for the form and the list. In my custom template, I can calculate these mileage numbers and poke them into the right place in the display. This would eliminate these read-only, calculated fields.

As I am a very lazy man, I was and am looking for the easiest way to solve this problem. Do you think I should change gears? Or am I almost there with my current path?

Got any wisdom for me? Recommend an attack plan? Thanks!

Using the database update will work, have done this many times. Read only fields are not written at all in the context of a user updating their record, so that’s not preventing you from writing the total to the database.

You probably need to take a closer look at your code to make sure it’s getting the value you need to store in the total field. Once you get that working, you can add the other types of totals you’re talking about.

Add some debugging statements to your code so you can see what numbers it’s coming up with, my hunch it it’s not getting the total, so it’s probably writing blank data to the database.