davidkoh83

I just found out a huge problem with 1 of your main function inet_ptoi. It calculates certain IP Addresses wrongly which is a major issue for your plugin.

We maintained an IP Address range of 128.6.0.0 to 128.6.255.255.
1 of our user was accessing via 128.6.37.84. Your function inet_ptoi translates this to 2080777556 which is wrong. If you use an online IP to integer converter, you will get 2147886420.

If you use SELECT INET_ATON(start), INET_ATON(end) FROM wp_ip_based_login in the database, you will see the range is 2147876864 to 2147942399 (128.6.0.0 to 128.6.255.255)

Hi Brijeshk89,

I identified that this chunk of code:
$query = "SELECT * FROM ".$wpdb->prefix."ip_based_login WHEREstatus` = 1″; David – 13/04/2021
$ip_ranges = ipbl_selectquery($query, 1);
if(!empty($ip_ranges) && is_array($ip_ranges)){
foreach($ip_ranges as $k => $v){
// Is the IP in the blacklist ?
if(inet_ptoi($v[‘start’]) <= inet_ptoi($logged_ip) && inet_ptoi($logged_ip) <= inet_ptoi($v[‘end’])){
$username = $v[‘username’];
break;
}
// Is it in a wider range ?
if(inet_ptoi($v[‘start’]) >= 0 && inet_ptoi($v[‘end’]) < 0){
// Since the end of the RANGE (i.e. current IP range) is beyond the +ve value of inet_ptoi,
// if the current IP is <= than the start of the range, it is within the range
// OR
// if the current IP is <= than the end of the range, it is within the range
if(inet_ptoi($v[‘start’]) <= inet_ptoi($logged_ip)
|| inet_ptoi($logged_ip) <= inet_ptoi($v[‘end’])){
$username = $v[‘username’];
break;
}
}
}
}`
causes the website to load very slowly. With more than 1200 records, this loop really slow things down with moderate traffic. It seem to me that the function inet_ptoi runs a bit slowly and you have it calculate the user’s logged in IP multiple times in every loop on top of the IPs from the database. In addition, this function is called on every page visit. Therefore, the time it takes is roughly like visitor * page visits * db records which is a lot of calls and causes the CPU to hit 100%.

I commented out the chunk of code and use:

$myip = inet_ptoi($logged_ip);
	$query = "SELECT * FROM ".$wpdb->prefix."ip_based_login WHERE <code>status</code> = 1 AND INET_ATON ( start ) <= ".$myip." and INET_ATON ( end ) >= ".$myip;
	$ip_check = ipbl_selectquery($query, 1);
	if(!empty($ip_check) && is_array($ip_check)){
		$username = $ip_check[0]['username'];
	}

This runs a lot faster as I get the database to find the IP instead and return only 1 record. Thanks

In addition to the above, when there are more than 600 entries in the database, the website will slow down significantly and causes timeout. You can simulate this at loader.io serving 100 visitors in 1 minute using a high end server

Hi,

I have tested and it is working perfectly now. Thank you for the fix and quick response!

Hi,

I don’t really want to install so many things on the server at the moment so I just made a screenshot and uploaded it to our server for your reference: https://cdn.cancerletter.online/media/2021/03/05151431/panda-scaled.jpg

To explain each part. The number below = the number on my screenshot:
1. Those are my pods
2. I made 1 ACT called contributor_detail that has a field called start_date
3. I made another ACT called contributor_institution which has article_id
4. The CPT contributors have 2 fields using your plugin to point to contributor_detail and contributor_institution. As you can see highlighted in red, I placed start_date and article_id for sorting
5. When I try to get the data using pods_field, the institution_detail that points to contributor_institution returns empty while the other is ok
6. I found out that you have a function to return the select statement so I used that to see what it was selecting. As you can see, for contributor_institution, instead of using article_id that was set, it used start_date instead from the previous value
7. In order to overcome this bug, I had to overwrite that by using your function but with extra param to state the order_by again to overwrite what was previously set

Hi Jory,

So I took your advice and created a CPT called people for this instead. It is definitely better than using taxonomy. However, I discover that when I try to get everything from the CPT, the PODS – List Item widget does not allow me to have a limit above 15. Everytime I key in a value above and save, it will go back to 15.
So to counter this, I put limit as 1 and use php to grab everything instead which then I stumbled that when you do pods(‘people’) without any parameters, it returns nothing. If I put pods(‘people’, array()) it creates an error so I had to use pods(‘people’, array(‘limit’ => 1000)) in order to get everything from the CPT. Are these restrictions intentional?

I will try it out! You definitely know this better than I do!
Just to let you know, I did try something which worked at first but caused problem as you mentioned it would. If I create a taxonomy and attach it to post and later create an extended post and include the same taxonomy as a relationship field attachment, it will cause the theme to crash when I use multiple selection (Because I wanted to arrange). Single selection seems fine. Thought I will just let you know in case you may encounter such a question from someone in the future who happens to do the same thing 🙂