MoodleDocs - User contributions [en]

Local plugins

2010-11-02T22:17:15Z

Azoltay: /* 2.0 pre-upgrade script */

{{Infobox Project
|name = Local customisations
|state = Implemented
|tracker = MDL-17376, MDL-16438
|discussion = http://moodle.org/mod/forum/discuss.php?d=126017 http://moodle.org/mod/forum/discuss.php?d=86903
|assignee = [[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]], some parts were originally proposed and implemented in 1.9 by Penny Leach
}}
{{Moodle 2.0}}

The recommended way to add new functionality to Moodle is to create a new standard plugin (module, block, auth, enrol, etc.).The /local/ plugins are mostly suitable for things that do not fit standard plugins.

=Custom /local/ plugins=

Local plugins are used in cases when no standard plugin fits, examples are:
* event consumers communicating with external systems
* custom definitions of web services and external functions
* applications that extend moodle at the system level (hub server, amos server, etc.)
* new database tables used in core hacks (discouraged)
* new capability definitions used in core hacks
* custom admin settings

Standard plugin features:
* /local/xxx/db/version.php - version of script (must be incremented after changes)
* /local/xxx/db/install.xml - executed during install (new version.php found)
* /local/xxx/db/install.php - executed right after install.xml
* /local/xxx/db/uninstall.php - executed during uninstallation
* /local/xxx/db/upgrade.php - executed after version.php change
* /local/xxx/db/access.php - definition of capabilities
* /local/xxx/db/events.php - event handlers and subscripts
* /local/xxx/db/messages.php - messaging registration
* /local/xxx/db/external.php - web services and external functions descriptions
* /local/xxx/lang/en/local_pluginname.php - language file

The ''xxx'' is used instead of your local plugin name, plugins of the same type are installed/upgraded in alphabetical order.

List of differences from normal plugins:
* always executed last during install/upgrade - guaranteed by order of plugins in <code>get_plugin_types()</code>
* are expected to use event handlers - events are intended for communication core-->plugins only, local plugins are the best candidates for event handlers
* can add admin settings to any settings page - loaded last when constructing admin tree
* do not need to have any UI - other plugins are usually visible somewhere
* some extra hooks (not implemented yet)

=Other /local/ customisation files=

==Customised site defaults==

Different default site settings can be stored in file /local/defaults.php.
These new defaults are used during installation, upgrade and later are
displayed as default values in admin settings. This means that the content
of the defaults files is usually updated BEFORE installation or upgrade.

These customised defaults are useful especially when using CLI tools
for installation and upgrade.

Sample /local/defaults.php file content:
<code php>
<?php
$defaults['moodle']['forcelogin'] = 1; // new default for $CFG->forcelogin
$defaults['scorm']['maxgrade'] = 20; // default for get_config('scorm', 'maxgrade')
$defaults['moodlecourse']['numsections'] = 11;
$defaults['moodle']['hiddenuserfields'] = array('city', 'country');
</code>
First bracket contains string from column plugin of config_plugins table.
Second bracket is the name of setting. In the admin settings UI the plugin and
name of setting is separated by "|".

The values usually correspond to the raw string in config table, with the exception
of comma separated lists that are usually entered as real arrays.

Please note that not all settings are converted to admin_tree,
they are mostly intended to be set directly in config.php.

==2.0 pre-upgrade script==

You can use /local/upgrade_pre20.php script for any code that needs to
be executed before the main upgrade to 2.0. Most probably this will
be used for undoing of old hacks that would otherwise break normal
2.0 upgrade.

This file is just included directly, there does not need to be any
function inside. If the execution stops the script is executed again
during the next upgrade. The first execution of lib/db/upgrade.php
increments the version number and the pre upgrade script is not
executed any more.

=Customisations outside of /local/ directory=

==Forced settings==

Sometimes it is useful to force some settings and prevent any changes of these settings via the standard admin UI. It is possible to hardcode these settings in config.php.

In case of course settings it is very simply, the values are assigned directly to $CFG properties. In case of plugins the values are specified in a multidimensional array in $CFG->force_plugin_settings.

Sample code in config.php
<code php>
$CFG->allowobjectembed = 0;
$CFG->forced_plugin_settings = array('page'=>array('displayoptions'=>5, 'requiremodintro'=>1), 'folder'=>'requiremodintro'=>1);
</code>

==Local language customisations==

Moodle supports other type of local customisation of standard language
packs. If you want to create your own language pack based on another
language create new dataroot directory with "_local" suffix, for example
following file with content changes string "Login" to "Sign in":
moodledata/lang/en_local
<code php>
<?php
$string['login'] = 'Sign in';
</code>
See also https://docs.moodle.org/en/Language_editing

==Custom script injection==

Very old customisation option that allows you to modify scripts by injecting
code right after the require 'config.php' call.

