I want to filter the wp_remote_get result. In my use-case, if https fails, I switch back to http (in case the user had a bad curl setup/obsolete SSL certificates) and try again.
Until now I've been patching the code, but that is, of course, silly!
Some hosts disable set_time_limit() and a few other functions. Calling the disabled function triggers a warning. In our case, using set_time_limit() is optional - PUC will usually work fine even if it can't increase the time limit - so lets just ignore the warning and carry on.
Reported in #111.
Cause: Debug Bar 0.9 now includes an admin bar menu that lists the available panels. This means that the special element that PUC uses to identify its panel titles (<span id="puc-debug-menu-link-$uid">) is no longer unique. This breaks the JS that's supposed to work around the fact that Debug Bar incorrectly assumes that every panel will have a unique PHP class name.
This may look like a lot of changes, but it's essentially a simple search & replace from "v4" to "v4p1". Note that the factory class name stays the same: Puc_v4_Factory. It will only change on a major release.
This is workaround that addresses a potential issue with automagic plugin vs theme detection. A user reports that sometimes get_theme_root() can return an empty string when using AMP. Also, there can be multiple theme roots.
Instead of dealing with that mess, lets simply look for a style.css file in the same directory as $absolutePath. This approach has low specificity (i.e. a plugin could have a style.css file), so it should have lower priority. I've moved it after the isPluginFile() check.
BC note: This means that when using PUC in a theme, the second argument to buildUpdateChecker() *must* be either the theme directory path, or a path to a file at the root of the theme. That is, all of these will work fine:
/foo/wp-content/themes/my-theme
/foo/wp-content/themes/my-theme/functions.php
/foo/wp-content/themes/my-theme/another-php-file.php
This will NOT work:
/foo/wp-content/themes/my-theme/includes/something.php
This shouldn't be an issue for people who followed the documentation.
Possible uses:
- See when it's safe to raise PHP version requirements.
- Avoid showing users updates that are incompatible with their PHP version.
- Have an LTS branch for people running old PHP versions, and deliver different update packages based on the version.
- Return updates for only those language packs that match the site locale, not all available languages.
Previously, PUC didn't specify any explicit sorting criteria. I incorrectly assumed that BitBucket would return the most recent tags first. As a result, when a repository had enough tags to trigger API response pagination, PUC could miss some recent tags. Related: #48
Technically, it's possible to place a plugin anywhere outside the WordPress directory and then create a symlink inside /wp-content/plugins that points to the plugin directory. If the plugin developer then passes the real, symlink-resolved path to the PUC factory, PUC will assume it can't be a plugin because it's not inside the expected directory.
Semi-fixed by checking if the input file contains a valid plugin header. However, I would still recommend against using symlinks in this manner because it's likely to cause odd bugs elsewhere. For example, __FILE__ resolves symlinks but plugin_basename() doesn't. This means that the basename that WP sees and the basename you generate in your own code might not match.
get_user_locale() is not available in older WordPress versions. Also, according to WP docs, load_plugin_textdomain (and, presumably, its siblings) should be called in `init` or later.
The code that updates the OAuth signature didn't account for the fact that the oauth_signature query parameter would end up in the wrong place. Instead of being sorted alphabetically with the rest of parameters, it must be the *last* one.
Apparently "latest compatible version" is a more common expression than "greatest compatible version". Also, lets move away from the idea of using the factory class to build anything other than update checker instances; it's probably not necessary.
Move most GitHub and BitBucket stuff to a general "VCS checker" class and put service-specific logic in API classes that follow a common interface.
Rationale: Upon further reflection, there's no need to have different theme & plugin checker implementations for each Git hosting service. The overall update detection algorithm stays the same. Only the API and authentication are different.
Not entirely happy with the code duplication in Vcs_PluginUpdateChecker and Vcs_ThemeUpdateChecker. Traits would be one solution, but can't use that in PHP 5.2. There's probably a "good enough" way to achieve the same thing through composition, but I haven't figured it out yet.
For private GH repositories, use setAuthentication('access_token_here') instead of setAccessToken().
We don't need two different implementation for GitHub and BitBucket, they use the same property name. But lets make the property configurable anyway in case other APIs do differ.
Refactor requestUpdate() filtering.
Rename getFilterName to getUniqueName because it's used for more than just filter names.
Added a couple of utility methods.
- Refactor the scheduler so that it can be used in themes.
- Add state storage to the base update checker.
- Move the "allow metadata host" workaround to the base class.
- Rename cron hook from "check_plugin_updates-$slug" to "puc_cron_check_updates-$slug" and "tuc_cron_check_updates-$slug".
David Anderson
Yahnis Elsts
Laptop 3
Nicolas GEHIN