Skip Navigation

[Resolved] Datepicker not filtering correctly

This support ticket is created 3 years, 3 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.

Sun Mon Tue Wed Thu Fri Sat
- 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 -
- 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 -

Supporter timezone: Asia/Karachi (GMT+05:00)

This topic contains 8 replies, has 2 voices.

Last updated by Waqar 3 years, 2 months ago.

Assisted by: Waqar.

Author
Posts
#1901551

Tell us what you are trying to do?
I am trying to filter the child posts displayed according to the date in the custom field. Some of the child posts connected are generated with information from an API using a unix timestamp to populate the date field. However some situations will require for us to manually create the child posts. I've manually created 7 child posts from 1/9-1/11. It is incorrectly displaying the child posts for those manually created.

Is there any documentation that you are following?

https://toolset.com/forums/topic/datepicker-not-filtering/
This exact code is being used. It correctly filters the child posts that are automatically generated but incorrectly filters the manually created child posts.

Is there a similar example that we can see?
What is the link to your site?

#1901927

Waqar
Supporter

Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

Hi,

Thank you for contacting us and I'd be happy to assist.

The date filters and the custom code from the other thread, rely on the custom field value of the dates to be in the Unix timestamp format. When the date is filled using Toolset Types' date/time type custom field, it also stores the values in Unix timestamp format.

If the manually entered posts are not getting filtered correctly, the most likely cause could be that their dates are stored in a different format.

Can you please check the date custom fields values for those manually created posts, to see the format? If the issue still persists, you're welcome to share temporary admin login details along with the page where this view can be seen.
( please also include information about the posts that are manually created )

Note: Your next reply will be private and please make a complete backup copy, before sharing the access details.

regards,
Waqar

#1903927

Waqar
Supporter

Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

Thank you for sharing these details.

During troubleshooting, I noticed that the imported date fields do seem to be saved in UNIX timestamp, but the time part is not consistent.

When a date is saved through Toolset's date type field (manually and without specifying a particular time), it always stores the UNIX timestamp for the date at 12:00am (UTC).
( screenshot: hidden link )

For consistency, it is important that while importing those dates, you convert them to the UNIX timestamp equivalent to 12:00am (UTC) at that date.

I hope this helps.

#1904777

Thank you for that information.

I've done two imports of the automatically generated child posts: one in UTC and another in HST. Our server is set to UTC timezone. Child posts are published immediately when imported in HST timezone. Whereas child posts in UTC are scheduled to be published. Do you know why this is occurring? And what changes can I make to ensure that the UTC child post imports are published immediately?

What changes can I make to the datepicker code to have it apply the unix conversion to the automatically generated post types?

#1906429

Waqar
Supporter

Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

This import of external posts was a one-time thing or you'll be frequently importing new ones in the future as well?

#1906925

The import of external posts will occur every hour.

#1908801

Waqar
Supporter

Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

This means that you must be using some third-party plugin or custom code to periodically run the imports, automatically.

Can you please share some more information about the workflow related to this import?

You should be looking for these:

1. Ideally make sure that the imported date custom field data is coming in UNIX timestamp equivalent to 12:00am (UTC).

2. If for some reason that is not possible, you'll need to see if the import tool you're using allows you to get the IDs of the imported posts after the import through a hook/filter.

If you have those IDs, you can attach some custom code to cycle through those post's date custom fields and convert them to UNIX timestamp equivalent to 12:00am (UTC).

#1913679

The other plugin (JSON Content Importer Pro) will access an API and it will obtain information needed for the child posts (Hazard Products).

The 3rd party plugin will add new posts and delete previously generated child posts if they are the same, disconnecting the relation between parent (Major Hazard) and child (Hazard Products) every time the plugin runs.

Here's more information on the workflow for the import: hidden link

For each import, I am specifying a value in the shortcode for "key": "randomkeyhere" and that is what identifies the connected child post. I would need assistance in attaching a custom code to cycle through the posts' date field.

#1914725

Waqar
Supporter

Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

I've noticed that you're using a Cron job plugin to run the shortcode "jsoncontentimporterpro" from the import plugin, to periodically run the import.

You can execute another custom shortcode, which should be executed after every import, that can cycle through all the published posts in the target post type, gets the value of the target custom field, and convert it to the 12:00am (UTC) equivalent value.

For example:


add_shortcode('convert_date_fields', 'convert_date_fields_func');
function convert_date_fields_func($atts) {
	// extract shortcode attributes
	extract( shortcode_atts( array(
		'post_type' => '',
		'field_slug' => '',
	), $atts ) );

	// get all the pulished posts from the target post type
	$args = array(
		'post_type'        => $post_type,
		'posts_per_page'   => -1,
		'post_status'      => 'publish',
		);

	$posts_array = get_posts( $args );
	// cycle through all found posts
	foreach ($posts_array as $post) {
		// get the value from the target custom field
		$post_field_value = get_post_meta($post->ID, $field_slug, true);
		// if the value is not empty
		if(!empty($post_field_value)) {
			// convert the date value to the midnight time
			$post_field_value_midnight = date('F j, Y g:i a', strtotime('today', $post_field_value));
			// convert the new midnight time to Unix timestamp
			$post_field_value_U = date_format(date_create($post_field_value_midnight),"U");
			// update this new Unix timestamp value into the target custom field
			update_post_meta( $post->ID, $field_slug, $post_field_value_U, $post_field_value );
		}
	}
}

The above code snippet can be included through either Toolset's custom code feature ( ref: https://toolset.com/documentation/adding-custom-code/using-toolset-to-add-custom-code/ ) or through active theme's "functions.php" file.

This shortcode will need two attributes:

post_type: slug of the target post type
field_slug: slug/key of the target custom field

For example to cycle through all Posts and update the value of the custom field "wpcf-post-date", the shortcode would be:


[convert_date_fields post_type='post' field_slug='wpcf-post-date']

Note: The custom code examples from our forum are shared to get you started in the right direction. You're welcome to adjust them as needed and for more personalized customization assistance, you can consider hiring a professional from our list of recommended contractors:
https://toolset.com/contractors/

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.