New plugin avaiable, dbfile
-
I’ve just released version 1.0 of my first WordPress plugin, dbfiles. It handles uploads/downloads/edits/deletions of files, that is stored in a MySQL database as BLOBs. Read more about it at:
https://dev.kanngard.net/Permalinks/ID_20050719162813.html
I’ve also registered it in the WordPress Plugin DB at https://wp-plugins.net/index.php?id=417– Johan
-
If this stores files/images in the database instead of on the server, why would someone want to do that ?
Does it confer advantages in some way ? Would it be better for some files than others ?I come from the Lotus Domino world. A Domino database consists of everything from the layout of the pages, to “records” of data and files (as attachments). With those databases, I can simply replicate complete applications in just one file. My question is, why would someone like to store images on the filesystem? ??
My idea with dbfiles, is that the files that belong to posts will go into the database. That can be images, code source, archives etc. The normal site images (for themes) etc, would not be e candidate to put in the database.Ahhhhhhhhhh ?? Thanks !
What is the potential downside of this (apart from the obvious impact on performance)? I take it there are reasons why WP and most blogs and CMSs do not store every image as a BLOB by default.
This may also solve some problems caused by PHP safe mode.
Where does it intercept the normal file reads and writes? Is there any potential to mess up wp-cache (I think thats a stupid question, but I am not sure so I am asking anyway).
The biggest advantage for something like this might be downloads. You can store your downloadable files in the database, then make them only available from a php script (this isn’t all that different from how source forge mirrors work.) That way they can’t simply https://yoursite.com/downloads/gimmiefile.zip — you can track who requested the file and/or prompt for password before downloading it.
Tg
graemep: one downside is that the database will grow as you add files.
My plugin does NOT intercept normal file reads/writes, so you could have a combination of both. The actual downloading takes place outside of the plugin architecture, so it will not mess up wp-cache. But perhaps some sort of caching mechanism could be interesting to add in the future. Mind that the current release is my first PHP, MySQL and WordPress project ever, and I’m sure there are several things that could be added ??I forgot to add the following information in the readme.txt file. It will be added in the next release:
Server side tested with:
Windows XP SP2
Apache httpd 2.0.54
PHP 5.0.4
MySQL 4.1.11-nt
Wordpress 1.5.1.3This looks like a very interesting plugin. I read over the files, and maybe I’m daft, but how would one link to a db’d file in their layout/loop?
For now, you have to manually add the URL to the file in for instance an img tag. I will add a tag(s) allowing you to getdb’d files per post or by file id or file name.
I don’t fully follow that, but that’s ok; I’d wait on trying this plugin until you have the tags (and dl count/reporting) worked out anyway.
One thing: I realize this sort of defeats the purpose, but would it be possible to have an option *not* to have the files written into the database, and have the db just point to a dir of the uploaded files?
A better explanation perhaps: if you would like to add a downloadable ZIP-file to a post, you do like this:
* Open “Manage”, “Add Database File”
* Upload the ZIP
* In “Manage”, “Database Files”, right click “View” and select “Copy Link Location”
* Create the post
* Click on the link Quicktag and paste the URL you copiedAnd for your other question, absolutely. Handling meta data for normal files could be handled, but it’s not anything I am interested in for now.
I got my first support mail today. A user running MySQL 4.0.22-standard got an error message when activating the plugin. This is because the SQL used is for 4.1. A workaround that works is to change the dbfile.inc file at row 399 to 409. Change them from:
$sql = “CREATE TABLE
".$table_prefix."files
(
id
int(11) NOT NULL auto_increment,
name
text,
mimeType
varchar(30) default NULL,
content
blob NOT NULL,
description
text,
created
datetime NOT NULL default ‘0000-00-00 00:00:00’,
modified
timestamp NULL default NULL on update CURRENT_TIMESTAMP,
UNIQUE KEYid
(id
),
FULLTEXT KEYname
(name
,description
)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=34 ;”;to:
$sql = “CREATE TABLE
".$table_prefix."files
(
id
int(11) NOT NULL auto_increment,
name
text,
mimeType
varchar(30) default NULL,
content
blob NOT NULL,
description
text,
created
datetime NOT NULL default ‘0000-00-00 00:00:00’,
modified
timestamp NULL default NULL,
UNIQUE KEYid
(id
),
FULLTEXT KEYname
(name
,description
)
) TYPE=MyISAM AUTO_INCREMENT=46 ;”;The diff reads as this:
406c406
<modified
timestamp NULL default NULL on update CURRENT_TIMESTAMP,
—
>modified
timestamp NULL default NULL,
409c409
< ) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=34 ;”;
—
> ) TYPE=MyISAM AUTO_INCREMENT=46 ;”;Thanks for the info. I installed the plugin, so I now see how this all works.
I use loop-based queries to supply the download url (they’re based on the ‘post-name’). Looking at your urls, this would work, except for the ‘&id=’, which has no association with the post. Is it possible to do an url without the ID? Or perhaps your future tag plans take this into account? Edit: nevermind, I read back that your tags will handle via ID or name. Nice ??
One other concern I have about db’d files is portability. I’ve have had trouble in the past trying to extract archival files that have been embedded into a db. This is why I was wondering about a metadata-only version of this plugin.
Arlo, I have no plans on doing a meta-data only version of my plugin at the moment. But if the interest is high enough, perhaps there are others who will pursue the matter?
Great plugin !! Especially if you blog is on a shared hosting service. I wrote a hack that lets you give an URL and the plugin will callout to URL and import the “file” to the DB.
edit dbfile.inc of the plugin like so:
in the editFile function:
locate the following:
<tr>
<td>File:</td>
<td><input type="file" name="FileData" /></td>
</tr>
and insert the this after it:
<tr>
<td>URL:</td>
<td><input type="text" name="FileURL" maxlength="400" /></td>
</tr>
In the receiveFile function locate:
if ($userfile != "") {
...
}
add the following else if condition :
} else if ($url != "") {
$url_array = parse_url($url);if ($url_array["scheme"] != 'http') {
die ('Only HTTP is supported at this time');
}$url_path_array = pathinfo($url_array["path"]);
$name = $url_path_array['basename'];
$extension = $url_path_array['extension'];if (!in_array(strtolower($extension), $fileTypes, true)) {
die('Invalid file type');
}$ch = curl_init();
// set URL and other appropriate options
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);// Perform remote request retieve contents, mime type & return code of URL
$fileContents = addslashes(curl_exec($ch));
$userfile_type = curl_getinfo ( $ch, CURLINFO_CONTENT_TYPE );
$http_code = curl_getinfo($ch, CURLINFO_HTTP_CODE);if ($http_code >= 300) {
die ("remote request returned HTTP code $http_code");
}// close curl resource, and free up system resources
curl_close($ch);
$fileSql = ", name=\"{$name}\", mimeType=\"{$userfile_type}\", content=\"{$fileContents}\"";
} else {
die ("Enter a URL or a local file path.");
}
- The topic ‘New plugin avaiable, dbfile’ is closed to new replies.