I’m trying to find a way to append new data to an existing custom meta field.
My full stack on my site is: GenerateBlocks Pro, Advanced Custom Fields Pro, with GF. I use custom post types with various custom fields on a post. One CPT is called “Requests” which is where customers submit a request for custom art and they communicate back and forth with the artist until a final draft is approved on.
I’ve created a custom version of a log file, so to speak, for each post in the CPT. This “log file” is just a custom field called “request_history”. It keeps track of all actions performed by the customer and artist and then displays it, with formatting. Kind of like the “Activity” tab in Fiverr, if you’re familiar with that. It’s updated using a third-party plugin that allows for current posts to update their meta fields.
Here’s the challenge:
There’s no built-in way to append data to an existing custom field in GF. So in order to add a new entry to this meta field, in the form that the artist or customer uses the current contents of the “request_history” field is loaded into the form using a merge tag on a hidden field. Then the new log entry is set to display after the merge tag data. This allows that meta field to grow in length, and then I can just display the contents of that entire field in GenerateBlocks with its dynamic data feature.
But the problem is that on occasion 2 people may have forms loaded. 1 submits the form and so then the log file is updated with their action. But the 2nd person still has a populated merge tag of the request_history field BEFORE the 1st person submitted their change. So when the 2nd person submits the form, the log file is overwritten with old data and it doesn’t show the action taken by the 1st person.
What’s the solution? Is there some custom GF hook I can use so that the “request_history” meta field is loaded and then overwritten only upon form submission? This would prevent an older version of the data being used, if the form was loaded prior to another change. Or is there some other solution that’d work with my stack that doesn’t require using a single meta field or that doesn’t even use a custom field altogether?
Thank you in advance for any creative ideas you may have!
I’d look at passing instead the post ID into the hidden field – using merge tag {embed_post:ID} – ref: {embed_post} Merge Tag. You could then hook togform_after_submission in order to get and update the meta for that post.
My instinct here is to actually use something like our Entry Blocks plugin to simply show a list of the entry data that represents those requests. In this way, you don’t need to duplicate the data—the data is already captured and preserved in the submitted entry—and Entry Blocks will give you a ton of control for what and how that data is displayed in the context of your post.
You also get to totally bypass this order of events issue because Entry Blocks would simply show the “log” of requests (e.g. entries) in the order they were submitted.
Let me know if you have any questions on implementation.
@david We are actually a GF Wiz Pro customer so we’ve heard of Entry Blocks. I appreciate you taking your busy time to offer help!
If I’m understanding how GF Entry Blocks works, though, I don’t think that solution will be feasible in our setup as each “Request” post in the this CPT can have data modified through about 8 different forms, between the customer, employees, and managers. Although we could redesign it and use a single form that has ALL of the dozens of custom fields needed (even if blank initially), and in place of the other 7 forms we simply modify the existing fields that are present from the first form, this probably wouldn’t allow for the level of flexibility needed for user-facing processes for customers, such as allowing the customer to complete purchases later on the custom art uploaded to the “Request”. Purchases and communication is all stored in the Request CPT and tracked in the request_history field.
But for future functionality, how would modifying a GF entry using Entry Blocks allow a “log file” to display on the post page the changes made, who made them, and when? Wouldn’t Entry Blocks simply list the current data listed in those form fields and not list who changed it and what they changed it to?
Ah, busted. I better understand what you’re trying to achieve here. Given that the updates are coming from so many different forms, you’re right, Entry Blocks wouldn’t be a good fit and you’re probably on the right track with the storing the changes in post meta.
I think @uamv’s suggestion above is a good starting point. Let me know if you have any questions on implementation from there.
