Testimonial Manager Support Thread (for ZC v1.5.x)

[kevin_remy]

Also, I added metatags code correctly. I think there is something wrong, too. You may check below pic.

[kevin_remy]

Hey, I still need your help. In all testimonials page, CSS does not work. Check below pic:

Attachment 17115

I added below codes to my template stylesheet.css

.testimonial {
color: #000;
padding: 0 5px 5px 5px;
text-align:left;
}
.testimonial p {
margin: 0; padding: 5px 0;
}
.testimonial span {
float:right;
}
.testimonialImage {
margin: 0;
padding: 0;
text-align: center;
} 

I fixed this problem. Need not reply.

[mc12345678]

I fixed this problem. Need not reply.

Okay, fixed it, but to help others that may experience the same thing, how was it fixed?

[kevin_remy]

Okay, fixed it, but to help others that may experience the same thing, how was it fixed?

It will work if I did not add these codes to my stylesheet.css

[kevin_remy]

Okay, fixed it, but to help others that may experience the same thing, how was it fixed?

Can you help me with my metatags problem?

[davewest]

Can you help me with my metatags problem?

Same as post 159, was answered in post 160..

[mc12345678]

That was one line that never made sense to me!

In the $_POST line 39

$testimonials_id = zen_db_prepare_input($_POST['testimonials_id']);

I could not find it in the template form anywhere!

Then in line 93

 $testimonials_id = zen_db_insert_id();

I can understand why we would get it from the database, just not sure why now! The function is not used anywhere else!

I've commented it out and did away with the function without any issues for some years now..

Just wondering why its in the POSTing side of the form. The Function exists in Admin and works there... Also thinking maybe there was some mixing of the admin code with the catalog side!

While not entirely sure of to where you are referring with this, but found "similar" code in the admin file. The way it is used there is to allow putting a testimonial id in the uri by using the bID parameter. When that gets used, data is posted into the form to then when submitted is available for further use/updating. The second, well, ideally such a database insert collection should be performed as close to after the insert as possible to prevent some other database insertion "losing" the record. This is more of an "issue" in newer ZC versions with software that has adopted the use of logging an action because that logging inserts a record though it is not "obvious" by the line of code to do so. :)

So, if you don't use something like ?bID=24 in the uri, the testimonials_id won't be "hidden" on the form and the $_POSTed data won't be fed back to the code.


That clarify things a little?

[davewest]

So, if you don't use something like ?bID=24 in the uri, the testimonials_id won't be "hidden" on the form and the $_POSTed data won't be fed back to the code.

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.

[mc12345678]

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

      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:

      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.

[davewest]

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.

We are on two different paths for sure, admin is not the problem at all...

The issue was with the catalog side where the testimonial is created by the user! includes/modules/pages/testimonial_add/header_php.php line 29 is posting from the sent form. However, its not getting inserted and no id getting sent from the form, so it would be blink all the time anyway.

Its just an open door that for me was closed without any problems.