`wp_get_installed_translations()` was introduced in WP 3.7. This change returns an empty result for the translations list if the function does not exist. (Encountered in the wild, fatal error).
The code that builds API URLs is probably complicated enough to warrant a separate method: it performs placeholder substitution, does authentication-related stuff (access_token), and builds the query string.
Behaviour change: An empty path now returns the collection itself, not the default value. This doesn't really matter for the current version because it only uses constant, non-empty paths.
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.
David Anderson
Yahnis Elsts
aaronlad
Laptop 3
Nicolas GEHIN