cvc1968

I am using the WooCommerce Stripe payment plugin, which is currently in test mode. I switched to live mode and it works perfectly. Thank you.

For anyone who needs a quick temporary workaround, add this to functions.php:

add_action('admin_footer','temp_expiration_workaround');

function temp_expiration_workaround() {
	$post_id = get_the_ID();
	$expiration = get_post_meta($post_id,'_expiration-date',true);
	$year = date("Y", $expiration);	
	?>	
	<script type="text/javascript">
		jQuery(document).ready(function($){
			$('#expirationdate_year').val('<?php echo $year; ?>');
		});
	</script>
	<?php
	
}

This just updates the year select so that when you update the post, and the postmeta gets rewritten to the database, the year remains what is was at load.

I believe I have found the issue. I tested this on the Twenty Twenty-One theme with no other plugins active.

The year dropdown in the Post Expirator metabox is not updating to the correct year (as stored in the database) and is instead falling back to the first option, which is always the current year, so if you then do any other update, it changes your expiration date in the database to the current year.

I verified that when you change the date, setting the selects and text inputs to, say, 2024 June 16 @ 12:19 and update, the _expiration-date for that post in the postmeta table correctly becomes 1718554740. If I reload the post edit page, the post expirator form now reads 2021 June 16 @ 12:19, which is what gets saved to the _expiration-date postmeta field as 1623860340 if I update the post.

The month and hour selects work correctly. It is only the year select that is not updating to the value from the database.

Sorry this reply was posted in the wrong thread. Please see This Thread

• This reply was modified 3 years, 9 months ago by cvc1968.
• This reply was modified 3 years, 9 months ago by cvc1968. Reason: Posted in wrong thread

I think this may be the issue I am seeing as well. We’ve tracked a number of posts that have expired exactly one year early. We do update expiration dates for these posts (which are paid business listings) on an annual basis, so it is likely that the posts that expired had renewed and had their expiration date updated.

Over this past weekend, a listing that had an expiration date of May 5, 2022 was expired on May 5, 2021. I have verified that the value in the postmeta table for ‘_expiration-date’ both before and after May 5, 2021 was ‘1651769880’, which is correct for May 5, 2022. I do not have database backups that go back a year, but the post_date on this listing was in May 2018, so it has definitely had its expiration date modified on at least one occasion.

I’ve been unable to get the debug logs to work, but I started a different thread for that.

If there is any further information I can provide to assist you, please let me know.

Thanks

Yes, it was the #poststuff h2 that was the issue. Thanks.

I just sent you an email with a detailed description and fix for a bug I found in the code that may or may not have been the cause of this error. Fixing that bug and re-installing Wordfence with default settings has, for now, resolved my issue.

Update: I found the issue. I was testing using 0.01 as the amount. Apparently you have to use at least .50 for payment intent.

I did a fresh install of the site and the plugin and it is now working. Must have been a permission error on one of the folder.

Thanks.

After reading the referenced article, I have copied the entire skins folder to:

/wp-content/themes/my_theme/modern-events-calendar-lite/app/skins/

And I’ve flushed the browser cache and there is no cache plugin on the site. Also, re-saved permalinks as suggested in another post.

Still not displaying my changes.

I’m also having this issue.

Specifically, I copied the entire skins folder to:

/wp-content/themes/my_theme/modern-events-calendar-lite/app/skins/

And none of my modifications to any of the skins are displaying.

Beautiful.

I’m not entirely clear on the usage of the helper function, particularly the $value = false.

So… if I wanted to conditionally include a field, it would be something like this(?):

function mail_content( $content, $email, $form, $fields ) {
      $content = ''; // to clear the default content
      $show_company = af_get_field( 'show_company' ); // a True/False field
      $company = af_get_field( 'company' );
      if ( $show_company && $company !== '' ) {
         $content .= "Company: " . _af_render_field_include( 'company', $value = true);
      }
}

Or use the $fields variable perhaps this?:

function mail_content( $content, $email, $form, $fields ) {
      $content = ''; // to clear the default content
      $show_company = $fields['show_company']; // a True/False field
      $company = $fields['company'];
      if ( $show_company && $company !== '' ) {
         $content .= "Company: " . _af_render_field_include( 'company', $value = true);
      }
}

(I’m never sure when to use $var[‘val’] vs $var->val)

I see this is marked as resolved, but I don’t see how.

I, too am having this problem, but in my case it gets to 810 posts before stopping.

I’m eagerly waiting to see if the logs that @koskow provided offer any solutions.

bcworkz,

As long as the page slug is unambiguous, WP will automatically do a 301 redirect from the old permalink when the hierarchy changes.

You’ve taught me something new. I had no idea this was the case. I’ve tested and confirmed this on the site in question, so my problem is solved.

As for non-pretty permalinks, I considered that but could find no documentation or examples on how to force the wplink tinymce plugin to use non-pretty permalinks or any other method for accomplishing this. I have however, found some examples of replacing wplink with a custom version of same, so I might consider that.

The other question I have about non-pretty permalinks is how would it affect SEO?

Anyway, thanks for saving me a ton of time.

Great.
Thanks.

Carl