wordpoints / beta-tester

WordPoints extension for beta testing the WordPoints plugin.

WordPoints

This is where development of the WordPoints WordPress plugin takes place. To download the latest stable release, seek support, or for more information about the plugin, see its home on WordPress.org. You may also want to visit the plugin's website, where you'll find user and developer documentation.

Reporting a bug

If you find a bug in the plugin, please report it here. Before opening a new issue, always be sure that you have searched the existing issues to make sure your bug is new. In your report be as detailed as possible, and be sure to include a list of steps to reproduce the bug. Please also give as much information as you can about your WordPress install and its envireonment: WordPress and PHP versions, active plugins, etc.

Whatever you do: never, ever report a bug for an old version of WordPoints. Make sure that you have the latest version installed before filing an issue. If possible, test that the bug exists in the development trunk as well.

If you aren't sure what all that means (or sometimes maybe even if you are) you should probably seek help in the support forums instead.

Security

See SECURITY.md.

Contributing

See CONTRIBUTING.md.

beta-tester's Issues

Show correct version number

Right now we don't show the correct version number initially. That is if the user is on a different version than the master branch. We just show the current version number as the new version.

Uninstall

We should clean up what little stuff we add on uninstallation.

Notice when updating using shiny updates

With the new shiny updates we get an error when updating:

[25-Jul-2016 20:10:30 UTC] PHP Warning:  opendir(/Users/johngrimes/svn/wordpress/trunk/src/wp-content/wptests-local//plugins/src): failed to open dir: No such file or directory in /Users/johngrimes/svn/wordpress/trunk/src/wp-admin/includes/plugin.php on line 259
[25-Jul-2016 20:10:30 UTC] PHP Stack trace:
[25-Jul-2016 20:10:30 UTC] PHP   1. {main}() /Users/johngrimes/svn/wordpress/trunk/src/wp-admin/admin-ajax.php:0
[25-Jul-2016 20:10:30 UTC] PHP   2. do_action() /Users/johngrimes/svn/wordpress/trunk/src/wp-admin/admin-ajax.php:91
[25-Jul-2016 20:10:30 UTC] PHP   3. call_user_func_array:{/Users/johngrimes/svn/wordpress/trunk/src/wp-includes/plugin.php:524}() /Users/johngrimes/svn/wordpress/trunk/src/wp-includes/plugin.php:524
[25-Jul-2016 20:10:30 UTC] PHP   4. wp_ajax_update_plugin() /Users/johngrimes/svn/wordpress/trunk/src/wp-includes/plugin.php:524
[25-Jul-2016 20:10:30 UTC] PHP   5. get_plugins() /Users/johngrimes/svn/wordpress/trunk/src/wp-admin/includes/ajax-actions.php:3684
[25-Jul-2016 20:10:30 UTC] PHP   6. opendir() /Users/johngrimes/svn/wordpress/trunk/src/wp-admin/includes/plugin.php:259

The update succeeds though.

The issue is that destination_name is still pointing to src, while we've of course renamed the plugin to its correct name. We can't really modify the destination_name after the update has completed, so I'm not sure how we'll fix this.

Stop adding filter to set `sslverify` to true during requests

This appears to be redundant, as true is already the default value for this parameter. The inline docs don't seem to indicate why we did this to start with. I suppose that we should try to figure that out before we remove this though. I believe that it must come from the GitHub updater plugin that we based this off of. The only thing that I can think of is that maybe there was concern that something would set sslverify to false, causing requests to fail. But that doesn't really make sense, because the filter priority is just 10. Either that or WordPress used to default that to false. Which is possible, I guess, though I haven't checked yet.

`develop` is now the WordPoints beta branch

See WordPoints/wordpoints#643.

Add unit tests

We really need unit tests here.

Give a warning if the build is broken

We should check the build status, and at least give users a warning if the build is broken. Maybe even disable updates until it is fixed.

Allow different branches other than master to be updated

Right now it just tracks the master branch. We should introduce a UI, or at least some filters, that will allow the user to change to, e.g. a point-release branch instead.

PHP Notice when checking for updates

I think this is only for WordPress 4.2 with shiny updates (see https://core.trac.wordpress.org/ticket/29820#comment:71). It's possible that this will change before 4.2 is released.

 PHP Notice:  Undefined index: plugin in /Users/johngrimes/svn/wordpress/trunk/src/wp-admin/includes/update.php on line 279
 PHP Stack trace:
 PHP   1. {main}() /Users/johngrimes/svn/wordpress/trunk/src/wp-admin/plugins.php:0
 PHP   2. WP_List_Table->display() /Users/johngrimes/svn/wordpress/trunk/src/wp-admin/plugins.php:473
 PHP   3. WP_List_Table->display_rows_or_placeholder() /Users/johngrimes/svn/wordpress/trunk/src/wp-admin/includes/class-wp-list-table.php:946
 PHP   4. WP_Plugins_List_Table->display_rows() /Users/johngrimes/svn/wordpress/trunk/src/wp-admin/includes/class-wp-list-table.php:1016
 PHP   5. WP_Plugins_List_Table->single_row() /Users/johngrimes/svn/wordpress/trunk/src/wp-admin/includes/class-wp-plugins-list-table.php:374
 PHP   6. do_action() /Users/johngrimes/svn/wordpress/trunk/src/wp-admin/includes/class-wp-plugins-list-table.php:632
 PHP   7. call_user_func_array() /Users/johngrimes/svn/wordpress/trunk/src/wp-includes/plugin.php:496
 PHP   8. wp_plugin_update_row() /Users/johngrimes/svn/wordpress/trunk/src/wp-includes/plugin.php:496

Doesn't work correctly for bulk updates

When plugins are being updated in bulk, the update doesn't work properly. In our source selection filter we don't detect that the plugin is being updated, with the result that the entire download is copied, instead of just the /src directory.

Add Channel and ID module headers

Use dev-lib

PHP Notice when viewing update details

When you click on the "View version X details" link, this notice is given:

[16-Mar-2015 20:35:39 UTC] PHP Notice:  Undefined property: stdClass::$name in /Users/johngrimes/svn/wordpress/trunk/src/wp-admin/includes/plugin-install.php on line 420
[16-Mar-2015 20:35:39 UTC] PHP Stack trace:
[16-Mar-2015 20:35:39 UTC] PHP   1. {main}() /Users/johngrimes/svn/wordpress/trunk/src/wp-admin/plugin-install.php:0
[16-Mar-2015 20:35:39 UTC] PHP   2. do_action() /Users/johngrimes/svn/wordpress/trunk/src/wp-admin/plugin-install.php:67
[16-Mar-2015 20:35:39 UTC] PHP   3. call_user_func_array() /Users/johngrimes/svn/wordpress/trunk/src/wp-includes/plugin.php:496
[16-Mar-2015 20:35:39 UTC] PHP   4. install_plugin_information() /Users/johngrimes/svn/wordpress/trunk/src/wp-includes/plugin.php:496

Texturize the changelog text through the GitHub API

That would transform ticket references into links automatically, etc.

Show update inforamation

We should be showing the correct update information when the user clicks the link to view the changelog. A list of the intervening commits would suffice.