Quote Originally Posted by davewest View Post
In Admin, it's correct and I do understand its use there, just not from the user input side where the ID is auto generated after the posting of the form data.

So how would one post the id before its auto generated is the question for line 29?

Picking up the ID after its created again, makes sense, but its not in use on the success page as a link nor used in the email sent out, which again would make sense.
Regarding posting of the testimonials_id "before" it is autogenerated: Here is how I understand the situation, but I think that we are possibly thinking down two different paths.

What seems to be the intended use: Admin knows the testimonials_id that they wish to edit/update, they type in their uri:
/admin/testimonials_manager.php?bID=24.

This takes them to the testimonial that has the id of 24. In so doing this, the action is identified as an update action, a field is populated on the page that contains the testimonials_id (which when the form is submitted will be POSTed) and the other fields to edit are provided. The admin edits the fields, submits the form, this then submits the testimonials_id to support capturing the update. That is where line 29 is involved. It collects the posted data. Then as it continues to process there is a fork in the road of either to insert or update and because this action is considered an update, the existing (POSTed) testimonials_id is used. But, as you may see/notice, the case 'insert' and case 'update' seem to follow the same path. Well, generally speaking an insert and an update both share common actions pretty much up until the end... But... an insert can not (as you have pointed out) already know what the testimonials_id is before it has been "committed". That is why an insert action goes through a collection/autogeneration step. Sure, one could use a web browser to edit the html on the page then submit the page with a testimonials_id and feed that through, but... Towards the end of the "process" because that would be considered an insert (unless that portion of the page was edited also to be an update) a new testimonials_id would be expected and is also controlled that way.

Now, could the code be modified/switched around a little so that there isn't a check to see if it is posted or not? Yeah I can see something like that, but it would/could change the way(s) others have worked with the code. Ie.:

This
Code:
      case 'insert':
      case 'update':
        if (isset($_POST['testimonials_id'])) $testimonials_id = zen_db_prepare_input($_POST['testimonials_id']);
        $testimonials_title = zen_db_prepare_input($_POST['testimonials_title']);
could be changed to:
Code:
      case 'update':
                  $testimonials_id = zen_db_prepare_input($_POST['testimonials_id']);
      case 'insert':
        $testimonials_title = zen_db_prepare_input($_POST['testimonials_title']);
But then could also ask, why make the change? What problem is solved? Might it prevent similar confusion? Sure, but also how much rework by others is expected to be done? (Helps to know things like that if/when such a thing is done that there be some form of "notification" of doing something from either/both sides. Notice that the overall ZC project does this type of thing by making the new version(s) available for a period of time before committing it for the community to use.

Sorry, I digress I think.. Anyways, hope that explanation helps/helped.