Unable to update post_meta (expiry date)

Hi @alireyad,

I’m pretty sure my code is correct; below is an example of what I am trying to do. As you can see I have another elseif section using virtually identical conditions (just a different entry in the same custom field of the listing form, _field_483) to change a listing to Never Expires, so I don’t think it is the conditionals, and having examined both the database and now your example code, I think the date format is correct. I tried both +3 months and +90 days in the strtotime, but it still didn’t work, so is that line of code the issue do you think? Have I made a syntax error? That is the only real difference between them, but how else can I achieve it? I am using save_post_rtcl_listing to trigger the function but I don’t think that is the problem as the other parts of the function are executing (it is a much longer function than shown here). Anything you can suggest is wrong?

$author = $post->post_author;
$user = new WP_User( $author );
if ($post->ad_type == 'swap'){
  $duration = $post->_field_483;
    if ($duration == 'standard'){
	    	return;
	   	 	}
//NOT WORKING
    elseif ($duration == 'long') {
	$current_expiry = $post->expiry_date;
	$expiry = date('Y-m-d H:i:s', strtotime('+90 days', strtotime($current_expiry)) );  
      update_post_meta ($id, 'expiry_date', $expiry );
	    	}
//WORKING
    elseif ($duration == 'indefinite') {
	if ( ! empty( $user->roles ) && is_array( $user->roles ) && in_array( 'lifetime', $user->roles ) ) {				
       update_post_meta ($id, 'never_expires', 1 );
    			}

Hi @alireyad,
I have been working night and day trying to resolve this and my functions have gone through multiple edits and additions to try to get this working, but after all my testing it seems apparent that the problem is actually accessing the necessary post meta data immediately as the listing is submitted, combined with the fact that if they are Pending rather than Publish, there is no expiry_date meta data available at all. Every combination I have tried fails because it can’t get the meta data before the listing is output to the page, with any of the available WordPress hooks. Is there a custom hook from the plugin that would allow meta data to be altered before the listing is output to the site? In other words after the ‘Thank you for submitting..’ message at the bottom of the listing form, but before the listing is displayed when it is a new listing that is being published immediately; I suspect my existing code might work for pending listings that are published later (although there may still be the problem of accessing the expiry date in meta data) but I haven’t had a chance to test that yet, as I am focused on paying members who get their listings published immediately. Just some further info, I have tested when the meta data becomes available as best I can using shortcodes, and it seems that it is available immediately the listing gets output, but as we are talking microseconds it might be just before, but I don’t know how to test this exactly. Any help or information you can offer would be gratefully received.

Hi @alireyad,

Can you tell me where the hooks that run after submit listing form are documented please? I couldn’t find anything on your website. The Hooks section is completely empty (https://www.radiustheme.com/docs/developer-docs/action-hooks/).

With regard to the expiry date not being available, this is only when the listing is Pending; once it is Published it appears in the post meta database, but the problem I am having is that I am running a function to publish listings of certain member levels within certain ad types as soon as they are submitted and none of the wordpress hooks can access it until after the listing has been output to the page. What you suggest is exactly what I have been trying to do, but the adjustment made is dependent on several bits of data that are in the post meta, that I can’t get access to! Notably the ad type and the expiry date. All I need is a hook that runs after the submission but before output to the page that provides either the user id, the post id or the post object and after the post meta has been updated.

• This reply was modified 1 year, 1 month ago by AWOL.

Hi @alireyad,

Thank you for that. I have replaced the hook I was last using with that hook and adjusted my function accordingly, but the listing is still created without the changes I want to the expiry date. Can you just confirm that the following is correct for the four variables the hook has:
$listing is the equivalent of $post (i.e. it is the post object)
$type is either new or update
$category_id is the category id
$new_listing_status is either publish, pending, draft or expired

If the above is correct, then that hook is also not able to update the expiry date meta data that my function depends on because it is also occurring before the original default expiry date has been written to the database. I think the problem lies in when this data is being saved. I have tried changing the priority of the function being triggered to 999 but this made no difference either. I now suspect there isn’t a hook that can do what I want.

If there is no hook that can do this then I will have to either rethink what I want to offer to the different membership levels or code this to occur after the listing is output, neither of which is ideal as both options have significant drawbacks; the first would make it less appealing to buy a membership, while the second would lead to confusion and complaints when members see their listing published initially without the promised longer expiry, even though it would be updated afterwards.

As an alternative, is there any way to hook into when the default expiry date is set/retrieved, or if absolutely necessary alter the file in the core plugin that deals with this, so I can set the conditions to alter the default when necessary? Which file, or files, handle this? What I want is a default expiry of 15 days (obviously built in to the plugin settings), with an additional choice for paying members for some ad types of either a long expiry (for example 90 days) or indefinite expiry (to the end of their membership plan, which in my site is either 1 year or forever; the forever part I have already managed to code by simply adding the same new meta data entry as the plugin does when the Never Expires checkbox on the edit listing page is checked). Please bear in mind I am not using the membership capabilities of your plugin but a separate membership plugin (Simple Membership) because I have another site that I need to connect the memberships to the one I am using your plugin on.

I should add that I tested this before today’s update to the plugin, so if that changes anything connected to this (I checked what has been altered and I don’t think it does) I will update here.

Hi @alireyad,
My customisations only extend to the templates that your own docs and support suggest, along with functions I have written to carry out certain checks in a child theme functions file – I have not made edits to core files. I already debugged and discovered what I have noted about when the expiry date is actually being saved to the database being the problem with regard to every hook I have tried, including the one you suggested. Can you at least confirm that the variables sent by the hook you referenced are what I think they are please? And let me know if there is any way to hook into the default expiry setting? I only gave the other info to help you understand what I am trying to do and why not being able to hook into the moment before output to page is a problem. If your documentation was a little better I would not need to be bothering you with all this. I can create a ticket on your site but I don’t really want to repeat everything, plus there may be other users of the plugin that would like to know the same things I do. If there are plans to add these sorts of functionalities to the Pro version then please say so, as I would understand a reluctance to harm your business, otherwise I don’t see the harm in answering here for everybody to see? It is a constant irritation for me in the support forums when potential solutions get hidden by requests for private tickets on the plugin author’s site rather than for everyone to see, and I don’t think I am the only one that feels this way.