I upgraded to 3.2 and now the plugin installer is missing. Under site administration > Plugins > there is no "install plugins" anymore. Was it deleted in 3.2? I'm using boost as a theme.
No, it was not deleted from 3.2. It is still there in the same place.
Check if there is an issue with the theme by switching from Boost to Clean. This would tell you if the issue is with Boost.
While logged in, in the address bar enter [yourmoodledomainaddress]/admin/tool/installaddon/index.php to bring up the plugin installer directly and see if it loads. If it does, then the code is there, the issue is is with the interface.
Those are most likely things to look at.
(There is a config.php setting that hides and disables the installer: $CFG->disableupdateautodeploy. It's very unlikely that is the issue if it was working before, but you could do a sanity check to make sure.)
Hi Randy,
The config.php does not include this particular line.
If I try to load the installer directly in boost and clean, I receive a section error.
How could I solve this and why was this occuring?
The config.php does not include this particular line.
If I try to load the installer directly in boost and clean, I receive a section error.
How could I solve this and why was this occuring?
When you turn on full developer level debugging, what is the whole trace of the error message?
That should lead you - hopefully - to find out where the root of the issue is.
A section error is something I have only seen a couple times and usually with the admin menus when it can't properly find a section of the configuration usually due to bugs or something went wrong in the upgrade. It thinks the page is not there. The full debug may help tell more.
Are there any issues or messages in Notifications or the Plugins overview page with anything not fully installed?
The way admin menus are presented was changed from 3.1 to 3.2 to deal with Boost. I suspect something amiss there.
Hi Randy,
the following errors are listed:
Debug info:
Error code: sectionerror
Error code: sectionerror
- line 496 of /lib/setuplib.php: moodle_exception thrown
- line 7599 of /lib/adminlib.php: call to print_error()
- line 29 of /admin/tool/installaddon/index.php: call to admin_externalpage_setup()
I did the upgrade via moodle from 2.7 (fresh install) to 3.2?
There isn't any repair function, is it?
Well, the error here is calling the admin_externalpage_setup('tool_installaddon_index') so it seems to be acting like the installer never got installed and so the menu does not know about how to add it to the menu.
(Some admin menu items call external page files, like the installaddon, instead of being internal functions.)
When you go to Site admin > Plugins > Plugin over, do you see that the plugin called "Plugin installer" is in the list and have a version number of 2016120500 like the other admin tools in 3.2?
Hey Randy,
yes, it's there under plugins > service plugins with the correct number and marked as installed.
You might double check permissions on your new install and if that doesn't help, maybe redownload the moodle code and go back through the upgrade process. Your site will not actually go through the upgrade but might resolve the issue. Sounds like either permissions are blocking you from the page or something was corrupted in the code during download.
That is a direct link to an index.php page contained in moodlecode/admin/tool/installaddon/
The link should be in the menu so that's strange, but ...
try this: after logging on, use your browser URL line and attempt to go directly to it:
http://yoursite/admin/tool/installaddon/
You don't need the index.php file in the URL as your server should be serving up index.php files if navigating to a directory by default.
Does that call up the form?
'spirit of sharing', Ken
Thank you all!
@Emma: I will try your advise.
@Ken: This happens when I use the link to go there directly:
Debug info:
Error code: sectionerror
Error code: sectionerror
- line 496 of /lib/setuplib.php: moodle_exception thrown
- line 7599 of /lib/adminlib.php: call to print_error()
- line 29 of /admin/tool/installaddon/index.php: call to admin_externalpage_setup()
I know that's what happens when you attempt to click the link in the Admin menu. What I was trying to get you to do is go directly there using the URL line in your browser to see if there was an error in accessing that way.
See attached pic if am not explaining very well.
If you click the link, then moodle produces the error, right? This line throws the error:
line 496 of /lib/setuplib.php: moodle_exception thrown
That line in /lib/setuplib.php is this function:
function print_error($errorcode, $module = 'error', $link = '', $a = null, $debuginfo = null) {
throw new moodle_exception($errorcode, $module, $link, $a, $debuginfo);
The next error reported, I think is the issue .... from /lib/adminlib.php (7599) comes from this function
if (empty($extpage) or !($extpage instanceof admin_externalpage)) {
** // The requested section isn't in the admin tree
** // It could be because the user has inadequate capapbilities or because the section doesn't exist
if (!has_capability('moodle/site:config', context_system::instance())) {
** // The requested section could depend on a different capability
** // but most likely the user has inadequate capabilities
print_error('accessdenied', 'admin');
} else {
print_error('sectionerror', 'admin', "$CFG->wwwroot/$CFG->admin/");
}
See ** lines above?
Check that the account you are using is indeed amoung those that can do it all ... superuser/admin level. Can't get there either? Use another account that is admin level.
So go to: http://yoursite//admin/roles/admins.php
and see if the account you are using is listed in the box on the left.
If it is, then one might need to check into moodle/site:config capability config on your site.
If this was a bug in code, there would be many many reporting the same issue. That hasn't been the case. This has to do with your particular install/config.
which leads the next question ... how was it upgraded and from what version? Please don't say 'I followed directions' as am sure you did ... but what directions where? ;) Seems like lots of folks have issues with 'one click upgrades' provided by provider OR doing it FTP etc.
Also note: this is the first version of Moodle that has tours. The theme you are using ... boost ... does have a tour that automagically begins/starts. Did you see a tour? Did you turn off the tour for that theme?
'spirit of sharing, Ken
Daniel,
I ask because I had a similar issue in an upgrade recently from 2.7 to 3.1 The installer page loaded but I couldn't install anything on it. It was in the Plugins overview and I found the code was up to date, but the configuration was not updated properly.
I fixed this by:
1) Uninstalling the Plugins Installer from the Plugins > Admin tools > Manage admin tools page. Click Continue to confirm removing it from the database.
2) After it removes it from the database, do NOT remove the plugin folder from the server when prompted to: click Cancel instead. This leaves the code in place on the server.
3) The very next page after you hit Cancel will be the 'Plugins check' page and it will offer to reinstall that plugin. Click 'Upgrade Moodle database now' button. This will reconfigure all the plugin settings with defaults, including where it lives in the admin menus.
That fixed my issue on that particular site. Since I knew the code was up to date (and I knew the permissions were correct, as Emma noted), that was all that was needed, just to force the settings to update. After that, it worked normally again.
Randy
Hi Randy,
unfortunately the reinstallation of the plugin didn't work. It's still not visible in the menus (only in the overview of installed plugins without further functions).
Hi Ken,
I did that with URL since I can't provoke the debug message anywhere else because there is no installer or anything to switch on.
I'm on a hosted Plesk Server without much knowledge about unix and no ssh access. I can execute some commands and php-scripts via something like a command line there.
We had to move our installation from another server 8 weeks ago. The moodle version there was 2.6.2. For the server, I don't know details anmyore.
I did the following:
- downloaded the moodledata via WINSCP in standard mode (which should normally be binary) to my Windows-PC as a zip.
- Then downloaded the database via mysql as zip.
- Downloaded moodle 3.2 which I could not install because I should install 2.7 before.
- I installed the 2.8.x stable release.
- I had to adjust the database to barracuda which I had to do via moodle.
- Then I upgraded to 3.2 via the system message.
- Everything seemed fine until I noticed that all teh docx, xls, jpgs and pdfs were corrupt. I did your hint with filegz (windows) after analyzing via the database the certain files in filedir. Some worked, some didn't.
- Right now, I'm the primary admin.
Where are you hosted? What hosting package? ... by the latter I mean what are the specs as well as limitations ... none really provide 'unlimited' even though some 'advertise' as such (read the fine print).
So from your response to me, it has been a migration and an upgrade.
On your first step ... moving from one server to another ... did you simple transfer what you had from old server to new server and get that running first? (with no errors) That, I think, is the first step in a migration (moving to another server). You then upgrade a known working site in place - in your case 2.6 to 2.7 (not hyperjumping to 2.8). Before doing that, however, one should make a full site backup ... code, db dump, and data directory. That becomes a fall back point should the next step fail.
From what you've described sounds like we tried a mirgration and upgrade in one swoop and as you have discovered, that usually leads to errors.
You did take some steps ... 2.6 -> 2.8 but only after discovering you couldn't take 2.6 to 3.2 without intermediate steps. Did you stop at 2.8 and check it all out? This issue with not having the ability to install plugins and now you mention differences in data from what's really in moodledata/filedir/ could have shown their ughly heads back then and marching forward ... hyperjumping ... hasn't fixed it ... may have even made things worse.
Do you still have the original backups of the 2.6? Has the site at the new server been used by Teachers/Students since it was moved and upgrades attempted? IF so, then think you're stuck at fixing rather than attempting in re-do of migration and upgrade.
How large are the backup files for the 2.6 ... code, DB dump, and data diretory for that version?
I might be able to make an offer if I've room on a tinker server ... fully functioning with NO errors running multiple versions of Moodle.
'spirit of sharing', Ken
Ran out of time ... tinkering ... so this addition ... Emma might be correct about ownerships/permisions. On new site ... does owner, group, others have at least *read* rights recursively to all code directories ... sub directories/files? especially in /code/admin/tool/installaddon/
'spirit of sharing', Ken
Thank you so much for these hints. In respect with the server, unfortunately I'm not allowed to use moodle outside the legal restrictions of Germany.
From the old server, I did not download the moodlecode directory - only the 2.6.2 moodledata directory and moodledb as a zipped sql. I don't have access to the old server anymore. My predecessor also only had backups of the moodledata.
I put the moodledata directory on the new server und tried to install the 3.2 code which didn't work without installing first 2.7. And I have chosen to install 2.8 as a stable release with our old database which brought a lot of warnings. Then I upgraded to 3.2.
I tried now to reinstall moodle 3.2 (and copy the config) but still the installer isn't there...
I found some other warnings during the installation.
From the old server, I did not download the moodlecode directory - only the 2.6.2 moodledata directory and moodledb as a zipped sql. I don't have access to the old server anymore. My predecessor also only had backups of the moodledata.
I put the moodledata directory on the new server und tried to install the 3.2 code which didn't work without installing first 2.7. And I have chosen to install 2.8 as a stable release with our old database which brought a lot of warnings. Then I upgraded to 3.2.
I tried now to reinstall moodle 3.2 (and copy the config) but still the installer isn't there...
I found some other warnings during the installation.
So basically all those items are either missing or in a different location on the new server. You need to start by resolving that...
I'll repeat ...
migrate the site first ... code, db, and datadirectory to new location and get that working first.
Why? IF the 2.6 site had custom plugins built, they may not work on the new server. IF the site had addons from 3rd party or even Moodle plugins site then you could research if those plugins were still compatible with the desired destination version ... that of 3.2.
If can't get the code directory, then best you can do is get the last release of 2.6.
https://github.com/moodle/moodle/archive/MOODLE_26_STABLE.zip
Using that code base might have problems ... missing any addons/customizations, etc.
But if can't solve that ... attempting any hyperjump will surely have things just lurking.
There was quite a lot of changes to themes from 2.6 to 2.7 ... other major re-works or changes inbetween as well.
I can see by the error screens shared that the paths will have to be changed to current system ... was Linux ... and you are using what now? Open_base path restriction ...
'spirit of sharing', Ken
Thank you both so much!
I'll try your suggestions which might take some time.
Didn't know that I also have to use the old version before installing a new one. Thought that I simply could do a new install just with a readjustment of the links to the data-directory organized through the database. I was asked if I would do the admin and migrate the system...Normally I'm just a user.
Now, I tried the following:
Therefore I guess, our old moodle installation was 2.6.2xxx. I can't tell.
But in this test installation, I'm getting the following error when I try to open a PDF from an old course:
The file can't be read because it doesn't exist or you don't have the rights.
I'm so sorry but I think the problem of "migrat-updating" might be the right track now.
If I could solve this, I would be able to upgrade to 2.7 or something on my way to 3.2. If the pdf (and the rest of the data) is corrupted because of the ftp transfer, I just want to update to the newest version and start off anew.
- Created a new subdomain for a testmoodle installation to try Ken's advise with the old moodle version 2.6.2
- Looked at s****forge for the 2.6.x releases.
- Downloaded 2.6.2.zip, uploaded it on the server and unzipped there.
- Built a new db, imported the old.sql
- Put the moodledata in root
- Tried the installation via browser
- Received the error: your code is older than the one which created the db
- Couldn't do anything in the new installation.
- Deleted the moodle directory on the server
- Downloaded 2.6.3 and installed it via browser
- Chose MariaDB because our new server works with that
- There were a lot of plugins which I didn't update because they didn't have a source.
- I received the message "the installed moodle data have been altered. Your moodle will be automatically updated to 2.6.3"
- In this code here, the installer is visible under websiteadministration.
Therefore I guess, our old moodle installation was 2.6.2xxx. I can't tell.
But in this test installation, I'm getting the following error when I try to open a PDF from an old course:
The file can't be read because it doesn't exist or you don't have the rights.
Debug info: [dataroot]/filedir/5f/b8/5fb8009081cf9e6b58fcd47c6aa595af188bbb1e
Error code: storedfilecannotread
Error code: storedfilecannotread
Stack trace:
Is this because of our new URL which is different to the old one? How can I find the old URL in the DB (I don't know it because the whole moodle migration task just fell in my lap)? My testurl is a new subdomain and the moodledomain in use is a also new one because SSL shall be implemented for our whole domain later.- line 447 of /lib/filestorage/stored_file.php: file_exception thrown
- line 2124 of /lib/filelib.php: call to stored_file->readfile()
- line 2472 of /lib/filelib.php: call to readfile_accel()
- line 435 of /mod/resource/lib.php: call to send_stored_file()
- line 4580 of /lib/filelib.php: call to resource_pluginfile()
- line 37 of /pluginfile.php: call to file_pluginfile()
I'm so sorry but I think the problem of "migrat-updating" might be the right track now.
If I could solve this, I would be able to upgrade to 2.7 or something on my way to 3.2. If the pdf (and the rest of the data) is corrupted because of the ftp transfer, I just want to update to the newest version and start off anew.
Sigh ... well, have to hand it to you ... you are determined ... and learning what doesn't work ... but that's good.
You are at a huge dis-advantage and given a job that requires some in-depth understanding of Moodle (something that really requires years ... not days)
Keep this concept in mind ... DB must match code ... moodledata must match what's in DB.
Work with a copy of the sql dump you have. Keep the original in case
you have to start over.
Hint provided ... MariaDB ... so am gonna guess you have CentOS.
Install nano editor ...
Work with a copy of the sql dump you have. Keep the original in case
you have to start over.
sql dump you have is 'moodle.sql' ... copy that file to another file by a different name:
cp moodle.sql moodletoedit.sql
Using nano (has search and replace) load up the .sql dump you have copied.
nano moodletoedit.sql
Search for: http://oldsite/ Replace with http://newsite/
Save.
Import the edited sql dump into MariaDB.
Using some tool to query/view the DB,
Look in mdl_config table.
In the name column there is one labels 'version'.
It will show a number ***like***: 2014111012 (I no longer have a 2.6 to look at)
That indicates the date the moodle software being used was released.
There is also a label for backup_release ... which will show 2.6
What you really need to find is the exact version that's in the DB.
**That requires the use of git** ... which is presently beyond your understanding
of Moodle code, the relationship to DB and to moodledata directory.
(Not that you couldn't get there, eventually, its just not needed right now)
Go to the true source of Moodle code ... that's not source forge ...
It's the git hub for Moodle ...
link:
https://github.com/moodle/moodle/archive/MOODLE_26_STABLE.zip
That will acquire the highest version of 2.6.
Use that code ... cause it's closest to what you have in the DB but it is
the highest subversion of 2.6. One of the recommendations in upgrading is to
always *update* the version you have to it's highest/most secure version first,
before upgrading to the next in the series ... in this case 2.7.highest
Install that code.
You have to manually create the config.php file for it.
Use config-dost.php as a guide ... copy config-dist.php to config.php
and then fill in values ... just the basics
DB user, DB password, DB, location of data directory, wwwroot URL, etc..
This **will/might result** in an **update** ... NOT an upgrade - to the version 2.6 to the highest/most secure/working version in that series. Now there might be
issues related to addons and plugins ... you have a base 2.6.x code but the database has references to addons/plugins that you don't have in the code directory.
You could find and download the zips for those and manually restore them.
Before doing that, however, I would research IF those addons have a version
for the desired end version ... that of 3.2.highest ... your goal.
IF the plugins/addons don't, some where along the march you will have to remove those
addons/plugins as they might stop an upgrade. No way round that either.
Now the moodledata directory matching should be closer ... but still might
have errors ... hopefully not as many. Can't do anything about that cept
to edit those links (each one) manually.
Am not aware of anyhing one could look at in moodledata that would be a clue as to the version of Moodle ... soooo.
FIX the 2.6 as best you can before upgrading to 2.7.
Before you attempt an upgrade do a full site backup ... code, DB, and data directory ... that becomes a fall back point just in case the next step fails.
'spirit of sharing', Ken
Thank you all so much for your support!
@Ken: I really appreciate all your hints and your time! Never came across that the order is so necessary. It'll take some time but I won't give up 'till I got it running (I also have no other option...)! I'll work through these steps.
Version of the db is: 2013111802.09
According to installation process it's 2.6.2+ (Build: 20140424) now updated to 2.6.11+
Welcome. So I take it that you now have a functioning 2.6.11+ site running, right?
Now the next step ... the hard way is the old way ftp files, copy plugins config.php etc. etc. ... leaves to much room for human error.
The *BEST* way is to use git. Assumes CentOS
skip this part ... go to **HERE** below cause you already have git.
Install git:
yum -y install git
Once it's installed ... whereis git ... will show the path to git ... probably in /usr/bin/git Perfect!
Now the tricky part ... can't update/upgrade a moodle code directory without the hidden .git diretory in the code directory.
So we side load a moodle 2.6.11+ directory using git, then copy the hidden .git directory from the sideload to the active code directory.
Let's say the code is in /var/www/html/
As root user, in /var/www/
issue the following command:
git clone git://git.moodle.org/moodle.git htmlgit
That will create a directory called htmlgit ... it's the one that will have the hidden .git directory in it.
Next cd htmlgit ... issue the following commands in the order shown:
git branch --track MOODLE_26_STABLE origin/MOODLE_26_STABLE
git checkout MOODLE_26_STABLE
to see what git has set:
fgrep '$release' version.php
should show you 2.6.11+
Great ... now the copy
You are still in /var/www/htmlgit
cp -rp .git ../html/.git
that's copy, recursively preserving permissions .git to ../html/.git which is up on level from htmlgit
When it's finished .... cd ../html/
Now check to see git works.
git pull [ENTER].
It shouldn't pull anything of core code ... it's already there and the highest version of that series.
** AFTER ** you have checked out the site ... everything works, ** MAKE A FULL SITE BACKUP **
** HERE **
mkdir /home/backup ... reason for creating location ... home is probably largest partition
from /var/www/ which should be the location of moodledata, issue the following commands
tar -cvf /home/backup/moodledata2611+.tar ./moodledata
tar -cvf /home/backup/moodlecode2611+.tar ./html/ that should get the code.
mysqldump -u [UPSERUSER] -p[password] [MDLDBNAME] > /home/backup/moodledb2611+.sql
Now to upgrade to 2.7 ... the easy way.
Back to using git.
git branch --track MOODLE_27_STABLE origin/MOODLE_27_STABLE
git checkout MOODLE_27_STABLE
git pull
(git will acquire 27 code and replace/add/delete whatever it needs ... but only core ... will NOT touch the addons/plugins)
php admin/cli/upgrade.php --non-interactive
The DB will be updated ... script uses the DB information in config.php of the site.
When that finishes:
fgrep '$release' version.php to see if it now says it's 2.7.highest.
** important **
You've been doing this as root ... all files/diretories that were changed below to root user and root group. Need to change them all for apache user and apache group. ... Uhhhh ... will harden later ... after the march.
while in /var/www/html/
chown apache:apache * -R
Check config.php ...
ls -l config.php ... that file needs to have at least read access by all - that's the last 'r' in the output of the ls -l config.php command.
Now hit site with browser.
Check things out ... get plugin updates.
Everything OK?
**BACKUP** changing the backup file names so they contain 27 version number.
Then we repeat the process ... changing only the numbers for the version we desire.
27 to 28
Here's one bash shell script you could use to either update or upgrade ... depending upon what's commented out. ** EDIT FOR YOUR SYSTEM ** If you don't have shell access .. get it.
put into /var/www/html/ to make the march easier
# 2.7.18 (Build: 20170109)
tar -cvf /home/backup/moodles/moodle2718-code-$(date +%Y%m%d%-H%M%S).tar ../moodle27;
tar -cvf /home/backup/moodles/moodle-data-2718-$(date +%Y%m%d%-H%M%S).tar /var/www/moodle27data;
mysqldump -u root -p[PASSWORD] moodle27 > /home/backup/moodles/moodle2718-db-$(date +%Y%m%d%-H%M%S).sql;
git branch -a
php admin/cli/cron.php;
php admin/cli/maintenance.php --enable;
git pull;
php admin/cli/upgrade.php --non-interactive;
# git branch --track MOODLE_28_STABLE origin/MOODLE_28_STABLE;
# git checkout MOODLE_28_STABLE;
# php admin/cli/upgrade.php non-interactive;
# php admin/cli/cron.php;
php admin/cli/maintenance.php --disable;
chown apache:apache * -R
fgrep '$release' version.php
Can 'march' a moodle up through each version 2.7->2.8->2.9->3.0->3.1->3.2 in one day's time
That includes backups and checking and acquiring updates to plugins via mdeploy via the Moodle UI as admin level user ... but not any config of additional features added in 3.1> of core.
'spirit of sharing', Ken