Metadata format about wp-update-server HOT 4 CLOSED

I don't think making the APIs use the same format would be particularly worthwhile.

• The WP.org plugin information API is very sparsely documented. As far as I can tell, stuff like available fields, date/time formats and field size limits are not listed anywhere. It is impossible to build something to spec if there is no spec. At best, you can try to study the API responses and figure out the format empirically (but you'll never know if you did it correctly since there is no standard and no test suite).
• I expect that many plugin authors will add custom fields to the metadata anyway. For example, for commercial plugins you might want to append license information to the update, or add some kind of an authorization token.
• The official API has a few fields that don't really apply to many third-party plugins, like user ratings, download counters and donation links.
• Finally, the API contains some design decisions that I personally disagree with such as naming the download URL download_link and combining the author name and homepage in a single author field.

from wp-update-server.

The WP.org plugin information API is very sparsely documented. As far as I can tell, stuff like available fields, date/time formats and field size limits are not listed anywhere. It is impossible to build something to spec if there is no spec. At best, you can try to study the API responses and figure out the format empirically (but you'll never know if you did it correctly since there is no standard and no test suite).

True enough, however, that is what you try to emulate with the toWpFormat() methods anyway.

I expect that many plugin authors will add custom fields to the metadata anyway. For example, for commercial plugins you might want to append license information to the update, or add some kind of an authorization token.

Absolutely correct, but leaving non-standard fields in place shouldn't be a problem. It's the standard fields which now provide data in a non-standard way which is.

The official API has a few fields that don't really apply to many third-party plugins, like user ratings, download counters and donation links.

We could either leave them out, leave them empty or possibly use server download stats and the like to fill them.

Finally, the API contains some design decisions that I personally disagree with such as naming the download URL download_link and combining the author name and homepage in a single author field.

Yeah, those are weird, but there's lots more weird stuff in WP in general and we still choose to use it, so we might as well try to comply with it.

from wp-update-server.

True enough, however, that is what you try to emulate with the toWpFormat() methods anyway.

Yes, because that's required to integrate with WP. That doesn't necessarily mean it's a good idea to try to use the same format for the external update API.

Having a well-defined metadata format and a converter that transforms it to the not-as-well-defined format used by WP seems more maintainable than trying to make the two formats identical. If WP decides to change the format or the internal update logic, I only have to fix the converter. On the other hand, if the formats are supposed to be identical and the "official" format changes, every plugin developer using this library has to change their metadata files to match the new format.

Absolutely correct, but leaving non-standard fields in place shouldn't be a problem. It's the standard fields which now provide data in a non-standard way which is.

There are only two or three such fields, anyway.

Yeah, those are weird, but there's lots more weird stuff in WP in general and we still choose to use it, so we might as well try to comply with it.

Well, I guess that's a matter of opinion. I use the weird stuff in WP (by necessity), but I try to make better stuff if I can :)

from wp-update-server.

Fair enough, I won't spend any time on this as a whole then, but will concentrate on the specific things I need in the child implementation.

Well, I guess that's a matter of opinion. I use the weird stuff in WP (by necessity), but I try to make better stuff if I can :)

Me too, like with patches to core and PRs to plugins and the like ;-)

from wp-update-server.