I recently updated moodle from 1.9.4 to 1.9.11. After the update completed and I restored the uploaddata a lot of images are missing. All images worked fine before the update.
Images do not display that are linked like this this:
http://www.mysite.org/file.php?file=/49/myimage.jpg
However, images work properly that are marked like this: 
Hopefully there is an easy solution. Any ideas?
Thanks,
Sorry that first post didn't display the links properly. Here is the problem I was trying to describe:
I recently updated moodle from 1.9.4 to 1.9.11. After the update completed and I restored the uploaddata a lot of images are missing. All images worked fine before the update.
Images do not display that are coded like this this:
siteurl/file.php/49/myimage.jpg
Some images display properly that are coded like this:
file.php?file=/49/myimage.jpg
Any ideas?
Thanks,
Me too, this is a crisis! I have upgraded 3 times previously without any issue. Now my site won't display images and I cannot add any images or redo links to images.
I rebuilt the server (serves the standard apache page) and installed an empty 1.9.11 and that has the same problem. When I edit and use the add image button the dialogue box pops up and lets me upload an image but when I select it the image doesn't appear in the dialogue box and doesn't show when I close the dialogue box.
I could really do with some advice here. My school has exams soon and students cannot access anything. Word documents also download corrupted as well. PDFs seem fine.
Hi Tom,
I don't know if the solution could be defined as "easy" , but here it goes.
First of all, the difference between the link formats is due to the Use slash arguments directive found on the HTTP page: Site administration > Server > HTTP. On Moodle 1.9.11 this setting is enabled by default (if I remember correctly, in Moodle versions before 1.9.7 it was turned off by default).
The first URL you mentioned follows the slash arguments format, the second one doesn't.
My first sugestion would be to go and disable the Use slash arguments directive and see if that fixes everything. If so, I would then reenable it and see everything is still working OK. The idea behind these two steps is to update all references inside the DB.
If the previous steps didn't work, then you'll need to:
Everything (images, course files) should be working fine after doing these steps.
(*) For the DB backup, via PhpMyAdmin:
The SQL backup file will be saved into your computer, ready to be edited.
Hope this helps.
Wow, is this really the only way to fix this? That is way more than I feel like taking on. Does anyone have any other solution?
Hahaha!! I definetely agree with you!
Well, is your problem actually the same (as described in the first post)? That is, a "file.php/49/myimage.jpg" vs. a "file.php?file=/49/myimage.jpg" issue?
If not, the solution might be easier
Could you describe your problem?
Cheers!
All of the images on my site were embedded like this:
<img src="http://MYSITEURL/file.php/1/IMAGE_NAME.png" alt="text" title="text" border="0" hspace="0" vspace="0" width="25" height="25" />
using the image button in the WYSIWYG editor. When I upgraded the site all of them show a broken image link like in the original post.
Have you tried going to Site administration > Server > HTTP and changing the "Use slash arguments" parameter to see if that fixes it?
http://docs.moodle.org/19/en/HTTP
If you change the aforementioned parameter, do link addresses appear differently?
Unfortunately, nothing changes when I do that. The image files still do not display.
On resources/labels, etc. where the images are missing, get into edit mode of that resource/label, click the broken image box to select it, then click the 'insert image' icon in the editor tool bar.
Take note of the actual file name of the image in the URL line, then go select the same image. Image, if located, should re-appear.
If you edit again, note the URL line - it will show the 'method' Moodle is using to link to image by the full URL (Moodle inserts the full URL to the image).
One could use relative addressing (an apache 'shortcut'), however, to see if the image displays. Say the image resides in a folder called 'images' and it's name is 'school_logo.gif'.
One should be able to use ./images/school_logo.gif on the URL line.
'restored the uploaddata' sounds like site is remotely hosted and the data folder was re-uploaded from a backup of some sort. Was the backup of the site used to restore the 'uploaddata' folder one that was created just previous to upgrading?
'spirit of sharing'
When I do that the link given is ../1/image.png
If I change the ".." to the URL of my site the image still does not show up.
I have never re-uploaded/restored anything on the site and the moodledata folder has always remained untouched.
On another site I admin I've seen users have success by replacing the .. with a URL and then the image appears again.
More strange info:
I have one course which is a duplicate of the other. In one of the courses, the images show, in the other it does not.
Both image embeds are identical except for the course number.
I have cleared the cookies in my browsers and viewed in multiple browsers.
Any luck on a resolution to this? I have the same problem and have so far not gotten anywhere. I did fix the broken links using the url/admin/replace.php script instead of doing the manual database method mentioned earlier in this post, but still getting the red x's. I have checked the directory in moodledata and the files are still there like they were when it worked prior to upgrading to 2.11+
I'm about to dig into the file.php source to see if I can figure out what in the heck it's doing.
Robert,
Your situation is a little different than the thread in that you've taken a 1.9.x to a 2.1.1 ... is that right? Was the migration to 2.1.1 done in place?
Take a peak at what URL is in there. Edit item, click on broken image to select it, click on the 'insert image' button in toolbar of editor. Note the URL (while your at it, the filename). URL have any 'strangeness' to it?
Oh, yeah ... the file system of 2 is completely different from 1.9. Even if the 'legacy' course ID folders are in the moodledata directory, in a migrated 2 (even with legacy turned on) the 'files' **that count** will NOT reside in the moodledata/courseidfolder/ They've been hashed and brought into the new filing system. Note the name of one of the missing image files. Then, in whatever you use for browsing the database for the Moodle, go to the mdl_files table and browse the whole table. Have an image on the front page of a Moodle that's an Alien .gif. Here's the reference in mdl_files: 3 783adb04a7da39ed7e4db1a0c4e6debda24635f5 4fb448a0985478c364aa288a43418cb8dcd7d000 2 course legacy 0 /fx/ alien_eyes_md_wht.gif 8545 image/gif In the moodledata folder there is a 'filedir' folder now. Inside that, I can actually find the image file, but it's no longer named the same in the file system itself. [root@moodle filedir]# ls 78 00 0f 30 3c 41 53 6b b2 bd d0 de e3 e9 f4 fd 05 16 3a 40 4b 69 aa b9 c9 d8 e1 e8 ec fa ff [root@moodle filedir]# ls 78/3a/ 783adb04a7da39ed7e4db1a0c4e6debda24635f5 [root@moodle filedir]# ls -l 78/3a/783adb04a7da39ed7e4db1a0c4e6debda24635f5 -rw-rw-rw- 1 apache apache 8545 Apr 28 20:57 78/3a/783adb04a7da39ed7e4db1a0c4e6debda24635f5 Note the byte size of the file (as it is named in 2): 783adb04a7da39ed7e4db1a0c4e6debda24635f5 is the same as the reference to size in the DB. It is the old alien_eyes_md_wht.gif Welcome to the new Moodle 2! 'spirit of sharing', Ken
Oddly enough, I repeated the whole process (with a couple added steps below) and now it's working fine.
What I did differently was to remove LAMS, HOTPOT, and LOANCALC from the 1.9.13 moodle site, delete their respective directories, and then did a mysqldump of that. Then, when migrating to the new server with the moodle 2.11 code, the module upgrade page had less red in it After that point, I still had the blank placeholders for images, but all I had to do to fix was use the /admin/replace.php script to fix the urls. In our old Moodle server, it was www.site.com/moodle18/...... for whatever reason. When I made the new server I created a virtual host with /var/www/moodle as the site root instead so the url was cleaner www.site.com. I knew this would be an issue, so I created a symbolic link inside the site root called moodle18 that pointed to the site root, essentially mimicking the old install. That way any old links or people's old bookmarks would work properly. Apache as you probably know can follow symbolic links, but apparently the way file.php handles slasharguments, or perhaps the way apache handles them, does not. So I had to us the replace script to replace the /moodle18/ with just /.
So there you have it. Not sure if anybody ever ran into this problem with symbolic links breaking their moodle 2.0 file.php functionality but hope this can help somebody in the future. Thanks Ken for the reality check.
And, why does your name sound so familiar?
Thanks for posting back your solution. Since many are contemplating making the move from 1.9 to 2.x it will help in preparation, etc..
'Familiar' ... could be because I have visited your place of employment and migrated the 1.6 Moodle to 1.8/9 a few years ago! ;)
'spirit of sharing', Ken
So we've been testing and none of the SCORM packages we had uploaded seem to be there. I ran a db query in mdl_files and the only things im showing in the particular course id are two image files which are working. Seems the scorm content just got chucked.
I tried re-uploading and I'm getting a DB write error.
Debugging now...
Ahh yes. I talked to Jeanie Cole and mentioned your name and she said the same. I think I'd seen your name in an email a couple years ago.
Small world.
So, I've been debugging the fact that scorm packages from the 1.9.13 moodle are gone. What I've found seems to be a database schema error.
mdl_courses_modules has a field 'delay' which is not nullable, has no default value, and none of the imported database has this field set. This obviously is a problem. I would consider making the field nullable, and then update all the current values to be null since they technically are (having no value set), but I'm going to take a look at a fresh 2.0 install's schema to see what it looks like. I'm assuming this is an oversight in the upgrade script.
UPDATE: a fresh install has NO delay column in the mdl_course_modules table, so I am going to drop this column in my migrated db.
SECOND UPDATE: Dropped column in db, am now able to upload SCORM packages! I am now going to try the following:
~robert
ok, this will sound noobish, but I have no clue what to do with that file that you linked to... ?
I examined the schema between my upgraded db and a fresh one and the differences are HUGE. I ran schemasync and moodle completely crashed.
It seems like moodle development doesn't really have their game straight for an upgrade, which seems to me makes the process completely pointless at this time. If it's just the scorm packages, I can reupload them and that's not going to be a big deal, but I'm sure I'm going to find other stuff too.
Under the legacy file browser too I see nearly all the files except the moddata and backupdata folders. The old 1.9.13 install used an external link to go to the scorm packages which was uploaded into the files folder. The new moodle, you upload the scorm package directly. It seems to work when I upload the package direct, but it also seems to have dumped all the old moddata and backupdata, thus the link will never work again.
~R
Not at all noobish! Tracker is supposed to be a place where one can get information concerning fixes (status/etc) for problems.
To be honest, I did quite a bit of experimentation with migration to 2.x. Findings (back then):
* work with a copy of current site
* upgrade the 1.9 to highest version
* remove add-ons that don't have a version 2 yet.
* a migration 'in place' actually created more work with 'legacy' on the fly
* new file system and repository will take some getting used to ;)
* migration 'in place' may NOT be the best option when moving to 2 depending upon what were the primary tools used in 1.9.x. (think you've found one of them - SCORM).
Unforunately, in 1.9.x, backing up a course that has SCORM in it, doesn't quite get the job done - still an issue with backups and SCORM with 1.9.x (discovered that when moving a course that was SCORM based to another server with an instance of 1.9.x).
We probably need to change the subject line of this to another focus! ;)
'spirit of sharing', Ken
