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.