now fixing a small cosmetic glitch and giving the correct commit message:
The latest and greatest version of the blocks documentation is here... Lots
of work and polishing to make it as useful as possible. I daresay that it's
pretty complete for its purpose now.
<p><a class="variable_title" href="#variable_content_type">$this->content_type</a> tells Moodle what kind of content to expect from this block. Here we have two simple choices. Either we set it to <a class="named_constant" href="#constant_block_type_text">BLOCK_TYPE_TEXT</a>, which tells Moodle to just take our content and display it on screen as-is; or we set it to <a class="named_constant" href="#constant_block_type_list">BLOCK_TYPE_LIST</a>, which tells Moodle that we want our block to display a nicely formatted list of items with optional icons next to each one. We can use <a class="named_constant" href="#constant_block_type_text">BLOCK_TYPE_TEXT</a> to manually create any content we want (do not be fooled by the name; HTML is allowed in the block's content without restriction) or use <a class="named_constant" href="#constant_block_type_list">BLOCK_TYPE_LIST</a> to easily create a simple menu.</p>
- <p><a class="variable_title" href="#variable_version">$this->version</a> is the version of our block. This actually would only make a difference if your block wanted to keep its own data in special tables in the database (i.e. for very complex blocks). In that case the version number is used exactly as it's used in activities; an upgrade script uses it to incrementally upgrade an "old" version of the block's data to the latest. We will outline this process further ahead, since blocks tend to be relatively simple and not hold their own private data. In our example, this is certainly the case so we just set <a class="variable_title" href="#variable_version">$this->version</a> to YYYYMMDD00 and forget about it.</p>
+ <p><a class="variable_title" href="#variable_version">$this->version</a> is the version of our block. This actually would only make a difference if your block wanted to keep its own data in special tables in the database (i.e. for very complex blocks). In that case the version number is used exactly as it's used in activities; an upgrade script uses it to incrementally upgrade an "old" version of the block's data to the latest. We will outline this process further ahead, since blocks tend to be relatively simple and not hold their own private data. In our example, this is certainly the case so we just set <a class="variable_title" href="#variable_version">$this->version</a> to <strong>YYYYMMDD00</strong> and forget about it.</p>
<p class="updating"><strong>UPDATING:</strong> Prior to version 1.5, the basic structure of each block class was slightly different. Refer to <a href="#appendix_b">Appendix B</a> for more information on the changes that old blocks have to make to conform to the new standard.</p>