Vegard Skjefstad

Workaround by @tbyron doesn’t work for me, but I can confirm that Gutenberg 6.1.0 works with Jetpack 7.5.2 is deactivated. With both plugins activated, I get the same blank screen described above.

The Apache error log, and the php7.3-fpm.log show no clues as to what might be the problem (they log nothing when the blank screen appears).

@zigarrenzone You still get Gutenberg as editor even when the plugin is disabled, becasue an older version of Gutenberg is bundled with WordPress > 5.0.

Not really. I did a little bit of searching, but I couldn’t find anything with the same feature set as IP Geo Block. You might want to consider using WordFence or another, similar plugin instead. It won’t block logins, but it will prevent brute forcing.

If anyone has a similar problem to this, I finally solved it by installing php-curl, which was not installed on my server. Neither is it a mandatory php-module to get WordPress to work, so WordFence should perhaps consider showing a huge warning if php-curl is not installed ??

I never managed to solve this, and stopped using the plugin.

FYI; this issue is still present in version 3.0.17.4.

Give this a go:

<?php wp_days_ago_v3 (604800, 604800); ?>

PHP allows you to skip method parameters, but only from the right. This means that if you want to use the $showDateAfter parameter, you also have to use the $stopUsingAjaxAfter parameter. I’ve set this value to the same as the $showDateAfter.

A better solution would be if the plugin allowed you to configure these value independently. Perhaps something for the next version, if that ever happens.

I’m also getting this error, and it looks like a path problem. When Cache Delivery Mode is set to “Expert”, the plugin complains that it can’t write to the .htaccess file located at

/www/data/public_html/vegard.net.htaccess

Notice the missing /, the correct path is supposed to be

/www/data/public_html/vegard.net/.htaccess

The file is owned by the same user that is running the webserver, and it’s writable by that user.

Thanks a lot for your fast turnaround.

With the new code, the error message disappeared, and I was also able to log out and in again.

Good times!

Unfortunately, this is not possible without some rather big changes to the plugin’s code.

Thank you for bringing this to my attention. This issue has been fixed in version 3.2.1 of the plugin. Please upgrade to that version.

I’m not familiar with the ColorMag theme, so it’s hard for me to tell where the code should be placed. Look for any code that displays date and time information related to post and pages and replace that code.

An old version of the plugin showed both minutes and seconds, hours and minutes, and so on. Please update to the latest version on you mcx.freetips.tips website.

Sorry for the late reply. Different themes tend to place the date code in different files, so it’s hard to tell exactly where to put the wp_days_ago code in the particular theme you’re using.

I don’t have the theme files myself, but based on screenshot on the WordPress site, it should be somewhere under the heading code for each post.

What you describe isn’t possible with the current version of the plugin. But if you replace the wp_days_ago_v3 method in the wp_days_ago-core.php file, it should work – the first parameter is the id of the post or comment you want to use the plugin for.

Please note, however, that this code is completely untested (I don’t even know if it compiles), and it will be overwritten you update the plugin from the WordPress admin interface in the future.

function wp_days_ago_v3 ($theId = null, $stopUsingAjaxAfter = 0, $showDateAfter = -1, $showDateFormat = null, $showYesterday = true, $context = 1) {
	if ($theId == null) {
		$id = ($context === 3 ? get_comment_ID() : get_the_ID());
	} else {
		$id = $theId;
	}

	if ($context <= 1 || $context > 3) {
		$the_time = get_post_time("U", true, $id);
		$ajax_wait_time = get_post_time("H:i", false, $id);
	} else if ($context === 2) {
		$the_time = get_post_modified_time("U", true, $id);
		$ajax_wait_time = get_post_modified_time("H:i", false, $id);
	}  else if ($context === 3) {
		$the_time = get_comment_time("U", true, $id);
		$ajax_wait_time = get_comment_time("H:i", false, $id);
	}

	if(gmmktime() - $the_time > $stopUsingAjaxAfter) {
		echo wp_days_ago_internal_v3($the_time, $id, $showDateAfter, $showDateFormat, $showYesterday);
	} else {
		echo "<script type=\"text/javascript\"><!--\n";
		echo "jQuery(document).ready(function(){";
		echo "get_wp_days_ago_v3(" . $id . ", '" . $the_time . "', '" . $showDateAfter . "', '" . $showDateFormat . "', '" . $showYesterday . "', '" . $context . "');";
		echo "})\n";
		echo "--></script>\n";
		echo "<span class=\"wp_days_ago\" id=\"wp_days_ago-" . $context . "-" . $id . "\">" . $ajax_wait_time . "</span>";
	}
}

What you describe is possible, but only through a combination of editing the plugin’s code and using the $showDateAfter parameter when you call the plugin in your theme.

Assuming you’re using the most recent version of the plugin, version 3.2, in the file wp_days_ago-core.php, remove line #61:

$output .= get_the_time($showDateFormat, $postId);

Keep in mind that your changes will be overwritten the next time the plugin is updated.

Then use the $showDateAfter parameter with a value of 31536000 when you call the plugin to stop it from displaying anything. Normally, it would display the date something was published, but you removed that functionality from the code.