This setting is enabled by manually setting $CFG->customscripts variable
in config.php script. The value is expected to be full path to directory
with the same structure as dirroot. Please note this hack only affects
files that actually include the config.php!

Examples:
* disable one specific moodle page without code modification
* alter page parameters on the fly

==Direct code modifications==
This is usually the last resort, if possible do not do it. And if you still do it use some version control system (preferably git).

==Direct database modifications==
Very strongly discouraged! Sometimes field lengths may be modified without side effects. Adding or removing of db fields will most probably cause major problems during future upgrades. New database tables should be added only from plugins.

=Local customisations in previous versions=
Previous versions include only partial support for customisations in /local/ directory.

List of local customisations in 1.9.x:
* /local/cron.php - custom cron jobs
* /local/settings.php - custom admin settings
* /local/db/upgrade.php - general modifications
* /local/lang/* - custom strings
* /local/lib.php - local_delete_course()

Migration from old 1.9.x /local/:
* <code>local/*</code> needs to be copied to new directory
* <code>local/xxxx/db/install.php</code> is intended for first installation, originally everything was in upgrade.php
* events are used instead of hooks
* upgrade code needs to migrate old settings, events, etc. directly in core db tables - such as change component strings and capability names from db/install.php or manually before/after upgrade

==See also==

* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=86903 Local Customisations] forum discussion
* http://cvs.moodle.org/moodle/local/readme.txt?view=markup
* [[Local customisation (Moodle 1.9)]]

[[Category:Local customisation]]

Unit test API

2010-01-21T00:32:16Z

Azoltay:

{{Moodle 1.7}}Location: ''Administration > Reports > Unit tests''

The purpose of Unit Tests is to evaluate the individual parts of a program (functions, and methods of classes) to make sure that each element individually does the right thing. Unit Tests can be one of the first steps in a quality control process for developing or tweaking Moodle code. The next steps will involve other forms of testing to ensure that these different parts work together properly.

The unit testing framework is based on the [http://www.simpletest.org/ SimpleTest] framework.

== Running the unit tests in Moodle ==

=== Running the basic tests ===

# Log in with an admin account.
# Administration ► Development ► Unit tests (moodle >= 2.0, Administration ► Reports ► Unit tests Moodle <= 1.9)
# Click on the '''Reports''' link near the bottom of the page.
# Click the '''Run tests''' button and wait.

This finds all the tests in Moodle and runs them. You can run a subset of the tests by entering a path (for example question/type) in the 'Only run tests in' box. Similarly, if a test fails, you get some links in the failure message to make it easy to re-run just those tests.

== Writing new tests ==

As an example, suppose we wanted to write some tests for the string_manager class in mod/quiz/editlib.php.

=== Where to put the tests ===

The unit test report finds tests by looking for files called 'test....php' inside folders called 'simpletest'.

So, for our example, we want to create called something like '''mod/quiz/simpletest/testeditlib.php'''. The skeleton of this file should look like:

<code php>
<?php
/**
* Unit tests for (some of) mod/quiz/editlib.php.
*
* @license http://www.gnu.org/copyleft/gpl.html GNU Public License
* @package question
*/

if (!defined('MOODLE_INTERNAL')) {
die('Direct access to this script is forbidden.'); // It must be included from a Moodle page
}

// Make sure the code being tested is accessible.
require_once($CFG->dirroot . '/mod/quiz/editlib.php'); // Include the code to test

/** This class contains the test cases for the functions in editlib.php. */
class quiz_editlib_test extends UnitTestCase {
function test_something() {
// Do the test here.
}

// ... more test methods.
}
?>
</code>

That is, you have a class called something_test, and in that class you have lots of methods called test_something. Normally, you have one test method for each particular thing you want to test, and you should try to name the function to describe what is being tested - without making the name too ridiculously long!

=== A test function ===

The a test function typically looks like

<code php>
function test_move_question_up() {
// Setup fixture

// Exercise SUT
$newlayout = quiz_move_question_up('1,2,0', 2);

// Validate outcome
$this->assertEqual($newlayout, '2,1,0');

// Teardown fixture

}
</code>

