MoodleDocs - User contributions [en]

Help:Editing

2008-03-07T17:49:53Z

Robek: /* Categories links */ corrected typo

{{Help}}
This page is for editing Moodle Documentation (MoodleDocs). This is a similar but much more robust type of program than the [[Wiki module|standard Moodle wiki]].

==Edit tab==
Every MoodleDoc page has an "edit" tab at the top . This link will let you edit the page you are viewing. Please try editing a page by using this [[Sandbox|sandbox link]]. We will cover more formatting and special MoodleDoc features below.

=== Show preview ===
In edit mode, the show preview button at the bottom of the page lets you see what the page will look like after your edit, before you actually save. We all make mistakes; this feature lets you catch them immediately. Using Show preview before saving also lets you try format changes and other edits without cluttering up the page history, and has a number of other advantages. Don't forget to save your edits after previewing, though!

=== Edit summary ===
Before saving the page, it's considered good practice to enter a very brief summary of your changes in the summary box below the edit-box.

== Formatting ==

Most '''formatting''' in MoodleDocs is usually done with MediaWiki markup - you don't have to learn HTML!

=== Bold and italics ===
'''Bolding''' and ''italicizing'' is done by surrounding a word or phrase with multiple apostrophes (<tt>'</tt>):

:<code><nowiki>''italics''</nowiki></code> appears as ''italics''. (2 apostrophes on both sides)
:<code><nowiki>'''bold'''</nowiki></code> appears as '''bold'''. (3 apostrophes on both sides)
:<code><nowiki>'''''bolded italics'''''</nowiki></code> appears as '''''bolded italics'''''. (5 apostrophes on both sides)

=== Headings and subheadings ===
Headings and subheadings are an easy way to improve the organization of an article.

Headings can be created like this:
:<code><nowiki>==Top level heading==</nowiki></code> (2 equals signs)
:<code><nowiki>===Subheading===</nowiki></code> (3 equals signs)
:<code><nowiki>====Another level down====</nowiki></code> (4 equals signs)

If an article has at least four headings, a table of contents will automatically be generated.

=== Indentations ===
The simplest way of indenting is to place a colon (<code>:</code>) at the beginning of a line. The more colons you put, the further indented the text will be. A newline marks the end of the indented paragraph e.g.
:<code>This is aligned all the way to the left.</code>
:<code><nowiki>:</nowiki>This is indented slightly.</code>
:<code><nowiki>::</nowiki>This is indented more.</code>
is shown as
:This is aligned all the way to the left.
::This is indented slightly.
:::This is indented more.

=== Lists ===
{| border="1" cellpadding="2" cellspacing="0"
|-
!What it looks like
!What you type
|-
|
* ''Unordered lists'' are easy to do:
** start every line with a star
*** more stars means deeper levels
*A newline
*in a list
marks the end of the list.

|<pre><nowiki>* Unordered Lists are easy to do:
** start every line with a star
*** more stars means deeper levels
*A newline
*in a list
marks the end of the list.
</nowiki></pre>
|-
|
# Numbered lists are also good
## very organized
## easy to follow
#A newline
#in a list
marks the end of the list.
|<pre><nowiki># Numbered lists are also good
## very organized
## easy to follow
#A newline
#in a list
marks the end of the list.
</nowiki></pre>
|-
|Descriptive lists:
; first tag : accompanying description
; second tag : more description
; third tag : surprise! more description
|<pre><nowiki>Descriptive lists:
; first tag : accompanying description
; second tag : more description
; third tag : surprise! more description
</nowiki></pre>
|}

=== Preserving formatting ===

{| border="1" cellpadding="2" cellspacing="0"
|-
!What it looks like
!What you type
|-
|
Leading spaces are another way to preserve formatting.

Putting a space at the beginning of each line
stops the text from being reformatted.
|<pre><nowiki>Leading spaces are another way to preserve formatting.

Putting a space at the beginning of each line
stops the text from being reformatted.
</nowiki></pre>
|}

You can also use <pre><pre></pre> tags around code and other preformatted text.
or use block the text and use the nowiki tool

== Links ==
Links to other pages are the heart of a wiki and MoodleDocs.

=== Wiki links ===
To make a wiki link, simply put the word in double square brackets, like this: <code><nowiki>[[Sandbox]]</nowiki></code> . Highlight text and using the "internal link" tool will do this as well.

If you want to use words other than the article title as the text of the link, you can do so by adding the pipe "|" divider followed by the alternative name or text.

For example, if you wanted to make a link to the [[Sandbox]], but wanted it to say "my text" you would write it as: <code><nowiki>[[Sandbox|my text]]</nowiki>...</code> It would appear as: [[Sandbox|my text]]... but would link to the sandbox.

=== External links ===

The easiest way to make an external link is to simply type in the full URL for the page you want to link to e.g. http://moodle.com.

To make the link display something other than the URL, use one square bracket at each end. If you want to make a link to moodle.com, type <code><nowiki>[http://moodle.com/]</nowiki></code>
This will display the link as a number in brackets, like this: [http://moodle.com/]. There is also the external link tool which can also assist you.

If you want the link to appear with text that you specify, add an alternative title after the address separated by a '''space''' (''not'' a pipe). So if you want the link to appear as [http://moodle.com Moodle], just type <code><nowiki>[http://moodle.com Moodle] </nowiki></code>.

===Categories links===
A category is a type of index page, a page of links listed in alphabetical order. In page view mode, a list of catagories that a page is linked to, appears at the bottom.
To put a page in a category, just type <code><nowiki>[[Category:]]</nowiki></code>, and put the name of the category between the colon and the brackets.

To link directly to a category use <code><nowiki>[[:Category:Teacher | teacher]]</nowiki></code>, this will show as [[:Category:Teacher | teacher]], note the preceding ":", which is different to <code><nowiki>[[Category:Teacher | teacher]]</nowiki></code>. The second will put the current page in the teacher category as mentioned above.

This page is linked to the single catagory "MoodleDocs".

===Inter-language links===

Simply type <code><nowiki>[[es:Corresponding page title in Spanish]]</nowiki></code> in the English Moodle Docs, or <code><nowiki>[[en:Corresponding page title in English]]</nowiki></code> in the [[:es:Portada|Spanish Moodle Docs]], at the bottom of the page, below the category link. Inter-language links will appear automatically in the "In other languages" block.

===User-page links===
User names can be linked to a user page. For example <nowiki>[[User:Helen Foster|Helen Foster]] </nowiki> will appear [[User:Helen Foster|Helen Foster]] and link to the user's page. Comments by other users are generally left on the Users page comment tab.

==Page comments==
The page comment tab is used for discussion about the page. Sometimes before making an edit on the page for the first time, it is a good idea to check the page comments. It can be formatted the same as a main page, thus can be used to show a draft of a proposed change.

Talk page contributions may be signed and dated by typing four tildes <nowiki>~~~~</nowiki>. This will appear as [[User:Helen Foster|Helen Foster]] 06:35, 19 February 2006 (WST), for example.

==Page history==
The page history tab allows a way to look at changes between different edits. It is also possible to revert (roll back) an edit to a previous version. Usually this is left to the administrator, but you certainly can rollback your recent edits.

==Watch and unwatch page==
A watched page will appear on "my watchlist" when ever someone edits the page. There is a tab next to history which acts as a toggle between watch and unwatch. There is also at the bottom of the page in edit mode a "Watch this page" check off box.

==See also==
*[http://meta.wikimedia.org/wiki/Help:Editing MediaWiki Help:Editing]
*[http://meta.wikimedia.org/wiki/Help:HTML_in_wikitext Help:HTML in wikitext]
*[http://diberri.dyndns.org/html2wiki.html HTML to MediaWiki converter]
*[http://wikipedia.mozdev.org/ Firefox Wikipedia extension] - The Wikipedia extension makes editing of wiki pages easier by adding a new toolbar to your browser and by providing new menu items in the context menu (right mouse key).
*[[Wiki module]] for the wiki included as part of the standard Moodle

[[Category:MoodleDocs]]

[[es:Ayuda:Cómo se edita una página]]
[[fr:Aide:Comment éditer une page]]
[[ja:Help:編集方法]]
[[nl:Meehelpen]]
[[ru:Справка:Редактирование]]

Database activity

2008-03-07T14:39:17Z

Robek:

[[ru: База_данных]]
{{Databases}}
{{Moodle 1.6}}

The '''Database module''' [[Teacher_documentation#Activity_modules|activity]] allows the teacher and/or students to build, display and search a bank of record entries about any conceivable topic. The format and structure of these entries can be almost unlimited, including images, files, URLs, numbers and text amongst other things.

This module will create one table for instance, but you may create as many instances you need. The records can be linked to other tables and all resources in the course, if you allow autolink in a name field, but you cannot build a SQL query.

The table is not created in the SQL database, it is just stored there in lines of other SQL tables (mdl_data*).

== How to use the database module ==
* The first task is to [[Adding/editing_a_database|add the database]]. You will be asked to give it a name, provide some text explaining its intended purpose to users and set a few other options.
* Next you define the kind of [[Database fields|fields]] that define the information you wish to collect. For example a database of famous paintings may have a picture field called ''painting'', for uploading an image file showing the painting, and two text fields called ''artist'' and ''title'' for the name of the artist and the painting.
* It is then optional to edit the [[Database templates|database templates]] to alter the way in which the database displays entries.
* Note that if you later edit the fields in the databases you must use the Reset template button, or manually edit the template, to ensure the new fields are added to the display
* the [[Teacher]] and/or [[Students]] can start entering data and (optionally) commenting on and grading other submissions. These entries can be viewed alone, viewed as a list or searched and sorted.
* Data can be uploaded into the database from a .csv file:
** Click the 'Add Entry' tab
** At the bottom of the page there is a link 'Upload entries from a file' which provides help in assigning data in a csv file to the relevant fields in your database.

==Database and Roles==

Since Moodle 1.7 a number of options in Database have been migrated over to the Roles system. For example, preventing students (or any other role) submitting data must be done by overriding the role for that particular instance of the Database. However, do note that by default teachers are unable to override roles and this ability must first be granted by your Administrator for the course or site as appropriate.

== Example databases ==

Moodle.org has three good examples of the database module in action:

* [http://moodle.org/mod/data/view.php?id=6140 Moodle Buzz], a database of the titles, authors and web links to news articles mentioning Moodle
* [http://moodle.org/mod/data/view.php?d=26 Themes], a database with screenshots, download links and user comments about Moodle [[Themes|themes]]
* [http://moodle.org/mod/data/view.php?d=13 Modules and plugins], a database containing a variety of web links (download, documentation, discussion) and info (maintainer, module type, requirements) about the modular components of Moodle, including those created by third parties.

== Creative uses ==

You could use the database module to:

* allow collaboration on building a collection of web links/books/journal references related to a particular subject
* display student created photos/posters/websites/poems for peer comment and review
* gather comments and votes on a shortlist of potential logos/mascot names/project ideas
* provide a [http://moodle.org/mod/forum/discuss.php?d=52699 student file storage area]

== See also ==

* [[Glossary module]], which performs a similar though more specialised, text-based role
* Using Moodle [http://moodle.org/mod/forum/view.php?id=3505 Database module forum]
* [http://treadwell.cce.cornell.edu/moodle_doc/database_moodle/index.html Screencast introducing the Database Module and walking through creating a database]
Using Moodle forum discussions:
* [http://moodle.org/mod/forum/discuss.php?d=72260 Database Module: Each learner Private DB?]
* [http://moodle.org/mod/forum/discuss.php?d=84487 Database for Dummies please!]
* [http://moodle.org/mod/forum/discuss.php?d=89117 Restricting access to database content by user?]

[[Category:Modules]]

[[es:Base_de_datos_%28m%C3%B3dulo%29]]
[[eu:Datu-basea]]
[[fr:Base de données]]
[[cs:Modul Databáze]]
[[ja:データベースモジュール]]

Database activity

2008-03-07T14:36:23Z

Robek:

[[ru: База_данных]]
[[pl: baza danych]]
{{Databases}}
{{Moodle 1.6}}

The '''Database module''' [[Teacher_documentation#Activity_modules|activity]] allows the teacher and/or students to build, display and search a bank of record entries about any conceivable topic. The format and structure of these entries can be almost unlimited, including images, files, URLs, numbers and text amongst other things.

This module will create one table for instance, but you may create as many instances you need. The records can be linked to other tables and all resources in the course, if you allow autolink in a name field, but you cannot build a SQL query.

The table is not created in the SQL database, it is just stored there in lines of other SQL tables (mdl_data*).

== How to use the database module ==
* The first task is to [[Adding/editing_a_database|add the database]]. You will be asked to give it a name, provide some text explaining its intended purpose to users and set a few other options.
* Next you define the kind of [[Database fields|fields]] that define the information you wish to collect. For example a database of famous paintings may have a picture field called ''painting'', for uploading an image file showing the painting, and two text fields called ''artist'' and ''title'' for the name of the artist and the painting.
* It is then optional to edit the [[Database templates|database templates]] to alter the way in which the database displays entries.
* Note that if you later edit the fields in the databases you must use the Reset template button, or manually edit the template, to ensure the new fields are added to the display
* the [[Teacher]] and/or [[Students]] can start entering data and (optionally) commenting on and grading other submissions. These entries can be viewed alone, viewed as a list or searched and sorted.
* Data can be uploaded into the database from a .csv file:
** Click the 'Add Entry' tab
** At the bottom of the page there is a link 'Upload entries from a file' which provides help in assigning data in a csv file to the relevant fields in your database.

==Database and Roles==

Since Moodle 1.7 a number of options in Database have been migrated over to the Roles system. For example, preventing students (or any other role) submitting data must be done by overriding the role for that particular instance of the Database. However, do note that by default teachers are unable to override roles and this ability must first be granted by your Administrator for the course or site as appropriate.

== Example databases ==

Moodle.org has three good examples of the database module in action:

* [http://moodle.org/mod/data/view.php?id=6140 Moodle Buzz], a database of the titles, authors and web links to news articles mentioning Moodle
* [http://moodle.org/mod/data/view.php?d=26 Themes], a database with screenshots, download links and user comments about Moodle [[Themes|themes]]
* [http://moodle.org/mod/data/view.php?d=13 Modules and plugins], a database containing a variety of web links (download, documentation, discussion) and info (maintainer, module type, requirements) about the modular components of Moodle, including those created by third parties.

== Creative uses ==

You could use the database module to:

* allow collaboration on building a collection of web links/books/journal references related to a particular subject
* display student created photos/posters/websites/poems for peer comment and review
* gather comments and votes on a shortlist of potential logos/mascot names/project ideas
* provide a [http://moodle.org/mod/forum/discuss.php?d=52699 student file storage area]

== See also ==

* [[Glossary module]], which performs a similar though more specialised, text-based role
* Using Moodle [http://moodle.org/mod/forum/view.php?id=3505 Database module forum]
* [http://treadwell.cce.cornell.edu/moodle_doc/database_moodle/index.html Screencast introducing the Database Module and walking through creating a database]
Using Moodle forum discussions:
* [http://moodle.org/mod/forum/discuss.php?d=72260 Database Module: Each learner Private DB?]
* [http://moodle.org/mod/forum/discuss.php?d=84487 Database for Dummies please!]
* [http://moodle.org/mod/forum/discuss.php?d=89117 Restricting access to database content by user?]

[[Category:Modules]]

[[es:Base_de_datos_%28m%C3%B3dulo%29]]
[[eu:Datu-basea]]
[[fr:Base de données]]
[[cs:Modul Databáze]]
[[ja:データベースモジュール]]

Development:Multilang filter

2006-12-12T01:10:00Z

Robek:

Currently the multilang filter breaks the cache system. The "lang" concept should be included in the mechanism to be able to cache contents when such filter is enabled.

New comment by Robert Brenstein:

With the introduction of unicode, the filter got rewritten and now works for all languages. So, this caching problem is gone and the following text has only historical value.

Written by Robert Brenstein:

I am not a proper Moodle developer, so I may be missing something very obvious, but since I was forced to occupy myself with functioning of format_text() function recently, I have also pondered the problem of caching multilang strings.

My interpretation of current setup is that multilang disables caching because the md5 key used by in the format_text() to identify cached entries is based on the text of cached items. In the case of filtered items, the text is changed by the filter called in the middle of format_text(), so the correct key cannot be ascerned upon entry to format_text(), that is before the text was processed by the filter. Catch 22 so to speak.

An approach to change this could be:

First, add language code to md5 key calculation in addition to all the $option parms that were recently added.

Second, base md5 key not on the filtered text but on the original text passed to the format_text() function.

These two combined should provide unique key values and catch all text and language changes while allowing the cache to function as expected.

In case dual behavior needs to be maintained, for example, to bypass caching when another filter is called, or to avoid any unexpected side-effects of this change, an extra parameter to format_text() function can be added, initialized as default to NULL, for example, so if it is NULL, the current behavior remains in effect. It would be then up to the caller to activate the alternative behavior. This approach would allow more than one alternative behavior.

A simpler variant could be for format_text() to check upon entry whether multilang filter is enabled and modify its behavior accordingly. In that case, adding the state of multilang filter to the string used to generate the md5 key would be desired.

[[Category:Developer]]

Development talk:Roles

2006-05-22T01:04:03Z

Robek:

The list of capabilities for some activities should include viewing as a separate capability since it is a distinct action from editing or taking part, for example

choice_canviewresults

Development talk:Roles

2006-05-22T01:03:04Z

Robek:

The list of capabilities for some activities should include viewing as a separate capability since it is a distinct action from editing or taking part, for example

choice_viewresults

Development:Multilang filter

2006-03-27T23:23:10Z

Robek:

Currently the multilang filter breaks the cache system. The "lang" concept should be included in the mechanism to be able to cache contents when such filter is enabled.

Written by Robert Brenstein:

I am not a proper Moodle developer, so I may be missing something very obvious, but since I was forced to occupy myself with functioning of format_text() function recently, I have also pondered the problem of caching multilang strings.

My interpretation of current setup is that multilang disables caching because the md5 key used by in the format_text() to identify cached entries is based on the text of cached items. In the case of filtered items, the text is changed by the filter called in the middle of format_text(), so the correct key cannot be ascerned upon entry to format_text(), that is before the text was processed by the filter. Catch 22 so to speak.

An approach to change this could be:

First, add language code to md5 key calculation in addition to all the $option parms that were recently added.

Second, base md5 key not on the filtered text but on the original text passed to the format_text() function.

These two combined should provide unique key values and catch all text and language changes while allowing the cache to function as expected.

In case dual behavior needs to be maintained, for example, to bypass caching when another filter is called, or to avoid any unexpected side-effects of this change, an extra parameter to format_text() function can be added, initialized as default to NULL, for example, so if it is NULL, the current behavior remains in effect. It would be then up to the caller to activate the alternative behavior. This approach would allow more than one alternative behavior.

A simpler variant could be for format_text() to check upon entry whether multilang filter is enabled and modify its behavior accordingly. In that case, adding the state of multilang filter to the string used to generate the md5 key would be desired.

[[Category:Developer]]

Development:Multilang filter

2006-03-27T23:19:12Z

Robek:

Development:Multilang filter

2006-03-27T23:09:53Z

Robek:

Currently the multilang filter breaks the cache system. The "lang" concept should be included in the mechanism to be able to cache contents when such filter is enabled.

Written by Robert Brenstein:

I am not a proper Moodle developer, so I may be missing something very obvious, but since I was forced to occupy myself with functioning of format_text() function recently, I have also pondered the problem of caching multilang strings.

My interpretation of current setup is that multilang disables caching because the md5 key used by in the format_text() to identify cached entries is based on the text of cached items. In the case of filtered items, the text is changed by the filter called in the middle of format_text(), so the correct key cannot be ascerned upon entry to format_text(), that is before the text was processed by the filter. Catch 22 so to speak.

An approach to change this could be:

First, add language code to md5 key calculation in addition to all the $option parms that were recently added.

Second, base md5 key not on the filtered text but on the original text passed to the format_text() function.

These two combined should provide unique key values and catch all text and language changes while allowing the cache to function as expected.

In case dual behavior needs to be maintained, for example, to bypass caching when another filter is called, or to avoid any unexpected side-effects of this change, an extra parameter to format_text() function can be added, initialized as default to NULL, for example, so if it is NULL, the current behavior remains in effect. It would be then up to the caller to activate the alternative behavior (more than one could actually be possible).

A variant of the latter would be to add a twin function, format_text2() or format_text_multi() or else, which would be called in place of the standard one when the modified behavior is needed.

[[Category:Developer]]

Development:Multilang filter

2006-03-27T23:09:24Z

Robek:

Currently the multilang filter breaks the cache system. The "lang" concept should be included in the mechanism to be able to cache contents when such filter is enabled.

Written by Robert Brenstein:

I am not a proper Moodle developer, so I may be missing something very obvious, but since I was forced to occupy myself with functioning of format_text() function recently, I have also pondered the problem of caching multilang strings.

My interpretation of current setup is that multilang disables caching because the md5 key used by in the format_text() to identify cached entries is based on the text of cached items. In the case of filtered items, the text is changed by the filter called in the middle of format_text(), so the correct key cannot be ascerned upon entry to format_text(), that is before the text was processed by the filter. Catch 22 so to speak.

An approach to change this could be:

First, add language code to md5 key calculation in addition to all the $option parms that were recently added.

Second, base md5 key not on the filtered text but on the original text passed to the format_text() function.

These two combined should provide unique key values and catch all text and language changes while allowing the cache to function as expected.

In case dual behavior needs to be maintained, for example, to bypass caching when another filter is called, or to avoid any unexpected side-effects of this change, an extra parameter to format_text() function can be added, initialized as default to NULL, for example, so if it is NULL, the current behavior remains in effect. It would be then up to the caller to activate the alternative behavior (more than one could actually be possible).

A variant of the latters would be to add a twin function, format_text2() or format_text_multi() or else, which would be called in place of the standard one when the modified behavior is needed.

[[Category:Developer]]

Development:Multilang filter

2006-03-27T23:07:51Z

Robek:

Currently the multilang filter breaks the cache system. The "lang" concept should be included in the mechanism to be able to cache contents when such filter is enabled.

Written by Robert Brenstein:

I am not a proper Moodle developer, so I may be missing something very obvious, but since I was forced to occupy myself with functioning of format_text() function recently, I have also pondered the problem of caching multilang strings.

My interpretation of current setup is that multilang disables caching because the md5 key used by in the format_text() to identify cached entries is based on the text of cached items. In the case of filtered items, the text is changed by the filter called in the middle of format_text(), so the correct key cannot be ascerned upon entry to format_text(), that is before the text was processed by the filter. Catch 22 so to speak.

An approach to change this could be:

First, add language code to md5 key calculation in addition to all the $option parms that were recently added.

Second, base md5 key not on the filtered text but on the original text passed to the format_text() function.

These two combined should provide unique key values and catch all text and language changes while allowing the cache to function as expected.

In case dual behavior needs to be maintained, for example, to bypass caching when another filter is called, or to avoid any unexpected side-effects of this change, an extra parameter to format_text() function can be added, initialized as default to NULL, for example, so if it is NULL, the current behavior remains in effect. It would be then up to the caller to activate the alternative behavior (more than one could actually be possible).

A variant of this would be to add a twin function, format_text2() or format_text_multi() or else, which would be called in place of the standard one when the modified behavior is needed.

[[Category:Developer]]

Development:Multilang filter

2006-03-27T23:07:21Z

Robek:

Currently the multilang filter breaks the cache system. The "lang" concept should be included in the mechanism to be able to cache contents when such filter is enabled.

Written by Robert Brenstein:

I am not a proper Moodle developer, so I may be missing something very obvious, but since I was forced to occupy myself with functioning of format_text() function recently, I have also pondered the problem of caching multilang strings.

My interpretation of current setup is that multilang disables caching because the md5 key used by in the format_text() to identify cached entries is based on the text of cached items. In the case of filtered items, the text is changed by the filter called in the middle of format_text(), so the correct key cannot be ascerned upon entry to format_text(), that is before the text was processed by the filter. Catch 22 so to speak.

An approach to change this could be:

First, add language code to md5 key calculation in addition to all the $option parms that were recently added.

Second, base md5 key not on the filtered text but on the original text passed to format_text() function.

These two combined should provide unique key values and catch all text and language changes while allowing the cache to function as expected.

In case dual behavior needs to be maintained, for example, to bypass caching when another filter is called, or to avoid any unexpected side-effects of this change, an extra parameter to format_text() function can be added, initialized as default to NULL, for example, so if it is NULL, the current behavior remains in effect. It would be then up to the caller to activate the alternative behavior (more than one could actually be possible).

A variant of this would be to add a twin function, format_text2() or format_text_multi() or else, which would be called in place of the standard one when the modified behavior is needed.

[[Category:Developer]]

Development:Multilang filter

2006-03-27T23:06:07Z

Robek:

Currently the multilang filter breaks the cache system. The "lang" concept should be included in the mechanism to be able to cache contents when such filter is enabled.

Written by Robert Brenstein:

I am not a proper Moodle developer, so I may be missing something very obvious, but since I was forced to occupy myself with functioning of format_text() function recently, I have also pondered the problem of caching multilang strings.

My interpretation of current setup is that multilang disables caching because the md5 key used by in the format_text() to identify cached entries is based on the text of cached items. In the case of filtered items, the text is changed by the filter called in the middle of format_text(), so the correct key cannot be ascerned upon entry to format_text(), that is before the text was processed by the filter. Catch 22 so to speak.

An approach to change this could be:

First, add language code to md5 key calculation in addition to all the $option parms that were recently added.

Second, base md5 key not on the filtered text but on the original text passed to format_text() function.

These two combined should provide unique key values and catch all text and language changes.

In case dual behavior needs to be maintained, for example, to bypass caching when another filter is called, or to avoid any unexpected side-effects of this change, an extra parameter to format_text() function can be added, initialized as default to NULL, for example, so if it is NULL, the current behavior remains in effect. It would be then up to the caller to activate the alternative behavior (more than one could actually be possible).

A variant of this would be to add a twin function, format_text2() or format_text_multi() or else, which would be called in place of the standard one when the modified behavior is needed.

[[Category:Developer]]

Development:Multilang filter

2006-03-27T22:56:56Z

Robek:

Currently the multilang filter breaks the cache system. The "lang" concept should be included in the mechanism to be able to cache contents when such filter is enabled.

Written by Robert Brenstein:

I am not a proper Moodle developer, so I may be missing something very obvious, but since I was forced to occupy myself with functioning of format_text() function recently, I have also pondered the problem of caching multilang strings.

My interpretation of current setup is that multilang disables caching because the md5 key used by in the format_text() to identify cached entries is based on the text of cached items. In the case of filtered items, the text is changed by the filter called in the middle of format_text(), so the correct key cannot be ascerned upon entry to format_text(), that is before the text was processed by the filter. Catch 22 so to speak.

An approach to change this could be:

First, add language code to md5 key calculation in addition to all the $option parms that were recently added.

Second, base md5 key not on the filtered text but on the original text passed to format_text() function.

These two combined should provide unique key values and catch all text and language changes.

In case dual behavior need to be maintained, for example to bypass caching when another filter is called as well as to avoid any unexpected side-effects of this change, an extra parameter to format_text() function can be added, initialized as default to NULL, for example, so if it is NULL, the current behavior remains in effect. It would be then up to the caller to activate alternative behavior (more than one could actually be possible).

[[Category:Developer]]

Development:Multilang filter

2006-03-27T22:55:56Z

Robek:

Currently the multilang filter breaks the cache system. The "lang" concept should be included in the mechanism to be able to cache contents when such filter is enabled.

Written by Robert Brenstein:

I am not a proper Moodle developer, so I may be missing something very obvious, but since I was forced to occupy myself with functioning of format_text() function, I have prondered the problem of caching multilang strings.

My interpretation of current setup is that multilang disables caching because the md5 key used by in the format_text() to identify cached entries is based on the text of cached items. In the case of filtered items, the text is changed by the filter called in the middle of format_text(), so the correct key cannot be ascerned upon entry to format_text(), that is before the text was processed by the filter. Catch 22 so to speak.

An approach to change this could be:

First, add language code to md5 key calculation in addition to all the $option parms that were recently added.

Second, base md5 key not on the filtered text but on the original text passed to format_text() function.

These two combined should provide unique key values and catch all text and language changes.

In case dual behavior need to be maintained, for example to bypass caching when another filter is called as well as to avoid any unexpected side-effects of this change, an extra parameter to format_text() function can be added, initialized as default to NULL, for example, so if it is NULL, the current behavior remains in effect. It would be then up to the caller to activate alternative behavior (more than one could actually be possible).

[[Category:Developer]]

Development talk:Filterall support

2006-03-27T22:04:11Z

Robek:

Seems that Admin Block in Courses is omitted in the list and there are the following items that need to be filtered:

Your word for Teacher
 Your word for Teachers
 Your word for Student
 Your word for Students

Development talk:Filterall support

2006-03-27T22:03:50Z

Robek:

Seems that Admin Block in Courses is omitted in the list and there are the following items that need to be filtered:

Your word for Teacher
 Your word for Teachers
 Your word for Students

Development talk:Filterall support

2006-03-27T22:03:21Z

Robek:

Seems that Admin Block in Courses is omitted in the list and there are the following items that need to be filtered:

Your word for Teacher
Your word for Teachers
Your word for Student
Your word for Students

Development talk:Filterall support

2006-03-27T22:01:40Z

Robek:

Development talk:Filterall support

2006-03-27T22:00:57Z

Robek: Admin Block is missing

Admin Block in Courses:
Your word for Teacher
Your word for Teachers
Your word for Student
Your word for Students