This project does not seem to handle request data directly as such no vulnerable execution paths were found.
include
, or for example
via PHP's auto-loading mechanism.
These results are based on our legacy PHP analysis, consider migrating to our new PHP analysis engine instead. Learn more
1 | <?php |
||
2 | |||
3 | abstract class CalendarAbstractView extends ViewableData |
||
0 ignored issues
–
show
|
|||
4 | { |
||
5 | |||
6 | // Static |
||
7 | |||
8 | private static $names = array(); |
||
9 | |||
10 | // Attributes |
||
11 | |||
12 | private $name; |
||
13 | protected $number; |
||
14 | |||
15 | protected $containerClass; |
||
16 | protected $innerClass; |
||
17 | |||
18 | protected $viewTitle; |
||
19 | |||
20 | protected $template; |
||
21 | protected $viewTitleDelimiter = ' - '; |
||
22 | |||
23 | // Contructor |
||
24 | |||
25 | public function __construct($name, $number = 1) |
||
26 | { |
||
27 | parent::__construct(); |
||
28 | View Code Duplication | if (is_string($name)) { |
|
0 ignored issues
–
show
This code seems to be duplicated across your project.
Duplicated code is one of the most pungent code smells. If you need to duplicate the same code in three or more different places, we strongly encourage you to look into extracting the code into a single class or operation. You can also find more detailed suggestions in the “Code” section of your repository. ![]() |
|||
29 | if (! in_array($name, self::$names)) { |
||
30 | $this->name = $name; |
||
31 | self::$names[] = $name; |
||
32 | } else { |
||
33 | user_error("CalendarAbstractView::__construct() : you cannot set the \$name attribute with the value '$name' because an other view with this name already exists", E_USER_ERROR); |
||
34 | } |
||
35 | } else { |
||
36 | user_error('CalendarAbstractView::__construct() : you cannot set the $name attribute with a non string value', E_USER_ERROR); |
||
37 | } |
||
38 | if (is_int($number + 0)) { |
||
39 | if ($number >= 1) { |
||
40 | $this->number = $number; |
||
41 | } else { |
||
42 | user_error('CalendarAbstractView::__construct() : you cannot set the $number attribute with a value less than 1', E_USER_ERROR); |
||
43 | } |
||
44 | } else { |
||
45 | user_error('CalendarAbstractView::__construct() : you cannot set the $number attribute with a non integer value', E_USER_ERROR); |
||
46 | } |
||
47 | $this->init(); |
||
48 | } |
||
49 | |||
50 | // Abstract Functions |
||
51 | |||
52 | abstract public function init(); |
||
0 ignored issues
–
show
For interfaces and abstract methods it is generally a good practice to add a
@return annotation even if it is just @return void or @return null , so that implementors know what to do in the overridden method.
For interface and abstract methods, it is impossible to infer the return type
from the immediate code. In these cases, it is generally advisible to explicitly
annotate these methods with a ![]() |
|||
53 | |||
54 | abstract public function needsMonth(); |
||
0 ignored issues
–
show
For interfaces and abstract methods it is generally a good practice to add a
@return annotation even if it is just @return void or @return null , so that implementors know what to do in the overridden method.
For interface and abstract methods, it is impossible to infer the return type
from the immediate code. In these cases, it is generally advisible to explicitly
annotate these methods with a ![]() |
|||
55 | abstract public function needsDay(); |
||
0 ignored issues
–
show
For interfaces and abstract methods it is generally a good practice to add a
@return annotation even if it is just @return void or @return null , so that implementors know what to do in the overridden method.
For interface and abstract methods, it is impossible to infer the return type
from the immediate code. In these cases, it is generally advisible to explicitly
annotate these methods with a ![]() |
|||
56 | |||
57 | abstract public function Calendars(Calendar $calendar); |
||
0 ignored issues
–
show
For interfaces and abstract methods it is generally a good practice to add a
@return annotation even if it is just @return void or @return null , so that implementors know what to do in the overridden method.
For interface and abstract methods, it is impossible to infer the return type
from the immediate code. In these cases, it is generally advisible to explicitly
annotate these methods with a ![]() |
|||
58 | |||
59 | abstract public function prevLinkParams(Calendar $calendar); |
||
0 ignored issues
–
show
For interfaces and abstract methods it is generally a good practice to add a
@return annotation even if it is just @return void or @return null , so that implementors know what to do in the overridden method.
For interface and abstract methods, it is impossible to infer the return type
from the immediate code. In these cases, it is generally advisible to explicitly
annotate these methods with a ![]() |
|||
60 | abstract public function nextLinkParams(Calendar $calendar); |
||
0 ignored issues
–
show
For interfaces and abstract methods it is generally a good practice to add a
@return annotation even if it is just @return void or @return null , so that implementors know what to do in the overridden method.
For interface and abstract methods, it is impossible to infer the return type
from the immediate code. In these cases, it is generally advisible to explicitly
annotate these methods with a ![]() |
|||
61 | |||
62 | abstract public function viewLinkParamsAndTitle(Calendar $calendar); |
||
0 ignored issues
–
show
For interfaces and abstract methods it is generally a good practice to add a
@return annotation even if it is just @return void or @return null , so that implementors know what to do in the overridden method.
For interface and abstract methods, it is impossible to infer the return type
from the immediate code. In these cases, it is generally advisible to explicitly
annotate these methods with a ![]() |
|||
63 | |||
64 | abstract public function getLinkParams($date); |
||
0 ignored issues
–
show
For interfaces and abstract methods it is generally a good practice to add a
@return annotation even if it is just @return void or @return null , so that implementors know what to do in the overridden method.
For interface and abstract methods, it is impossible to infer the return type
from the immediate code. In these cases, it is generally advisible to explicitly
annotate these methods with a ![]() |
|||
65 | |||
66 | abstract public function title(); |
||
0 ignored issues
–
show
For interfaces and abstract methods it is generally a good practice to add a
@return annotation even if it is just @return void or @return null , so that implementors know what to do in the overridden method.
For interface and abstract methods, it is impossible to infer the return type
from the immediate code. In these cases, it is generally advisible to explicitly
annotate these methods with a ![]() |
|||
67 | abstract public function DateTitle(Calendar $calendar); |
||
0 ignored issues
–
show
For interfaces and abstract methods it is generally a good practice to add a
@return annotation even if it is just @return void or @return null , so that implementors know what to do in the overridden method.
For interface and abstract methods, it is impossible to infer the return type
from the immediate code. In these cases, it is generally advisible to explicitly
annotate these methods with a ![]() |
|||
68 | |||
69 | // Functions |
||
70 | |||
71 | public function getName() |
||
72 | { |
||
73 | return $this->name; |
||
74 | } |
||
75 | |||
76 | public function setContainerClass($containerClass) |
||
77 | { |
||
78 | $this->containerClass = $containerClass; |
||
79 | } |
||
80 | public function setInnerClass($innerClass) |
||
81 | { |
||
82 | $this->innerClass = $innerClass; |
||
83 | } |
||
84 | |||
85 | public function setViewTitle($viewTitle) |
||
86 | { |
||
87 | $this->viewTitle = $viewTitle; |
||
88 | } |
||
89 | |||
90 | // Template Functions |
||
91 | |||
92 | public function setTemplate($template) |
||
93 | { |
||
94 | $this->template = $template; |
||
95 | } |
||
96 | |||
97 | public function getTemplates() |
||
98 | { |
||
99 | if ($this->template) { |
||
100 | $templates[] = $this->template; |
||
0 ignored issues
–
show
Coding Style
Comprehensibility
introduced
by
$templates was never initialized. Although not strictly required by PHP, it is generally a good practice to add $templates = array(); before regardless.
Adding an explicit array definition is generally preferable to implicit array definition as it guarantees a stable state of the code. Let’s take a look at an example: foreach ($collection as $item) {
$myArray['foo'] = $item->getFoo();
if ($item->hasBar()) {
$myArray['bar'] = $item->getBar();
}
// do something with $myArray
}
As you can see in this example, the array This might or might not be intended. To make your intention clear, your code more readible and to avoid accidental bugs, we recommend to add an explicit initialization $myArray = array() either outside or inside the foreach loop. ![]() |
|||
101 | } |
||
102 | $class = get_class($this); |
||
103 | while ($class != 'CalendarAbstractView') { |
||
104 | $templates[] = $class; |
||
0 ignored issues
–
show
The variable
$templates does not seem to be defined for all execution paths leading up to this point.
If you define a variable conditionally, it can happen that it is not defined for all execution paths. Let’s take a look at an example: function myFunction($a) {
switch ($a) {
case 'foo':
$x = 1;
break;
case 'bar':
$x = 2;
break;
}
// $x is potentially undefined here.
echo $x;
}
In the above example, the variable $x is defined if you pass “foo” or “bar” as argument for $a. However, since the switch statement has no default case statement, if you pass any other value, the variable $x would be undefined. Available Fixes
![]() |
|||
105 | $class = get_parent_class($class); |
||
106 | } |
||
107 | return $templates; |
||
108 | } |
||
109 | |||
110 | public function setViewTitleDelimiter($viewTitleDelimiter) |
||
111 | { |
||
112 | $this->viewTitleDelimiter = $viewTitleDelimiter; |
||
113 | } |
||
114 | |||
115 | public function NameClass() |
||
116 | { |
||
117 | $class = "{$this->class}_{$this->name}"; |
||
118 | $class[0] = strtolower($class[0]); |
||
119 | return $class; |
||
120 | } |
||
121 | |||
122 | public function showCalendar(Calendar $calendar) |
||
123 | { |
||
124 | $calendars = $this->Calendars($calendar); |
||
125 | $templates = $this->getTemplates(); |
||
126 | |||
127 | return $this->customise(array('ID' => $calendar->ID(), 'ContainerClass' => $this->containerClass, 'Calendars' => $calendars))->renderWith($templates); |
||
128 | } |
||
129 | } |
||
130 |
You can fix this by adding a namespace to your class:
When choosing a vendor namespace, try to pick something that is not too generic to avoid conflicts with other libraries.