Migrate filemanager/attachment nodes to 5.x core tables
davea - April 5, 2007 - 13:25
| Project: | Attachment |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Jump to:
Description
This patch moves attachments from attachment tables used in 4.7 to core tables used in 5.x . I left the code in place to delete the old records and tables but they are commented out. This was tested on 5.1 core base with the most recent version of the attachment module and filemanager modules.
Thanks
| Attachment | Size |
|---|---|
| attachment_5.patch | 2.66 KB |
#1
i guess this patch should have been attached to: http://drupal.org/node/123560 but since there's a patch here i'll mark that as a duplicate. it looks good to me but i'd like to have some people test it before i commit it.
#2
Hey, this is great; thanks, nomad! Hope to try this soon enough.
#3
Closing this out because it's no longer necessary after filemanager and attachment were updated for 5.x
#4
I reopened this issue. I'm upgrading my site to 6.x, and since there are currently no 6.x options for Attachment/Filemanager module users, migrating the attachment info/files to the core tables seems like the easiest and safest course of action.
I hope to take a look a the original "attachment.module 4.7 -> core 5.x" migration patch submited here, and see if the same code can work for "attachment.module 5.x -> core 5.x".
#5
Alright, So I've just migrated my filemanager/attachment info to core tables and here's my report.
I was able to manually apply the supplied patch to the 5.x attachment.install file; the patch was originally written for the 4.7.x version but apparently works just as fine in 5.x (don't know if you can apply the patch automatically, though... I always do it manually because that's the only way I know how to in a Windows environment).
I did a test run running update.php, and came across a problem! Everything else seemed fine, but the paths to the ported files were wrong: like "private/active/0/filename.ext" instead of "files/active/0/filename.ext".
I looked at the code and the culprit was this:
+ // ... and build a filepath+ $oldfile->path = variable_get('filemanager_private_path', 'files') .'/active/'. $node->directory .'/'. $oldfile->filename;
My filemanager_private_path was set to "private" on my website. I changed the "filemanager_private_path" in this particular line of code to "filemanager_public_path", which was set to "files". This seemed to do the trick, my second test run seemed to work perfectly, yay!
I have no private files on my website, so using the public_path was not a problem. I presume the author of the patch only had private files on his website, hence his use of the private_path. I don't remember now if filemanager/attachment allowed you to have both private and public files, but if it does, and if you have both public and private files, beware; make sure you know what you're doing before trying this patch out.