ingonieur

Hi, I got this error as well and it is still not fixed…

Unfortunately, the developers did a kind of sloppy job with the brackets in the query for checking for custom styles….

This leads to accessing the $this->options Array even if it is not set (boolean “false”).

The easiest way is to fill this array with Custom Styles…
Simply go to Customizer ->Material Design and save the values or deactivate it…
wp-admin/customize.php?autofocus[section]=cf7md_options

Hi Gregory.

wpdb->insert does its job, but not with log-int-values that cannot be stored as integers on 32-bit-machines.
You use PHP ip2long, that doesn’t work either.

Within the wpdb->insert Excerpt I wanted to focus on the INTEGER Format-Mapping of the long IPs. On a 32-Bit Machine this also leads to an Integer-Interpretation/mapping where the long-Value (even if correct) possibly leads to an overflow and a resulting negative value, that cannot be stored in the UNSIGNED-Int CERBER_ACL_TABLE field.

So take “%s” instead of “%d”:
array( '%s', /* >> */ '%s', '%s' /* << INSTEAD OF %d, %d */,

Did you get the rest? Please don’t get me wrong, i don’t want to appear harsh or arrogant or sth like that… I think it might be a misunderstanding here.
I do not have a question. I found a Bug and have a Solution.
Sorry, it’s a really serious bug – I was hoping that it would get it into the new update – I really think you should implement this fix as soon as possible…

I’ll try to recap:
For many IPs the whole Cerber Blocking Mechanism DOES NOT WORK with ip2long you are using in every Block-Check. The way Cerber currently converts and saves the IPs does not work as intended on 32-Bit-Machines.
The Blocking Mechanism is one of the most important things of a Firewall, but Cerber currently does not work on 32 Bit Servers – it fails silently without error…

PHP says:
ip2long:
https://www.php.net/manual/en/function.ip2long.php

Note:
Because PHP's int type is signed, and many IP addresses will result in negative integers on 32-bit architectures, you need to use the "%u" formatter of sprintf() or printf() to get the string representation of the unsigned IP address.

And in the cerber_acl Table the long IP values (ip_long_begin, ip_long_end) are stored in UNSIGNED bigint(20). Therefore: while trying to store a negative value it becomes cutted to Zeros…

That’s why functions (and several others) like “cerber_acl_add” in dashbaord.php (also in Version 8.8.3) keep failing:

5208	if ( cerber_is_ipv4( $ip ) ) {
5209		$begin = ip2long( $ip );
5210		$end   = ip2long( $ip );
5211	}

but if you would take

	if ( cerber_is_ipv4( $ip ) ) {
		$begin = sprintf("%u", ip2long($ip));;
		$end   = sprintf("%u", ip2long($ip));;
	}

or better – a helper-function like sth I mentiones in my first post, then it would work again, because with ip2long only “0”-Values are stored in the Database, because of the unsigned Storage (cerber_acl Table Structure) and negative Values cannot be checked correctly with a “greater-or-smaller-than-IP-range-check”… so the sprintf-U-way is one of the smartest solutions I think…

I hope this makes it more clear now.
If not, please tell me, then I will again try to explain what i mean.

Many greetings and nevertheless thanks again for this great plugin! : ))

ingo

• This reply was modified 3 years, 8 months ago by ingonieur.
• This reply was modified 3 years, 8 months ago by ingonieur.

Hey @gingerbooch,

haha, yeah, good solution! And very stable, ideed. But cerber is such a great tool and of course more comfortable than a htaccess List. : )

I also had such a “magic fix” on another Server because the ACL_Fixing-Function runs every time Cerber gets a Plugin-Update and on this Server my hoster switched from faulty 32 to properly functioning 64-Bit…

But the Problem itself in the Cerber-Plugin kept and still is the same.

thanks for your message!
ingo

• This reply was modified 3 years, 8 months ago by ingonieur.

Hi Gregory,

no, it all breaks down to the ip2long-Problem.
Mine as well as the mentioned/linked ones from @gingerbooch and @ableads

Everything comes from this, if IPs are not correctly converted.

… Black-List-Entries are faulty created as begin-0-end-0-IP-Entries (negative values are cut off because unsigned)

… following IP Additions to the Block-List are inserted multiple times because the check-whether-ip-is-already-in-block-list fails (due to the faulty conversion)

… ACL detections do not work anymore/intrusions are not detected/blocked because the intrusion-IP-is-in-Block-List-Range-Check fails (due to the faulty conversion).

… your repair-DB-Script/Fix-ACL does not correct the faulty IPs, because the new long-IP-Value still is converted faulty…

I hope you can add the ip2log-Fix with the next Update, because I unfortunately do still have some 32-Bit Servers from a shared hoster…

The above mentioned solution in my first post is a fix that works great. Try to test it in a 32 Bit Environment. If you don’t have one, I can give you a test-access.

Many thanks in advance!
many greets, ingo

• This reply was modified 3 years, 8 months ago by ingonieur.

Hi Jules,
unfortunately, after this rewrite there also now is an error while changing MultiStep-Form-Pages, because of this Error:

scripts_es6.js:921 Uncaught TypeError: wpcf7.setStatus is not a function
    at Object.<anonymous> (scripts_es6.js:921)

the wpcf7.setStatus function does not appear in the code anymore….

@gm_alex Hi Alex, first of all: thankx for your great plugin!
in V2.2.7 there is also an Issue with the Type Hinting in the ShortCodeController.
I’m calling an uam_public Shortcode without Attributes (except content of course) and get the Error:

Fatal error: Uncaught TypeError: Argument 1 passed to UserAccessManager\Controller\Frontend\ShortCodeController::publicShortCode() must be of the type array, string given, called in 
/homepages/.../wp-includes/shortcodes.php on line 343 and defined in /homepages/.../wp-content/plugins/user-access-manager/src/Controller/Frontend/ShortCodeController.php:95 
Stack trace: 
#0 /homepages/.../wp-includes/shortcodes.php(343): UserAccessManager\Controller\Frontend\ShortCodeController->publicShortCode('', 'Bitte geben Sie...', 'uam_public') 
#1 [internal function]: do_shortcode_tag(Array) 
#2 /homepages/.../wp-includes/shortcodes.php(218): preg_replace_callback('/\\[(\\[?)(LOGIN_...', 'do_shortcode_ta...', '<h2>Ihr Zugang ...') 
#3 /homepages/.../wp-content/plugins/js_composer/include/helpers/helpers.php(240): do_shortcode(' in /homepages/.../wp-content/plugins/user-access-manager/src/Controller/Frontend/ShortCodeController.php on line 102

My quick-and-dirty-bring-it-back-to-work solution was to skip the type hinting and remove the “array” from the function declaration in Line 95:

public function publicShortCode($attributes, $content = ''): string

…but I think you might have a better Solution. ??

Hi, I had the same issue in V1.1.2. But you may change it in the code, ideed.
But be aware that this hard-coded change might get lost with a new update!

Open “staff-directory/classes/staff-directory-shortcode.php” and search the shortcode-function (probably line 81)
static function photo_url_shortcode(){

once there, add the ‘full’ param to the wp_get_attachment_image_src-function:
$attachment_array = wp_get_attachment_image_src( get_post_thumbnail_id(), 'full' );

this worked for me. : )