Conditions | 2 |
Paths | 2 |
Total Lines | 60 |
Lines | 0 |
Ratio | 0 % |
Changes | 0 |
Small methods make your code easier to understand, in particular if combined with a good name. Besides, if your method is small, finding a good name is usually much easier.
For example, if you find yourself adding comments to a method's body, this is usually a good sign to extract the commented part to a new method, and use the comment as a starting point when coming up with a good name for this new method.
Commonly applied refactorings include:
If many parameters/temporary variables are present:
1 | <?php // phpcs:disable WordPress.PHP.DevelopmentFunctions.error_log_print_r |
||
72 | public function render_ui() { |
||
73 | ?> |
||
74 | <h1>XML-RPC errors</h1> |
||
75 | <p> |
||
76 | This page helps you to trigger XML-RPC requests with invalid signatures. |
||
77 | </p> |
||
78 | <?php if ( $this->dev_debug_on ) : ?> |
||
79 | <div class="notice notice-success"> |
||
80 | <p>JETPACK_DEV_DEBUG constant is ON. This means every xml-rpc error will be reported. You're good to test.</p> |
||
81 | </div> |
||
82 | <?php else : ?> |
||
83 | <div class="notice notice-warning"> |
||
84 | <p>JETPACK_DEV_DEBUG constant is OFF. This means xml-rpc error will only be reported once evey hour. Set it to true so you can test it.</p> |
||
85 | </div> |
||
86 | <?php endif; ?> |
||
87 | |||
88 | <p> |
||
89 | Now head to <a href="https://jetpack.com/debug/?url=<?php echo esc_url_raw( get_home_url() ); ?>">Jetpack Debugger</a> and trigger some requests! |
||
90 | </p> |
||
91 | |||
92 | <div id="current_xmlrpc_errors"> |
||
93 | |||
94 | |||
95 | <form action="<?php echo esc_url( admin_url( 'admin-post.php' ) ); ?>" method="post"> |
||
96 | <input type="hidden" name="action" value="clear_all_xmlrpc_errors"> |
||
97 | <?php wp_nonce_field( 'clear-xmlrpc-errors' ); ?> |
||
98 | <h2> |
||
99 | Current Unverified Errors |
||
100 | <input type="submit" value="Clear all unverified errors" class="button button-primary"> |
||
101 | </h2> |
||
102 | </form> |
||
103 | <p> |
||
104 | Unverified errors are errors that were detected but that we don't know if they are legit and came from WP.com |
||
105 | </p> |
||
106 | <p> |
||
107 | After an error is detected, we send a request to WP.COM and ask it to reach back to us with a nonce to confirm the error is legit. They do this by sending a request to the verify error API endpoint. You can simulate this request clicking on the "Verify error" buttons below. |
||
108 | </p> |
||
109 | <div id="stored-xmlrpc-error"> |
||
110 | <?php $this->print_current_errors(); ?> |
||
111 | </div> |
||
112 | <div id="verified-xmlrpc-error"> |
||
113 | <form action="<?php echo esc_url( admin_url( 'admin-post.php' ) ); ?>" method="post"> |
||
114 | <input type="hidden" name="action" value="clear_all_verified_xmlrpc_errors"> |
||
115 | <?php wp_nonce_field( 'clear-verified-xmlrpc-errors' ); ?> |
||
116 | <h2> |
||
117 | Current Verified Errors |
||
118 | <input type="submit" value="Clear all verified errors" class="button button-primary"> |
||
119 | </h2> |
||
120 | </form> |
||
121 | <p> |
||
122 | Verified errors are errors we know are legit and now we will display them to the user or do some self healing, depending on the error. |
||
123 | </p> |
||
124 | <div id="verified_errors_list"> |
||
125 | <?php $this->print_verified_errors(); ?> |
||
126 | </div> |
||
127 | </div> |
||
128 | </div> |
||
129 | |||
130 | <?php |
||
131 | } |
||
132 | |||
213 |
In PHP it is possible to write to properties without declaring them. For example, the following is perfectly valid PHP code:
Generally, it is a good practice to explictly declare properties to avoid accidental typos and provide IDE auto-completion: