block shows two links next to search other (Search Courses/All courses)
which point to the same place....
The all courses link is able to be switched off and the search courses is not,
for this reason i've gone for removing the search courses link.
Merged from MOODLE_19_STABLE
This is messy because the links are hidden in the configdata column, which is serialized and base64encoded. So we have to untangle that, then ask the block whether there are any bits of $config that need to be fixed, then re-encode it before backup up. And reverse that on restore. It needs to remain base64 encoded in the backup file, so that the file format is backwards compatible.
I disucssed this with Eloy before doing it.
Merged from MOODLE_19_STABLE.
Can't find it documented anywhere, but applicable_formats() is only
ever called as a class method, so it cannot say $this. Instead, say
block_admin_tree::has_admin_caps().
Dan Poltawski said:
> Previously users with different permissions could have granular
> access to the admin menu for the items they have access to, so
> limiting to only users with moodle/site:config would break that.
> Although I agree that that menu is slowww to render and needs
> fixing. Perhaps permissions for the various elements could be
> gathered and checked first
This commit addresses the problem checking for all the caps that are
mentioned by code in /admin (according to grep, at least). Some light
testing with the "moodle/user:create" seems to work properly.
This burdens us with maintaining the list in has_admin_caps() -- less
than ideal, but easier than rewriting /admin.
Saves >10DBq and 18 includes at the homepage for all nonadmin users.
For non admin users, this makes the homepage _much_ more lightweight.
Before: inc 101 DBq 51 time 1.2s
After: inc 76 DBq 36 time 0.2s
So this commit shaves 1 full second for the non-logged-in homepage.
Still pretty bad on the includes, but shaved a good 25 files and 15 DBqs.
