Debates comenzados por Tim Hunt

Imagen de Core developers Imagen de Documentation writers Imagen de Particularly helpful Moodlers Imagen de Peer reviewers Imagen de Plugin developers

https://webaim.org/projects/screenreadersurvey8/. For me, the three most interesting graphs are:

"Which of the following is your primary desktop/laptop screen reader?"


"When trying to find information on a lengthy web page, which of the following are you most likely to do first?"


"When navigating a web page by headings, how useful are the heading levels (e.g., "Heading 1", "Heading 2", etc.) to you?"


Promedio de valoraciones:Useful (5)
Imagen de Core developers Imagen de Documentation writers Imagen de Particularly helpful Moodlers Imagen de Peer reviewers Imagen de Plugin developers

For years, it has been possible to add tags to questions in the question bank. Then in Moodle 3.5 (thanks to the MUA) it became possible to use tags to randomly select questions to fo into quizzes.

Then, in Moodle 3.6 we added the ability for questions and categories to have an idnumber (because we wanted it for the Embed questions filter).

However, until now, those things have not been displayed in the question-bank interace, which makes it more difficult than necesasry to organise things.

I dicided to have a go at fixing that, and here is what I have managed so far. Comments welcome sonrisa

Also, when adding questions to the quiz:

and when editing the list of question categories:

(In case you are wondering, 0 is not a sensible idnumber for a category. However, it is a good way to find bugs like MDL-66796. Also, while working on this I discovered MDL-66801. Three fixes for the price of one, I hope!)

Promedio de valoraciones:Useful (5)
Imagen de Core developers Imagen de Documentation writers Imagen de Particularly helpful Moodlers Imagen de Peer reviewers Imagen de Plugin developers

I just tried to work this out. If your plugin has an admin_setting_confightmleditor setting, what is the correct way to output that? Normally when you output something that was user intput, you pass it through format_text(), format_string() or s(), and doing this is an important security thing.

My normal approach to try to answer this question is to look for example in the standard Moodle code. There is no advice in the doc-comment on admin_setting_confightmleditor. There are only a few examples where it is used. However, in this case, looking at the example just left me confused:

  • maintenance_message is a special case. The maintenance message can be displayed when Moodle is in mid upgrade, so you can't rely on anything working, so it is just output with no extra processing.
  • backup/backup_async_message goes into an email, not displayed on-screen, so that is different.
  • auth_instructions - if you decode auth/classes/output/login.php, this eventually gets passed through external_format_text (with hard-coded FORMAT_MOODLE). Since web services are almost certainly not involved, that seems like a dangerous example to copy.
  • auth_shibboleth does format_text($config->auth_instructions); but that turns out to be a setting that came from an admin_setting_configtextarea.
We make more use of admin_setting_confightmleditor in various OU plugins. In all those examples, we  just output the value directly. (Since it was input by an admin, this is not a security risk.)

Before doing all this research, my guess would have been format_text($CFG->thing, FORMAT_HTML).

If anyone thinks they know the 'right' answer here, please let me know. Thanks.

Promedio de valoraciones: -

Moodle in English -> Plugins traffic -> Recent Travis-CI issues with plugins

de Tim Hunt -
Imagen de Core developers Imagen de Documentation writers Imagen de Particularly helpful Moodlers Imagen de Peer reviewers Imagen de Plugin developers

I am making this post to share what I have learned from other people. I certaninly did not work most of htis out, but I am sharing what I have lerned in the hope that it helps others.

Travis-CI

Travis has recently changed the default VM it gives you from Ubuntu Trusty to Ubunty Xenial. This means several things:

A) You need to say

services:
mysql

Or you will get errors about MySQL not working.

B) If you were saying

  apt:
packages:
- oracle-java8-installer
- oracle-java8-set-default

to make Behat work, you instead need to say

  apt:
packages:
- openjdk-8-jre-headless

C) Also, as well as Xenial being the new default, there are already Ubuntu Bionic VMs available and they seem to work well. In fact, in once case my Behat was failing, and then I changed to Bionic it started working. Not sure why. Anyway, it seems to me that if you are storting things out now, you may as well say

dist: bionic

now, and get that working, because that will keep working for longer into the future.

Chrome / Behat

If you have upgraded to the latest Chrome, you will find Behat breaks horribly. That is a general Moodle problem being tracked over at MDL-66378 where Andrew Nicols is doing heroic work to fix it.

If you really want to make your Behat work on Travis before that lands, there is a crazy one-liner that you can add to your build sript to patch in a fix:

  # The following line is a temporary work-around for https://tracker.moodle.org/browse/MDL-66378.
# Once that is fixed, the next line can be deleted.
- curl https://github.com/timhunt/php-webdriver/commit/7a0aa38f591b7395939df25d8cb6677bf99a481f.patch | git apply --directory moodle/vendor/instaclick/php-webdriver
- moodle-plugin-ci behat --profile chrome
New JavaScript system in master

Moodle 3.8 is going to use a new way of building JavaScript. That means that, if like me you try to have one version of your plugin to support all recent Moodle versions, then the moodle-plugin-ci grunt will fail on Master saying

File is stale and needs to be rebuilt: amd/build/[filename].min.js

(that is, if you build the JS using Moodle 3.7 or earlier). For now, I have just stopped running the tests against Moodle master. Before Moodle 3.8 is released, we will need to think of a better answer to this one.

Summary

To see all this together (including a few other irrelevant changes) here is the commit I made to fix all these issues in one of my plugins: https://github.com/moodleou/moodle-qtype_pmatchjme/commit/4fccd62877bb2df3d5b34c24c78d44a49a53890b

I hope this is useful.

Promedio de valoraciones:Useful (9)
Imagen de Core developers Imagen de Documentation writers Imagen de Particularly helpful Moodlers Imagen de Peer reviewers Imagen de Plugin developers

A lot of Moodle's Behat tests repeatedly test navigating around Moodle before getting to the feature they really want to test. For example:

    And I log in as "teacher"
And I am on "Course 1" course homepage
And I follow "Quiz 1"
And I follow "Attempts: 1"
And I follow "Review attempt"

This is bad for several reasons:

  • When the Moodle navigation structure changes, all our Behat tests break. This is why, at one point, the 'I am on "Course 1" course homepage' step had to be introduced to fix one breakage. The breakage that caused the '... in current page administration' to be created is another example.
  • It makes the test take longer to run, becuase you have to load a whole lot of pages that you are not interested in testing.

So, I think that we should have a step to go straight to the feature you want to test. (Of course, we should also have automated tests for how Navigation works, but we should test that once, not in every scenario.) I had a go at implementing this over at MDL-66335 / https://github.com/timhunt/moodle/compare/master...MDL-66335.

However, while the principle seems sound, I think the details need to be a bit better. In particualr, the steps like the following are not very human-readable.

    And I am on "mod_quiz" "Quiz 1" "edit"
    And I am on "mod_quiz" "Quiz 1/student/1" "attempt review"

I am posting here in the hope that some people will look at what I have done, and have some good suggestions for how to make it better. Thanks.

Promedio de valoraciones:Useful (1)