Bart Kuijper

Sorry, I haven’t been able to respond earlier.

This is great, thank you very much for implementing this feature. I can’t believe you did it so quickly as well. Thanks again!

WordPress 5.5.1 has been released and fixed this Site Health message. It will no longer appear when there is in fact nothing wrong with your PHP configuration.

See https://www.ads-software.com/support/wordpress-version/version-5-5-1/#summary for a summary of this release.

See https://core.trac.www.ads-software.com/ticket/50945 for the ticket relating to this Site Health message specifically.

For those wanting to know the proper values: memory_limit should be larger than post_max_size, and post_max_size should be larger than upload_max_filesize.

Source: the PHP manual at https://www.php.net/manual/en/ini.core.php#ini.post-max-size

@maxvelio The fact that you still have the warning most likely means you didn’t effectively set the same value for both. For example if you set the values in your .htaccess or php.ini file, there’s a chance these settings are overruled by whatever value is configured via your server’s control panel.

But like I posted earlier, you shouldn’t set the same values for post_max_size and upload_max_filesize. Instead you should configure the values properly and ignore WordPress’ incorrectly displayed error message. So memory_limit > post_max_size > upload_max_filesize, as specified on https://www.php.net/manual/en/ini.core.php#ini.post-max-size. For example 256M, 64M, 32M would be a valid configuration.

As an extra bit of info, post_max_size has nothing to do with WordPress posts, it refers to a HTTP POST request used for example to upload an image to your media library. Since this request also has some overhead, setting it and upload_max_filesize to the same value makes no sense, since you’ll never be able to upload a 1M file if the POST request containing that file is also limited to 1M. Not to mention it’s also possible to upload multiple files using a single POST request, which is why you’d want post_max_size to be larger than upload_max_filesize.

@mnatseah624 Several PHP directives (such as the ones discussed here) accept shorthand byte values: K for Kilobytes, M for Megabytes, G for gigabytes. See also https://www.php.net/manual/en/faq.using.php#faq.using.shorthandbytes.

Like @diondesigns said, it’s a bug with the Site Health tool. The message appears whenever post_max_size and upload_max_filesize are not equal. But in fact the message should only appear when post_max_size is smaller than or equal to upload_max_filesize.

For those interested, here you can read what the PHP manual has to say about the proper relative values for post_max_size, upload_max_filesize, and memory_limit: https://www.php.net/manual/en/ini.core.php#ini.post-max-size

What it boils down to is that memory_limit should be larger than post_max_size, and post_max_size should be larger than upload_max_filesize.

Alright one more addition, this time an alternative method. I created this because the previously posted method only worked to an extent. Certain bbp-style-pack options still didn’t work, probably because they rely on overruling parts of the bbpress.css which isn’t being loaded.

The code is again specific to the evolve theme, but it should be easy enough to adapt to a different theme.

How it works: the evolve theme hooks into wp_print_styles to deregister the bbp-default style. So we hook into that same action with a lower priority (PHP_INT_MIN) and unhook evolve’s function before it gets a chance to run. An important note about removing hooks: you don’t get an error message if removing the hook failed, and in order to succesfully remove a hook you need to specify the exact priority that was used to add the hook in the first place. Also in this case the theme’s hooked function is luckily not inside a class, so all I need is the function’s name.

My code then searches through the enqueued styles and injects some dependencies to make the bbp-default style load after the theme’s CSS.

add_action( 'wp_print_styles', 'style_dependency_fix', PHP_INT_MIN, 0 );

function style_dependency_fix() {
	remove_action( 'wp_print_styles', 'evolve_deregister_bbpress_styles', 15 );
	global $wp_styles;
	foreach ( $wp_styles->queue as $style ) :
		if ( 'bbp-default' === $wp_styles->registered[ $style ]->handle ) {
			$wp_styles->registered[ $style ]->deps = array_merge( $wp_styles->registered[ $style ]->deps, array( 'evolve-style', 'evolve-bootstrap' ) );
			break;
		}
	endforeach;
}

• This reply was modified 4 years, 6 months ago by Bart Kuijper. Reason: typo

Thanks for the compliment!

