I’m finally back at the blog, and while I have been away for a while, I am happy to say that this was only because so many cool things have been happening. In fact, this post is just to frame a tiny (yet crucial) element of a larger push by the faculty I work with at UMW to re-imagine the relationship of the web to their research, teaching, and learning practices. While each of these projects have much in common, they are all particular enough that they will need a more sustained tracing of the development, planning and final product on this blog, something I plan to begin this weekend. However, if you are dying for the 30 second version -which I know you are- here it is: I have been collaborating with a number of professors over the past month (during the Summer mind you - these folks are dedicated!) to re-examine and re-imagine what they are doing with the all too traditional, locked-down, and patented Course Management System the University offers (namely BlackBoard) in an effort to redefine and their own relationship to other possibilities for using web-based technology to guide a class through a series of intellectual discoveries.
The reason why I am able to even consider such a thing at this moment is largely based upon the fact that WordPress 2.0.4 (with a K2 0.9 theme, mind you) has been made increasingly more user-friendly, effectively making the technology a tool rather than an impediment. Software like WordPress offers a golden opportunity to re-examine the static, imprisoned web-based teaching resource that is BlackBoard, simultanoeusly allowing for a driven exploration of the boundaries of the dynamic, web-based classroom premised upon an open-source model. “How so?” you ask. Well, quite frankly, because programs like WordPress are pretty damn easy to use! I can train a group of professors who are familiar with BlackBoard to use Wordpress effectively in about a half hour! In fact, while WordPress is recognized as a blogging software - a realm wherein it is unmatched - it is also an exceptionally intuitive and comprehensive Content Management System (CMS). And while the CMS wars rage on, to quote Darcy Norman, I am playing with Drupal for larger community sites but staying with WordPress for the one off class sites because the low threshold for competency and the strong possibility that faculty might immediately be able to adopt and manage a WordPress site is much more likely than a Drupal site - but I may be showing my prejudices here given my less frequent exposure to Drupal than WordPress. However, as I have become more and more familiar with programs like Lyceum and WordPress Multi-User the idea of scaling becomes less frightening for such a solution.
So why the crazy techy-specific title to this post then? Well, because one of the beautiful new elements of WordPress 2.0x is the ability for users to upload files quickly and easily. For example, a user can now upload an mp3 files that can then be integrated with the inimitable wordpress plugin PodPress, a process that would have required an ftp client previously. While I was giving a demonstration of Wordpress’s upload feature for podPress to a professor this morning, I failed to realize that Wordpress has the uploading limit set to no more than 2MBs (that is what an FTP client like transmit will do to the honest MAC user!). So while I was uploading a 3.5 MB mp3 file, I got a friendly reminder from WordPress that I needed to changed the maximum file size limit for upload in my php.ini file, so without further ado - this is how you do it if you are using Bluehost and WordPress 2.0x (I imagine any other web-hosting service will have a similiar php.ini file they can send you so that you can still use the directions below.):
- Get a copy of the standard php.ini file that is used with your web-hosting service. if you use blue host click php.ini for a copy.
- Now, seach for the upload parameters in the php.ini document (they should be around line 251 in the ini file above) which will look something like this:
;;;;;;;;;;;;;;;;
; File Uploads ;
;;;;;;;;;;;;;;;;
file_uploads = On; Whether to allow HTTP file uploads
;upload_tmp_dir = ; temporary directory for HTTP uploaded files (will use system default if not specified)
upload_max_filesize = 2M ; Maximum allowed size for uploaded files (fyi, M = MB) - This is where you will change upload_max_filesize = 2MB to the appropriate size for your purpsoses - I went to 8 MB, for example (but go higher if you will be doing video!).
- Once this is done you need to save the file as php.ini and place in in the wp-includes folder within the WordPress directory.
And D-I-S-C-O, DISCO!! Now all your faculty can leave behind the ossified world of traditional Course Management Systems and begin forging a new community within the excitingly intersections of teaching, learning and scholarship in an open and accessible web-based environment!
I love WordPress!
Loading ...
Best
i’m curious about this process, i went ahead and used the code you provided with the bluehost link, but i wasnt sure if the saved file would have to match the extension of all my other blog files (adobe live).
does this work if you just edit the code in adove live? then save as ini.php? why is it reversed, as “php.ini?”
best,
kevin
I’m not entirely sure I understand your question. But here’s what I think you may need to do. Don;t edit it in adobe live, just copy and paste the code into a plain old text editor and save it as php.ini (the ini needs to be at the end of the file -for it is an extension the web server will read to get the settings for all your PHP goings on in your public_html folder). For example, if you are using WordPress and want to increase the upload limit for your files, just save a copy of php.ini in the wp-admin folder and that should do it. Am I making any sense?
The article itself says to put the modified php.ini file in wp-includes, and the link via the 7/31 pingback recommends putting it in every directory that has PHP files, essentially. The former is wrong and the latter is “overcomplete.”
I just did this and learned that the modified php.ini file has to be (and ONLY has to be) in wp-admin/, because that’s where the relevant script, i.e. “upload.php” lives. I assume it’s just been moved since this article was written back in 2006.
Excellent info, I haven’t played with this for a while, but I will be testing it shortly, and your advice comes at just the right time. Thanks for clarifying here in the comments, I’m sure others will find it useful as well.