12

Here are some options on how we can override the native layout for each comment: Approach #1 - Overriding start_el() with a custom walker Let's define our custom wpse comment format: // Arguments for wp_list_comments() $args = [ 'style' => 'ol', 'format' => 'html5', 'short_ping' => true, ]; // Use our custom walker if it'...


6

Edit: wp_next_scheduled() returns the timestamp of the next scheduled job of a specified wp-cron job-arguments pair. Please note that this differs slightly in functionality to the answer below, in that you have to provide the arguments passed to cron job's callback (if it has any). The original answer would provide the time of the next specified job ...


5

You should use date_i18n(): $timestamp = get_post_meta($post_to_edit->ID, '_single_date', true); $friendly_date = date_i18n( get_option('date_format'), $timestamp ); ?><input value="<?= $friendly_date ?>" name="_single_date" />


4

General WordPress rule: when a function starts with get, it will return the value. If it starts with the, it echoes the value. Here, you need get_the_date('d-m-Y') instead of the_date('d-m-Y').


4

The issue is that for correct output WP needs to process date through date_i18n() function. When you use date format, hardcoded in PHP code (not simply saved in PHP DATE_* constant) like 'c' - it's not available to your code and so for WP to process. System-wide fix would be to re-process date with analogous format that can be accessed by WP code: ...


4