I have one more thing to add to the code I posted. In order to make sure the BBP Style Pack can overrule my theme’s CSS, I’ve added some of my theme’s styles as a dependency to my bbp-default dummy style, in order to ensure that the bsp style gets loaded after my theme’s CSS.

wp_register_style( 'bbp-default', false, array( 'evolve-style', 'evolve-bootstrap' ) );

Just wanted to add that for completeness, in case anyone with a similar issue comes across this topic.

Thank you very much for your reply, your code, your effort, and your time!

I couldn’t get bbp-default to register, not even when giving my wp_enqueue_scripts hook a priority of PHP_INT_MAX to make sure it goes last.

So then I had another look at when my theme deregisters bbp-default. Turns out the evolve theme deregisters the style using the wp_print_styles hook that fires later than wp_enqueue_scripts. Note: since WP 3.3 the wp_print_styles hook isn’t supposed to be used for enqueueing scripts and styles for the frontend. (source)

Since I’m not using a child theme currently, I decided to create a small Must-Use plugin that fixes the issue by registering the bbp-default style with its source set to false. This way the bbp-default style doesn’t actually get loaded and so doesn’t interfere with my theme, but it does satisfy this plugin’s bsp style dependency.

There’s of course some fluff in the mu-plugin (file header, comments) which I won’t all paste here. The actual magic happens in just these few lines of code anyway. Again I’m using a priority of PHP_INT_MAX, since the evolve theme uses this same hook to deregister the style and I want to make sure my hook fires last.

add_action( 'wp_print_styles', 'fix_bbp_dependency', PHP_INT_MAX, 0 );
function fix_bbp_dependency() {
	wp_register_style( 'bbp-default', false );
}

• This reply was modified 4 years, 7 months ago by Bart Kuijper. Reason: typo's & marked as resolved
• This reply was modified 4 years, 7 months ago by Bart Kuijper. Reason: corrected an ambiguous sentence

Don’t forget to leave a review.

Done and thanks again!

That makes perfect sense, I feel like I owe you an apology for even considering that you had broken backwards compatibility.

Thank you very much for your fast answer and thank you even more for the continued development of this excellent plugin!

PHP RFC: Deprecate curly brace syntax for accessing array elements and string offsets

Until this is fixed in the theme’s source, anyone bothered by the deprecation notice (like I am ?? ) can fix it by replacing the curly braces {} with square brackets [] in evolve/inc/support.php at line 170:

if ( !isset( $version{1} ) ) {

should be changed to

if ( !isset( $version[1] ) ) {

• This reply was modified 4 years, 8 months ago by Bart Kuijper.
• This reply was modified 4 years, 8 months ago by Bart Kuijper.
• This reply was modified 4 years, 8 months ago by Bart Kuijper.
• This reply was modified 4 years, 8 months ago by Bart Kuijper.

Here’s the diff for the current (version 2.40.1, revision 2233202) and previous (version 2.40.0, revision 2211492) revisions: https://plugins.trac.www.ads-software.com/changeset?old=2211492&old_path=strong-testimonials&new=&new_path=strong-testimonials

I’m no expert, but if I’m interpreting the code and the changes correctly, there was a way for a malicious POST request to inject code due to improper sanitization.

Also the domain was changed for the link to the paid version, from strongtestimonials.com to wp-modula.com. Both domains were registered 2 months apart in 2017 with the same registrar.

• This reply was modified 4 years, 9 months ago by Bart Kuijper.

I understand people are concerned, but at this stage (given that it’s a bug affecting every version of this plugin with no patch yet avilable), it’s impossible to reveal any more specific information without also increasing the risk of said bug being exploited. In this particular cirsumstance I believe ‘security by obscurity’ is the lesser evil. Just my two cents.

You are most welcome! This plugin is essential to my website, it’s free and it’s never let me down. The least I could do was leave a review. Thank you and I wish you and yours a great 2020!

Thank you kindly for taking the time to satisfy my curiosity ??

@mintjelly Consider the alternative, a plugin silently deleting all the custom posts you made upon uninstalling it.

Anyway the easiest way is to reinstall this plugin, then go to its Settings page, select the Misc tab, enable the ‘Remove Data on Uninstall?’ option and then uninstall it again.