Best practice forum (Archived)
تمت إزالة منتدى المناقشة هذا
Hi Liz,
The block installs fine for me?
Cron will never run if there is a block or other plugin waiting to be installed, so that behaviour is normal. Delete the blocks/progress folder first, run cron, then put the folder back and try to install the block again.
Maybe you could turn on debugging Site Administration -> Development -> Debugging and change "Debug messages" to "DEVELOPER" and check the "Display debug messages" box, then try to install the block again and see if you get any error messages which might offer a clue. Remember to change them back afterwards if this is a production site!
We normally don't support problems with third-party plugins though.
Hi Liz,
According to this moodle forum post the usual explanation for plugins refusing to install is incorrect file permissions. The plugin directories (usually /local/xxx) need to be readable by the server's webserver user (usually www-data on Ubuntu, or the IUSR_xxx account on Windows) and may also need Execute privileges.
https://moodle.org/mod/forum/discuss.php?d=187593
Hope that helps,
Ciaran
I've never seen this before so have no real ideas.
You might need a server administrator to check the file permissions and also look in the web server and database log files to see if there are any error messages being logged. Try to uninstall the plugins you have tried to add already (Site Administration -> Plugins -> Plugins overview) and delete their code from the /local/ folder, in case one of these is causing the problem.
Also to clarify are you getting the "cron won't run" message on the install/upgrade screen before it stalls; or did you mean that you can't get cron to run after trying to install the plugins?
A screenshot of the stalled upgrade screen would also be useful.
Hmmm. I think at that point in the code it is either trying to update the timezone information, or rebuilding the Cache....could you check the server has access to the internet to get the latest timezone info; and check the permissions on the {$CFG->dataroot}/cache directory (needs to be writeable by the webserver user)?
Yeah I think this is some kind of a timeout error as we've just received a similar report from another client.
Something somewhere must have changed in 2.5.3 to remove the normal overrides that allow long-running processes to complete.
Let me investigate further.
Hey Liz,
If you add these lines to your config.php temporarily, it might force debugging messages on.
$CFG->debug = 32767;
$CFG->debugdisplay = 1;
I'm still none the wiser but it does seem to be narrowing down to something somewhere forcing a fatal timeout error.