Page format

Other tools ::: format_page
Maintained by Valery Fremaux
Part of set Page Course Format.
the "page format" is a very flexible course format allowing building a hierarchical course with nested pages organisation and a totally floxeible way of compositing the course with blocs and activities placed anywhere in the three-or-less-columns layout. Additionnally it proposes a new richer way to integrate activities in course, with "alternate views" that changes the historical [ "icon" + Link ] display. Some standard activities will have some alternate available views, and we still receive suggestions about how could some activites have an "enriched" display in the course pages. The page format is now maintained by ActiveProLearn (France)
Latest release:
32 sites
14 downloads
24 fans
Current versions available: 7

IMPORTANT NOTE FOR PLUGIN ARCHIVE AVAILABILITY : due to the large amount of plugins supported, it is NOT affordable for us to update moodle.org packages. Please use the Source Control urls to our github to get plugins archives

This format has been used in big size project in France (Perform@nce, Ministry of Education with Intel support, is adopted in Rectorat de Strasbourg and recently the france southern region Provence Alpes Côte d'Azur for secondary education.

Provides several enhancements over the historical 1.9 flexpage version :

  • Easy move of widgets all around the layout
  • Easy page duplication
  • Easy page reorder with graphical treeview
  • Enhanced access control : Public external access pages
  • Enhanced access control : Teachers reserved pages (hidden but published)
  • Enhanced access control : Students published pages
  • Enhanced access control : Activity score conditional page
  • Layout enhancement : Page override by another activity module 
  • Individualisation : User specific pages
  • Individualisation : Group specific pages
  • Individualisation : With page_module new structure, indivualize each widget per user (expermiental)
  • Page side comment pages fot teachers
Strong dependencies: 
  • You NEED the block page_module being installed for the page format to work
  • You NEED customscripts to be activated, and provided customscripts to be settled
  • Standard Moodle have a protection to not set a module in several sections of the course (not consistant in standard course formats). Page format needs this restriction to be overriden. A singleline impact point patch is provided in the distribution. 
Weaker dependencies:
  • You SHOULD choose one of block page_tracker (Learning Stations)
  • The original pagemenu course module is OBSOLETE and ils NOT any more maintained.
What other components are Page format aware:
  • The use_stats (block) and trainingsessions (report) know about page format. They can provide a course report time tracking presenting the guessed course structure based on page format organisation.
  • The (future publication, based in checklist) learningtimecheck module and report are aware of page format, and will propose to work in a page or page tree scope (in addition to section and course scope as for standard formats)

Screenshots

Screenshot #0
Screenshot #1
Screenshot #2
Screenshot #3

Contributors

Valery Fremaux (Lead maintainer)
Please login to view contributors details and/or to contact them

Comments RSS

Comments

  • Valery Fremaux
    Mon, 3 Feb 2014, 5:06 PM
    After testing : Some deprecated functions to fix (easy). Again big changes in standard layout management functions. with result of having to redraw much deeper the page block manager to override new incompatible behaviours (removed block move commands)... Some amount of work again for 2.6 forth follow....
  • Valery Fremaux
    Sat, 8 Mar 2014, 7:02 AM
    new release fixes definitevely the course restore issues using more accurately the subpage block location.
  • MD shot of me from his iphone4
    Thu, 17 Apr 2014, 5:05 PM
    Thanks Valery for maintaining this smile
    We should publish this soon.

    Is the __goodies folder necessary for the plugin to work?
    it would be better to refactor these into separate plugins that are specified as 'required' within version.php

    At the moment, the way it is now with stuff under __goodies, it will cause upgrade path issues. If needed, please create MDL issues to help improve modularity in core moodle.
  • MD shot of me from his iphone4
    Thu, 17 Apr 2014, 5:13 PM
    I've created the set 'Page Course Format' and am adding the 4 to it so we can see the dependencies/set clearly.
  • MD shot of me from his iphone4
    Thu, 17 Apr 2014, 5:17 PM
    Valery, can you comment that the plugins are correct in the set. Do you want to provide a description for the overall set? Mine is obviously not very clear there.
  • Valery Fremaux
    Thu, 1 May 2014, 4:57 PM
    Hi Aparup, sorry for that delay... lot to do here... reltive to __goodies : these are parts that do not really fit into the plugin, and are not for some essential for the plugin to work (the theme sample). Another goodie is conversely important to be installed properly, but has no legacy location in Moodle, except the usual practice of overriding customscripts into the "local" area. I know this is a bit confusing and collides with the new 'local' subplugin policy... Is there another Moodle 2 "usual location" for writing customscripts ?

    Relative to set : gonna see what i can see from here and tell you
  • Valery Fremaux
    Thu, 1 May 2014, 5:02 PM
    Set definition : The Page Course Format set assembles all the parts providing a flexible multiple page course format based on the moodle 1.9 version of Flexpage, highly reworked and enhanced with a lot of new features. Given to ensure the technical continuity of old content written as flexpage courses in Moodle 9, it keeps the exact data structure and GUI concepts. Productivity, format cross compatibility, and course individualisation have been added for a stronger integration.
  • David Mudrák
    Wed, 21 May 2014, 5:36 AM
    It's apparent that the Page format integration with a site is not a trivial
    task. As additional manual steps are required, we should not really display
    the "Install" button for none of these Page set plugins. We will need to
    improve the Plugins directory code so we are able to disable this feature from
    selected plugins (once we have that, we can move your VMoodle block to the
    appropriate category again, by the way). Note that we generally discourage
    form solutions that require post-installation hacks like this. We try hard to
    make plugins installation and updates as automatic as possible for good
    reasons.

    I must admit I'm not a big fan of solutions based on custom scripts as they
    can easily take the whole site into a problematic state (e.g. when the
    original script is updated during the regular Moodle upgrade or if a security
    related issue is fixed in some overridden native script). That feature was not
    really intended to be (ab)used by distributed plugins.

    I would like to hear more on relation between this Page format and the
    Flexpage format by Moodlerooms (which is already present in the Plugins
    directory). Was their 1.x version just a conceptual inspiration or was some
    code actually re-used?

    Please note there is nothing like @reauthor doc tag supported. Author names
    can be mentioned in the @copyright tag. But that has nothing to do with giving
    the credit. It's there purely for legal reasons as the original file author
    holds the copyright (copyleft) and is the one who ignites the GPL viral
    behaviour.

    The installation instructions in the README.txt file needs probably a
    revision. They mention to rename the format_page folder that is not present in
    the ZIP now. The /local folder is not recommended location for
    $CFG->customscripts any more as it became the root of the new plugin type. I
    understood - on contrary to what instructions say, that all the __goodies are
    to placed as custom scripts. Am I right?

    I noticed that the recommended boilerplate was not used in many files
    file. The boilerplate is recommended at the beginning of each file and makes
    explicit the GPL license. You may want to review
    http://docs.moodle.org/dev/Coding_style#Files to learn more about the
    boilerplate comments.

    Please note that overall coding style is currently far far away from
    recommended Moodle's coding style as outlined in
    http://docs.moodle.org/dev/Coding_style and  http://docs.moodle.org/dev/Coding
    This makes the code review much less funny job than it could be and does not
    put a good light on the product itself. Masterpiece plugins are great in
    details such as the coding style, too. The code checker plugin can be quite
    helpful in fine tuning your code and can be found at:
    https://moodle.org/plugins/view.php?plugin=local_codechecker You may wish to
    consider using that tool to further improve your plugin.

    For now, I am going to mark all the plugins in the set as needing more work
    until we get these issues resolved. Thanks for your patience with the review
    and approval process.
  • Valery Fremaux
    Wed, 21 May 2014, 3:49 PM
    Hi David,

    first let me thank you for your deep analysis. It may be the first time in ten years of continuous developement over Moodle i get such a core view return.

    About remarks :

    Automated install : I'm really sure to NEVER enable this in my moodles. Although the contrib review process is really improving and leading to more quality, i'm getting convinced that there is no real way to avoid completely regression risks in an open widely contributed technology...

    Customscript : i totally agree with you. Customscript is the very last extremity i use when all other architectural core sidepath attempts have failed. In that case, the page-format routing was really untweakable in core.

    I was wondering how to deal with local/customscripts collision. I think you gave me the way to some better solution. I will rework in that diretion to remove this old practice in all my instances and projects.

    Related to Page/Flexpage : Things are gone a very different way between both : Page format redraw is really based on Flexpage1.9 original structure and code, but was intended to :
    - Provide content reuse of a lo of old flexpage based content on 1.9 programs
    - Avoid using a proprietary, opaque coded framework (mr)
    - Try to enhance the "page in theme" integration, not trivial in new Flexpage and forcing to draw a special integration for each theme instance being used. (Page just adds page formats to existing theme and that's all)
    - Keep the simple concept of three columns
    - Add a LOT of new features and author tools to improve productivity
    - Add a lot of improvement and flexibility around content individualiation, page control.
    As a result, the Page format can now superseed most of pedagogic strategies that were needing external authoring tool and using the poorly featured intermediate scorm format. In other words, we can now build very scorm similar sequenced content only with native Moodle contents and activities.

    Code strictness : I will improve the check of the code to get it more accurate. This is one of my constant effort, but being damped by daily charge and a lot of plugins/versions to handle (and with such indirect funding for it of course). Code checker is a good idea. By the way, reviewing a lot of contribs, i'm not sure i am the furthest people from Moodle standards wink.

    Cheers ! work in progress...
  • David Mudrák
    Wed, 21 May 2014, 5:11 PM
    Hi Valery,

    thanks for your constructive reply and understanding my point of view.

    WRT the automatic install, there is also an alternative way we could proceed. Instead of a set for your plugins,
    we could make a subcategory below the Others category and put all Page related plugins there. We would make sure
    that the category description contains a warning that installation of these plugins require special attention and
    manual steps when integrating them to a site. So it would allow both making your valuable work published as well
    as protect those who use the auto-installation and auto-updates feature from unexpected results.

    I am aware of your issues with making your code working with the standard core files and I am happy you understand
    that customscripts should really be used as a last attempt. In fact, I would personally prefer set of patches
    (in .diff format) that must be applied to the core to make it work. You may consider that as an alternative if
    required changes were not that big. Anyway, I understood you would try and re-implement your code so that it
    does not rely on this. Let's see if you find it doable.

    Thanks for the explanation of the relation to the Flexpage. It helps me to understand the context of your project.

    And of course. The note about the coding style was really meant as a suggestion for eventual improvements. We do not
    generally discriminate because of it. And as you correctly noted, the Plugins directory contains much more "creative"
    code, indeed smile But we also believe that coding style consistency makes the code easier to understand for other
    Moodle developers, which is important for its further maintenance and bug fixing. I definitely did not mean it as
    a show stopper, sorry if it sounded like that.

    Looking forward to hearing from you and to re-review you work.
  • Valery Fremaux
    Sat, 21 June 2014, 6:25 AM
    Hi david !!
    A Huuuuge code review has been performed on all Page format components in all >= 2.4 versions with a meticulous reformatting, and solving the installation proposal avoiding to confuse the local folder.

    cheers !
  • David Mudrák
    Fri, 27 June 2014, 8:11 PM
    Your README file mentiones dependency on couple of other plugins. These should be explicitly set in your version.php too to avoid
    problems during the installation (regardless what you personally think about auto-install and auto-update features, there are people
    out there relying on it).

    Let me suggest to review the README file in details. There are quite misleading instructions such as "Get the theme/page in the
    __theme folder of the distributrion and copy the layout/page.php into your working format". I must admit I did not get too far when
    trying to test this plugin. I gave up trying to understand what "Open the config.php file of the format page, and copy the layout
    definitions into you current theme configuration" was supposed to mean.

    Anyway, you are cleared to land now on the Others runway. I am sure there are sites that will be happy with your plugin - regardless
    all the risks caused by custom scripts and non-trivial setup procedure. Wish you luck with maintaining this, it won't be easy task.
  • Nadav Kavalerchik
    Sat, 28 June 2014, 8:42 PM
    For a clean install on Moodle 2.7, You will also need the page_module block : https://github.com/vfremaux/moodle-block_page_module/tree/MOODLE_27_STABLE
  • Valery Fremaux
    Sun, 29 June 2014, 12:29 AM
    This is the case for all versions. Dependencies are on publish request, soon to be released. Next summer work will be to complete documentation on docs.moodle.org site.
  • Maxime Taisne
    Mon, 7 July 2014, 5:37 PM
    Hi Valery,
    This course format seems wonderful! Thanks!
    I've installed the complete plugin set and added the page layout and custom scripts flawlessly.
    However, when I change a course format to "Page", I'm asked to create a new page (I think this is normal since I don't have a page at this level). But when it doesn't work when I enter the needed information and submit.
    I'm just brought back to the page creation form and get no error message whatsoever, even when turning on the extra debug info.
    I'm running Moodle 2.7 under IIS 7.5 and SQL Server 2008. Could it be a incompatibility with the DB engine?
    Thanks for your feedback.
Please login to post comments