Listing expiration action always fails

[Miro]

Hello,

I have this annoying listing expiration issue as scheduled event hivepress/v1/events/hourly always fails.
I tried everything: disabled all plugins, increased php memory_limit to 2048M and execution time to 600 seconds etc.
Also I checked to have no more than 1-2 listings set to expire (expiration date before current date).
I found nothing relevant in debug.log or server logs.
I have WP-CRON disabled and run via cron job but I tried to run the event also with WP-CRON enabled and is still failing.
I exclude server related issues because the expiration works as expected on fresh install.
On the other hand expire_listing function works when executed manually and for the time being I set a cron job to run the expiration function.
However, I prefer to avoid unnecessary customisations and maybe this event failure hides some bigger issues I need to solve before continuing the project.

[andrii]

Hi,

Please clarify, did you test separately on a WordPress fresh site and everything works correctly? If so, can you specify after what changes this action stops working?

[Miro]

Hello, thank you for following up.
I tested the listing expiration feature on fresh WP install to eliminate issues related to server configuration.
However, scheduled event fails on my production site for a reason I am unable to identify by checking logs, disabling plugins etc.
On production site I am testing by deactivating/activating hivepress plugin and I can see that event hivepress/v1/events/hourly is started and fails after 300 seconds.
Please let me know if there are some known plugin conflicts I need to address or how can I spot the issue.
Thank you

[cotasson]

I concur (unfortunately) : setting an expiration date on listing has no effect.

[andrii]

Hi,

We tested this locally, and by default, up to 1 hour, this action is triggered and the listing gets the Draft status. Can you please clarify if you have made any additional customizations to change the Scheduled Actions? If so, please try disabling all third-party plugins and customizations and check if the issue persists.

[Miro]

Hello,
Thank you for following up, I believe testing expired listing worked because I implemented a workaround (a custom php script and cron job triggering listing_expire every hour).
However, listing expiration via scheduled action does not work and unfortunately I have same problem in another similar website.
Because trafic is lower I tested your solution in this second site doing the following:
-disabling ALL plugins except hivepress
-reverting to listing hive theme
-generating new .htaccess file
-changing all listing expiration dates in the future.
-increasing php memory to 4096M
-running database repair for all tables

The issue still persists, I believe that scheduled actions enters in some infinite loop because is now is running for hours.
It is true that my sites are not new, having some 6000 listings, many already expired.
What can be the reason of this issue?

[ihor]

Thanks for the details, we’ll re-test this again on 2 different servers, this way we’ll check if this is related to server- or WP-level settings or this depends on the number of listings.

[Miro]

Hello,

Thank you for following up, I was lucky to find the culprit by adding additional logging to functions clear_meta_cache and expire_listings fired by hivepress/v1/events/hourly hook.
Turned out that my post_meta table was clogged with hundreds of thousands expired transients (not detected by database maintenance plugins) making the processing of deleting expired transients to exhaust server resources.
After deleting all expired transients from database the listing are expired as expected by sending expired listing email to user.

All the best,

Ion

[cotasson]

Thank you for your feedback, but since I have a fresh install, and not so much content, your solution may not be suitable for me…

So basically, I created a new listing, and first set an expiration date to one day in the hivepress > settings for listings.
It still shows on my website.
It’s been like 4 days now…

[Miro]

Hello, try to check the behaviour of hivepress/v1/events/hourly hook in scheduled actions page. You can fire the hook by disabling/enabling the hivepress plugin. If execution fails at scheduled time then some error message will suggest the reason. Another usual suspect is WP_CRON, you can try to fire the hook by manually scheduling hivepress/v1/events/hourly using WP Crontrol plugin.

[cotasson]

Thank you @Miro .

As I set up the WP Crontrol plugin, I saw this interesting message :

The DISABLE_WP_CRON constant is set to true

So I checked in wp-config.php and there was this constant ! I don’t know if a plugin or my hosting platform set this up.
I simply reverted the value to false.

Added another listing, with expiry date set to 1 (day). Waited overnight.

Next day :

30 minutes later :

No error (failed), just reset.

The listing was still online.

So I “ran” the daily event, but the listing is still visible (even when disconnected).

[Miro]

Hi,

If DISABLE_WP_CRON constant is set to true then you must set a custom cron like this at server level: wget -q -O - You are being redirected... >/dev/null 2>&1. You can ask your hosting to check if this cron is scheduled or not.
You can also try to add hivepress/v1/events/hourly as a scheduled action using WP Crontrol plugin, it worked in my case.
Disclaimer: My advice is based on my own experience, I am not a trained IT professional or a member of Hivepress support staff.

All the best

[cotasson]

Hello @Miro,

Thank you again. It’s funny as two days ago I wrote a blog post about wp-cron on my blog (in french), and mentioned the fact that you can offload the triggering of these tasks to the server, instead of relying on the traffic.

Unfortunately, it is still not working for me.
So maybe the support team (@andrii, @ihor ? ) would be kind enough to point me towards the right direction ?

The hosting support team said they weren’t responsible for the DISABLE_WP_CRON set to true. So I set to false instead. No improvement.

Some cron tasks are triggered (like the wp smtp mail weekly summary, which I can disable and probably will). I even created my own event. it works.

