These results are based on our legacy PHP analysis, consider migrating to our new PHP analysis engine instead. Learn more
1 | <?php |
||
0 ignored issues
–
show
|
|||
2 | /** |
||
3 | * Version management for database migrations. |
||
4 | * |
||
5 | * Database changes require special care: |
||
6 | * - the model has to be adjusted for users installing the plugin |
||
7 | * - the current setup has to be migrated for current users |
||
8 | * |
||
9 | * These migrations are a way to handle current users. They do *not* |
||
10 | * run on plugin activation. |
||
11 | * |
||
12 | * Pattern: |
||
13 | * |
||
14 | * - increment \PodloveSubscribeButton\DATABASE_VERSION constant by 1, e.g. |
||
15 | * ```php |
||
16 | * define( __NAMESPACE__ . '\DATABASE_VERSION', 2 ); |
||
17 | * ``` |
||
18 | * |
||
19 | * - add a case in `\PodloveSubscribeButton\run_migrations_for_version`, e.g. |
||
20 | * ```php |
||
21 | * function run_migrations_for_version( $version ) { |
||
22 | * global $wpdb; |
||
23 | * switch ( $version ) { |
||
24 | * case 2: |
||
25 | * $wbdb-> // run sql or whatever |
||
26 | * break; |
||
27 | * } |
||
28 | * } |
||
29 | * ``` |
||
30 | * |
||
31 | * Feel free to move the migration code into a separate function if it's |
||
32 | * rather complex. |
||
33 | * |
||
34 | * - adjust the main model / setup process so new users installing the plugin |
||
35 | * will have these changes too |
||
36 | * |
||
37 | * - Test the migrations! :) |
||
38 | */ |
||
39 | |||
40 | namespace PodloveSubscribeButton; |
||
41 | use \PodloveSubscribeButton\Model; |
||
42 | |||
43 | define( __NAMESPACE__ . '\DATABASE_VERSION', 2 ); |
||
44 | |||
45 | add_action( 'admin_init', '\PodloveSubscribeButton\maybe_run_database_migrations' ); |
||
46 | add_action( 'admin_init', '\PodloveSubscribeButton\run_database_migrations', 5 ); |
||
47 | |||
48 | function maybe_run_database_migrations() { |
||
49 | $database_version = get_option('podlove_subscribe_button_plugin_database_version'); |
||
50 | |||
51 | if ( $database_version === false ) { |
||
52 | // plugin has just been installed or Plugin Version < 1.3 |
||
53 | update_option( 'podlove_subscribe_button_plugin_database_version', DATABASE_VERSION ); |
||
54 | } |
||
55 | } |
||
56 | |||
57 | function run_database_migrations() { |
||
58 | if (get_option('podlove_subscribe_button_plugin_database_version') >= DATABASE_VERSION) |
||
59 | return; |
||
60 | |||
61 | if (is_multisite()) { |
||
62 | set_time_limit(0); // may take a while, depending on network size |
||
63 | \PodloveSubscribeButton\for_every_podcast_blog(function() { migrate_for_current_blog(); }); |
||
64 | } else { |
||
65 | migrate_for_current_blog(); |
||
66 | } |
||
67 | |||
68 | if (isset($_REQUEST['_wp_http_referer']) && $_REQUEST['_wp_http_referer']) { |
||
69 | wp_redirect($_REQUEST['_wp_http_referer']); |
||
70 | exit; |
||
71 | } |
||
72 | } |
||
73 | |||
74 | function migrate_for_current_blog() { |
||
75 | $database_version = get_option('podlove_subscribe_button_plugin_database_version'); |
||
76 | |||
77 | for ($i = $database_version+1; $i <= DATABASE_VERSION; $i++) { |
||
78 | \PodloveSubscribeButton\run_migrations_for_version($i); |
||
0 ignored issues
–
show
|
|||
79 | update_option('podlove_subscribe_button_plugin_database_version', $i); |
||
80 | } |
||
81 | } |
||
82 | |||
83 | /** |
||
84 | * Find and run migration for given version number. |
||
85 | * |
||
86 | * @todo move migrations into separate files |
||
87 | * |
||
88 | * @param int $version |
||
89 | */ |
||
90 | function run_migrations_for_version( $version ) { |
||
91 | global $wpdb; |
||
0 ignored issues
–
show
Compatibility
Best Practice
introduced
by
Use of
global functionality is not recommended; it makes your code harder to test, and less reusable.
Instead of relying on 1. Pass all data via parametersfunction myFunction($a, $b) {
// Do something
}
2. Create a class that maintains your stateclass MyClass {
private $a;
private $b;
public function __construct($a, $b) {
$this->a = $a;
$this->b = $b;
}
public function myFunction() {
// Do something
}
}
![]() |
|||
92 | |||
93 | switch ( $version ) {} |
||
0 ignored issues
–
show
|
|||
94 | |||
95 | } |
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.