#5909 - Screens using main_multi_content may trigger ORDERBY_HACK
| Identifier | #5909 |
|---|---|
| Issue type | Major issue (breaks an entire feature) |
| Title | Screens using main_multi_content may trigger ORDERBY_HACK |
| Status | Completed |
| Tags |
Roadmap: v11 (custom) |
| Handling member | PDStig |
| Version | 11 beta4 |
| Addon | core |
| Description | Screens which use main_multi_content (e.g. downloads, galleries) may trigger an ORDERBY_HACK.
This is because these modules may have their own custom sorting columns which do not use the banal ones defined in sources/content.php . This gets passed in as a parameter into the main_multi_content block which is then read by handle_abstract_sorting and then triggers an ORDERBY_HACK . This effectively breaks anything using main_multi_content if the default sort order is set to a non-banal sort. Fixing this is beyond my complexity. Adding in the column names into allowed_sorts would fix the issue but introduce another bug where read_abstract_sorting_params is expected (by handle_abstract_sorting) to return a banal sort but instead returns an explicit column name. Furthermore, there may be cases where it is impossible to resolve without doing some big refactoring (e.g. downloads has a file_size sort which does not match any banal sorts nor is it defined as a content_meta_aware field). |
| Steps to reproduce | |
| Additional information | Temporary workaround: Comment line 901 out in sources/content.php "log_hack_attack_and_exit('ORDERBY_HACK');" (after "if (($strict_error) && (!in_array($url_sort, $banal_default_sorts))) {"). This will prevent false-positive ORDERBY_HACK errors and instead fall back to using the first acceptable sorting mechanism. |
| Funded? | No |
| Commits | Refactor sorting (e24d7ca3) · Commits · Composr ecosystem / Composr · GitLab |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".


Comments
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).