The dual front-page/system-wide form to edit blocks can
be reduced asuming that, always:
A) system sets the context to system,
recursively and with page-type set to "*"
B) frontpage only sets the context to site-course,
non-recursively and with page-type set to "site-index"
C) frontpage all added sets the context to site-course,
recursively and with paget-type set to "*"
And that is the change that this patch provides, by:
1) detecting properly if we are editing blocks @ protpage
2) passing that information to the form data processor
3) setting parentcontextid, showinsubcontexts and
pagetypepattern following the A, B, C immutables above.
Finally, and affecting some other system-wide pages, there
are cases (my, user templates...) having only one possible
pagetypepattern, and it looks badly if the page has subpages, so
for those system-wide cases we are showing exceptionaly the
pagetypepattern statically. This will be revisited once MDL-30574
is decided and implemented, although perhaps it's ok to leave it
as default to places with only one pagetypepattern available.
This is an alternative solution to MDL-27812. If the current block
instance has page type set to site-index, we need to provide a way how
that page type pattern can be reset back to other value.
In particular for editing sticky blocks. If the admin addes one at site level,
then the teacher should not be able to change its configuration from
the course page, but should be able to set the position on this page.
This mostly works now, but ...
* The UI needs further work. In particular we need a non-advanced mode.
* This only works for blocks that use a new edit_form.php to replace config_instance.html.
* .. and so far I have only implemented edit_form.php for the HTML block so far.
* Needs to be enabled (with no block-specific config) for blocks without instance config, so you can control their positioning.
