Blocks/Appendix B - Revision history

Mudrd8mz: Text replacement - "`" to ""`


2021-07-14T13:34:25Z
Text replacement - "<code php>" to "<syntaxhighlight lang="php">"

				
				
				
				
				
				← Older revision
				Revision as of 13:34, 14 July 2021
				
Line 7:
Line 7:
In Moodle 1.4, all block classes were required to have a name like '''CourseBlock_something''' and the base class from which the derived was '''MoodleBlock'''. This has changed in Moodle 1.5, to bring the naming conventions in line with other object-oriented aspects of Moodle (for example there are classes enrolment_base, resource_base etc). The new block classes should instead be named like '''block_something''' and derive from '''block_base'''. This means that in order to make a block compatible with Moodle 1.5, you need to change the class definition In Moodle 1.4, all block classes were required to have a name like '''CourseBlock_something''' and the base class from which the derived was '''MoodleBlock'''. This has changed in Moodle 1.5, to bring the naming conventions in line with other object-oriented aspects of Moodle (for example there are classes enrolment_base, resource_base etc). The new block classes should instead be named like '''block_something''' and derive from '''block_base'''. This means that in order to make a block compatible with Moodle 1.5, you need to change the class definition



<code php> <syntaxhighlight lang="php">
class CourseBlock_online_users extends MoodleBlock { ... } class CourseBlock_online_users extends MoodleBlock { ... }
</syntaxhighlight> </syntaxhighlight>
Line 13:
Line 13:
to to



<code php>   <syntaxhighlight lang="php">  
class block_online_users extends block_base { ... } class block_online_users extends block_base { ... }
</syntaxhighlight> </syntaxhighlight>
Line 19:
Line 19:
An exception to the above is the special case where the block is intended to display a list of items instead of arbitrary text; in this case the block class must derive from class '''block_list''' instead, like this: An exception to the above is the special case where the block is intended to display a list of items instead of arbitrary text; in this case the block class must derive from class '''block_list''' instead, like this:



<code php>   <syntaxhighlight lang="php">  
class block_admin extends block_list { ... } class block_admin extends block_list { ... }
</syntaxhighlight> </syntaxhighlight>
Line 27:
Line 27:
In Moodle 1.4, in each block class it was mandatory to define a constructor which accepted a course data record as an argument (the example is from the actual Online Users block): In Moodle 1.4, in each block class it was mandatory to define a constructor which accepted a course data record as an argument (the example is from the actual Online Users block):



<code php> <syntaxhighlight lang="php">
function CourseBlock_online_users ($course) { function CourseBlock_online_users ($course) {
   $this->title        = get_string('blockname','block_online_users');    $this->title        = get_string('blockname','block_online_users');
Line 38:
Line 38:
In contrast, Moodle 1.5 does away with the constructor and instead requires you to define an [[Blocks/Appendix_A#init.28.29| init()]] method that takes no arguments: In contrast, Moodle 1.5 does away with the constructor and instead requires you to define an [[Blocks/Appendix_A#init.28.29| init()]] method that takes no arguments:



<code php> <syntaxhighlight lang="php">
function init() { function init() {
   $this->title   = get_string('blockname','block_online_users');    $this->title   = get_string('blockname','block_online_users');
Line 47:
Line 47:
Of course, this leaves you without access to the $course object, which you might actually need. Since that's probably going to be needed inside [[Blocks/Appendix_A#get_content.28.29| get_content()]], the way to retrieve it is by using this code: Of course, this leaves you without access to the $course object, which you might actually need. Since that's probably going to be needed inside [[Blocks/Appendix_A#get_content.28.29| get_content()]], the way to retrieve it is by using this code:



<code php>   <syntaxhighlight lang="php">  
   $course = get_record('course', 'id', $this->instance->pageid);    $course = get_record('course', 'id', $this->instance->pageid);
</syntaxhighlight> </syntaxhighlight>
Line 53:
Line 53:
If you are going to need access to $course from inside other methods in addition to [[Blocks/Appendix_A#get_content.28.29| get_content()]], you might fetch the $course object inside the [[Blocks/Appendix_A#specialization.28.29| specialization()]] method and save it as a class variable for later use, in order to avoid executing the same query multiple times: If you are going to need access to $course from inside other methods in addition to [[Blocks/Appendix_A#get_content.28.29| get_content()]], you might fetch the $course object inside the [[Blocks/Appendix_A#specialization.28.29| specialization()]] method and save it as a class variable for later use, in order to avoid executing the same query multiple times:



<code php> <syntaxhighlight lang="php">
function specialization() { function specialization() {
   $this->course = get_record('course', 'id', $this->instance->pageid);    $this->course = get_record('course', 'id', $this->instance->pageid);

`Mudrd8mz: Text replacement - "`" to ""

