Jonathan Bossenger

@sacconi can I just confirm what I understand you want to do here.

1. You are storing a meta value on the author with the key pulizia_esc
2. You also want to store a meta value on the post with the key function_pulizia
3. Based on your description, they are all Euro values (eg amount in Euro)
4. You want to be able to output the total of pulizia_esc on the author and function_pulizia on the post and echo this in the div with class pulizia_esc

In that case, something like this should work:

$pulizia_esc = intval( get_the_author_meta( 'pulizia_esc', $post->post_author ) ) + intval( get_post_meta( $post->ID, "function_pulizia", true ) );
if ( $pulizia_esc !== 0 ) {
	$pulizia_esc = '<div class="pulizia_esc">' . $pulizia_esc . '</div>';
}

What this code does is convert the two meta values to integers using PHP intval function, and then add the two integers together using the +, to get the total.

Then the conditional checks if the value is not zero, and if it isn’t, performs the string concatenation using the . with the integer value. When you concatenate an integer to a string, PHP will convert the integer back to a string.

What I would suggest as a small improvement is to also set $pulizia_esc to an empty string if the total is zero, so that you don’t get 0 output to the screen

$pulizia_esc = intval( get_the_author_meta( 'pulizia_esc', $post->post_author ) ) + intval( get_post_meta( $post->ID, "function_pulizia", true ) );
if ( $pulizia_esc !== 0 ) {
	$pulizia_esc = '<div class="pulizia_esc">' . $pulizia_esc . '</div>';
} else {
	$pulizia_esc = '';
}

I would also point out that if you plan to include decimals (i.e. cents) to the values, you might want to use floatval and not intval.

Last note, to make the above code cleaner and less prone to error, I would define a custom function to perform the calculation and return the string.

function generate_pulizia( $post ) {
	$pulizia_total = intval( get_the_author_meta( 'pulizia_esc', $post->post_author ) ) + intval( get_post_meta( $post->ID, "function_pulizia", true ) );
	if ( $pulizia_total === 0 ) {
		// If the total is 0 return an empty string.
		return '';
	}
	// Otherwise return the total.
	return '<div class="pulizia_esc">' . $pulizia_total . '</div>';
}

And then call that function wherever you need to generate the output

$pulizia_esc = generate_pulizia( $post );

Hi @eliot1988

Is this indication under the critical issues list, or the recommended improvements list?

If it’s under recommended improvements, it’s probably ok to ignore it, unless the scheduled event is something that you need to work.

It would also help if you’re able to share a bit more detail about the notification message, as that will help with determining how important it is.

Hello @yeknafar

The error you are getting looks like you need to update the user trying to create the MySQL tables, as that user doesn’t have the required permissions to create tables on the database environment you’re trying to set it up on.

Are you trying to create a copy of your site on your web hosts staging environment, or on a local WordPress installation? If it’s with your web host, best to check with their support.

If locally, how are you creating the staging copy of the site and what local WordPress installation software are you using?

Hi @tazcrzy

In my opinion, it’s usually best to “trash” from inside WordPress, as it should also delete any associated data (eg metadata). Additionally, if any custom plugins need to delete associated data, their delete routines would also kick in if you trash from within WordPress.

You could consider automating this process, by gathering the custom post ids, looping through the ids, and calling wp_trash_post() on each one. This would be faster than doing in the admin UI.

However, it is possibly faster if you delete via MySQL, you will just need to ensure that you also delete any associated data.

Were the only changes you made by using the SiteOrigin CSS plugin? Looking at the HTML source code, there are also differences in the HTML structure. Did you make those using the same plugin, or somewhere else?

Hi @lyurk I did a bit of digging into this, and this was the feedback I received.

Headers are case-insensitive in all versions of HTTP.

HTTP clients also need to handle this per the spec; for example, Requests (which WP_Http uses) has a case-insensitive dictionary for this

So it’s generally expected that headers will be case insensitive, and to not expect them to be sent using a specific case, even if they are set that way in the code.

Hi @jamescready

It looks like it could be possible that something in the Sydney theme is conflicting with the default column styles to cause this.

Are you able to test this out by switching to one of the default themes (like Twenty Twenty-Three) and see if the problem still exists?

If your web host supports staging sites, I would recommend making a copy of the live site to a staging site and testing it out there.