This new parameter / property will decide if we want to reduce
the run data before processing it:
- By default it will be disabled in table mode.
- By default it will be enabled in graph mode.
- The defaults can be changed by adding reducedata=[0|1] in the URLs
- Once data reduction is enabled, it stays enabled while
navigating within the xhprof reports.
This covers the 2 new functions with unit tests:
- xhprof_topo_sort()
- reduce_run_data()
Note that the example graph used in the provider is the
one shown in the issue to explain the reduction procedure.
Here we are reducing the xhprof runs data by removing the
__Mustache==>__Mustache calls and all the orphaned data.
To save N iterations what we are doing is:
0. The information is "topologically" sorted, so we ensure that
all the parents in the data are processed before the children.
(this will help a lot when cleaning orphaned data, see below).
1. First pass, all the candidate (by regexp) calls are removed
from the run data.
2. Second pass, all the orphaned information (calls that have
ended losing his parent) are also removed, so data is consistent.
Note that, normally we would need N passes to remove all the
orphaned data (because each pass creates new orphan candidates),
but, as far as we have ensured that the information is topologically
sorted (see point 0 above), all this can be done in one unique pass.
TODO:
- Add unit tests.
- Enable some system to be able to decide which utilities we
want to get the data reduced and which ones will continue
using the complete data. Right now the reduction is being
applied to all the utilities (both table and graph views).
- Document the change and, if implemented, the way to select
between complete/reduced data.
- Consider adding some caching to speed-up the reduction process
(some TODOs have been left in the code pointing to the critical
points).
The external test file URL concerns itself only with HTTP_USER_AGENT
matching, not sending response headers, which can differ according to
HTTP protocol in use by the endpoint (1.1 vs 2).
Given the returned response code itself is irrelevant to the testcase,
there's not much benefit to asserting it and risking random failures.
The above syntax is defined as supported by the class, for example the
format '5/10' means:
"At every 10th <unit> from 5 through <max>."
It is analogous to '5-<max>/10'.
Instead of doing an exact checking of the page title in
\behat_hooks::before_step(), do a more lenient check by checking that
the page title contains the acceptance test's site name.
* Use the page title separator constant when displaying the page title
during upgrade and installation.
* No need to display the site name during install when because it hasn't
been set at this point.
* Page titles should display the most unique information first. For
admin pages it would be useful to display the information that
is unique to the page first before the broader categories that the
page belongs to.
* Also use the new page title separator constant.
MDL-78806 core: Remove redundant site name on page titles
* With the site name now being appended to the page titles, there
is no need to manually append the page titles.
The `contextid` argument of the `tiny_equation_filter` AJAX call is
hardcoded to 1, which causes trouble if the context table does not start
with id 1.
Signed-off-by: Gregor Eichelberger <gregor.eichelberger@tuwien.ac.at>
Read-only forms do not belong to a <form> element, so we can't refer
to that. Instead find the `.mform` element (which exists for regular
and read-only forms).
While, right now, sites using long (> 10 chars) $CFG->prefix
can continue working (because we still don't have any table
> 28 chars), as soon as some new table with long name is added,
it won't work with PostgreSQL anymore (if the 63 limit is raised).
Hence, this environmental check will verify on both install and
upgrade that the $CFG->prefix is always <= 10 chars.
Sites with longer prefixes will need to rename all their tables
(and maybe other objects, depending on the dbtype) to use a shorter
prefix.
