-
Notifications
You must be signed in to change notification settings - Fork 16
Fix Composer version issues #16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from 3 commits
5c46cc0
9b3824f
5e3d309
9d33b9b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1 +1,2 @@ | ||
| vendor | ||
| vendor | ||
| /.idea | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -52,7 +52,28 @@ $wps['run']->silenceErrorsInPaths( '~^((?!/my-plugin/).)*$~', E_NOTICE | E_WARNI | |
| // Silence for plugins _except_ specific plugin. | ||
| $wps['run']->silenceErrorsInPaths( '~/wp-content/plugins/(?!my-plugin)~', E_NOTICE | E_WARNING ); | ||
| ``` | ||
| ### Testing a fatal error state | ||
|
||
|
|
||
| If you desire a method to test that the plugin is installed correctly, you can [create a simple mu-plugin](https://developer.wordpress.org/advanced-administration/plugins/mu-plugins/). At `/wp-content/mu-plugins` create the file `trigger-fatal-error.php`. Add the following code: | ||
|
|
||
| ```php | ||
| /** | ||
| * Plugin Name: Trigger Fatal Error | ||
| */ | ||
| add_action('wp_loaded', function () { | ||
| if( | ||
| isset($_GET['triggerFatalError']) && | ||
| WP_DEBUG && | ||
| WP_DEBUG_DISPLAY | ||
| ) { | ||
| noSuchFunction(); | ||
| } | ||
| }, 1); | ||
| ``` | ||
|
|
||
| On the frontend of your site, trigger an error by appending `?triggerFatalError=true` to your URL. | ||
|
|
||
| Like Whoops, this should only be used in a non-production environment. | ||
|
|
||
| ## License | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -20,12 +20,17 @@ | |
| "issues": "https://github.com/Rarst/wps/issues" | ||
| }, | ||
| "require" : { | ||
| "php" : ">=5.5.9", | ||
| "composer/installers": "~1.6", | ||
| "php": "^7.2 || ^8.0", | ||
| "composer/installers": "^v2.3.0", | ||
|
Owner
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've been thinking about just bumping this... But also pondering is there any downside to keeping v1 installers allowed (as OR)? I mean if I could work on it right now, I'd review a whole plugin and bring it up to date. But since I don't/can't I don't really want to raise floor on PHP version without due diligence.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think my recommendation here is that if someone needs the older version of the installers, they can easily do so by limiting the version of the package that is installed. Bump this version as a breaking change, and tag it as such?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Automattic/WP.org is pushing PHP v7.4 as the minimum required version. It's certainly possible to run it in older environments... To me version bumping, tagging and releasing under 2.x would both make sense and align with WP overall. 🤷♂️ |
||
| "filp/whoops" : "^2.3.1", | ||
| "pimple/pimple" : "^3.2.3" | ||
| }, | ||
| "autoload" : { | ||
| "classmap" : ["php/"] | ||
| }, | ||
| "config": { | ||
| "allow-plugins": { | ||
| "composer/installers": true | ||
| } | ||
| } | ||
| } | ||
| } | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change not relevant.