MylinksThumbPlugin
last analyzed

Size/Duplication

Total Lines 42
Duplicated Lines 0 %

Importance

Changes 0
Metric Value
dl 0
loc 42
c 0
b 0
f 0

12 Methods

Rating   Name   Duplication   Size   Complexity  
getProviderUrl() 0 1 ?
getProviderName() 0 1 ?
setShotSize() 0 1 ?
getShotSize() 0 1 ?
setSiteUrl() 0 1 ?
getSiteUrl() 0 1 ?
setAttribution() 0 1 ?
getAttribution() 0 1 ?
setProviderPublicKey() 0 1 ?
getProviderPublicKey() 0 1 ?
setProviderPrivateKey() 0 1 ?
getProviderPrivateKey() 0 1 ?
1
<?php
2
/**
3
 *  mylinks Thumb Provider Plugin Interface Class Elements
4
 *
5
 * @copyright ::  {@link http://xoops.org/ XOOPS Project}
6
 * @copyright ::  ZySpec Incorporated
7
 * @license   ::    {@link http://www.gnu.org/licenses/gpl-2.0.html GNU Public License}
8
 * @package   ::    mylinks
9
 * @subpackage:: class
10
 * @author    ::     zyspec ([email protected])
11
 */
12
13
defined('XOOPS_ROOT_PATH') or die('Restricted access');
14
15
/**
16
 * MylinksThumbPluginInterface
17
 *
18
 * @package   ::   mylinks
19
 * @author    ::    zyspec ([email protected]), Herve Thouzard
20
 * @copyright ::  {@link http://xoops.org/ XOOPS Project}
21
 * @copyright :: Copyright (c) 2012 ZySpec Incorporated, Herve Thouzard
22
 * @access::    public
23
 */
24
interface MylinksThumbPlugin
25
{
26
    public function getProviderUrl();
0 ignored issues
show
Documentation introduced by
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 @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
27
28
    public function getProviderName();
0 ignored issues
show
Documentation introduced by
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 @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
29
30
    /**
31
     * @param $szarray
32
     * @return mixed
33
     */
34
    public function setShotSize($szarray);
35
36
    public function getShotSize();
0 ignored issues
show
Documentation introduced by
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 @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
37
38
    /**
39
     * @param $url
40
     * @return mixed
41
     */
42
    public function setSiteUrl($url);
43
44
    public function getSiteUrl();
0 ignored issues
show
Documentation introduced by
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 @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
45
46
    public function setAttribution();
0 ignored issues
show
Documentation introduced by
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 @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
47
48
    public function getAttribution();
0 ignored issues
show
Documentation introduced by
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 @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
49
50
    /**
51
     * @param $key
52
     * @return mixed
53
     */
54
    public function setProviderPublicKey($key);
55
56
    public function getProviderPublicKey();
0 ignored issues
show
Documentation introduced by
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 @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
57
58
    /**
59
     * @param $key
60
     * @return mixed
61
     */
62
    public function setProviderPrivateKey($key);
63
64
    public function getProviderPrivateKey();
0 ignored issues
show
Documentation introduced by
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 @return doc comment to communicate to implementors of these methods what they are expected to return.

Loading history...
65
}
66