Blocks

Hi Rosario

Suspect the Fatal error I reported may have been due to something else I had been doing on Moodle, so may have been a false alarm.

Thanks for your detailed explanation of the performance issues. That said, when just displaying categories on the front page, the Site Navigation block is performing well.

Thanks again!

With YUI-Library treeview and what is called XHR request (XMLHttpRequest), now it is possible to asynchronously and dynamically load/reload only desired parts of a web-page. See my post below.

Rosario

Would be possible to show the number of courses at the end of the category link, as earlier promoted?

>>I just discovered a little shift in the display of the siteNavigation tree when the block is displayed in a course.

Today I saw that the display remains correct in FireFox. It is only in Internet Explorer that there seems to be a problem. And I just realized that this problem exists only if the myCourses block precedes the siteNavigation block. So to avoid displaying problems in IE work around it by either setting the myCourses block BELOW the siteNavigation block or on the opposite side.

Rosario

Dear Julian,

as you can see, there still remains some work to do until I will feel ready to release both blocks in the Modules and Plugins database.

And yes, I will need your help to upload everything there. But I guess this will not be before Christmas.

Thanks a lot for your ideas and assistance, and all the work you did to keep alive the FN myCourses block.

Rosario

After testing a little bit and studying the YUI-documents and best practices for speeding up web pages, I have to retain these points:

1. there is a means of dynamically loading the contents of a node in the treeview which would help us speed up the rendering of the whole tree on medium to large scale sites. Have a look at an example here: http://developer.yahoo.com/yui/examples/treeview/dynamic_tree.html
2. there is the possibility to load the tree, as I considered already in previous posts, as a file

What are the benefits and drawbacks?

1. would be the fastest solution because it would render only the root categories all collapsed, i.e. on our site with more than 900 categories only the first 15 categories would appear. These categories represent each one University and some special places for teachers and students. Getting the root-cats from the database with Moodle-API-calls is very fast. But as soon as we delve into all nested cats to retrieve cats and courses, the looping and recursive queries go up to 1'800 DB queries if I show only our 900 cats. The JavaScript Code generated would consist only of a few lines and would be fast to load and execute. The main drawbacks are: the so called XHR request (or XMLHttp Request) allows for asynchronous requests dynamically based on what the user does, e.g. clicking on a node to expand in our tree. Of course, again, such a request would only execute the DB-queries needed to represent the next level of nodes and courses contained in only one node, the one that is going to be expanded, and hence would be fast as desired. Nevertheless the user experience would be the one of click-and-wait as you can test yourselves in the yui-example above. The complexity of the code on the server-side would grow a little bit beyond the code of a "simple" block. But fortunately we have everything we need in the myCourses block, so that we can reuse its interface for Admins and Teachers to compose XHR requests to load and expand nodes dynamically. The other big big drawback is that the trees and nodes must be rendered and composed for every user and every page visited, which consumes the same resources in a too expensive manner. But I must admit that this is still a very elegant and very tempting solution.
2. on the other hand, loading a file, in our case, loading the file with the javascript necessary to render the whole tree, remains the most efficient solution in terms of resources because the file has to be produced only on a time schedule, lets say every 3 hours, and can then be used by every user on every page he visits. In the cited best practices for speeding up web pages you will find also the advice to load javascript files because they can be cached by the user's browser (versus embedding the javascript code directly into the HTML-file). So this technique would really speed up things in our case as the siteNavigation tree to be rendered on every course page is the same and could hence be cached by the user's browser. Technically speaking I would add another Admin config option, lets say block_siteNavigation_composetreedelay. This way you could type in from 1 to 24 hours. The code would then test whether the desired delay has expired and would compose the tree anew and store it in the javascript file to be loaded by the client browser. If the delay would have not expired the file would not be generated.

It is still difficult for me to decide which of both solutions is the one to realize. On one hand we are working on a highly dynamic system, like every database-system is per definition, which means we should fetch every information on the fly from the database. On the other hand the whole siteNavigation Tree, or the site-map, does not change every few seconds, does it? So even if we compose the tree every hour we can save a lot of resources compared to the actual solution and compared even with solution 1) above.

If you have suggestions, feel free to comment here.

Rosario

I am banging my head against a wall to find the good decision. Please help me:

