Gravity Forms: Update Custom Posts From The Front End With Revision Updates.

Have you ever wanted to update a post, inside of WordPress, from the front end? Great. We found a way to do that with Gravity Forms. Do you have post revisions enabled on your posts? Awesome. Well the problem that we had was allowing a post or custom post type to be updated from the front end of a WP site, and create a new revision for that post in the back end.

Recently GeekStreetWP.com has been building a brand new Processing Submission Que Line for one of our clients, Valley West Mortgage. This is a very new concept that does not yet exist, according to our research, in the WordPress Community or in the Mortgage Industry. Valley West Mortgage contacted us and asked us to build a DMV like system that allows their employees to see an overview of all of their files and to assign submissions to an employee. After many hours of research, we came up with a pretty rad concept.

The Concept

The concept is to use a custom post type (CPT) and put all of the submissions into that CPT. Then we use taxonomies to assign a submission to an individual person or an individual Que line. We modified a template to query those submissions and then display them in a que line per person. And then we order the submissions in the query by their last modified date. It’s tricky, but we figured it out.

We took a Bootstrap Theme (WP-Bootstrap) and made some css styling changes. We created a custom post type with 5 custom taxonomies. We then used Advanced Custom Fields and Advanced Custom Fields Pro to add custom fields to the custom post type. Once the fields were created, we updated the theme to show the fields. Our geeks then made more changes to the theme to build custom templates. These templates include an overview screen that is placed on a large T.V. inside the company. We also built a template for individual employees. This template shows active and in-active submissions for an individual’s Que line.

So here’s what the site looks like

For the purpose of writing this article, all submissions and Valley West Mortgage employee names have been made up. The end result is still the same. This is what the overall view looks like for the large T.V. inside the company. This way all loan officers and employees can see the status of their loan and in what order it is in the Que line. This page only shows 3 individual Que lines, and only their active pipeline. Meaning that these submissions are ready to be worked on. When a submission is added to a Que line, it moves to the bottom of a persons Que Line. This is based on the Modified Date inside of WordPress. Also known as the most recent revision date. We’re also using a plugin that allows us to refresh the page every 30 seconds. This way a user can see when their submissions are moved or when a submission is assigned to them.
Valley West Mortgage Submission Que Line

An individual que line looks like this. It’s a custom template to query posts in the submission CPT based on a taxonomy. We created three (3) taxonomies for this. A Processor, a L.O.C. and an In-Active taxonomy. So on an individual Que Line, you can see the active Submissions in green and the In-Active in red. If a person wants to move an In-Active submission into their active submission Que Line, they would just un-check if from their In-Active and check it into the Active Que Line. We’ll cover how to do that in a bit. For now, here is what an individual Que Line looks like.
single que line
So far this is all pretty simple.

Now that we know what the overview’s look like, let’s go into the single-submissions.php template and take a look at that. A user would click on View Submission, and it takes them to the single-submission.php template. Here you can see the name of the borrower, all of the custom fields and a Gravity Form to update the post (submission). The gravity form is simply created inside of WP the usual way. Here is the view of the single-submission.php template.
single-submission-php
The gravity form is located in the_content(); section of the post. So you can see we modified the template in order to show the custom fields first, and then the content second. Like we mentioned earlier, a user can update the post, change who the L.O.C. is and un-check / check a submission into another Que Line.

Here is where our problem came in.

Originally we were just having all of their users log into wp-admin to update a submission. When a user updated the submission, a revision of that submission was created. That enabled us to query the posts and show the latest updated submission all the way at the bottom of a Que Line. The theory here is that when a submission is updated, it’s now waiting on something before it can be updated again. So the submission goes to the bottom, and a user now knows the next submission to work on. Pretty cool huh?

The first problem that we had was that some users forgot how to log into wp-admin, since we are hiding the wp-admin bar from the top of the site. The second problem was that users were clicking on things they were not supposed to. Like the settings and appearances. So we decided to create a form to allow the users to update submissions from the front end. Since we’re already using Advanced Custom Fields Pro, we decided to use the Advanced Custom Fields: ACF-Forms function. It’s pretty simple to use and embed into a template.

A Big Problem

The problem was that when a user updated a post, ACF-Forms was not creating a new revision in the back end of WordPress. So instead of ordering all of the submissions by the modified date, all of the submissions were being sorted by origination date, or when the submission was created inside of WordPress. Even if a user updated a submission, it could theoretically move right up to the top of their list.

So after many hours of research and contacting the developers of Advanced Custom Fields, we decided that the ACF-Forms were not going to work for us. So we started looking into how to update a custom post type by using gravity forms. We ended up discovering a plugin called Gravity Forms: Post Updates. All we had to do now consisted of adding a form into the content area of a submission and adding update to the form. Something like this.

gravityform id="1" update

.

A Second Problem

When we went into the backend and added the gravity form, the update form on the front end showed up. After a user updated a submission and viewed the submission again, the form was no where to be found. It’s because you need to have the gravity form shortcode in the content area every time. So there lies our second problem. After some searches, we found out that you can set a default value into the BODY of the gravity form. So now, every single time, the form will show up. We simply added a class to the body field in the gravity form and set it’s visibility to hidden. It looks like this.

gravityform-shortcode
So you can see that now every time a submission is updated, the gravity form is added back into the content (Body) section of the post in the back end.

Side Note: When a users updates a submission, the form redirects them to a page that says congratulations, your post is updated. We didn’t want to use ajax to update the form.

Not out of the clear yet.

So now that we used a plugin that allowed us to embed a update-able gravity form into a submission ever time, we had one last thing to do. On the front end of the site, we have another gravity form that allows a user to add a new submission into the pipeline and assign it to a persons Que Line. When a new submission was created, the update form was not added. So we had to, once again, go into that specific gravity form and set the default value of the body to that gravity form short code. Now, every time a new submission is created, the update gravity form is added to the body and the update form shows on the post.

That was simple right?

Now that we figured out how to get a gravity form into a new submission we had one last thing to do. We had to go into every single submission, in the back end of WordPress, and add that shortcode into the body. There were 250 submissions. Not all of them are being used, but just in case an already closed loan submission needed to be updated, we had to include it. So we updated all 250 submissions and the system is working flawlessly!

In Conslusion

All of our work is always done on development servers. That way the live site keeps working and we can break things until they are perfected! We always make a back up as well.