2021-07-14T13:03:06Z

Text replacement - "</code>" to "</syntaxhighlight>"

← Older revision		Revision as of 13:03, 14 July 2021
Line 9:		Line 9:
	<code php>		<code php>
	class CourseBlock_online_users extends MoodleBlock { ... }		class CourseBlock_online_users extends MoodleBlock { ... }
	</~~code~~>		</syntaxhighlight>

	to		to
Line 15:		Line 15:
	<code php>		<code php>
	class block_online_users extends block_base { ... }		class block_online_users extends block_base { ... }
	</~~code~~>		</syntaxhighlight>

	An exception to the above is the special case where the block is intended to display a list of items instead of arbitrary text; in this case the block class must derive from class '''block_list''' instead, like this:		An exception to the above is the special case where the block is intended to display a list of items instead of arbitrary text; in this case the block class must derive from class '''block_list''' instead, like this:
Line 21:		Line 21:
	<code php>		<code php>
	class block_admin extends block_list { ... }		class block_admin extends block_list { ... }
	</~~code~~>		</syntaxhighlight>

	=== Constructor versus ''init()'' ===		=== Constructor versus ''init()'' ===
Line 34:		Line 34:
	$this->version = 2004052700;		$this->version = 2004052700;
	}		}
	</~~code~~>		</syntaxhighlight>

	In contrast, Moodle 1.5 does away with the constructor and instead requires you to define an [[Blocks/Appendix_A#init.28.29\| init()]] method that takes no arguments:		In contrast, Moodle 1.5 does away with the constructor and instead requires you to define an [[Blocks/Appendix_A#init.28.29\| init()]] method that takes no arguments:
Line 43:		Line 43:
	$this->version = 2004111600;		$this->version = 2004111600;
	}		}
	</~~code~~>		</syntaxhighlight>

	Of course, this leaves you without access to the $course object, which you might actually need. Since that's probably going to be needed inside [[Blocks/Appendix_A#get_content.28.29\| get_content()]], the way to retrieve it is by using this code:		Of course, this leaves you without access to the $course object, which you might actually need. Since that's probably going to be needed inside [[Blocks/Appendix_A#get_content.28.29\| get_content()]], the way to retrieve it is by using this code:
Line 49:		Line 49:
	<code php>		<code php>
	$course = get_record('course', 'id', $this->instance->pageid);		$course = get_record('course', 'id', $this->instance->pageid);
	</~~code~~>		</syntaxhighlight>

	If you are going to need access to $course from inside other methods in addition to [[Blocks/Appendix_A#get_content.28.29\| get_content()]], you might fetch the $course object inside the [[Blocks/Appendix_A#specialization.28.29\| specialization()]] method and save it as a class variable for later use, in order to avoid executing the same query multiple times:		If you are going to need access to $course from inside other methods in addition to [[Blocks/Appendix_A#get_content.28.29\| get_content()]], you might fetch the $course object inside the [[Blocks/Appendix_A#specialization.28.29\| specialization()]] method and save it as a class variable for later use, in order to avoid executing the same query multiple times:
Line 57:		Line 57:
	$this->course = get_record('course', 'id', $this->instance->pageid);		$this->course = get_record('course', 'id', $this->instance->pageid);
	}		}
	</~~code~~>		</syntaxhighlight>

	=== Blocks with configuration ===		=== Blocks with configuration ===

Skodak at 12:25, 10 November 2013

2013-11-10T12:25:40Z

← Older revision		Revision as of 12:25, 10 November 2013
Line 1:		Line 1:
			{{obsolete}}
	== Differences in the Blocks API for Moodle versions prior to 1.5 ==		== Differences in the Blocks API for Moodle versions prior to 1.5 ==

Line 79:		Line 80:

	That's everything; your block will now be ready for use in Moodle 1.5!		That's everything; your block will now be ready for use in Moodle 1.5!

	~~[[Category:Blocks]]~~
	~~[[Category:Tutorial]]~~

	[[es:Desarrollo de bloques]]		[[es:Desarrollo de bloques]]
	[[ja:開発:ブロック/付録B]]		[[ja:開発:ブロック/付録B]]

Mits: ja link

2009-06-21T15:54:47Z

ja link

← Older revision		Revision as of 15:54, 21 June 2009
Line 84:		Line 84:

	[[es:Desarrollo de bloques]]		[[es:Desarrollo de bloques]]
			[[ja:開発:ブロック/付録B]]

Nakohdo: /* Blocks with customized applicable formats */

2009-02-08T18:40:37Z

Blocks with customized applicable formats

← Older revision		Revision as of 18:40, 8 February 2009
Line 70:		Line 70:
	=== Blocks with customized applicable formats ===		=== Blocks with customized applicable formats ===

	The correct way to specify the formats you want to allow or disallow your block to exist has been reworked for Moodle 1.5 to take account of the fact that blocks are no longer restricted to just courses. To have a block retain its intended behavior, you must change these format names (array keys in the return value of [[~~Blocks_Howto~~#~~method_applicable_formats~~\| applicable_formats]]) if they are used in your block:		The correct way to specify the formats you want to allow or disallow your block to exist has been reworked for Moodle 1.5 to take account of the fact that blocks are no longer restricted to just courses. To have a block retain its intended behavior, you must change these format names (array keys in the return value of [[Blocks/Appendix_A#applicable_formats.28.29\| applicable_formats()]] if they are used in your block:

	# '''social''' should become '''course-view-social'''		# '''social''' should become '''course-view-social'''

Nakohdo: /* Blocks with configuration */

2009-02-08T18:39:05Z

Blocks with configuration

← Older revision		Revision as of 18:39, 8 February 2009
Line 62:		Line 62:
	In Moodle 1.4, blocks could only have what are now (in Moodle 1.5) called "global configuration" options, to differentiate from the new "instance configuration" options. If your block has support for configuration, you will need to take these steps:		In Moodle 1.4, blocks could only have what are now (in Moodle 1.5) called "global configuration" options, to differentiate from the new "instance configuration" options. If your block has support for configuration, you will need to take these steps:

	# Rename your ~~<span class="filename">~~config.html~~</span>~~ file to ~~<span class="filename">~~config_global.html~~</span>~~.		# Rename your '''config.html''' file to '''config_global.html'''.
	# Edit the newly renamed file and completely remove the <form> tag (Moodle now wraps your configuration in a form automatically).		# Edit the newly renamed file and completely remove the <form> tag (Moodle now wraps your configuration in a form automatically).
	# If you are using any HTML <input> tags other than those that directly affect your configuration (for example, "sesskey"), REMOVE those too (Moodle will add them automatically as required).		# If you are using any HTML <input> tags other than those that directly affect your configuration (for example, "sesskey"), REMOVE those too (Moodle will add them automatically as required).
	# If you have overridden '''print_config''', rename your method to ~~'''~~config_print~~'''~~.		# If you have overridden '''print_config''', rename your method to [[Blocks/Appendix_A#config_print.28.29\|config_print()]].
	# If you have overridden '''handle_config''', rename your method to ~~'''~~config_save~~'''~~.		# If you have overridden '''handle_config''', rename your method to [[Blocks/Appendix_A#config_save.28.29\|config_save()]].

	=== Blocks with customized applicable formats ===		=== Blocks with customized applicable formats ===

Nakohdo: /* Blocks with customized applicable formats */ added links

2009-02-08T18:35:20Z

Blocks with customized applicable formats: added links

← Older revision		Revision as of 18:35, 8 February 2009
Line 76:		Line 76:
	# '''weeks''' should become '''course-view-weeks'''		# '''weeks''' should become '''course-view-weeks'''

	You should also keep in mind that there is now the possibility of blocks being displayed in other pages too, like the introductory page that users see when they enter an activity module. You might therefore need to make the specification for applicable formats more restrictive to keep your block out of pages it is not supposed to be shown in. Also, there are subtle changes to the way that the final decision to allow or disallow a block is made. For the technical details refer to the definition of [[~~Blocks_Howto~~#~~method_applicable_formats~~\| applicable_formats]], and for a more extended example read [[~~Blocks_Howto~~#~~section_authorized_personnel_only~~\| the section dedicated to this subject]].		You should also keep in mind that there is now the possibility of blocks being displayed in other pages too, like the introductory page that users see when they enter an activity module. You might therefore need to make the specification for applicable formats more restrictive to keep your block out of pages it is not supposed to be shown in. Also, there are subtle changes to the way that the final decision to allow or disallow a block is made. For the technical details refer to the definition of [[Blocks/Appendix_A#applicable_formats.28.29\| applicable_formats()]], and for a more extended example read [[Blocks#Authorized_Personnel_Only\|Authorized Personnel Only]], the section dedicated to this subject.

	That's everything; your block will now be ready for use in Moodle 1.5!		That's everything; your block will now be ready for use in Moodle 1.5!

Nakohdo: /* Constructor versus ''init()'' */

2009-02-08T18:32:29Z

Constructor versus ''init()''

← Older revision		Revision as of 18:32, 8 February 2009
Line 50:		Line 50:
	</code>		</code>

	If you are going to need access to $course from inside other methods in addition to [[Blocks/Appendix_A#get_content.28.29\| get_content()]], you might fetch the $course object inside the [[~~https://docs.moodle.org/en/Development:~~Blocks/Appendix_A#specialization.28.29\| specialization()]] method and save it as a class variable for later use, in order to avoid executing the same query multiple times:		If you are going to need access to $course from inside other methods in addition to [[Blocks/Appendix_A#get_content.28.29\| get_content()]], you might fetch the $course object inside the [[Blocks/Appendix_A#specialization.28.29\| specialization()]] method and save it as a class variable for later use, in order to avoid executing the same query multiple times:

	<code php>		<code php>

Nakohdo: /* Constructor versus ''init()'' */ added links

2009-02-08T18:31:46Z

Constructor versus ''init()'': added links

← Older revision		Revision as of 18:31, 8 February 2009
Line 35:		Line 35:
	</code>		</code>

	In contrast, Moodle 1.5 does away with the constructor and instead requires you to define an init() method that takes no arguments:		In contrast, Moodle 1.5 does away with the constructor and instead requires you to define an [[Blocks/Appendix_A#init.28.29\| init()]] method that takes no arguments:

	<code php>		<code php>
Line 44:		Line 44:
	</code>		</code>

	Of course, this leaves you without access to the $course object, which you might actually need. Since that's probably going to be needed inside [[~~Blocks_Howto~~#~~method_get_content~~\| get_content]], the way to retrieve it is by using this code:		Of course, this leaves you without access to the $course object, which you might actually need. Since that's probably going to be needed inside [[Blocks/Appendix_A#get_content.28.29\| get_content()]], the way to retrieve it is by using this code:

	<code php>		<code php>
Line 50:		Line 50:
	</code>		</code>

	If you are going to need access to $course from inside other methods in addition to [[~~Blocks_Howto~~#~~method_get_content~~\| get_content]], you might fetch the $course object inside the [[~~Blocks_Howto~~#~~method_specialization~~\| specialization]] method and save it as a class variable for later use, in order to avoid executing the same query multiple times:		If you are going to need access to $course from inside other methods in addition to [[Blocks/Appendix_A#get_content.28.29\| get_content()]], you might fetch the $course object inside the [[https://docs.moodle.org/en/Development:Blocks/Appendix_A#specialization.28.29\| specialization()]] method and save it as a class variable for later use, in order to avoid executing the same query multiple times:

	<code php>		<code php>

Nakohdo: /* Constructor versus init() */

2009-02-06T22:01:53Z

Constructor versus init()

← Older revision		Revision as of 22:01, 6 February 2009
Line 22:		Line 22:
	</code>		</code>

	=== Constructor versus init() ===		=== Constructor versus ''init()'' ===

	In Moodle 1.4, in each block class it was mandatory to define a constructor which accepted a course data record as an argument (the example is from the actual Online Users block):		In Moodle 1.4, in each block class it was mandatory to define a constructor which accepted a course data record as an argument (the example is from the actual Online Users block):

← Older revision		Revision as of 13:34, 14 July 2021
Line 7:		Line 7:
	In Moodle 1.4, all block classes were required to have a name like '''CourseBlock_something''' and the base class from which the derived was '''MoodleBlock'''. This has changed in Moodle 1.5, to bring the naming conventions in line with other object-oriented aspects of Moodle (for example there are classes enrolment_base, resource_base etc). The new block classes should instead be named like '''block_something''' and derive from '''block_base'''. This means that in order to make a block compatible with Moodle 1.5, you need to change the class definition		In Moodle 1.4, all block classes were required to have a name like '''CourseBlock_something''' and the base class from which the derived was '''MoodleBlock'''. This has changed in Moodle 1.5, to bring the naming conventions in line with other object-oriented aspects of Moodle (for example there are classes enrolment_base, resource_base etc). The new block classes should instead be named like '''block_something''' and derive from '''block_base'''. This means that in order to make a block compatible with Moodle 1.5, you need to change the class definition

	<~~code~~ php>		<syntaxhighlight lang="php">
	class CourseBlock_online_users extends MoodleBlock { ... }		class CourseBlock_online_users extends MoodleBlock { ... }
	</syntaxhighlight>		</syntaxhighlight>
Line 13:		Line 13:
	to		to

	<~~code~~ php>		<syntaxhighlight lang="php">
	class block_online_users extends block_base { ... }		class block_online_users extends block_base { ... }
	</syntaxhighlight>		</syntaxhighlight>
Line 19:		Line 19:
	An exception to the above is the special case where the block is intended to display a list of items instead of arbitrary text; in this case the block class must derive from class '''block_list''' instead, like this:		An exception to the above is the special case where the block is intended to display a list of items instead of arbitrary text; in this case the block class must derive from class '''block_list''' instead, like this:

	<~~code~~ php>		<syntaxhighlight lang="php">
	class block_admin extends block_list { ... }		class block_admin extends block_list { ... }
	</syntaxhighlight>		</syntaxhighlight>
Line 27:		Line 27:
	In Moodle 1.4, in each block class it was mandatory to define a constructor which accepted a course data record as an argument (the example is from the actual Online Users block):		In Moodle 1.4, in each block class it was mandatory to define a constructor which accepted a course data record as an argument (the example is from the actual Online Users block):

	<~~code~~ php>		<syntaxhighlight lang="php">
	function CourseBlock_online_users ($course) {		function CourseBlock_online_users ($course) {
	$this->title = get_string('blockname','block_online_users');		$this->title = get_string('blockname','block_online_users');
Line 38:		Line 38:
	In contrast, Moodle 1.5 does away with the constructor and instead requires you to define an [[Blocks/Appendix_A#init.28.29\| init()]] method that takes no arguments:		In contrast, Moodle 1.5 does away with the constructor and instead requires you to define an [[Blocks/Appendix_A#init.28.29\| init()]] method that takes no arguments:

	<~~code~~ php>		<syntaxhighlight lang="php">
	function init() {		function init() {
	$this->title = get_string('blockname','block_online_users');		$this->title = get_string('blockname','block_online_users');
Line 47:		Line 47:
	Of course, this leaves you without access to the $course object, which you might actually need. Since that's probably going to be needed inside [[Blocks/Appendix_A#get_content.28.29\| get_content()]], the way to retrieve it is by using this code:		Of course, this leaves you without access to the $course object, which you might actually need. Since that's probably going to be needed inside [[Blocks/Appendix_A#get_content.28.29\| get_content()]], the way to retrieve it is by using this code:

	<~~code~~ php>		<syntaxhighlight lang="php">
	$course = get_record('course', 'id', $this->instance->pageid);		$course = get_record('course', 'id', $this->instance->pageid);
	</syntaxhighlight>		</syntaxhighlight>
Line 53:		Line 53:
	If you are going to need access to $course from inside other methods in addition to [[Blocks/Appendix_A#get_content.28.29\| get_content()]], you might fetch the $course object inside the [[Blocks/Appendix_A#specialization.28.29\| specialization()]] method and save it as a class variable for later use, in order to avoid executing the same query multiple times:		If you are going to need access to $course from inside other methods in addition to [[Blocks/Appendix_A#get_content.28.29\| get_content()]], you might fetch the $course object inside the [[Blocks/Appendix_A#specialization.28.29\| specialization()]] method and save it as a class variable for later use, in order to avoid executing the same query multiple times:

	<~~code~~ php>		<syntaxhighlight lang="php">
	function specialization() {		function specialization() {
	$this->course = get_record('course', 'id', $this->instance->pageid);		$this->course = get_record('course', 'id', $this->instance->pageid);