This is the [http://xunitpatterns.com/Four%20Phase%20Test.html four phase test pattern]. Those comments use a lot of testing jargon. The fixture is the background situation that needs to be set up before the test runs. SUT is short for 'situation under test'. This is where you call the function or method that you want to test. Then you check to see if the function did the right thing. Finally, you have to clean up the fixture you created. With luck there is nothing to do here

In this simple example, there is no setup or teardown to do. We just call the function we are testing with some sample input, and check that the return value is what we expect.

=== Shared setUp and tearDown methods ===

If all your test cases relate to the same area of code, then they may all need to same bit of fixture set up. For example, all the tests in lib/simpletest/teststringmanager.php need an instance of the string_manager class to test.

To avoid duplicating code, you can override a method called <code>setUp()</code> that sets up the test data. If present, this method will be called before each test method. You can write a matching <code>tearDown()</code> method if there is any clean-up that needs to be done after each test case has run. For example, in lib/simpletest/teststringmanager.php there are setUp and tearDown methods that do something like:
<code php>
public function setUp() {
// ...
$this->stringmanager = new string_manager(...);
}

public function tearDown() {
$this->stringmanager = null;
}
</code>
Then, each test can use $this->stringmanager without having to worry about the details of how it is set up.

=== Further information ===

The ''SimpleTest'' documentation is at: http://www.simpletest.org/.

== Changes to your existing code to make it work with unit testing ==

The whole point of unit testing is to test each piece of functionality separately. You can only do this is by isolating that function and call it individually, perhaps after setting up a few other things.

Therefore, it is good if you can write your code to depend on as few other things as possible.

=== Include paths ===

Includes like

<code php>
require_once('../../config.php'); // Won't work.
</code>

won't work. Instead, the more robust option is

<code php>
require_once(dirname(__FILE__) . '/../../config.php'); // Do this.
</code>

=== Access to global variables ===

Because your code was included from within a function, you can't access global variables until you have done a global statement.

<code php>
require_once(dirname(__FILE__) . '/../../config.php');
require_once($CFG->libdir . '/moodlelib.php'); // Won't work.
</code>

<code php>
require_once(dirname(__FILE__) . '/../../config.php');

global $CFG; // You need this.
require_once($CFG->libdir . '/moodlelib.php'); // Will work now.
</code>

=== Calls to global functions ===
Testing a class method that calls global functions can be problematic. At least, it's always complex, because we can't control what goes on in the global functions. We can't override the global functions or mock them in our unit tests. If the global functions themselves are well tested, this may not be a big problem, but most global functions are not well tested.

==== Bridge Pattern ====
If your code needs to rely extensively on some public API, you could use the [http://en.wikipedia.org/wiki/Bridge_pattern bridge pattern] to decouple your code from that API. This way, when you write unit tests, you can override the bridging class or mock it, and control its outputs while you focus exclusively on testing your code.

An basic example follows: Imagine that I do not trust the ''get_string()'' global function, but my code needs to use it. Initially my code has strong coupling with ''get_string()'':

<code php>
class myclass {
public function print_stuff($stuff) {
echo get_string($stuff);
}
}
</code>

Now let's write a bridging class to solve this coupling issue and use it instead of ''get_string()'':

<code php>
class languageBridge {
public function get_string($stuff,$module='moodle') {
echo get_string($stuff, $module);
}
}

class myclass {
public $lang_bridge;
public function __construct() {
$this->lang_bridge = new languageBridge();
}
public function print_stuff($stuff) {
echo $this->lang_bridge->get_string($stuff);
}
}
</code>

The following is yet another example using a bridging method to decouple from the Moodle core API.

<code php>
class workshop_api {
/**
* This is a method we want to unittest
*/
public function get_peer_reviewers($context) {
static $users=null;
if (is_null($users)) {
$users = $this->get_users_by_capability($context, 'mod/workshop:peerassess',
'u.id, u.lastname, u.firstname', 'u.lastname,u.firstname', '', '', '', '', false, false, true);
}
return $users;
}

/**
* Bridging method to decouple from Moodle core API
*/
protected function get_users_by_capability() {
$args = func_get_args();
return call_user_func_array('get_users_by_capability', $args);
}
}
</code>

'''Warning:''' Here are some comments on the examples above expressing that the bridge pattern should be used very carefully.

* "I think that is a case of unit tests leading to worse software design, in that you are not using the standard API for something. But if you really want to unit test, I can't think of a better solution."
* "I think this can be OK if used very selectively. Unfortunately I don't think it's the solution if you want to decouple the very complex and deeply nested Moodle functions from each other"
* "...your code is designed to be part of Moodle, so decoupling from a standard Moodle API is perverse."

== Unit testing in 2.0 ==

{{Moodle 2.0}}
With the Objectification of the Database libraries in Moodle 2.0, new and better approaches to Unit testing can be used. Here is a sample of a simple test case: (in course/simpletest)

<code php>
require_once($CFG->dirroot . '/course/lib.php');

global $DB;
Mock::generate(get_class($DB), 'mockDB');

class courselib_test extends UnitTestCase {
var $realDB;

function setUp() {
global $DB;
$this->realDB = $DB;
$DB = new mockDB();
}

function tearDown() {
global $DB;
$DB = $this->realDB;
}

function testMoveSection() {
global $DB;
$course = new stdClass();
$course->id = 1;

$sections = array();
for ($i = 1; $i < 11; $i++) {
$sections[$i] = new stdClass();
$sections[$i]->id = $i;
$sections[$i]->section = $i - 1;
}

$DB->expectOnce('get_records', array('course_sections', array('course' => $course->id)));
$DB->setReturnValue('get_records', $sections);
$this->assertFalse(move_section($course, 2, 3));
}
}
</code>

See also '''UnitTestCaseUsingDatabase''' in lib/simpletestlib.php.

=== Testing HTML output ===

(work in progress - to be documented properly once the API stabilizes)

* ContainsTagWithAttribute($tag, $attribute, $value)
* ContainsTagWithAttributes($tag, $attributes)
* ContainsTagWithContents($tag, $content)
* ContainsEmptyTag($tag)

The syntax is
<code php>
$this->assert(new ContainsTagWithAttribute($tag, $attribute, $value), $html);
</code>

== Code coverage analysis==
<p class="note">'''Note:''' This section is a work in progress. Please use the [[{{TALKPAGENAME}}|page comments]] or an appropriate [http://moodle.org/course/view.php?id=5 moodle.org forum] for any recommendations/suggestions for improvement.{{{info|}}}</p>

{{Moodle 2.0}}

'''[[Wikipedia:Code_coverage|Code coverage]]''' is a technique, strongly tied with software testing, that allows to '''check and improve the quality of the tests''' by measuring the degree of source code that is being covered by them. With Moodle supporting more and more tests each day (slowly towards a '''Test Driven Development''' model) we need to integrate some tool into our development process helping to analyse the quality of ours tests.

Right now (in Moodle 2.0) we are using [http://www.simpletest.org/ SimpleTest], one simple and great tool to perform all the tests. Unluckily, it doesn't support code coverage analysis at all. In the other hand, other PHP unit testing products like [http://www.phpunit.de/ PHPUnit], more complex and powerful, have built-in support for that technique, but switching to a new product is out from our current [[Roadmap]] plans.

So, after some readings and comparisons, Moodle will implement its own extensions to SimpleTest, in order to fulfil the main goal of having statement/line code coverage analysis working under Moodle 2.0 onwards. To achieve this, also [http://developer.spikesource.com/projects/phpcoverage Spike PHPCoverage], a basic code-coverage tool, will be used and extended. You can find the details of the implementation of this tool at MDL-19579.

=== Changes ===

To enable code coverage in your tests, only a few modifications need to be performed to your current code:

# Change your test classes by adding two (public static) attributes: '''$includecoverage''' and '''$excludecoverage''', both arrays, being used to inform to the code coverage tool (via reflection) about which source code files and dirs must be covered/skipped by the analysis.
# Use '''[http://cvs.moodle.org/moodle/lib/simpletestcoveragelib.php?view=markup simpletestcoveragelib.php]''' instead of simpletestlib.php in your caller scripts.
# Use the '''autogroup_test_coverage''' class instead of the AutoGroupTest one (see below for details) in your caller scripts.

(note that only the 1st point above is needed for new unit tests being created because both 2 and 3 (changes in caller scripts) are already implemented in Moodle and awaiting your cool unit tests.

That's all! With those 3 basic changes, you will end with a complete code coverage report available for further analysis.

=== API ===

When using code coverage within Moodle there are two alternative APIs available, both providing the same code coverage reports at the end, but doing that in a different way. Here they are:

* '''Internal (hidden) coverage API''': This API is completely hidden beyond the Unit testing API and you won't need to know the details about it. Just perform the 1-2-3 changes described above and, after running the tests you'll get the final report available for being used immediately, without needing to perform anything in your code. His major drawback: it only can perform '''one''' "code coverage session" (a.k.a. instrumentation), so it's only suitable for testing scripts using only one unit test execution. One example of this type of unit testing is [http://cvs.moodle.org/moodle/admin/report/unittest/index.php?view=markup admin/report/unittest/index.php] where only one (big) test-group is executed.
* '''External (explicit) coverage API''': This API needs extra coding as long as coverage instantiating, configuration and report generation happens in the main script. It's a bit more complex but, in the other hand, it support '''multiple''' instrumentations to be performed, and gives you more control about the code coverage process. One example of this type of unit testing is [http://cvs.moodle.org/moodle/admin/report/unittest/dbtest.php?view=markup admin/report/unittest/dbtest.php] where multiple (one for each DB being tested) test-group are executed.

So, first of all (point 1 in prev section - usage), we need to define, for each unit test, which files / directories (relative to dirroot) we want to analyse with the tool. Here it's one example, for the '''dml_test''' unit test ([http://cvs.moodle.org/moodle/lib/dml/simpletest/testdml.php?view=markup /lib/dml/simpletest/testdml.php]), all we need to add to these lines to the class declaration :

<code php>
public static $includecoverage = array('lib/dml');
public static $excludecoverage = array('lib/dml/somedir');
</code>

By doing so, the code coverage tool will know which are the target files to perform coverage analysis/reporting and will do that for all the files (recursively) in the ''lib/dml''' dir but excluding the ''lib/dml/somedir'' directory (recursively too). Note that both attributes are arrays so multiple paths can be specified in any of them. Also note that the dir where the UnitTest is stored is automatically excluded (usually ''simpletest'' dirs).

And, as said, that's all you need to fulfil in order to get current/new unit tests being analysed by the code coverage tool by current Moodle scripts. The documentation below is only interesting for developers wanting to create new scripts able to perform unit testing with code coverage (points 2 and 3 in prev section - usage).

==== Internal coverage API ====
<code php>
$test = new autogroup_test_coverage($showsearch, $test_name, $performcoverage, $coveragename, $coveragedir);
</code>
Create one new autogroup test object with code coverage support, there you can specify if you want to perform coverage (true/false), the name of the report (title) and the directory where the final report will be created (under moodledata/codecoverage).
Optionally you can add more files and directories (relative to dirroot) to the list of files to be covered / ignored by using these functions (in case the defined in point 1 aren't enough).
<code php>
$test->add_coverage_include_path($path);
$test->add_coverage_exclude_path($path);
</code>
And then, affter adding a bunch of unit tests to the group, you simply invoke the test execution with code coverage support to end with a nice code coverage report under ''dataroot/codecoverage/$coveragedir'':
<code php>
$test->run($unit_test_reporter);
</code>
(don't forget that this API supports only '''one''' instrumentation to be performed)

And that's all!

==== External coverage API ====
<code php>
$covreporter = new moodle_coverage_reporter($coveragename, $coveragedir);
$covrecorder = new moodle_coverage_recorder($covreporter);
</code>
Create one coverage reporter, by passing its title and output directory as parameters.
<code php>
$test = new autogroup_test_coverage($showsearch, $test_name, $performcoverage);
</code>
Create one new autogroup test object with code coverage support, you don't need to specify the title and dir here (as already have been defined by the moodle_coverage_reporter object).
Optionally you can add more files and directories (relative to dirroot) to the list of files to be covered / ignored by using these functions (in case the defined in point 1 aren't enough).
<code php>
$test->add_coverage_include_path($path);
$test->add_coverage_exclude_path($path);
</code>
Then, after adding a bunch of unit tests to the group, you simply invoke the test execution with code coverage support with:
<code php>
$test->run_with_external_coverage($unit_test_reporter, $covrecorder);
</code>
(don't forget that this API supports '''multiple''' instrumentations to be performed)

And finally, you generate the code coverage report (under ''dataroot/codecoverage/$coveragedir'') using:
<code php>
$covrecorder->generate_report();
</code>
Once more, that's all!

==== Final notes ====
* Note that there are some more methods available in the moodle_coverage_recorder class. They will allow to control starting/stopping instrumentations by hand and other minor things but they shouldn't really be used. The run() and run_with_external_coverage() methods should be enough in 99% of cases.
* Not being part of the API, but used by it, there is one '''[http://cvs.moodle.org/moodle/admin/report/unittest/coveragefile.php?view=markup overagefile.php]''' script under ''admin/report/unittest'' responsible for serving the coverage report files from within Moodle. See current scripts in that dir to see how can be used.
* All the test execution / reporting / coverage utilities must be protected with the 'moodle/site:config' permission.

== A warning ==

In 'xUnit Test Patterns' there is a [http://xunitpatterns.com/TestAutomationRoadmap.html scale of testing difficulty] that goes from 1. to 6. Moodle is definitely at number 6. on that scale 'Non-object-oriented legacy software'. It then goes recommend that you don't start to learn about unit testing with that sort of software :-(

== Further reading about unit testing ==

[http://manning.com/reiersol/ PHP in Action] has an excellent chapter explaining unit testing in PHP with ''simpletest''. (Although the rest of that book advocates a style of programming that is very different from the style used in Moodle.)

[http://www.pragprog.com/titles/utj/pragmatic-unit-testing-in-java-with-junit Pragmatic Unit Testing in Java with JUnit] is also a very good introduction, despite being in the wrong programming language. JUnit and Simpletest are very similar.

[http://xunitpatterns.com/ xUnit Test Patterns] is the ultimate unit test book. I think it teaches you everything you could learn about unit testing by reading a book. The only way to learn more would be years of experience. It has really great advice for dealing with the kind of messy problems you get in a big, real project like Moodle.

[[Category:Coding guidelines|Unit tests]]
[[Category:Quality Assurance]]

User talk:Helen Foster

2009-11-19T23:16:21Z

Azoltay: /* PHP Settings by Moodle version */ new section

== Creating new FAQ pages ==

Hi Helen,

I have successfully created a stub for a XML FAQ page (https://docs.moodle.org/en/XML_FAQ) but how do I get it promoted on https://docs.moodle.org/en/Category:FAQ ?

I also would like to create an Import/Export FAQ for collecting all the information regarding Moodle import and export which is scattered in different forums.

Regards,
[[User:Frank Ralf|Frank Ralf]]

:Hi Helen will have to answer the Import/Export question. I jumped in and added <nowiki>[[Category:FAQ]]</nowiki> to the bottom of the page, which anyone can do. And took your hint and added a <nowiki>{{stub}}</nowiki> template at the top. Thanks for the XML work. Best --[[User:chris collman|chris collman]] 14:16, 3 December 2008 (CST)

::Hi Frank, thanks for your offer - an [[Import and export FAQ]] page would be great, thanks! --[[User:Helen Foster|Helen Foster]] 04:12, 4 December 2008 (CST)
:::Thanks to both of you! Helen, how did you get that nice Contents menu on your Import and export FAQ page? I couldn't figure that out from the source. --[[User:Frank Ralf|Frank Ralf]] 05:30, 4 December 2008 (CST) Problem solved, just found the documentation ;-) --[[User:Frank Ralf|Frank Ralf]] 05:43, 4 December 2008 (CST)

== Suggestion that is probably total overkill ==
<onlyinclude>
# Create a new FAQ namespace.
# In this namespace, create one page for each frequent question, where the contents of the page is the answer.
# Use our new knowledge of transclusions to build the FAQ lists by just pulling in pages from the FAQ namespace.

The benefits of doing this are
* The same FAQ can appear in more than one list without copying-and-pasting.
* Each question gets a unique URL that so in the forums, we can point people to a page that just answers their specific question.

Disadvantages
* Editing FAQ lists becomes incomprehensible to anyone who is not a MediaWiki geek.

If we went this way, I would like to use B to build a new FAQ page: "Troubleshooting FAQ". Might be a good idea anyway.
</onlyinclude>
I hasten to say that I am not recommending this approach. The disadvantages could easily outweigh the advantages. I am simply pointing out a technical possibility that may be worth considering either now, or in the future.<onlyinclude>--[[User:Tim Hunt|Tim Hunt]] 07:11, 4 December 2008 (CST)</onlyinclude>

:Just added [[MoodleDocs:Transclusion]]. Good thing I had my first cup of coffee, Tim's thoughtful post got me rubbing the sleep out of my eyes. I wonder if I can get the partial transclusion of this section to work in Sandbox then in [[MoodleDocs_talk:Transclusion]]. Definitely a tool to be used with care. But Wowie Zowie ! --[[User:chris collman|chris collman]] 06:49, 5 December 2008 (CST)

:: Hello Tim, I think your suggested solution would indeed be overkill and would make maintaining FAQ too difficult. I see FAQ as an intermediary step between the unorganised kind of "documentation" which is provided in the forums towards "real" documentation. Therefore the ease of editing is crucial in my opinion. What about using Moodle's '''autolinking mechanism''' to automatically link to FAQ pages, e.g. if there is a mention of grades in the forums that would create an automatic link to Grades FAQ. I am quite new to Moodle, but couldn't that be done with setting up a kind of FAQ Glossary? --[[User:Frank Ralf|Frank Ralf]] 02:44, 16 December 2008 (CST)

::: Hi Tim, thanks for your suggestion, though I think it's overkill too! The current FAQ pages have nice short titles which are easy to find and to include in forum posts. Having a page for each FAQ would result in really long URLs. Also, I think that when we point people to an FAQ page, and they have to look through it to find the answer to their question, they may well find answers to other questions they have. As other people have suggested, I think FAQ pages work well as start pages with links to lots of other pages i.e. they're kept fairly short, for example [[Contributed code FAQ]]. --[[User:Helen Foster|Helen Foster]] 04:49, 18 December 2008 (CST)

::: Frank, regarding autolinking to FAQ pages, have you come across the Moodle Docs filter on moodle.org? Please see the [[Moodle.org FAQ]] for more details. --[[User:Helen Foster|Helen Foster]] 04:49, 18 December 2008 (CST)
::::Helen, thanks for the hint. But isn't that the usual ''manual'' way of wiki linking? But on second thought that might really be the best way of linking to FAQ pages as it keeps getting the forums cluttered with too many (automatic) links. In fact, it just might be a matter of good practice to put advice of lasting value from the forums into a more structured form of documentation and nothing which could or should be done in an automatic and technical way... --[[User:Frank Ralf|Frank Ralf]] 05:11, 19 December 2008 (CST)

== Security Notification registration ==

Hi Helen,

It was suggested to me through the #moodle channel on freenode that I raise this concern with you.

I'm developing a moodle installation behind a firewall on a non-public URL and am interested in subscribing to security updates (prompted to check this after seeing a moodle vulnerability mentioned on Bugtraq). I had previously attempted to subscribe by registering our installation through the admin pages, however that registration was rejected as the site was located behind a firewall and not accessible.

Due to that rejection, I wasn't subscribed to security updates.

I now find myself in the unfortunate position where I cannot subscribe to security updates without having a public facing site (which I can't reasonably know is secure as I'm not receiving security updates through your mailing list).

The burden for those of us who have an internal site they're developing (or perhaps is in production) is that we must now create a public facing site to register for the sole purpose of receiving security updates. If the thought is that only parties interested in maintaining a moodle site should have access to those messages, perhaps a different measure could be put into place (a code that appears once moodle is installed, for example).

I've tried subscribing through sympa@lists.moodle.org, however that method does not work either.

Could you please provide a process for folks like me to get on the security updates list without having to install moodle on a public web server first?

Thanks!

- P.

:Hi Paul, how about subscribing to the [http://moodle.org/mod/forum/view.php?f=996 security announcements forum], where all important security issues are published. --[[User:Helen Foster|Helen Foster]] 04:34, 18 December 2008 (CST)
== Unseen (not hidden) activities==
Hi Helen (This is partly my attempt at practising here by the way!) I've posted several times recently about the concept of 'unseen' topics with resources that can be linked to on the course page where hidden ones wouldn't work. is there documentation about that somewhere here ? If so, where? Then I can point Moodlers to it next time.If not, shall I write it? Thanks - [[User: Mary Cooch|Mary Cooch]]

:Hi Mary, I've just had a quick look and can't find any documentation about unseen topics, so it would be helpful if you could write some, perhaps here: [[Course homepage]]. Thanks in advance :-) --[[User:Helen Foster|Helen Foster]] 17:20, 19 December 2008 (CST)
:Helen - please can you check what I have done as you know I'm still a novice and don't want to put the wrong thing in the wrong place! Also, if you look on my usertalk Chris Colman said it might be useful on the html linking page? [[User: Mary Cooch|Mary Cooch]]

== Downloading Moodle Core ==

Hi Helen,
I came across Moodle just this morning, and read a little about its design, and loved it, it is perfect for the project Im starting.

Ive gone to the download page, to download the Moodle core zip package, but when I click on the link to download I get the following message;

'A server error that affects your login session was detected. Please login again or restart your browser.'

( Continue )

I had a look around the FAQ pages, to see if there was anything on there, but it only mentions about people who already have moodle and are having this difficulty,

Please could you send me an alternative link,

Kind Regards
Andrew
:Hi Andrew, I left a comment on your [[User_talk:Andrew_Abel|user comment page]], just in case you were in a hurry to play with Moodle. --[[User:chris collman|chris collman]] 07:40, 1 January 2009 (CST)

::Hi Andrew, I hope you've been successful in downloading Moodle by now. Chris, thanks for your helpful comments :-) --[[User:Helen Foster|Helen Foster]] 01:21, 2 January 2009 (CST)

== "experimental:" prefix ==

[[User:Marc Grober|Marc Grober]] 12:00, 12 January 2009 (CST)

We started using experimental: as a prefix because there was some confusion about the use of Development: as a prefix.....

In the Moodle docs, Development: appears to cover Moodle developer documentation, not docs under development, so we wanted to use a prefix that connote that the docs were, as we suggest, "experimental" (i.e. not ready for prime time). I had not come across [[Experimental|Experimental]] as the search is a bit temperamental and searching for the root, experiment, produced no result.....

Perhaps we need a different topic name?

I have encouraged AT to ask you to move these pages out of the experimental: topic but I think she feels they are not quite ready and I want to respect hre wishes on this.

We also have some experimental pages under development with respect to gradebook "cases".

I would encourage you to discuss the progress on all these pages with AT.

Thanks

----

:Marc, thanks for your comments. The use of experimental: as a prefix is fine by me. Alternatively you could use a [[MoodleDocs:Templates|Moodle Docs template]] to add a message saying that the page is experimental. --[[User:Helen Foster|Helen Foster]] 02:41, 13 January 2009 (CST)
::Marc and Helen, something new to me. I found 7 pages when I searched on "experimental:" and found 7 Article title matches. 6 started with "experimental:" and of course "Experimental". Wondering if an alternative draft to Main Page should be done that way with the Experimental template. :)--[[User:chris collman|chris collman]] 06:00, 13 January 2009 (CST)
:::Helen, thanks for moving some of the experimental: pages. The page here, however, has yet to be moved: [https://docs.moodle.org/en/experimental:Getting_Help_Installing_and_Managing_Moodle]. Vis-a-vis topics/categories, I think it makes sense to have a category that is not searched by default so that users do not find materials that is not ready for prime time. By the same token, I think, as I mentioned above, that Development: is problematic because it confuses as far as whether it is a topic for Developers or addresses material under development, which are really two different areas. Likewise, as long as there is an Experimental page the use of experimental: could cause confusion. I would argue for three distinct categories.... [[User:Marc Grober|Marc Grober]] 12:16, 24 January 2009 (CST)

::As I understood your (Helen's) comment (posted I don't recall where) you (Helen) were I think suggesting that what I was really suggesting was a new name space such that folks could develop documents that were not included in a default search..... which I think is exactly what I was looking for.... So the question becomes can and should we do such a thing..... --[[User:Marc Grober|Marc Grober]] 23:44, 9 March 2009 (UTC)

:::Marc, I guess you're referring to my forum post [http://moodle.org/mod/forum/discuss.php?d=115736#p509590 Re: Not including pages in the Moodle Docs search]. How about using a Moodle Docs template for now to indicate docs under development and add them to an appropriate category, then when there are sufficient pages to warrant it, we can create a new namespace and move all the pages into it. --[[User:Helen Foster|Helen Foster]] 11:46, 10 March 2009 (UTC)

==Talk:Helen's page is over 32k==
FYI: I got that warning. Maybe a subpage for the older stuff and a link, so we don't loose some stuff. Of course alternatively, if I deleted all my comments/questions, that would shorted it a lot :) --[[User:chris collman|chris collman]] 06:04, 13 January 2009 (CST)
::Seriously, I would be happy to edit my posts here down to a nub or nothingness. I think some of the language requests for help could be put in one heading and shortened, without losing anything. --[[User:chris collman|chris collman]] 06:13, 13 January 2009 (CST)

:Chris, thanks for creating [[User talk:Helen Foster/1]]. I think it's a good solution :-) --[[User:Helen Foster|Helen Foster]] 02:51, 14 January 2009 (CST)

==See also==

*[[User talk:Helen Foster/1]] for older comments

== Registered Users Bug with Mediawiki ==

Hi, [[User_talk:David_Scotson#Moodle_Docs_stats|Way back in 2006 you mentioned]] a work-around for a bug resulting in registered users stats on [[Special:Statistics]] not updating properly. I think I am encountering this same bug on my internal wiki now. I know that was a long time ago, but do you remember what you did to fix it/what the work-around mentioned was?
Thanks,
--[[User:Adrian Archer|Adrian Archer]] 11:02, 4 March 2009 (CST)

:Hi Adrian, here are Eloy's workarounds (easy to do with phpMyAdmin):

:# To refresh the count of pages, if it's not working: table: site_stats, field: ss_total_pages, setting it to -1 should force recalculation of pages
:# To refresh the count of registered users, delete the contents of the "cached statistics" table

:Thanks to Eloy for recalling them :-) I hope you are able to upgrade to a newer MediaWiki version soon. --[[User:Helen Foster|Helen Foster]] 09:01, 5 March 2009 (CST)

::Thanks so much for the quick response, that sounds like it should work. I'm actually using Version 1.13.3, so I guess the bug still exists. --[[User:Adrian Archer|Adrian Archer]] 09:17, 5 March 2009 (CST)

:::Hmm, Moodle Docs is actually using version 1.11.2, though we're hoping to upgrade very soon (MDLSITE-657). --[[User:Helen Foster|Helen Foster]] 09:35, 5 March 2009 (CST)

== Function if in grade calculations? ==

Hi Helen

Thanks for your jobs.

Sorry for my lousy english.

I am trying to use the "if" function in "Grade calculations" in a similar way as is done in "opencalc"

do you know if this is possible?

How to introduce a note of recovery, only for a few students, without changing the original calification?

My email is trujillo@unex.es

Thanks

== Using Moodle for Teachers ==

Hi Helen,

I teach math at Woodland Middle School in Woodland, WA. I'm also just beginning work with the Ubuntu Learning Project (name?). Is your book (Using Moodle - Teaching with the Popular Open Source Course Management System) available for download on Moodle Docs free to teachers? If so, is there some type of creative commons license? Or should we just link to Moodle Docs? I found your book extremely useful when I taught a 3-day Moodle Bootcamp to teachers this summer.

Thanks, Mark Knudson

:Hi Mark, glad to hear you found my book useful :-) It's available for download under the Creative Commons Attribution-Noncommercial-Share Alike licence here: [[Using Moodle book]]. --[[User:Helen Foster|Helen Foster]] 19:11, 21 September 2009 (UTC)

== PHP Settings by Moodle version ==

Hi Helen,

I'm new to this community (and to Moodle) and am not sure how I should request an update to the documentation relating to a Moodle PHP extension requirement - specifically zlib.
I noticed that this page:
https://docs.moodle.org/no/Installering_av_Moodle has a section stating that "The zlib extension is required for zip/unzip functionality." under the PHP Extensions and Libraries, but it doesn't exist here:
https://docs.moodle.org/en/PHP_settings_by_Moodle_version

The PHP_settings_by_Moodle_version is a Stub and is waiting for review - I was thinking about updating it with the text from the https://docs.moodle.org/no/Installering_av_Moodle page.

Looking for a little direction.

Thanks!
Andy