Parent-child relationship tables (trees) can only be constructed if
the entire table is loaded. When WHERE filters are applied to the
table, the tree cannot be made, which causes #3204.
When a filter is active, a tree representation is no longer
appropriate because the filter can filter out parents of a matched
row, which breaks the concept of a tree.
To resolve this and restore search functionality, this commit disables
the sort_parent of the tree model in order to activate the
e_tree_model::getRowsList() method and avoid the tree logic entirely.
Fixes: #3204
Supersedes: #3208
e_tree_model is apparently used for flat lists as well as parent-child
relationships (trees). Trees are expected to be far smaller than possible flat
lists. Very large flat lists (10,000+ rows or greater) are rendered very slowly
because of the tree computation overhead.
This change figures out whether a flat list or a tree is requested and chooses
the appropriate code to run based on what is requested. Trees run the more
expensive code while flat lists are returned as-is.
In addition, the tree rendering code has been optimized. Optimizations:
* Unchanging tree node ID is set once instead of inside a foreach() loop
* The parent-child query is now sorted by the sort parent ID so that each move
rows to tree nodes iteration doesn't have to run through every remaining row
Fixes: #3062
Subclasses may forget to run code to do a total record count, which
leads to output showing "Total Records: 0" on some pages with lists,
like `/e107_admin/links.php`.
This commit cuts out the record counting from the getList() method of
any e_admin_form_ui subclasses and the base class so that subclasses do
not have to reimplement record counting.
The caveat with this implementation is that it violates the Law of
Demeter, as evidenced by the new chained method call:
$this->getController()->getTreeModel()->getTotal()
Jumping through two objects to get a value is not ideal, but this is the
code we have to work with at the moment.
In #3025, e_tree_model sorting was reimplemented in pure PHP, but this
broke custom sorting (like `?field=cat_name&asc=desc`).
This commit introduces a hack that simulates a subset of MySQL/MariaDB
ORDER BY clauses, which should be sufficient for all known custom
sorting that can be requested.
Tree formatting is always preserved, but custom sorting will apply for
all items at a certain depth under the same parent.
This commit also contains some minor formatting fixes and makes a minor
change to some regex to make use of non-capturing groups.
Fixes: #3029
Eliminated e107 dependency on the MySQL/MariaDB CREATE PROCEDURE permission
As a bonus, any attempt to use e107's native custom sorting (e.g.
`?field=cat_name&asc=desc`) will preserve the correct tree hierarchy. The past
behavior was to sort as requested but keep showing depth, even though the
apparent tree hierarchy would be wrong.
Fixes: #3015
Supercedes: #2929