At some point, I had about 50+ failed events, but deleted them altogether, to see if any more event would fail. None so far.

However listings due to expire yesterday (for debugging purposes) are still showing.

Any idea on how to find the culprit ?

The following code is triggered when I forced it (ran it manually) :

function my_cron_function() {
    error_log('Cron (daily hivepress) job executed at: ' . current_time('mysql'));
    // should I add some logic here to force the due listings to expire ? 
}
add_action('hivepress/v1/events/daily', 'my_cron_function');

It shows in the debug.log file. So the hivepress/v1/events/daily cron task seems to run (at least manually), but does not do anything to the expired listings (should change their status to draft, as I understand).

I am using Taskhive theme, I assume the expiry feature also work for this theme.
At least it is available in the Hivepress > Settings > Listings dashboard section.

Looking forward to hearing from you, guys !

[EDIT]

Here are the settings in /wp-admin/admin.php?page=hp_settings for listings :

(for debugging purposes, the listing should expire the next day).

I recreated a new listings (logged as vendor, not admin).
Then I went to check the expiry date set in the backend for this listing (therefore as admin) :

(–> May 4th, 2025, instead of tomorrow (Feb 4th), as set in the settings above.

This may look like the beginning of an explanation…

As you can see my backend language is set to English, but date shows in French format (DD/MM/YY instead of MM/DD/YY). Anyway, when I switch back to french, the same date shows, exactly the same (in french format and wording), only labels would switch to french.

Reason for which I set my backend in English, even though I am French, is that it is easier to speak the same language, take screenshot, or debug (based on error messages) in this ‘lingua franca’. To do this, I would go to Users > Profile > and set language to en-US.

Then I checked the date format under (WP) Settings > General :

Should I change anything here ?
But then dates in the front end (user/listing/request creation, last login…) would display in a funny way, instead of French format (which is my audience). Changing the language, the way I did, affects the backend only and for myself only (admin), as far as I know.

I don’t know if this is the beginning of a solution , but I thought I should mention this finding.

[/EDIT]

[EDIT2]
I went a little further and played around with the date format :

But the date in the listings still remains buggy (to me) :

I then even switched to m/d/Y, recreated a new listing, same problem : expiration date shows 04/05/2025 (or 05/04/2025 depending of the date format chosen).

[/EDIT2]

Please advise.

[ihor]

Thanks for sharing the solution! If these transients were related to HivePress, you can disable them just in case with this code snippet:

define('HP_CACHE', false);

[ihor]

We use Action Scheduler instead of the default WordPress scheduling API https://actionscheduler.org/ It’s a reliable solution developed and used by WooCommerce.

The date format shouldn’t affect the recurring jobs, I recommend disabling/enabling HivePress and if the action fails, it’s most likely because the database is overloaded, or there’s something on the hosting level.

Hope this helps

[cotasson]

Hello @ihor ,

Thank you for your answer. I can see you are working relentlessly too.
I scanned the hivepress plugin, and yes many occurrences of “action scheduler” uses.

As I mentioned previously, the cron itself seems not to be the reason for the expiration not happening.

It’s just the date being set is not reflecting what has been set in the HivePress settings. I don’t see the reason why.

The database is not overloaded, and the hosting is pretty reliable. I have been using them for various projects.

[ihor]

If you have some UI for the database, please check the hp_expired_time meta field in wp_postmeta table, this is where the timestamp of the expiration is stored. It doesn’t depend on the date format, the value itself is stored in seconds so it should be ok. If this helps with debugging, here’s where the expiration function is implemented hivepress/includes/components/class-listing.php at master · hivepress/hivepress · GitHub We plan to optimize it to expire listings in batches, currently if many listings expire at the same hour then the function may be slow or terminate depending on the max_execution_time setting.

[cotasson]

Hello !

After relentless search, countless debugging, trial and errors, and some head-banging, I may have found the reason :

I diligently followed the TaskHive tutorial on Udemy (same as the one of YouTube).
like adding a premium package, limited to 3 products and 90 days (3 months), about 2 months ago, and totally forgot about it.

Problem is, there is another setting under hivepress > settings > listings, which I wanted to experiment more recently. In there I set this (for debugging purposes) :

So why is there two different locations to set expiration date ?
What is the difference and which one takes precedence ? (Apparently the one under package).

Insights welcome and necessary.

[ihor]

This option exists in Paid Listings extension only, it’s used to offer different expiration periods depending on the purchased package. For example, free listings use the default settings in HivePress/Settings/Listings/Expiration, but if the package is purchased, it can have its own settings (e.g. free listings can be published 1 week, while those added via a package 1 month). But the main setting that defines the actual expiration (checked by the recurring job) is per-listing (the date set when you edit a listing, it’s just set automatically on listing creation based on those settings with the number of days).

[cotasson]

Thank you @ihor for your reply.

I eventually got it. I learnt it at my own expenses.
But this is definitely misleading.
As a suggested improvement, general hivepress settings (Hivepress > Settings > Listings) regarding expiration date should be disabled when Paid Listings is enabled.

Some extensions add their own settings to these hivepress settings tabs.
And I appreciate they are all to be found in a central and logical way.

But it some cases, it makes the “legacy” (native) settings useless, and therefore confusing, like here. At least it should be documented.

My two cents.