wp_cron operates on intervals and there is no interval that will hit exactly the first day and the 15th of every month. You could run your wp-cron job every day and check the date, similar to this but with a simple callback like: cron_callback_wpse_113675() { $date = date('d'); if ('01' == $date || '15' == $date) { // run your function } } Or, ...


4

This is not a WordPress question, but to help you out: function displaydate() { return date( 'd/m/Y G:i', strtotime( '-6 hours' ) ); } add_shortcode('date', 'displaydate'); The shortcode itself should work fine.


3

The output of current_time('timestamp') should be time() + ( get_option( 'gmt_offset' ) * HOUR_IN_SECONDS ); according to WP 3.5.2, so you should check your get_option( 'gmt_offset' ) settings. Also current_time('timestamp', 1 ) should give you time().


3

You should store the time as a unix time stamp then you can use human_time_diff to compare. echo human_time_diff( get_the_time('U'), current_time('timestamp') ); If the difference is more than 24 hours difference it will return the value in days.


3

The post_date is the post_date_gmt after the Timezone value (in Settings) has been applied. So, if you like, the reasoning is that there's a standard time for everybody, and then your own site's time depending on your Settings, so say you want to change that later, the standard time is always left untouched.


3

You can do: echo str_replace('mins', 'minutes', human_time_diff( get_the_time('U'), current_time('timestamp') ) . ' ago'); Update: The same using filter as suggested: add_filter('human_time_diff', 'new_human_time_diff', 10, 2); function new_human_time_diff($from, $to) { // remove filter to prevent the loop remove_filter('human_time_diff', '...


3

Just use the_date(), it has this as a built-in feature. See the dev docs for more info.


2

WordPress automatically sets the server's timezone in PHP to GMT. This is to make any date manipulations consistent - and if changed, can cause some errors. This means any native functions like date will interpret any date to be in the GMT (or UTC) format. Similarly the timezone for DateTime objects will be UTC. You should not really change this, as this ...


2

(Nevermind, follow the better answers above. Please do NOT edit this answer. It exists as a reference.) The Situation Most of the WordPress themes and plugins (especially ones by esteemed developers) use the c constant which outputs the timestamp in a format identical to this: 2012-06-14T10:32:11-00:00. For instance, <?php get_the_date( 'c' ) ?> ...


2

WordPress sets the php timezone to UTC for internal calculations. So at 4pm PST, date() will be producing a date that reads 10pm UTC. Hence the event is considered past. There are two ways to resolve this. (The preferred method) Store dates in the database in UTC. Handle all date calculations in UTC, and convert to the desired timezone on output (frontend ...


2

the_time() is for outputting the time at which a post was written, and gets this value from the global $post. I'm guessing you just want php's date()?


2

As @amit wrote, the submission should have a daily counter that saves the count for that user, in the wp_usermeta table. If you can run a cron job that runs daily, you can save the submission counter only. The daily cron can reset the counter on assigned time. But if you don't you should save the counter and the day also. $current_user = ...


2

You can get the post's creation date/time and compare it to the current date/time. global $post; $now = time(); // Current time in seconds since Epoch $post_created = strtotime( $post->post_date ); // post's creation date in seconds since Epoch, so we're comparing apples to apples $one_day_in_seconds = 24*60*60; if ( ( $now - $post_created ) < $...


2

What is the purpose of the timezone setting in the Admin -> Settings section? Since WordPress handles time zone on its own (separately from native PHP functionality) that is where the setting made and result is stored in options. Whenever anything that works with timezones needs to happen, the time zone setting is retrieved and used in calculations/output. ...


2

One: Purpose of the timezone setting in the Admin -> Settings section? Two: How is the time of the blog saved? To set your local time, use the wp-admin » Settings - Timezone. As a comment there is saying: "Choose a city in the same timezone as you." For each of the blogpost there are two fields in the database: post_date and post_date_gmt. So ...


2

It's a WP non-code programming thinking error. Under General Settings > Timezone It should be set to your own timezone.


2

As suggested, you can break down the date format in different parts. echo '<span class="date-day">' . get_the_date( 'd' ) . '</span>'; echo '<span class="date-month">' . get_the_date( 'M' ) . '</span>'; echo '<span class="date-year">' . get_the_date( 'Y' ) . '</span>'; Now each item have class associated with it, so you ...


2

To print relative time on posts automatically we can use get_the_date filter. We will check the time difference and print it in human readable form. // Relative date & time function wp_relative_date() { return human_time_diff( get_the_time('U'), current_time( 'timestamp' ) ) . ' ago'; } add_filter( 'get_the_date', 'wp_relative_date' ); // for posts ...


2

You can use 'B' as the format for the_date() and/or the_time() to generate Swatch Internet Time format. If you're modifying a theme, just find the references to the_date() and/or the_time() in the template files and change the value of the format parameter. If you're creating a plugin, you can hook into the get_the_date and/or get_the_time filters.


2

Old answer (based on misconception that you wanted a cache buster): You can use add_query_arg() which adds/replaces query arguments. <?php /** * Plugin Name: wpse_84670 * Version: 0.0.1 * Description: replace script/style version with time as a cache buster */ /** * replace script or stylesheet version with current time * @param string $url the source ...


2

Before Wordpress 4.1, you can show the date archive page titles with the following code: (Taken and slightly modified from the twentyfourteen theme) if ( is_day() ) { printf( __( 'Daily Archives: %s', 'twentyfourteen' ), get_the_date() ); } elseif ( is_month() ) { printf( __( 'Monthly Archives: %s', 'twentyfourteen' ), get_the_date( _x( 'F Y', '...


2

First things first, I suppose that your function already works - I did not debug it, but wanted to point you in the right direction of WordPress scheduling of events. You should use wp-cron for that. It let's you schedule events, and let them be handled by WordPress. Please keep in mind that this is not a real cronjob, and depends on your site being called....


2

If you check out the source of human_time_diff: if ( $diff < HOUR_IN_SECONDS ) { $mins = round( $diff / MINUTE_IN_SECONDS ); if ( $mins <= 1 ) $mins = 1; /* translators: min=minute */ $since = sprintf( _n( '%s min', '%s mins', $mins ), $mins ); } elseif ( $diff < DAY_IN_SECONDS && $diff >= HOUR_IN_SECONDS ) { $...


2

human_time_diff() only returns a single {number} {unit} string back. It rounds to nearest whole unit, instead of breaking down the difference precisely. To get an exact duration difference, you'll need to use your own function. As this is a popular need in PHP, there's lots of solutions online - here's a clever one I found: $t1 = "Jan 08 2018 07:45:14"; $...


2

If it is the example in the timezone settings you're referring to here: Then this is expected behaviour, and is correct by definition according to ISO standards, because this is not the time, it's a timestamp. This way there is no ambiguity about the time being referenced, and it's the only place in WordPress where a timestamp is used in the admin UI. As ...


Only top voted, non community-wiki answers of a minimum length are eligible