• of course siteNavigation and myCourses can still be displayed as before, but in one block instead of two (for those who want to continue with two separate blocks, I can continue to support the 1.9.07 line which has come to an acceptable end stage anyway)
• independently of the display, there are two major issues:

1. should we keep the blue, orange and grey toggles for admins and teachers to toggle on/off the display of their active, inactive and for admins ALL courses? If yes, this will be a problem when displaying the blocks in their popUp-Windows because technically speaking a click on one of the buttons sends a request to the server and the response goes back to the main window and not to the popUp-Window. So if we stick on it, I must find a solution first. On the other hand, I was always against it because in my opinion admin-accounts are meant for admin operations and not to enrol in courses. To enrol in courses as teachers and students, admins should use separate accounts so as to separate things completely at role level. What I wanted to add to the myCourses Block anyway, was a means for the students to display only the courses they really want to see, which would free them from the teachers forgetting to unenroll students from old courses or wanting to keep them in because of the grades, which makes the myCourses list grow longer and longer with each semester in our universities. So this would mean to develop a new solution anyway.
2. to display the siteNavigation and the myCourses lists in popUp windows, I have to write the whole output to files and if I write to files, there comes up another question: how do we delete the old files? Normally you do this simply with a nightly cron-job like rm *_siteNavigation.html and rm *_myCourses.html, but I am not sure whether you all have the means to run your own server and add such a cron-job. I already explained the performance blast we get by writing and reading the output into/from files instead of composing the same output on every course page the users visit. But technically speaking we never know when the user quits the session without using the logoff button/link. So these files are going to be orphaned in the $CFG->dataroot/1/ directory. If we decide to create the siteNavigation file only once a day or at predefined time intervals of 15 minutes to 6 hours, there is no problem to use always the same file and create it after the given time intervals expire. But it is different for the myCourses files because they are individual and we never know when the users quit. Of course we could use always the same user's file, e.g. username_myCourses.html, but only the active users files would be reused this way. The users you delete from Moodle would leave an orphaned username_myCourses.html file. So my best offer is to resolve that case with cron-jobs. Using cron-jobs to nightly purge the siteNavigation and myCourses files means also that we can use admin options to control the generation of the siteNavigation tree. Eg. a time interval of 0 (zero) means that the tree is generated on the fly when the users log in. This is how it was handeled before with the only difference, that the tree is only generated once for every user session and not on every page he visits. A time interval of 1 and more minutes means that we generate only ONE siteNavigation file for all users to use, at the given time interval. For those who have no means of controlling their own server I could leave the display of both trees in one block, i.e. without popUp windows, as it was before. So there would be no gain in performance and hence this would remain a solution only for small to medium sized sites. Starting with more than 1'000 courses, siteNavigation can only be used to display the categories as I did until now on my own site (https://moodle.fhnw.ch, no login required to navigate through the roughly 1'000 deeply nested categories). And starting with more than 2'000 courses the siteNavigation can no longer be displayed on every course page because it would take too long to render even in category-only mode. At the same time this display could be used by those admins who want to keep the blue, orange and grey buttons. (At least until I find a solution to do it also in the popUp windows, if there is a solution)

Let me know, if you have suggestions, and keep watching development on my test server: https://moodle.fhnw.ch/moodleTest

Rosario

And as I just realised and expressed earlier here, the navigation is very complicated and complex to track as it is part of the big $PAGE object. I think that trying to change any bits in this complex is too risky as it affects quite a lot of core files and is no longer encapsulated for its own in a separate block. The block_navigation actually does only the rendering part as dockable block. Regarding speed I saw that the navigation is initialized only once per user session and then fetched from cache on every subsequent course page, but I should test the rendering speed on my medium sized site.

So for the moment I have no clue on how to realize cookie support, popUp-windows and other features of my siteNavigation in 2.x Maybe the best would still be to program an own block, we could use as alternative to the built in navigation.

Rosario (slightly frustrated)

No problem, the different versions are kept for download, look in the DOWNLOAD VERSIONS Tab

https://moodle.org/plugins/pluginversions.php?plugin=block_sitenavigation

Just uploaded Version 23.02 as I had to rewrite the code for storing the user session-files outside the yourMoodle/data directory when using the popUp-Window mode. This was necessary because in Moodle 2.3 the new file API does no longer serve files with file.php