Moodle
  1. Moodle
  2. MDL-32652

Make block drag-drop work throughout Moodle

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.3, 2.4.1, 2.5
    • Fix Version/s: 2.5
    • Component/s: Blocks, Course
    • Labels:
    • Testing Instructions:
      Hide

      With editing turned on, attempt to drag/drop blocks to rearrange them on various types of pages:

      • Course pages
      • Mod pages
      • Admin pages
      • My Home page

      Make sure to reload the page after dragging blocks around, to ensure that the change has "stuck".

      Show
      With editing turned on, attempt to drag/drop blocks to rearrange them on various types of pages: Course pages Mod pages Admin pages My Home page Make sure to reload the page after dragging blocks around, to ensure that the change has "stuck".
    • Affected Branches:
      MOODLE_23_STABLE, MOODLE_24_STABLE, MOODLE_25_STABLE
    • Fixed Branches:
      MOODLE_25_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      MDL-32652_master
    • Rank:
      39589

      Description

      At the moment blocks drag-drop is working on course pages only. There is already infrastructure to make it work everywhere (blocks drag-drop js module initialiser can be moved to blocks output functions), but it requires some polishing.

      The inconsistency is awkward, as (assuming JS/AJAX is enabled) some pages will have the move icon on blocks, whereas others use drag & drop - with no obvious (to the user) reason why.

        Issue Links

          Activity

          Hide
          Mary Evans added a comment - - edited

          This may be the thing I am looking for that will fix the problem when you have a new block-region in a customised theme like Aardvark Post-IT (see attached image).

          Moving blocks in the old way was easy. Now with 'drag-n-drop' it is impossible! see MDL-33890

          Show
          Mary Evans added a comment - - edited This may be the thing I am looking for that will fix the problem when you have a new block-region in a customised theme like Aardvark Post-IT (see attached image). Moving blocks in the old way was easy. Now with 'drag-n-drop' it is impossible! see MDL-33890
          Hide
          Paul Nicholls added a comment -

          Pull details added. The main change is to shift the block drag/drop initialisation from course init to init_requirements_data (it claims to be there to initialise "the bits of JavaScript that every Moodle page should have", so seems like the most logical place), but some tweaks were required in the block dragdrop JS and the AJAX block move handler in order to make it work as expected on admin pages and My Home.

          Show
          Paul Nicholls added a comment - Pull details added. The main change is to shift the block drag/drop initialisation from course init to init_requirements_data (it claims to be there to initialise "the bits of JavaScript that every Moodle page should have", so seems like the most logical place), but some tweaks were required in the block dragdrop JS and the AJAX block move handler in order to make it work as expected on admin pages and My Home.
          Hide
          Damyon Wiese added a comment -

          Thanks Paul,

          Thanks for the patch - it looks good.

          Peer Review checklist:

          [Y] Syntax
          [Y] Output
          [Y] Whitespace
          [-] Language
          [-] Databases
          [Y] Testing
          [Y] Security
          [-] Documentation
          [Y] Git
          [Y] Sanity check

          Notes for integrators:
          I thought hard and tested a few things about the context setting code in:
          lib/ajax/blocks.php
          But it looks OK - the pagetype seems to be enough to secure this.

          I also looked closely at the javascript that turns the my-home content region into a block region (adds classes) and that does seem better than changing all the themes or adding an extra wrapping div in my/index.php etc.

          Sending for integration review.

          Thanks - Damyon

          Show
          Damyon Wiese added a comment - Thanks Paul, Thanks for the patch - it looks good. Peer Review checklist: [Y] Syntax [Y] Output [Y] Whitespace [-] Language [-] Databases [Y] Testing [Y] Security [-] Documentation [Y] Git [Y] Sanity check Notes for integrators: I thought hard and tested a few things about the context setting code in: lib/ajax/blocks.php But it looks OK - the pagetype seems to be enough to secure this. I also looked closely at the javascript that turns the my-home content region into a block region (adds classes) and that does seem better than changing all the themes or adding an extra wrapping div in my/index.php etc. Sending for integration review. Thanks - Damyon
          Hide
          Dan Poltawski added a comment -

          The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

          TIA and ciao

          Show
          Dan Poltawski added a comment - The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week. TIA and ciao
          Hide
          Ruslan Kabalin added a comment -

          Looks good to me, well done Paul!

          Show
          Ruslan Kabalin added a comment - Looks good to me, well done Paul!
          Hide
          Dan Poltawski added a comment -

          I've integrated this to master only. Its a an improvement a little bit risky for us to put in the stable branch.

          Great work, thanks guys!

          Show
          Dan Poltawski added a comment - I've integrated this to master only. Its a an improvement a little bit risky for us to put in the stable branch. Great work, thanks guys!
          Hide
          Ankit Agarwal added a comment -

          I cannot exactly describe the replication steps, but I got the following error when trying to move blocks around as admin in the user profile page (user/profile.php)

          This block (id=72) does not exist on this page (http://ankit.moodle.local/int/master/moodle/lib/ajax/blocks.php?courseid=1&pagelayout=mydashboard&pagetype=user-profile).
          URL: /lib/ajax/blocks.php?courseid=1&pagelayout=mydashboard&pagetype=user-profile
          Debug info: Error code: blockdoesnotexistonpage
          Stack trace:
          
          * line 830 of /lib/blocklib.php: block_not_on_page_exception thrown
          * line 1448 of /lib/blocklib.php: call to block_manager->find_instance()
          * line 112 of /lib/ajax/blocks.php: call to block_manager->process_url_move()
          

          I was using the blocks admin bookmarks and activity.
          Got the error more than once.
          Failing this sorry.
          Thanks

          Show
          Ankit Agarwal added a comment - I cannot exactly describe the replication steps, but I got the following error when trying to move blocks around as admin in the user profile page (user/profile.php) This block (id=72) does not exist on this page (http://ankit.moodle.local/int/master/moodle/lib/ajax/blocks.php?courseid=1&pagelayout=mydashboard&pagetype=user-profile). URL: /lib/ajax/blocks.php?courseid=1&pagelayout=mydashboard&pagetype=user-profile Debug info: Error code: blockdoesnotexistonpage Stack trace: * line 830 of /lib/blocklib.php: block_not_on_page_exception thrown * line 1448 of /lib/blocklib.php: call to block_manager->find_instance() * line 112 of /lib/ajax/blocks.php: call to block_manager->process_url_move() I was using the blocks admin bookmarks and activity. Got the error more than once. Failing this sorry. Thanks
          Hide
          Dan Poltawski added a comment -

          Hi Ankit,

          It'd be good if you could remember what pages this was on, etc?

          Show
          Dan Poltawski added a comment - Hi Ankit, It'd be good if you could remember what pages this was on, etc?
          Hide
          Ankit Agarwal added a comment -

          Hi Dan,
          I mentioned that I was on user profile page (user/profile.php). Isn't that the info you are looking for?

          Show
          Ankit Agarwal added a comment - Hi Dan, I mentioned that I was on user profile page (user/profile.php). Isn't that the info you are looking for?
          Hide
          Dan Poltawski added a comment -

          Hi Paul,

          Are you able to look at this? Otherwise i'm afraid we will need to revert it to do the release.

          Show
          Dan Poltawski added a comment - Hi Paul, Are you able to look at this? Otherwise i'm afraid we will need to revert it to do the release.
          Hide
          Paul Nicholls added a comment -

          Hi Dan,
          I'm looking into it at the moment. Will hopefully have a fix shortly - probably another context tweak in lib/ajax/blocks.php.

          Show
          Paul Nicholls added a comment - Hi Dan, I'm looking into it at the moment. Will hopefully have a fix shortly - probably another context tweak in lib/ajax/blocks.php.
          Hide
          Mary Evans added a comment -

          This ERROR is caused because PLUGIN has been deleted and not uninstalled and DB still holds information about it. This happened to me. So is on the testers server nothing to do with this fix.

          Show
          Mary Evans added a comment - This ERROR is caused because PLUGIN has been deleted and not uninstalled and DB still holds information about it. This happened to me. So is on the testers server nothing to do with this fix.
          Hide
          Mary Evans added a comment - - edited

          @Ankit Agarwal have you deleted some block plugins? Have you uninstalled them via Admin manage blocks? Check your DataBase for block id=72

          Show
          Mary Evans added a comment - - edited @ Ankit Agarwal have you deleted some block plugins? Have you uninstalled them via Admin manage blocks? Check your DataBase for block id=72
          Hide
          Paul Nicholls added a comment -

          Hi Mary,
          Thanks for your comments, but that's not what's happening in this case - the AJAX block drag/drop handler isn't looking for the block instance in the right place, so it thinks that it isn't there. I've just about got it sorted.

          Show
          Paul Nicholls added a comment - Hi Mary, Thanks for your comments, but that's not what's happening in this case - the AJAX block drag/drop handler isn't looking for the block instance in the right place, so it thinks that it isn't there. I've just about got it sorted.
          Hide
          Paul Nicholls added a comment - - edited

          Hm, adding another case to the pagetype switch works for editing the blocks on your own profile - but (as an admin) I've managed to get to another user's profile with editing on... at which point it gets trickier, because we're not passing the user ID of the profile we're viewing to lib/ajax/blocks.php. I'm pondering how to deal with this - if anyone reading this has any bright ideas, please comment

          Show
          Paul Nicholls added a comment - - edited Hm, adding another case to the pagetype switch works for editing the blocks on your own profile - but (as an admin) I've managed to get to another user's profile with editing on... at which point it gets trickier, because we're not passing the user ID of the profile we're viewing to lib/ajax/blocks.php. I'm pondering how to deal with this - if anyone reading this has any bright ideas, please comment
          Hide
          Ankit Agarwal added a comment -

          Thanks for the feedback guys, just to confirm anyway
          block instance id 72 represents "activity_modules" which is not deleted/removed from the site . And as far as I remember, I never deleted/removed/uninstalled any block modules on the instance of moodle on which am testing.

          Thanks

          Show
          Ankit Agarwal added a comment - Thanks for the feedback guys, just to confirm anyway block instance id 72 represents "activity_modules" which is not deleted/removed from the site . And as far as I remember, I never deleted/removed/uninstalled any block modules on the instance of moodle on which am testing. Thanks
          Hide
          Mary Evans added a comment - - edited

          @Paul Nicholls

          Sorry but I know very little about Javascript but would just like to ask what is the relevance of

          REGIONMAIN : 'region-main'

          when REGIONCONTENT : region-content is already added?

          To make blocks move you need to add class="block-region" to the container where blocks are wanting to be moved to.

          I know that the way blocks were moved to the center column (region-main) was created with a 'hack' whereas the block-regions (region-pre) and (region-post) are coded differently.

          Could this be anything to do with the problem you have now?

          Curiously...Mary

          Show
          Mary Evans added a comment - - edited @ Paul Nicholls Sorry but I know very little about Javascript but would just like to ask what is the relevance of REGIONMAIN : 'region-main' when REGIONCONTENT : region-content is already added? To make blocks move you need to add class="block-region" to the container where blocks are wanting to be moved to. I know that the way blocks were moved to the center column (region-main) was created with a 'hack' whereas the block-regions (region-pre) and (region-post) are coded differently. Could this be anything to do with the problem you have now? Curiously...Mary
          Hide
          Paul Nicholls added a comment -

          Ankit Agarwal / Dan Poltawski / Damyon Wiese,
          I've pushed a second commit to my Github repo (same branch) which gets as close as possible to making block drag/drop work on user profile pages. Note that there's still a small edge case that doesn't work - administrators moving blocks inherited from the system context on other users' profiles. Users (including admins) can move them on their own profile pages, though, and if an admin really desperately needs to move a system block on another user's profile, they can still click the button to edit the block instance config and move it that way. Alternatively, they can use the "login as" functionality to become the user in question, in which case it will also work just fine. There simply isn't sufficient information being passed through in the AJAX call in order to determine the correct context in this tiny edge case - and I don't have the time (or the inclination) to completely rewrite the block moving system at the moment, so I'm hoping that you're willing to accept this one small issue (we could create a new issue in the tracker for it, if you like) given that there are a few workarounds for it.

          Note that this commit also fixes an issue whereby the drop target that's added for an otherwise empty pre/post block region to end up in the wrong place if there are custom regions (such as the central "content" block region on user profile / My Home pages). It also adds a couple of divs around the "content" block region on the user profile page, because there wasn't sufficient structure to do the ID/class tweaks with JS as I did with My Home pages - but since this is only being integrated into master, I don't imagine that a minor page structure change like this is an issue - if there are any themes for which this causes display issues, they'll have plenty of time to deal with it before 2.5 is released.

          Mary Evans,
          CSS.REGIONMAIN ("region-main") is used as part of the selector that identifies the central block region on the My Home page, so that the relevant classes and IDs can be applied to make it actually work for block drag/drop. CSS.REGIONCONTENT ("region-content") is also used as part of this process, as it's not only a class name that needs to be applied to an inner div (hence its prior existence in blocks.js) but also an ID that's required because the central block region is called "content" (it's been set up by calling $PAGE->blocks->add_region('content');) - block regions need to have their ID set to "region-" followed by the region name. I hope that makes some sense to you - it's a bit tricky to explain unless you understand how block regions and the block drag/drop code work...

          -Paul

          Show
          Paul Nicholls added a comment - Ankit Agarwal / Dan Poltawski / Damyon Wiese , I've pushed a second commit to my Github repo (same branch) which gets as close as possible to making block drag/drop work on user profile pages. Note that there's still a small edge case that doesn't work - administrators moving blocks inherited from the system context on other users' profiles. Users (including admins) can move them on their own profile pages, though, and if an admin really desperately needs to move a system block on another user's profile, they can still click the button to edit the block instance config and move it that way. Alternatively, they can use the "login as" functionality to become the user in question, in which case it will also work just fine. There simply isn't sufficient information being passed through in the AJAX call in order to determine the correct context in this tiny edge case - and I don't have the time (or the inclination) to completely rewrite the block moving system at the moment, so I'm hoping that you're willing to accept this one small issue (we could create a new issue in the tracker for it, if you like) given that there are a few workarounds for it. Note that this commit also fixes an issue whereby the drop target that's added for an otherwise empty pre/post block region to end up in the wrong place if there are custom regions (such as the central "content" block region on user profile / My Home pages). It also adds a couple of divs around the "content" block region on the user profile page, because there wasn't sufficient structure to do the ID/class tweaks with JS as I did with My Home pages - but since this is only being integrated into master, I don't imagine that a minor page structure change like this is an issue - if there are any themes for which this causes display issues, they'll have plenty of time to deal with it before 2.5 is released. Mary Evans , CSS.REGIONMAIN ("region-main") is used as part of the selector that identifies the central block region on the My Home page, so that the relevant classes and IDs can be applied to make it actually work for block drag/drop. CSS.REGIONCONTENT ("region-content") is also used as part of this process, as it's not only a class name that needs to be applied to an inner div (hence its prior existence in blocks.js) but also an ID that's required because the central block region is called "content" (it's been set up by calling $PAGE->blocks->add_region('content'); ) - block regions need to have their ID set to "region-" followed by the region name. I hope that makes some sense to you - it's a bit tricky to explain unless you understand how block regions and the block drag/drop code work... -Paul
          Hide
          Damyon Wiese added a comment -

          I have a general concern about the way lib/ajax/blocks.php functions here (not a blocker and I don't have any better suggestions - just posting it for the record).

          Determining the page context from the pagetype is a bit flawed - I mentioned it before and couldn't find any examples of where it was broken - but clearly the user profile page was one - I wonder if there are others?

          Show
          Damyon Wiese added a comment - I have a general concern about the way lib/ajax/blocks.php functions here (not a blocker and I don't have any better suggestions - just posting it for the record). Determining the page context from the pagetype is a bit flawed - I mentioned it before and couldn't find any examples of where it was broken - but clearly the user profile page was one - I wonder if there are others?
          Hide
          Damyon Wiese added a comment -

          The div changes to user/profile.php also do not seem right. Now you can drag blocks to the center region - but you can't normally put them there if you edit the block settings.

          Show
          Damyon Wiese added a comment - The div changes to user/profile.php also do not seem right. Now you can drag blocks to the center region - but you can't normally put them there if you edit the block settings.
          Hide
          Dan Poltawski added a comment -

          Paul,

          Thanks for all your hard work on this.

          Seems there are still a few things left to do, so rather than leave this in not quite right state i'm going revert it for this week and we can come back to it in a future week when we've got it more complete.

          Show
          Dan Poltawski added a comment - Paul, Thanks for all your hard work on this. Seems there are still a few things left to do, so rather than leave this in not quite right state i'm going revert it for this week and we can come back to it in a future week when we've got it more complete.
          Hide
          Paul Nicholls added a comment -

          Damyon, although you can't put blocks into the center region on the user profile page via the instance config, the non-AJAX block moving gives a target in the center - otherwise I wouldn't have implemented it (you can confirm this by disabling Javascript in your browser, then clicking the move icon in any block on the user profile page).

          I'm at home now, so I don't have ready access to my dev sites to confirm, but I'm pretty sure it's the same on My Home - although you can move blocks there via the block moving interface (and, with my patches, by dragging and dropping), it's not an option in the instance config (except possibly if you're editing the config for an instance that's already in the "content" region). I suspect that the way it's getting the list of block regions doesn't account for custom regions added by the page itself (although it might account for those added by the theme).

          I'm fine with this being reverted for this week. Next week, I'll have a quick look (as that's all I'll have time for) to see how feasible it is to simply pass $PAGE->context->id into the $PAGE->requires->yui_module call - if the call is happening late enough in the page generation process, we should be able to safely assume that the page context won't change; if not, maybe it can be shifted to somewhere later in the process so that this holds. It'd definitely be cleaner and nicer if we can directly specify the page context in the AJAX call, though we'll still need some of the current checks in order to finish setting everything up (such as the troublesome "content" block region on My Home / user profile).

          -Paul

          Show
          Paul Nicholls added a comment - Damyon, although you can't put blocks into the center region on the user profile page via the instance config, the non-AJAX block moving gives a target in the center - otherwise I wouldn't have implemented it (you can confirm this by disabling Javascript in your browser, then clicking the move icon in any block on the user profile page). I'm at home now, so I don't have ready access to my dev sites to confirm, but I'm pretty sure it's the same on My Home - although you can move blocks there via the block moving interface (and, with my patches, by dragging and dropping), it's not an option in the instance config (except possibly if you're editing the config for an instance that's already in the "content" region). I suspect that the way it's getting the list of block regions doesn't account for custom regions added by the page itself (although it might account for those added by the theme). I'm fine with this being reverted for this week. Next week, I'll have a quick look (as that's all I'll have time for) to see how feasible it is to simply pass $PAGE->context->id into the $PAGE->requires->yui_module call - if the call is happening late enough in the page generation process, we should be able to safely assume that the page context won't change; if not, maybe it can be shifted to somewhere later in the process so that this holds. It'd definitely be cleaner and nicer if we can directly specify the page context in the AJAX call, though we'll still need some of the current checks in order to finish setting everything up (such as the troublesome "content" block region on My Home / user profile). -Paul
          Hide
          CiBoT added a comment -

          Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.

          Show
          CiBoT added a comment - Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.
          Hide
          CiBoT added a comment -

          Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.

          Show
          CiBoT added a comment - Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.
          Hide
          Paul Nicholls added a comment -

          I haven't finished testing yet, but just passing the context ID in (as per my previous comment) seems to be working wonders. I've also narrowed down why I was having a hard time editing blocks on other users' profile pages - the user has to have customised it first, in order for the public entry (private=0) for that user to be created in mdl_my_pages. Once that's been done, admins (and perhaps managers - I haven't tried that yet) can shuffle blocks around on the user's profile page.

          Clicking the "Customise this page" button on another user's profile also redirects you back to your own profile (with editing turned on), which makes me wonder whether the ability to customise the blocks on another user's page is even intentional: if it is, the redirection back to your own profile is a bug, as is the lack of a public mdl_my_pages record (it should be created as needed no matter who is trying to customise the page, assuming that they have permission); if not, the ability to customise blocks on other users' profiles at all is a bug. If somebody is able to clarify what the intended behaviour is here, I'm happy to file another bug ticket as appropriate (and maybe even work on it, if I can find time).

          Show
          Paul Nicholls added a comment - I haven't finished testing yet, but just passing the context ID in (as per my previous comment) seems to be working wonders. I've also narrowed down why I was having a hard time editing blocks on other users' profile pages - the user has to have customised it first, in order for the public entry (private=0) for that user to be created in mdl_my_pages. Once that's been done, admins (and perhaps managers - I haven't tried that yet) can shuffle blocks around on the user's profile page. Clicking the "Customise this page" button on another user's profile also redirects you back to your own profile (with editing turned on), which makes me wonder whether the ability to customise the blocks on another user's page is even intentional: if it is, the redirection back to your own profile is a bug, as is the lack of a public mdl_my_pages record (it should be created as needed no matter who is trying to customise the page, assuming that they have permission); if not, the ability to customise blocks on other users' profiles at all is a bug. If somebody is able to clarify what the intended behaviour is here, I'm happy to file another bug ticket as appropriate (and maybe even work on it, if I can find time).
          Hide
          Paul Nicholls added a comment -

          I've pushed another commit which changes over to passing the context ID - it simplifies the code in lib/ajax/blocks.php and makes it work in the previously broken corner case (admin moving system blocks on another user's profile page). I haven't found anywhere that it doesn't work.

          I'll rebase and squash, so there's just a single commit - but can anyone tell me whether I ought to do this on a new branch or whether it's ok to do this on the existing branch, given that it was integrated and then reverted?

          Show
          Paul Nicholls added a comment - I've pushed another commit which changes over to passing the context ID - it simplifies the code in lib/ajax/blocks.php and makes it work in the previously broken corner case (admin moving system blocks on another user's profile page). I haven't found anywhere that it doesn't work. I'll rebase and squash, so there's just a single commit - but can anyone tell me whether I ought to do this on a new branch or whether it's ok to do this on the existing branch, given that it was integrated and then reverted?
          Hide
          Damyon Wiese added a comment -

          The best for the integrator is a single patch on top of an up to date integration branch.

          Second best is a single clean patch that cherry-picks cleanly (and put a note to the integration that they should cherry-pick).

          Show
          Damyon Wiese added a comment - The best for the integrator is a single patch on top of an up to date integration branch. Second best is a single clean patch that cherry-picks cleanly (and put a note to the integration that they should cherry-pick).
          Hide
          Paul Nicholls added a comment -

          I've (force-)pushed an updated branch - a single commit, based on current master. It should cleanly cherry-pick onto 2.4 if it's decided that it's safe enough to backport (I'll be picking it onto our local 2.4 branch - if it doesn't apply cleanly, I'll push an updated 2.4 branch as MDL-32652_24, which currently has the first patch on top of the then-current 24_STABLE branch).

          Show
          Paul Nicholls added a comment - I've (force-)pushed an updated branch - a single commit, based on current master. It should cleanly cherry-pick onto 2.4 if it's decided that it's safe enough to backport (I'll be picking it onto our local 2.4 branch - if it doesn't apply cleanly, I'll push an updated 2.4 branch as MDL-32652 _24, which currently has the first patch on top of the then-current 24_STABLE branch).
          Hide
          Damyon Wiese added a comment -

          Thanks Paul,

          I think this is ready for integration now - the change to context looks good. Looking harder at the user profile page - it is correct to allow blocks there it is the edit block settings page that has the bug (Cannot set to content region - mymoodle page is the same) - not this patch.

          +1 from me!

          Show
          Damyon Wiese added a comment - Thanks Paul, I think this is ready for integration now - the change to context looks good. Looking harder at the user profile page - it is correct to allow blocks there it is the edit block settings page that has the bug (Cannot set to content region - mymoodle page is the same) - not this patch. +1 from me!
          Hide
          Mary Evans added a comment -

          Apologies I have just deleted my last comment and the image I had attached. The problem I was getting is not attributed to this tracker issue but a fault with the theme I used.

          Sorry!

          Show
          Mary Evans added a comment - Apologies I have just deleted my last comment and the image I had attached. The problem I was getting is not attributed to this tracker issue but a fault with the theme I used. Sorry!
          Hide
          Dan Poltawski added a comment -

          Integrated, thanks Paul!

          Show
          Dan Poltawski added a comment - Integrated, thanks Paul!
          Hide
          Jason Fowler added a comment -

          Works fine Paul, thanks for the patch

          Show
          Jason Fowler added a comment - Works fine Paul, thanks for the patch
          Hide
          Damyon Wiese added a comment -

          Congratulations! This issue has been resolved. Thanks for helping to make Moodle better for everyone!

          Regards, Damyon

          Show
          Damyon Wiese added a comment - Congratulations! This issue has been resolved. Thanks for helping to make Moodle better for everyone! Regards, Damyon
          Hide
          Helen Foster added a comment -

          Removing the docs_required label, as I can't think of anywhere in the user docs where this improvement should be mentioned. If you can think of anywhere, please shout!

          Also, if it needs mentioning in the dev docs, someone please add the dev_docs_required label.

          Show
          Helen Foster added a comment - Removing the docs_required label, as I can't think of anywhere in the user docs where this improvement should be mentioned. If you can think of anywhere, please shout! Also, if it needs mentioning in the dev docs, someone please add the dev_docs_required label.
          Hide
          Mary Evans added a comment - - edited

          Helen, since drag-n-drop will only work if AJAX is enabled, and since there is a new setting, I believe, that allows users to choose if they want to enable AJAX or not. So can't this be related to that in User documentation? That's if the setting is also documented!

          Show
          Mary Evans added a comment - - edited Helen, since drag-n-drop will only work if AJAX is enabled, and since there is a new setting, I believe, that allows users to choose if they want to enable AJAX or not. So can't this be related to that in User documentation? That's if the setting is also documented!
          Hide
          Mary Evans added a comment -

          Helen...I've just realised the setting I mentioned earlier is a Local Plugin. https://moodle.org/plugins/view.php?plugin=local_profileswitches

          Show
          Mary Evans added a comment - Helen...I've just realised the setting I mentioned earlier is a Local Plugin. https://moodle.org/plugins/view.php?plugin=local_profileswitches
          Hide
          Helen Foster added a comment -

          Thanks Mary for the clarification and for the link to the local plugin which people browsing this issue may find helpful.

          Show
          Helen Foster added a comment - Thanks Mary for the clarification and for the link to the local plugin which people browsing this issue may find helpful.
          Hide
          Dr. Indira Koneru added a comment -

          My home customized page in Moodle 2.4.

          Show
          Dr. Indira Koneru added a comment - My home customized page in Moodle 2.4.
          Hide
          Dr. Indira Koneru added a comment -

          My home customized page in Moodle 2.4. Dragged and dropped Calendar and Upcoming events to the center.

          Show
          Dr. Indira Koneru added a comment - My home customized page in Moodle 2.4. Dragged and dropped Calendar and Upcoming events to the center.
          Hide
          Dr. Indira Koneru added a comment -

          I'm unable to drag and drop blocks to the center column while customizing My home page (my/indexsys.php) in 2.5 (Site administration / ► Appearance / ► Default My home page).

          But, in 2.4 I was able to move Calendar and Upcoming events blocks to the center!!!

          Show
          Dr. Indira Koneru added a comment - I'm unable to drag and drop blocks to the center column while customizing My home page (my/indexsys.php) in 2.5 (Site administration / ► Appearance / ► Default My home page). But, in 2.4 I was able to move Calendar and Upcoming events blocks to the center!!!
          Hide
          Helen Foster added a comment -

          As this issue is closed, if you have discovered a drag-and-drop bug in 2.5, please create a new issue for it and link it to this issue.

          Show
          Helen Foster added a comment - As this issue is closed, if you have discovered a drag-and-drop bug in 2.5, please create a new issue for it and link it to this issue.

            People

            • Votes:
              7 Vote for this issue
              Watchers:
              13 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: