Thanks for spotting this issue! We had wbformatvalue on our radar as well. Getting it to work as long as datatype or property are provided should be straightforward. I'll make a patch!

In T360603#9704577, @Physikerwelt wrote:

Maybe this also applies to extension MathSearch?

If I'm not mistaken there is already a field in DataTypeDefinitions for exactly this purpose called parser-factory-callback. From the docs: "ValueParser for this data type" which is what we want. Looking through the code, this field so far was effectively only used for *value* type definitions. A few extensions do use it (codesearch) for data type definitions, but most (all of the ones active on wikidata) only copied the default code for the corresponding value type, which doesn't have any effect.

@Ifrahkhanyaree_WMDE I don't think this should apply to PATCH entities/properties/property_id. Any modification of a statement ID, or an attempted creation of a statement with an ID should result in a statement-id-not-modifiable error when patching a property IMO.

Yes, thanks!

In T350338#9631643, @Jdlrobson wrote:

This test is not supposed to be skipped - it is supposed to act as a safe guard for performance so any increase should be investigated. I'll resolve once this has been restored.

I will investigate what and how this increased.

Product-verifiable on beta: https://wikidata.beta.wmflabs.org/w/rest.php/wikibase/v0/property-data-types

I don't think this needs to be a train blocker. We just agreed in a meeting with our PM (cc @Ifrahkhanyaree_WMDE) that we're fine with it being broken for a week given this is all still considered experimental. Patch requests using application/json as the content type still work, only application/json-patch+json doesn't.