This issue covers migrating the existing format functions into a new class for calling.

One of the issues we currently face is that we have a combination of uses of both:

• format_string; and
• external_format_string.

The main difference between these is that:

• for format_string filters are enabled by default
• for external_format_string filters are disabled by default.

This sounds easy at a first glance until you consider the fact that many WS call standard libraries whichi use the standard format_string method rather than the external_format_string method, which can lead to partially-filtered content.

This issue is looking to add a new class, \core\formatting, and migrate the content of the existing format_string, format_text, and any other related methods there.

Further to that I'm looking into the feasability of adding a set of static methods for:

• enable_filters(): void
• disable_filters(): void
• filters_enabled(): bool

The intent being that rather than the external_format_stirng method disabling filters by default, we disable them in the web service chain - that is, in an earlier part of the API.

For the new WS framework we are implementing the intent is to support enabling/disabling filters by setting an appropriate request header, similar to how a client may specify the Accept (HTTP_ACCEPT) (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept header to a value such as application/json. For example FilterContent with a boolean-like value. This will allow the client to decide whether content is filtered (note, the actual filters which are applied will not change).

Ideally we should also allow provision of fields required to rewrite pluginfile URLs and allow format_text to have the same API for both web and external usage.