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".
The readme.txt format that's used by WordPress is not quite standard Markdown. It includes a couple of features that are not directly supported by popular Markdown parsers. One of those features is parsing "= string =" as "<h4>string</h4>" (the opening "=" must be at the start of the line). Leading whitespace is allowed. This syntax is typically for plugin version numbers in the changelog section.
The problem: the readme parser discards leading whitespace when parsing these headers. This means it can also discard the previous line break character(s). As a result, this markup:
* abc
= 1.2.3 =
* def
Becomes this:
* abc
<h4>1.2.3</h4>
* def
The way that Parsedown handles this markup is to make the H4 a part of the preceding list item. And that's a bug.
Fixed by keeping leading whitespace instead of throwing it away.
Closes#68
Yahnis Elsts
Nicolas GEHIN