Skip to content
Open
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion .gitignore
Original file line number Diff line number Diff line change
@@ -1 +1,2 @@
vendor
vendor
/.idea
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change not relevant.

21 changes: 21 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm. I don't think this warrants readme space. WordPress installs are... rarely in a state when getting an error is a problem. :)


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

Expand Down
11 changes: 8 additions & 3 deletions composer.json
Original file line number Diff line number Diff line change
Expand Up @@ -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",
Copy link
Owner

Choose a reason for hiding this comment

The 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.

Copy link
Author

Choose a reason for hiding this comment

The 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?

Copy link
Author

Choose a reason for hiding this comment

The 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
}
}
}
}
Loading