Legacy Upload Folder
Posted by Ben Miller on 2013-07-12 16:16
Currently there are three different types of media attachments for sermons in SB2:
I've been working on another option that will allow users to select a file from a folder on the server without having to type in the name or URL of the file. This would work very similar to the "upload folder" in SB1, where the user can upload files to the upload folder via FTP and then choose the file from a list on the Edit Sermon admin screen. I've been calling this the "legacy upload folder." The reasons for this are:
I've already added a new "legacy upload folder" setting on the Options page of SB2, and I've got a jQuery/AJAX file picker working on the Edit Sermon screen. (Try out branch "ben-options", rev 145.)
Options
Here is my question: I see a couple of options for attaching files from the "upload folder" to the sermons.
1. Add a new "legacy" attachment type. In addition to the three attachment types listed above, I would add a fourth attachment type, which I've tentatively called "legacy." The filename would be stored in the database. When this attachment is called for, Sermon Browser will look up the "legacy upload folder" setting, look at the filename stored in the database, and put them together to figure out the location of the file, similar to the way that attachments work in SB1. (This is the option I've already coded in the "ben-options" branch.)
2. Instead of creating a new attachment type, we could store these types of attachments as a "URL" type attachment. When the attachment is added to the sermon, we build the direct URL to the file, and then attach it just as if the user had explicitly typed in the URL himself.
Pros and Cons
Pros for the new "legacy" attachment type:
Cons for the new "legacy" attachment type:
Pros for using the "URL" attachment type for files in the legacy upload folder:
Cons for using the "URL" attachment type for files in the legacy upload folder:
Which approach would be best? I would love to read any thought or opinions on the approach we should take.
- Library: The user chooses an item from the WordPress Media Library (or uploads a new file to be added to the Media Library)
- URL: The user enters a URL that points to a media file. The media file might be located anywhere on the web, or it might be a URL pointing to a media file that is stored somewhere on the local server.
- Embed: The user enters embed code from some place like YouTube or Vimeo, or enters a custom WordPress shortcode.
I've been working on another option that will allow users to select a file from a folder on the server without having to type in the name or URL of the file. This would work very similar to the "upload folder" in SB1, where the user can upload files to the upload folder via FTP and then choose the file from a list on the Edit Sermon admin screen. I've been calling this the "legacy upload folder." The reasons for this are:
- Some users might prefer to upload their sermons via FTP, rather than using the uploader in WordPress. This would especially be the case if they are trying to add lots of old sermons.
- For those importing their sermons from a Sermon Browser 1 installation, we will be able to import any sermons that have an attachment from the Upload Folder without having to copy the files to a new place or importing those files into the WordPress media library.
I've already added a new "legacy upload folder" setting on the Options page of SB2, and I've got a jQuery/AJAX file picker working on the Edit Sermon screen. (Try out branch "ben-options", rev 145.)
Options
Here is my question: I see a couple of options for attaching files from the "upload folder" to the sermons.
1. Add a new "legacy" attachment type. In addition to the three attachment types listed above, I would add a fourth attachment type, which I've tentatively called "legacy." The filename would be stored in the database. When this attachment is called for, Sermon Browser will look up the "legacy upload folder" setting, look at the filename stored in the database, and put them together to figure out the location of the file, similar to the way that attachments work in SB1. (This is the option I've already coded in the "ben-options" branch.)
2. Instead of creating a new attachment type, we could store these types of attachments as a "URL" type attachment. When the attachment is added to the sermon, we build the direct URL to the file, and then attach it just as if the user had explicitly typed in the URL himself.
Pros and Cons
Pros for the new "legacy" attachment type:
- It provides more flexibility in the future. If we know that a file is on the local server, we could handle those attachments differently than files that are on a different server.
- If the user wants to rearrange or rename their upload folder, they can move the upload folder somewhere else, change the setting on the Options page, and all of the attachments will continue to work.
Cons for the new "legacy" attachment type:
- If the setting on the Options page is wrong, none of the "legacy" attachments will work (just like SB1)
- As a result, only one upload folder is allowed. (However, unlike SB1, with the code I've written subfolders inside the legacy upload folder ARE allowed and working)
Pros for using the "URL" attachment type for files in the legacy upload folder:
- Simplifies the code. Attached file can be handled the same, whether or not they are on the local server or a remote server.
- Users could use multiple upload folders in different locations. At any time, the user could create a new upload folder somewhere on the server, change the setting on the Options page, and attach new files to new sermons. As long as they don't move the old files, the old attachments will continue to work, whether or not the setting on the Options page is right.
Cons for using the "URL" attachment type for files in the legacy upload folder:
- If the user want to move the attached files to a new location, they need to go to each sermon and manually adjust the URL.
Which approach would be best? I would love to read any thought or opinions on the approach we should take.
Home / Developer API / Tour / Get a Project - Solutions for Bug & Issue Tracking, Collaboration Tools, Subversion Hosting, Git Hosting
Sermon browser 2.0 is powered by Assembla.
5 Comments
By Ben Miller on 2013-07-31 17:04
By Ben Miller on 2013-08-03 04:30
What would the advantages be for this approach?
By Ben Miller on 2013-08-24 03:33
By Ben Miller on 2013-09-09 04:41
So my options are:
1. Forget the media library for files in the sermons upload folder, and make all of these files the "legacy" attachment type.
2. I could check whether or not the sermons legacy upload folder is in the WordPress upload folder or not: if so, add the files to the media library and make them library attachments; if not, make them legacy attachments.
By Ben Miller on 2013-09-10 20:15