Having the purge options appear after the purge is a little confusing.

I'm not sure what you mean by your questions. The caches are local on the server rather than on your machine. They are used to cache language strings, JavaScript, styles, etc., but not page history. The reason you might want to purge these caches is that you have made a change to one of the items that is being cached, so the latest changed version can appear.

Michael;

I think what Daniele is asking, is much the same thing I have asked myself, time and time again, each time I use "Purge all caches". Clicking on the link in Site Administration > Development > Purge all caches brings you to the page Daniele is referring to. Clicking the button marked Purge, a redirect page appears telling your the purge has been done - continue. This then brings you back to the Purge page you started off at. It is at this point you wonder why, and then how do I get back. Strangely enough I was reluctant to press 'Cancel' as I thought that might actually cancel the action of purging the cache.

The first time I used the method Daniele describes, where the 'Purge all caches' link appears on everypage when Debugging is on, I clicked the 'Purge' button again as I thought it had not worked, but when I got back to the Purge page again I realised, that's as good as it gets.

I think what is actually needed, is a loop which once you have selected Purge, and the action completed, then the "PURGE" button should change to "DONE" which when clicked takes you back to where you were previously.

Mary

Thanks Mary
you exactly described my issue.
One more way to see the same problem is: the link to "Purge all caches" at the bottom of the page should move the user to the "Purge all caches" page but not actually purging. Otherwise, after the purge, why do the "Purge all caches" page is displayed?

I think it stays there because you might want to hit it over and over (while doing developery things in other windows).

Peer review please.

I am fixing this since I originally broke it in MDL-24591.

If this passes peer review, then I think it should be back-ported to all stable branches.

Thanks for fixing this Tim,

Patch looks good, few points which you might want to consider before pushing it forward.

1. returnurl parameter is used by other code in moodle, it might be nice to rename it, to avoid any conflicts.
2. At #L1R502 and #L0R50, /admin is hard-coded in url. Moodle defines $CFG->admin to change admin directory path.
3. It might be nice to keep cancel and purge cache button, and clicking on cancel should take user to old page where user came from.
   • When user comes to purge page via navigation, add returnurl to navigation link for purge cache.
   • Clicking cancel will take user back to the old page.

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

Thanks for the review Raj.

I disagree with all three of your points:

1. I do not see how the returnurl parameter will clash. The form of a purgecaches request is ...?confirm=1&sesskey=

&returnurl=

since the returnurl value is encoded, nothing in there can clash with our returnurl parameter. Let me know if I am missing anything.

2. No. moodle_url('/admin/...') correctly takes care of $CFG->admin for you. You don't have to. This is the correct code.

3. In the situation where there is a return URL, the user is immediately redirected back to the page they were on, so no form is shown, and there is no place to have a cancel button. If the user got to the purge caches page using the admin menu, then the button is shown, but there is no return URL to for the cancel button to send them back to.

Purge caches is added to the admin menu as an admin_externalpage. It does not seem feasible to make the URL depend on the current page.

I will backport and submit for integration in some hours.

Hello Tim,

Can you please try following:

1. Log in as admin/teacher
2. Go to course with wiki
3. Click on files tab and click "Edit wiki files"
4. Check returnurl hidden field
5. Click purge cache from footer and it will purge cache and redirect back to this page.
6. Check returnurl again and you will see the difference.

Point 2: Agree this is optional, moodle_url takes care of this. It will just avoid str_replace.

Point 3: Similar to "Switch role to" we can add returnurl for "Purge cache", so that cancel behaviour can be achieved. Leaving it for you to decide. IMHO, user should be given cancel option to return to where he/she came from.

1. That is a bug in the wiki. It is using referrer as the return URL, rather than passing around returnurl properly. In addition, some servers have a security heruristic where they block URL parameters (not sure about POST paramters) that are full URLs. You should always use a URL relative to wwwroot (output with moodle_url::out_as_local_url), and receive it with PARAM_LOCALURL. Shall I file a wiki bug about this?

2. It is not opitional. You should not use $CFG->admin manually. Read the PHPdoc comment on the Moodle URL constructor, or ask Petr Skoda.

3. I still disagree. I don't see this as any different to any other admin page. None of the others have a back button. (Your web browser does.)

MDL-41044 wiki bug.

Submitting for integration.

Thanks Tim,

Not sure if anyone of these will fail, but just adding grep which I looked at.

tag/coursetags_add.php
38:$returnurl = optional_param('returnurl', null, PARAM_LOCALURL);

backup/backupfilesedit.php
36:$returnurl  = optional_param('returnurl', null, PARAM_LOCALURL);

user/files.php
35:$returnurl = optional_param('returnurl', '', PARAM_LOCALURL);

question/question.php
41:$originalreturnurl = optional_param('returnurl', 0, PARAM_LOCALURL);

question/addquestion.php
35:$returnurl = optional_param('returnurl', 0, PARAM_LOCALURL);

blocks/rss_client/viewfeed.php
34:$returnurl = optional_param('returnurl', '', PARAM_LOCALURL);

blocks/rss_client/managefeeds.php
31:$returnurl = optional_param('returnurl', '', PARAM_LOCALURL);

blocks/rss_client/editfeed.php
149:$returnurl = optional_param('returnurl', '', PARAM_LOCALURL);

grade/grading/manage.php
39:$returnurl  = optional_param('returnurl', null, PARAM_LOCALURL);

grade/grading/form/rubric/edit.php
47:$returnurl = optional_param('returnurl', $manager->get_management_url(), PARAM_LOCALURL);

grade/grading/form/guide/edit.php
49:$returnurl = optional_param('returnurl', $manager->get_management_url(), PARAM_LOCALURL);

mod/quiz/addrandom.php
38:$returnurl = optional_param('returnurl', '', PARAM_LOCALURL);

mod/wiki/filesedit.php
34:$returnurl = optional_param('returnurl', '', PARAM_LOCALURL);

course/switchrole.php
37:$returnurl  = optional_param('returnurl', '', PARAM_RAW);

comment/comment_post.php
41:$returnurl = optional_param('returnurl', '/', PARAM_LOCALURL);

As explained above. These will not fail.

Yay! thanks for fixing this Tim - has been bugging me for so long!

Thanks Tim - passing this now

Cảm ơn!

Your changes have now been merged upstream in git and will be available on the Moodle download sites shortly!

Một hai ba, yo