RentbitsWidgets   A
last analyzed

Complexity

Total Complexity 4

Size/Duplication

Total Lines 79
Duplicated Lines 0 %

Coupling/Cohesion

Components 1
Dependencies 0

Importance

Changes 0
Metric Value
dl 0
loc 79
rs 10
c 0
b 0
f 0
wmc 4
lcom 1
cbo 0

4 Methods

Rating   Name   Duplication   Size   Complexity  
A __construct() 0 3 1
A rb_enqueue() 0 5 1
A get_rental_comparison_widget() 0 15 1
A get_average_rental_rates_widget() 0 15 1
1
<?php
0 ignored issues
show
Coding Style Compatibility introduced by
For compatibility and reusability of your code, PSR1 recommends that a file should introduce either new symbols (like classes, functions, etc.) or have side-effects (like outputting something, or including other files), but not both at the same time. The first symbol is defined on line 15 and the first side effect is on line 9.

The PSR-1: Basic Coding Standard recommends that a file should either introduce new symbols, that is classes, functions, constants or similar, or have side effects. Side effects are anything that executes logic, like for example printing output, changing ini settings or writing to a file.

The idea behind this recommendation is that merely auto-loading a class should not change the state of an application. It also promotes a cleaner style of programming and makes your code less prone to errors, because the logic is not spread out all over the place.

To learn more about the PSR-1, please see the PHP-FIG site on the PSR-1.

Loading history...
2
/**
3
 * Rentbits Widgets Class
4
 *
5
 * @package RE-PRO
6
 */
7
8
// Exit if accessed directly.
9
if ( ! defined( 'ABSPATH' ) ) { exit; }
10
11
if ( ! class_exists( 'RentbitsWidgets' ) ) {
12
	/**
13
	 * HomeFinderWidgets class.
14
	 */
15
	class RentbitsWidgets {
0 ignored issues
show
Coding Style Compatibility introduced by
PSR1 recommends that each class must be in a namespace of at least one level to avoid collisions.

You can fix this by adding a namespace to your class:

namespace YourVendor;

class YourClass { }

When choosing a vendor namespace, try to pick something that is not too generic to avoid conflicts with other libraries.

Loading history...
16
17
		/**
18
		 * Widget data to be sent to JS.
19
		 *
20
		 * @var [Array]
21
		 */
22
		static private $rb_data;
23
24
		/**
25
		 * __construct function.
26
		 *
27
		 * @access public
28
		 * @return void
0 ignored issues
show
Comprehensibility Best Practice introduced by
Adding a @return annotation to constructors is generally not recommended as a constructor does not have a meaningful return value.

Adding a @return annotation to a constructor is not recommended, since a constructor does not have a meaningful return value.

Please refer to the PHP core documentation on constructors.

Loading history...
29
		 */
30
		public function __construct() {
31
			add_action( 'wp_footer', array( $this, 'rb_enqueue' ) );
32
		}
33
34
		/**
35
		 * Handle multiple rb widgets js enqueues.
36
		 */
37
		public function rb_enqueue() {
38
			wp_enqueue_script( 'rb-widgets-js', plugins_url( 'rb-widgets.js', __FILE__ ), array( 'jquery' ), null, true );
39
			wp_localize_script( 'rb-widgets-js', 'rb_data', static::$rb_data );
0 ignored issues
show
Bug introduced by
Since $rb_data is declared private, accessing it with static will lead to errors in possible sub-classes; consider using self, or increasing the visibility of $rb_data to at least protected.

Let’s assume you have a class which uses late-static binding:

class YourClass
{
    private static $someVariable;

    public static function getSomeVariable()
    {
        return static::$someVariable;
    }
}

The code above will run fine in your PHP runtime. However, if you now create a sub-class and call the getSomeVariable() on that sub-class, you will receive a runtime error:

class YourSubClass extends YourClass { }

YourSubClass::getSomeVariable(); // Will cause an access error.

In the case above, it makes sense to update SomeClass to use self instead:

class SomeClass
{
    private static $someVariable;

    public static function getSomeVariable()
    {
        return self::$someVariable; // self works fine with private.
    }
}
Loading history...
40
41
		}
42
43
		/* Rentbits WIDGETS. */
44
45
		/**
46
		 * Get Rental Comparison Widget.
47
		 *
48
		 * @access public
49
		 * @param mixed $loc1 First Location.
50
		 * @param mixed $loc2 Second Location.
51
	 	 * @param mixed $loc3 Third Location.
52
		 * @param mixed $loc4 Fourth Location.
53
		 * @return void
54
		 */
55
		public function get_rental_comparison_widget( $loc1, $loc2, $loc3, $loc4 ) {
56
57
			$url = 'http://rentbits.com/rb/pageinc.do?p=widget-cmp-price&loc1=' . $loc1 . '&loc2=' . $loc2 . '&loc3=' . $loc3 . '&loc4=' . $loc4;
58
59
			$rb_data = array(
60
				'width' => '195px',
61
				'height' => '295px',
62
				'url' => $url,
63
			);
64
			static::$rb_data[] = $rb_data;
0 ignored issues
show
Bug introduced by
Since $rb_data is declared private, accessing it with static will lead to errors in possible sub-classes; consider using self, or increasing the visibility of $rb_data to at least protected.

Let’s assume you have a class which uses late-static binding:

class YourClass
{
    private static $someVariable;

    public static function getSomeVariable()
    {
        return static::$someVariable;
    }
}

The code above will run fine in your PHP runtime. However, if you now create a sub-class and call the getSomeVariable() on that sub-class, you will receive a runtime error:

class YourSubClass extends YourClass { }

YourSubClass::getSomeVariable(); // Will cause an access error.

In the case above, it makes sense to update SomeClass to use self instead:

class SomeClass
{
    private static $someVariable;

    public static function getSomeVariable()
    {
        return self::$someVariable; // self works fine with private.
    }
}
Loading history...
65
66
			$index = count( static::$rb_data ) - 1;
0 ignored issues
show
Bug introduced by
Since $rb_data is declared private, accessing it with static will lead to errors in possible sub-classes; consider using self, or increasing the visibility of $rb_data to at least protected.

Let’s assume you have a class which uses late-static binding:

class YourClass
{
    private static $someVariable;

    public static function getSomeVariable()
    {
        return static::$someVariable;
    }
}

The code above will run fine in your PHP runtime. However, if you now create a sub-class and call the getSomeVariable() on that sub-class, you will receive a runtime error:

class YourSubClass extends YourClass { }

YourSubClass::getSomeVariable(); // Will cause an access error.

In the case above, it makes sense to update SomeClass to use self instead:

class SomeClass
{
    private static $someVariable;

    public static function getSomeVariable()
    {
        return self::$someVariable; // self works fine with private.
    }
}
Loading history...
67
			echo '<div id="rb-widget-' . $index . '"></div>';
68
69
		}
70
71
		/**
72
		 * Get Average Rental Rates Widget.
73
		 *
74
		 * @access public
75
		 * @param mixed $loc Location.
76
		 * @return void
77
		 */
78
		public function get_average_rental_rates_widget( $loc ) {
79
80
			$url = 'http://rentbits.com/rb/pageinc.do?p=widget-avg-price&loc=' . $loc;
81
82
			$rb_data = array(
83
				'width' => '330px',
84
				'height' => '365px',
85
				'url' => $url,
86
			);
87
			static::$rb_data[] = $rb_data;
0 ignored issues
show
Bug introduced by
Since $rb_data is declared private, accessing it with static will lead to errors in possible sub-classes; consider using self, or increasing the visibility of $rb_data to at least protected.

Let’s assume you have a class which uses late-static binding:

class YourClass
{
    private static $someVariable;

    public static function getSomeVariable()
    {
        return static::$someVariable;
    }
}

The code above will run fine in your PHP runtime. However, if you now create a sub-class and call the getSomeVariable() on that sub-class, you will receive a runtime error:

class YourSubClass extends YourClass { }

YourSubClass::getSomeVariable(); // Will cause an access error.

In the case above, it makes sense to update SomeClass to use self instead:

class SomeClass
{
    private static $someVariable;

    public static function getSomeVariable()
    {
        return self::$someVariable; // self works fine with private.
    }
}
Loading history...
88
89
			$index = count( static::$rb_data ) - 1;
0 ignored issues
show
Bug introduced by
Since $rb_data is declared private, accessing it with static will lead to errors in possible sub-classes; consider using self, or increasing the visibility of $rb_data to at least protected.

Let’s assume you have a class which uses late-static binding:

class YourClass
{
    private static $someVariable;

    public static function getSomeVariable()
    {
        return static::$someVariable;
    }
}

The code above will run fine in your PHP runtime. However, if you now create a sub-class and call the getSomeVariable() on that sub-class, you will receive a runtime error:

class YourSubClass extends YourClass { }

YourSubClass::getSomeVariable(); // Will cause an access error.

In the case above, it makes sense to update SomeClass to use self instead:

class SomeClass
{
    private static $someVariable;

    public static function getSomeVariable()
    {
        return self::$someVariable; // self works fine with private.
    }
}
Loading history...
90
			echo '<div id="rb-widget-' . $index . '"></div>';
91
92
		}
93
	}
94
}
95