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

      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.

        Gliffy Diagrams

          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: