Bumped to a major bug. This actually triggers a mass flood of ORDERBY_HACK attacks just for one request, so one request could cause a user to get banned. Probably a separate bug in of itself.

Automated response: Screens using main_multi_content may trigger ORDERBY_HACK

A fundamental issue with how Composr was handling sorting resulted in some sorts triggering ORDERBY_HACK when the relevant template utilised main_multi_content.

This fix makes a major refactoring of how sorting is done:

- content.php now also implements sorting capabilities on an abstract level for id, title, category, image, author, submitter, add date, edit date, views, and order fields.
- Some fallback sorts have been defined, so if we attempt to sort on a field which is not allowed, and we are not triggering a hack attack for it, then we will fall back to something we can sort by.
- Content and resource hooks now define a additional_sort_fields property. This is a map of sortable name to custom SQL (without direction) (null: name of sortable is a field, and we want to sort directly on that). Also supports mapping a sortable name to a map of ASC and DESC to define separate SQL for ASC sort versus DESC sort, or when the module itself handles sorting instead (value of each will be blank).
- These have been added to codebook_standards

Sortables on database rows which are not content nor resources shall not use this standard and shall continue to operate as they previously did in v10. However, standards now expect that names of sortables never contain raw SQL queries anymore (for security reasons).