[Resolved] Start date and expiration date to the front end
This thread is resolved. Here is a description of the problem and solution.
Problem:
A Toolset Form is used to submit posts, and contains fields for start-date and end-date which should be used to automatically set the published status of the post.
Solution:
Toolset includes a feature to expire posts after a certain interval, but not to "enable" them.
You will first want to enable post expiration on Toolset Forms at Toolset > Settings > Forms.
Then on an individual form you can set a default interval such as "posts expire 60 days from now" then that will be applied to all posts submitted with the form.
Once such posts are submitted, if you edit the posts in the backend you will see when the post is due to expire, and you can update it from the post edit screen when you save the post.
The expiry date is stored as a UNIX timestamp in wp_postmeta for the post, with the key "_cred_post_expiration_time".
So you have your end-date field in the form. You can add a code snippet triggered by the cred_save_data hook which updates the _cred_post_expiration_time post meta according to what was chosen in the form.
An example of such code is given in the thread.
This support ticket is created 6 years, 5 months ago. There's a good chance that you are reading advice that it now obsolete.
This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
I am currently working on a project where the user (subscriber) can place posts.
He posts these posts through a post form (Toolset forms).
The challenge is the following:
The posts (ads) have a start date + time and an end date + time.
This must determine the subscriber itself, it must be able to set the start date + time & end date + time on the front end.
When the end date + time has expired, the post (ad) will automatically deleted.
Then on an individual form you can set a default interval such as "posts expire 60 days from now" then that will be applied to all posts submitted with the form.
Once such posts are submitted, if you edit the posts in the backend you will see when the post is due to expire, and you can update it from the post edit screen when you save the post.
The expiry date is stored as a UNIX timestamp in wp_postmeta for the post, with the key "_cred_post_expiration_time".
So you have your end-date field in the form. You can add a code snippet triggered by the cred_save_data hook which updates the _cred_post_expiration_time post meta according to what was chosen in the form.
Is that something you can do? If you get stuck let me know.
I have had to read your message several times but to be honest it seems very complicated.
I do not fully understand the process.
Just to be sure: Once this is done, the user (subscriber) can decide when a post will be placed and when the message expires?
The user (subscriber) sets this on the front end?
I have a feeling that I am going to have some trouble getting this done,
Is there a possibility to get this clearer? or can you possibly help me?
Toolset Forms support post expiration, but there is no equivalent support for "post activation". You can set a date when the post expires with this method, but you would need another solution if you want users to submit posts and only have those posts become visible after some period.
For the expiration:
1 - you need to go to Toolset > Settings > Forms and enable the expiration functionality
2 - your Form settings need to set a default expiration time (e.g. 10 days from when the post is submitted)
3 - you need to include a custom field in the form that specifies the number of days after which the post should expire
4 - copy the following code into your theme's functions.php file (or using a plugin such as Code Snippets). You will need to edit the form ID and the field slug (note that Types adds a 'wpcf-' prefix to the slugs).
/**
* Set custom expiry date based on form field
*/
function tssupp_custom_expiry( $post_id, $form_data ){
$expires_field = 'wpcf-self-destruct';
if ( 6 == $form_data['id'] ) { // Edit form ID
if ( isset( $_POST[ $expires_field ] ) {
$expires = $_POST[ $expires_field ];
$new_expiration = time() + $expires * 24 * 60 * 60;
update_post_meta( $post_id, '_cred_post_expiration_time', $new_expiration );
}
}
}
add_action( 'cred_save_data', 'tssupp_custom_expiry', 10, 2 );
The workflow would then be that a user submits this form. If they do not set a value for the expiration length then the default from the form settings is used, but if they do the default is overwritten with the new value (which you can verify by editing the submitting post on the back end where you will see the post expiration date/time).
Note that this assumes the field in the form specifies how many days before the post expires. You could modify the above so that the user specifies an actual date and time, for example.
You write that there must be a custom field with the number of days, but the user must specify a date and time (Time is certainly important). I had thought to use the date / time selection.
On the change post page is also the same date / time selection so that the user can change the post. .
The details:
Form ID for creating post: 349
Form ID for changing post: 885
Custom field (type date/time) fieldslug: einddatum-en-tijd-aanbieding
Have added the code below in functions.php, but it does not work (:
/**
* Set custom expiry date based on form field
*/
function tssupp_custom_expiry( $post_id, $form_data ){
$expires_field = 'wpcf-self-destruct';
if ( 6 == $form_data['id']==349,885 ) {
if ( isset( $_POST[ $expires_field ] ) {
$expires = $_POST[ $expires_field ];
$new_expiration = time() + $expires * 24 * 60 * 60;
update_post_meta( $post_id, '_cred_post_expiration_time', $einddatum-en-tijd-aanbieding );
}
}
}
add_action( 'cred_save_data', 'tssupp_custom_expiry', 10, 2 );
I've edited it so that it works with either your publish or edit forms, and it expects a custom field with the date/time (slug einddatum-en-tijd-aanbieding).
/**
* Set custom expiry date based on form field
*/
function tssupp_custom_expiry( $post_id, $form_data ){
$expires_field = 'wpcf-einddatum-en-tijd-aanbieding';
if ( in_array( $form_data['id'], array( 349, 885 ) ) ) {
if ( isset( $_POST[ $expires_field ] ) ) {
$expires = $_POST[ $expires_field ];
update_post_meta( $post_id, '_cred_post_expiration_time', $expires );
}
}
}
add_action( 'cred_save_data', 'tssupp_custom_expiry', 10, 2 );
Hi, Nigel is out today and will return tomorrow to continue assisting you. Please provide login credentials in the private fields here, and he will have the information he needs when he returns.
I submitted a test post on your site to check whether the code to modify the post expiration date was working, and it was not.
But when I checked the functions.php file of your AgentPress Pro theme the code is not included.
Where—if anywhere—did you add the custom code?
While looking at your site and seeing the form, it occurs to me you can use WordPress's schedule post status for the start date of when an offer is valid. You could update the code I provided above like so to include the valid from functionality, like so:
There were a couple of minor things I noticed when reviewing the code which I've fixed.
I added the code to your site using the Code Snippets plugin and made a test post, the results of which you can see "Toolset test" that is set to be published in the future and has an expiry date which I set in the form.
After I received your message I was very curious 🙂
I have also posted a test post myself this afternoon, I had set the post on the date of today from 16:00 till 16:30.
I waited and waited, ooh so exciting, but the post was not published at 16:00.
I feel we are almost there, but what could it be? I have been searching the internet and I read that this could also have something to do with cronjobs. I do not want to mess it, so I even wait for your message.
WordPress will interpret and post that has a future post time as scheduled, and once that time has been reached it will be a normal published post.
To check that the above code is working you should edit the post in question on the backend and check the Publish details (see screenshot publish.png).
Check that the Scheduled time corresponds with what you are expecting.
As for the post expiration, this is a little more complex.
First, to check that the above code is working correctly, again edit the post in the backend and verify that the automatic post expiration date and time correspond to what you expect (screenshot expiration.png).
Both the screenshots are from the test post I made on your site, so it seems the code is working correctly.
The expiration date/time is not an exact time when the post will expire, though.
What happens is that a WordPress cron job will be run at intervals which you set in Toolset > Settings > Forms > Other, e.g. once hourly.
That will scan for posts which have expired since the cron job was last run and update their status accordingly. So if the scan happens hourly, a post could in theory still be published for 59 minutes after the expiry time.
And note that WordPress cron jobs only run whenever someone visits the site (front-end or back-end). So if no-one visits the site for 2 days, the "hourly" cron jobs won't run during this time. That's just how WordPress cron jobs work.
I just read the message, I tested yesterday with the post form (front end) and the change post form (front end) and this did not work. I did not test the backend. The users will place and change the ads via the front end.
Thanks for the explanation regarding the function cronjobs, the fact that the post does not disappear immediately is not that bad, because on the website it can be seen until when the post (offer) is valid.
The fact that it will be removed is already an improvement.
but.. setting a start date and time and end date and end time on the front end is something that is desirable. Users (our customers) may not come on the backend.
Those screenshots I shared were taken from the backend because that is where you can see the data (without looking directly in the database), but the post itself was created with the front-end form.
When I submitted the form with values for the start and end dates it worked (as shown by the screenshots subsequently taken in the backend).
Please make a test submission from the front end form and then edit the new post in the back end to verify the dates have been set correctly.