-
I have just uploaded 1.1.7 of MiniCard here and to the WordPress theme directory. This updates includes:
- New networks; xing, gowalla, yelp, foursquare, mobileme, google buzz
- A way to change link text and define multiple links of the same network
- A way to define your own custom links + icons
- Improved admin panel
Hope you like it, and don’t forget you can show your support by purchasing the premium pack from here.
-
It’s been about two weeks now since I made the transition from a shared reseller hosting account to a VPS (Virtual Private Server) account – impressions so far, excellent performance but fiddly to configure.
The reason I wanted to change from shared hosting was the fact the server was always being hacked (even though ALL my scripts were secure), there was frequent downtime, support blamed me for problems every time, and it was slow as hell.
Those used to a shared hosting environment would probably not know where to start when faced with configuring a VPS. Luckily, a lot of it was pre-configured when I received my account – certainly some of the major security holes were patched. I was not satisfied with those however. As a victim of hacking in the past (previous host swears it was not there fault, something I don’t believe) I took extra care to secure it as a much I could – configuring brute force detection, the firewall, installing mod security (excellent rules for that here: http://www.atomicorp.com/wiki/index.php/Atomic_ModSecurity_Rules) and going though multiple guides (like this one: http://www.webhostingtalk.com/showthread.php?t=468168) with a fine-tooth comb.
The result? My pages are loading at least 6 times faster, I have had no down time (or at least have not noticed any), and I feel in control and happy. No longer am I at the mercy of shared hosts 
If your interested, I chose ServInt as my provider as they offered a great deal, as well as being a managed service (so I’m not on my own if I screw things up). I was tempted by the bells and whistles of Media Temple, but felt the ServInt service was better value.
-
Download Monitor has received some more love and has been updated. Here’s the change log from the new version:
- Small bugfix in uploader.php – cat ID
- Changed stats graph calculation – thanks lggemini
- Changes to headers in download.php to avoid caching
- File Browser fixes – $root was clashing with something….
- exclude_cat works in all sections of download_page now
- Removed hardcoding of /uploads/
- Added action to download.php – should be able to use it to stop a download if you want – maybe limiting downloads per day or something? Whatever you want…
- Made it so if you post new file on ‘edit’ screen, the post date is updated.
- Fixed the ‘blank meta’ section which blanks out custom field values when nothing is set.
- Moved ‘allow_url_fopen’ check.
- Someone said downloads don’t work with spaces in the name. They do! Wasting my time sonny…
- All work and no play make jolley a dull boy
- Had to rename capabilities so they work. Apologies if you have to set this up again! Cheers to Mark Dingemanse.
- {category_ID} custom format tag added. Useful if you want to send someone to its category on the DL page I guess. Also added {category_other} so when no category is set “other” is shown – this is because the download page can show an ‘other’ section if you want it to.
- You can now manually edit the post date on the edit download screen.
If you have edited capabilities for download monitor user permissions, you’ll have to again sorry! This is because I named them too long. Also, you should check your forced downloads still work because there was a logic error meaning they may not have been forced after-all…
Enjoy.
-
Today I completed the update for the Wordpress Download Monitor Plugin – many tweaks, fixes, and features added. There were no changes to the database structure so people upgrading should be fine. Here is the list from the change log:
- {user} tag added for custom formats
- ‘autop’ option fix
- Download page buttons applied with CSS so they are easier to customise/translate.
- Fix for pagination bug after editing a download
- Category output fix on edit downloads screen
- Category urls on download page use ID rather than name to prevent errors when cats have the same names.
- exclude_cat added to download_page shortcode
- Localised ‘hits’ ‘date’ ‘title’ on download page
- Option to disable the download logging
- Read file ‘chunked’ some people found large files were corrupted so this should help (fingers crossed)
- Added show_tags option to download page – displays x amount of tags on the download page.
- File Browser root setting and download.php logic/mime types modified thanks to Jim Isaacs (jidd.jimisaacs.com)
- Interface Improvements
- Bulk edit categories, custom fields, tags, member only downloads
- Added roles for download monitor admin – should be able to use with a role manager plugin if you want anyone other than admin to access the admin section e.g. http://wordpress.org/extend/plugins/capsman/
- Change redirect after add
- Edit Cat names/parents
- Dedicated tags and thumbnails fields (they still use meta table though)
And yes, those category link bugs are fixed at long last, and you can edit category names finally. Phew!
Anthony says:
That’s cool, Plugin page add on is a nice touch!
Comment made on May 22, 2009 at 9:17 pm
wordy says:
You rock Mike! I am broke now but the next second i have spare in my card i’ll make a donation . I know that doesnt help but we appreciate your efforts and this awesome plugin! Thanks
Comment made on May 23, 2009 at 12:24 pm
Jim Isaacs says:
Mike,
First I want to thank you for a great plugin. Really a live saving for us open source enthusiasts.
A long while back I was actually in the process something similar, which was supposed to be a download monitor, and much more. Needless to say I bit off more than I could chew and development stopped before it really got started.
Why am I telling you all this?
Well because I the one thing I notice in your plugin that I really wish would before I started using it immensely is the ability of downloading files from anywhere, including from directories that are non inherently web accessible. You may ask why would you want to? I will tell you that I really hate making duplicate files when I don’t have to. Everyone likes cutting down on organizational work to make their lives a little easier. Therefore when I post downloads to my blog, I actually post a link to a file that is not directly served by apache. Then I use php to read and serve the file on the fly for linking or download.
You may still be asking “so what is the benefit again?”. If you like to be organized like me, then you can see the goodness of having one centralized development library located on your server that you may connect to via ftp, samba, svn, ssh, etc.. and leave it closed to http because if it not necessarily available for release. The great thing is that using php to read a file without it being served normally is that I only need one place for my library, and choose what file to make available simply by posting a link!
Anyway, I’ll try to be more brief now and tell you that I actually got this far in my development. I have my plugin reading from anywhere on the server, and then serving individual files through php. I even have .htaccess settings like yours to hide the path to the original file. There are slugs for the file to force download, and a regular link request. The file may be posted with short tags called [file] and [vfile]. I realize the “vfile” was going a little overboard and is unnecessary. It is Shortcode which actually allows you to treat the content within the short tag as the content of a file. It may be templated, and even downloaded. Like I said, too much.
With these short codes, they are both parsed in similar ways, using php templates. These templates may be strung together in an attribute so you may using multiple templates for one file or piece of content, and cause no unnecessary processing.
Now here is where I stopped. Like I said I just overwhelmed myself because I intended this thing to be so so so much.
What I would like you to do is take a look at my source, and see where I was headed, and even take any of my ideas into consideration for your Download Monitor. In particular the php templates and especially the ability to use php to serve the files.
Please go to this link for more info.
http://ji.dd.jimisaacs.com/archives/10
And please feel free to email me at the email used for this comment.
Thanks again,
Jim Isaacs
Comment made on June 6, 2009 at 1:00 am
Mike Jolley says:
@Jim Isaacs: Hi Jim. Thanks but the problem here is my time is stretched and I don’t think I have enough to go through it, understand it, then port it over to my plugin. If you have any specific suggestions however Id definitely consider them for inclusion.
Comment made on June 13, 2009 at 5:05 pm
Jim Isaacs says:
@Mike Jolley: Mike, I understand the time it takes to do such things, which I guess is the reason why I let this plugin’s initial intention go by the wayside. Regardless, to reply to your last comment. The feature I was explaining in my last comment, and would like to see would be the abilitiy to point a download to a file path rather url. Or the option to do either. This is the main thing I was hinting at. To do such a thing one would have to link downloads referencing file paths to a resource parsing php script. htaccess can be used to hide the resource script’s url. This resource script then serves up the download from the specified location in reference in that download record. I was thinking something like this.
Raw:
http://mysite.com/wp-content/plugins/wp-download-monitor/resource.php?id=5
Htaccess:
http://mysite.com/downloads-base/5
Within the resource script you can actually do the check to see if it should look for a file path or a url. If it is a file path, then serve up the download right there with headers etc.. If it is a url then do a redirect etc.
I hope this makes sense. As I said, my last comment was mostly about this feature, and I was just pointing to my old plugin as a way to reference what I was trying to say. I was also trying to explain why a feature like this would be a great thing for developers. If you don’t think so, I would love to hear a better blog/WordPress style solution, and I’m not being facetious.
Comment made on June 16, 2009 at 11:54 pm
Mike Jolley says:
@Jim Isaacs: But it does do that doesn’t it? The download is served through download.php, and can be hidden though htaccess too. If you choose not to use the built in uploader you can add a path through ‘Add Existing’. Admittedly downloads are redirected rather than outputted through headers, but the option is available if you wish (by adding the ‘force’ custom field).
Comment made on June 17, 2009 at 1:10 am
Jim Isaacs says:
@Mike Jolley: I know your plugin is already close to what I was asking for, which is the main reason I figured I would comment here about this in the first place.
This ‘force’ field you speak of I was unaware of, as I can see in the file, it is added automatically with the “members only” option selected, and adds the appropriate headers to force a download in the exact way I described. I even see the condition for adding headers for a local or remote resource. This condition though I see might be the problem:
if (strstr($thefile, get_bloginfo(‘url’))) {
This, as I understand, is how you determine if it is local or remote by returning a relative link if the blog url is within the string. Though it also hinders the capability of reading a file from anywhere else on the local server. There are too many ways to change this for me to list in order to allow it, but it is up to you as to how to handle it from the admin perspective, versus string parsing automation which I think is what you were going for.
Maybe it is as simple as checking for a protocol in the string (eg: :// ), if there is none, then read the file without modifying the path string. Doing it this way, a relative file path will be from the download.php of course, which is messy, but absolute file paths will work fine. Sorry for thinking while typing in a comment, but maybe there is something like this that can be done:
if (strstr($thefile, ABSPATH) {
This still doesn’t quite work with what you were going for, things just get confusing without telling a user specifically what local paths are relative too. Which still brings me to that one missing option. Maybe it is as simple as adding one option of “Relative File paths BASE DIRECTORY”. This could be the directory all local files without a protocol are relative to. Maybe the javascript file browser can even browse from that (I haven’t looked into this yet)
All in all, I know you are busy as you said, so I might go ahead and do it myself if I get a chance and send you the version if that’s ok. I was wandering if I do this, is there some way you would like me to send you the files? As I said feel free to contact me at the email attached to my comments if you wish.
Comment made on June 17, 2009 at 4:51 am
Jim Isaacs says:
@Mike Jolley: Ok, I apologize for not doing this before my last comment, but as you an I said it was already very close…
First off, I was confused as to what “members only” and the “force” meta was doing, but then this line cleared it up.
if ($d->members && $force && ini_get(‘allow_url_fopen’) ) {
You are looking for “force” meta to be set, AS WELL AS the “members” flag before a force download can happen. This was screwing me up, because I want a force download to happen without a “members only” file.
So I changed it temporarily to this:
if ($force && ini_get(‘allow_url_fopen’) ) {
Now I found out that your plugin works great from anywhere on my server, even from non-web-accessible files and directories. Exactly what I wanted! Just needed set the “force” meta value to “1″, as well.
Problem here is the code logic, I want to allow a members only file to be forced, as well as a non-members to be forced. I haven’t quite picked apart your code fully to see what I can do here.
As for the file browser, that is very sleek jQuery AJAX you got going on there I must say. Just one little variable “root” and the whole file browser can browse from anywhere on the server. Here I was questioning again. The ideal way to do this would allow the user to select their root directory some how, like I said, but now understanding things better, this base only needs to be implemented for the file browser.
My other temporary solution to this was simply:
root: ”,
I am just backing up out of the ABSPATH one level to get to my webserver’s root. I figured this would be fine since nearly all hosts always have a user home directory for their clients. The only reason this wouldn’t work in all cases is if wordpress is not installed in the root webserver directory.
It works fine for me right now though.
I think my next steps would be to figure out the logic of the download.php script to do what I need to and stay inline with what you are going for. Then figure out where and how to add one more database option for the file browser root.
Comment made on June 17, 2009 at 5:58 am
Jim Isaacs says:
@Jim Isaacs: I’m very sorry, I didn’t use the
codetag, and you’ve added to the comment form for us to use it!What I changed the root variable for the file browser to:
realpath( ABSPATH . DIRECTORY_SEPARATOR . '..' . DIRECTORY_SEPARATOR ) . DIRECTORY_SEPARATORComment made on June 17, 2009 at 6:03 am
Jim Isaacs says:
OK, I think I have it. I added another option for the file browser root. It is set in the general options on the Configuration page. It defaults to ABSPATH.
I also tried to figure out that logic in the download.php, I think I have it, but before I send it to you, I wanted to ask a small favor.
On this page:
http://jidd.jimisaacs.com/archives/3
I have 2 download link in the post. Each download is being forced, and from a secure location on my web host.
I wanted to know if there is anyway for you to see the secure path to these files. Or if it stays hidden.
Thanks again.
Comment made on June 17, 2009 at 3:08 pm
Mike Jolley says:
@Jim Isaacs: Phew let me get up to speed – may be better to continue this via email but here goes.
As you noticed, I check for a local file by comparing it to the blog url. This is because when my uploader works we save as an absolute path. I think we could do a second check for a relative path/local file too (as I think you suggested).
Im quite sure it won’t reveal the real path if its forced – it should just try to read it from the server. If you dont force then it would redirect and show the path.
O and if your wondering why force is off by default, some people had corrupted file issues and I don’t think I found the fix (although they may have been remote files which wont work in all cases).
Comment made on June 17, 2009 at 4:49 pm
Patty says:
I have a lot of respect for people who share their work with the community and help improve stuff! Great plugin, thanks a lot!
Comment made on September 10, 2009 at 3:44 am