[Assigné] Toolset forms not expiring posts

[Auteur]

Publications

[smileBeda]

Tell us what you are trying to do?
Test if Toolset Forms is expiring posts

Is there any documentation that you are following?
No

Is there a similar example that we can see?
There have been many reports of this in past, it seems either still an issue, or perhaps a misunderstanding of how it works

What is the link to your site?
Please enable private form for log in

[Minesh]

Hello. Thank you for contacting the Toolset support.

That is really strange.

Can you please share problem URL as well as admin access details and what posts are not expiring.

*** Please make a FULL BACKUP of your database and website.***
I would also eventually need to request temporary access (WP-Admin and FTP) to your site. Preferably to a test site where the problem has been replicated if possible in order to be of better help and check if some configurations might need to be changed.

I have set the next reply to private which means only you and I have access to it.

[Minesh]

Hi Beda,

When I checked the CRON listing page that controls all cron:
- lien caché

I see there is a notice:

The DISABLE_WP_CRON constant is set to true. WP-Cron spawning is disabled.

Is this related to your issue?

[smileBeda]

No, because the CRON control screen has "run now" features, so, even if CRON is disabled, it can run the hooked functions.

That's how I do it on many other websites - as long as you "run now", it does not matter if CRON is disabled.
Of course, naturally the normal process of the CRON is hooked off, meaning you _have_ to click "run now" to trigger the hooked code.

[Minesh]

Hi Beda,

May I know what timezone you are in and using what timezone you created the following post:
- lien caché

For instance, when I tested with my localhost, I set WordPress timezone to UTC+0.
(Please remember my timezone is UTC+5:30)

The form that creates the post - I set the post expiration setting to expirt post in 1 minute after submission of the form and change the post status to "draft" as you can see with the following screenshot.
- lien caché

I've added the following code to theme's functions.php file:

add_filter ('cred_post_expiration_cron_schedules', 'func_cron_one_minute_schedule', 10,1);
function func_cron_one_minute_schedule ($schedules) {
  
     $schedules['every1minute'] = array( 'interval' => 1 * MINUTE_IN_SECONDS, 'display' => __( 'Every 1 minute' ) );
    $schedules['every2minute'] = array( 'interval' => 2 * MINUTE_IN_SECONDS, 'display' => __( 'Every 2 minute' ) );
    return $schedules;
}

And from the Toolset => Settings I've set the post expiratioin cron setting to run "Every 2 minute".

So, basically, with the form when new post will be created,the post expiration date set is 1 minute after the post submission and change the post status to "draft" and I set the CRON to run every 2 minuets.

I created the post using form and I can not see post expiration works as expected.

But when I change the WordPress timezone to UTC+5:30 from Seetings => General and then edit the post I've created using form and enable the post expirataion and set the post expiration date to 14th May at 18:00 (6 PM) - and when I refresht the page after 2-5 minutues the post status does changed to "draft".

It seems - you need to adjust the post-expiration timestamp we stored with correct timezone if I'm not wrong.

[smileBeda]

Hi Minesh

I cannot change that website's timezone. My own timezone is UTC-3, their timezone is UTC-0 and their clients might be who knows from UTC+7 or -7

The point is that the post I created as testing did not expire neither minutes after MY timezone nor UTC-0's timezone timeout passed.
Moreover, now that over three days passed, it should have expired no matter in what timezone we are thinking, since there are exactly only 24 of those worldwide, so we could expect a maximum of 24 hours delay on the most extreme case.
Yet, the post simply does not expire.

From your testing, it results that the WP site UTC must be _identical_ to the user's timezone who creates the post?
Then the feature is broken, because we cannot expect a user to be in the site's timezone all the time.

I did not test the feature on a brand-new install. I tested on that staging site without custom code/non-essential plugins (which involve WooCommerce!), so maybe the issue is buried in that additionally?