Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
After moving a OA site to octopus box, path to uploaded files changed from http://oa.domain.org/sites/default/files/filename.pdf" to "http://oa.domain.org/groupname/%252Fsites/oa.domain.org/files/filename.pdf" and it gives 404 as a result.
Currently in /admin/settings/file-system i have: "sites/oa.domain.org/files"
I tried changing file-system path to "files" or "/sites/oa.domain.org/files" and it says directory not existing.
thanx for help.
Comments
Comment #1
omega8cc CreditAttribution: omega8cc commentedDid you follow the 8-steps import how-to? See: https://gist.github.com/960279
This should rename the paths correctly in the files table. You shouldn't attempt to modify paths hardcoded by Aegir in the settings.php
Comment #2
szczym CreditAttribution: szczym commentedi changed variable in database, it not works. originally i migrated site to default OA platform to take advantage of additional stuff, like boost and ect.
i have boost and cache enabled, stable 8.2 and fresh octopus install.
next problem is that on those wired files paths is not working search404.
Comment #3
omega8cc CreditAttribution: omega8cc commentedYou need to check the paths in the
files
table, not in the variables. You shouldn't also change any variables to fix this.Comment #4
szczym CreditAttribution: szczym commentedwhen i edit path of file in files table, attachment is gone from node display and new files still getting wired path with %252F prefix
Comment #5
memtkmcc CreditAttribution: memtkmcc commentedHmm, the %252F prefix looks familiar, see: http://drupal.org/node/1146238
This looks like a weird bug caused by encoded forward slash added in the path, but we have seen this only in the path created for d5 login link, so far.
This issue belongs either to Hostmaster or Provision, as it doesn't look specific to Barracuda/Octopus install, so I'm moving it there.
Comment #6
szczym CreditAttribution: szczym commentedI just did _empty_ openatrum-beta10 site on octopus platform 8.2, problem still occurs. Same new site in static folder with openatrum-beta10 and problem is gone. I did not head the problem with any previews versions of octopus.
Comment #7
omega8cc CreditAttribution: omega8cc commentedPlease upgrade to Octopus 1.0-boa-T-8.5 or HEAD, as it was probably related to the known Pressflow core bug.
Comment #8
szczym CreditAttribution: szczym commentedI just upgraded the instance to newest stable Octopus 8.5, problem still occurs with new and existing OA sites made on Octopus platform (pressflow based).
Problem is gone when i migrate site to vanila OA (no pressflow) in ~/static.
Im moving bug report back to Octopus project, as it is the provider of pressflow (please correct me if im wrong).
Thank you for help Omega8.cc
Comment #9
omega8cc CreditAttribution: omega8cc commentedPlease submit a bug in the Pressflow queue, as it is not an Octopus bug: https://bugs.launchpad.net/pressflow
Comment #10
szczym CreditAttribution: szczym commented@omega8cc: could you please check, can you reproduce the bug on your systems ?
Comment #11
szczym CreditAttribution: szczym commentedNew summary:
After moving a OA site to octopus box (pressflow based stack from omega8.cc), path to uploaded files changed from http://oa.domain.org/sites/default/files/filename.pdf" to "http://oa.domain.org/groupname/%252Fsites/oa.domain.org/files/filename.pdf" and it gives 404 as a result. I could reproduce bug while making new, vanilla site.
Currently in /admin/settings/file-system i have: "sites/oa.domain.org/files"
I tried changing file-system path to "files" or "/sites/oa.domain.org/files" and it says directory not existing.
Bug is gone when i migrate to "orginal" drupal codebase.
I reported it pressflow issue queue: https://bugs.launchpad.net/pressflow/+bug/781962
Comment #12
omega8cc CreditAttribution: omega8cc commentedI can't reproduce it, it just works on fresh install (Octopus head), see http://oa.o4.linode.us.host8.biz/abc/node/2
So I don't think it is a Pressflow issue.. maybe something in your import?
How are you adding the files (where) in the OA?
Comment #13
omega8cc CreditAttribution: omega8cc commentedOops.. I checked only the path, and it looks correct, but the link doesn't work:
http://oa.o4.linode.us.host8.biz/abc/sites/oa.o4.linode.us.host8.biz/fil...
This is because the correct URL to the file is:
http://oa.o4.linode.us.host8.biz/sites/oa.o4.linode.us.host8.biz/files/d...
I'm not sure what causes it.
Could you post some links from your tests on Pressflow and vanilla Drupal OA installs, so we can test it?
Comment #14
omega8cc CreditAttribution: omega8cc commentedThis commit fixes the issue for me: http://drupalcode.org/project/octopus.git/commit/b954f03
If you have still encoded forward slash, then something is wrong in your install/import probably.
Comment #15
linuxgeneral CreditAttribution: linuxgeneral commentedI am having a similar problem in Drupal Commons.
After the upgrade to version 1.0-boa-T-8.5. I still get an incorrect pathname for uploaded documents.
http://sites/domain.com/files/file.name
instead of:
http://domain.com/files/file.name
Comment #16
omega8cc CreditAttribution: omega8cc commented@linuxgeneral
In the multisite world you will never get URLs like http://domain.com/files/file.name, it will be always http://domain.com/sites/domain.com/files/file.name, and the short URLs will work only thanks to rewrite in Nginx, but I'm not sure it is the same issue here.
There was a bug in Pressflow core a few weeks ago, and we helped to fix it in the Pressflow head.
Check in your page source if you have double slash in the path like
"//sites/domain.name/files/file.name"
. If yes, then you should upgrade Barracuda and it will fix it for you on the next day automagically, or if you can't wait, run manuallybash /var/xdrago/usage.sh
to get it fixed for all platforms with sites created.Comment #17
linuxgeneral CreditAttribution: linuxgeneral commented@omega8cc
I understand that the short URL is a result of a recent rewrite rules and also not sure if this is part off the issue.
Checked the page source and the page sources shows the "double slash" exactly as you described above.
Upgraded Barracuda to HEAD and ran /var/xdrago/usage.sh tested this several times and the problem persists.
To reproduce this simply:
1. Add a Drupal Commons site
2. Add a new document with a freshly uploaded file
3. Observe incorrect the document file path that begins with http://sites/
Thanks for all you do on this project
Comment #18
memtkmcc CreditAttribution: memtkmcc commentedThe bug has been confirmed also by @mysty - https://github.com/omega8cc/nginx-for-drupal/issues/269
Comment #19
mysty CreditAttribution: mysty commentedYes, just to confirm this is not limited to Open Atrium, as I experienced it with Drupal Commons and stock Drupal 6.20.
So I changed the title - hope that's OK.
This was when using filefield. Will need to test if this repeats with plain Upload module, and report back.
Comment #20
AntiNSA CreditAttribution: AntiNSA commentedI used to have this problem.... but I found only after migrating twice and reverifying did the bug automagically dissappear. It used to be a very big headache. The key was ingrate and verify twice. I have only used drupal 6.
Comment #21
omega8cc CreditAttribution: omega8cc commentedThis is due to confirmed bug in the Pressflow core, reported already by many people in the Pressflow issue queue.
To fix this on your server please apply this patch http://drupalcode.org/project/octopus.git/patch/0b5c78895154cb903ba010fa... to the
/var/xdrago/usage.sh
file and then run it as rootbash /var/xdrago/usage.sh
(it may take a few minutes depending on the number of sites you have on your Octopus instance).This fix will work only for sites hosted on all Octopus instances.
To fix the issue on your other Pressflow based platforms hosted on your Master Aegir Instance created by Barracuda, you need to apply patches manually to the Pressflow core:
https://github.com/pressflow/6/commit/629464b871aa66aaa2eaaf6d7da64f155c...
https://github.com/pressflow/6/commit/e8e49429bd604edad672b15dda53f7afdb...