This one falls into the “reminding myself how to do the workaround” category, but maybe it will be helpful to someone else, too.

The WordPress media player has some nice buttons for play, volume, full-screen, and so on. But no matter what I did, I could not see those buttons in any browser. They were there, and could be clicked, but were completely invisible.

The problem is that those buttons are produced as .svg files (scalable vector graphics) and some servers have trouble associating mime-types with those. So the server won’t serve them up (or it serves them as plain text, or something, which they’re not, so they’re not visible), no matter what browser you use.

There are various htaccess tricks to register the mime-type, but I couldn’t get them to work.

However, those same buttons also exist right in the same directory as .png files, which the server is fine with, so I just went to /wp-includes/js/mediaelementplayer.min.css

(UPDATE: It’s now  /wp-includes/js/mediaelement/mediaelementplayer.min.css )

and replaced every reference to “svg” with “png.” That did it (had to clear my cache in safari to see them there).

It’s ugly to edit core css like this, and will break every time I upgrade, most likely, so I’ll have to do it again, so that’s why I’m noting it here!

After a long day of struggling with various .htaccess solutions (none of which I could get to work at all in WordPress multisite), I had the wonderful idea to ask for help from the wp-edu listserv and within minutes, Daniel Bachhuber responded with a perfect solution.

But maybe I should have started with the problem.  (Let’s do it as a theoretical).  A professor has a class site in a WordPress install.  That professor has permission from the copyright holder (or has the right under fair use) to share a journal article with her class as a PDF.  She does NOT have the right to share that journal article with the entire internet.  So she scans the article to a PDF, uploads it to her WordPress install, and links to it on a page that is password-protected, giving the password only to the students (and changing it at the end of the semester) so nobody else can access that page.

The problem is that while the page where the link sits is password-protected, the file itself is not.  So anyone with the direct URL to the file can download it instantly, without knowing the password at all.  What makes matters worse, google (and others) indexes the content of PDFs quite commonly, so even an attempt at security by obscurity of the filename is bound to fail.  Anyone googling for the author’s name, or any of the terms in the journal article, would find a quick and easy link directly to the file, which the professor is now, in violation of copyright, giving away free to one and all (I’m not going to get into a discussion at this point of the overall ethics of copyright and whether or not that journal article “wants” to be free).

Extensive searching, extensive trial and error, over an extensive time had left me unable to solve this problem.  But Daniel Bachhuber’s suggestion is a simple and beautiful plugin, Ben Balter’s WP Document Revisions. I admit I had come across this suggestion in my googling, but I rejected it without really thinking it through, on the grounds that I didn’t need “document revisions.”  Silly me.

The plugin (which works fine and dandy in multisite, although I do recommend the network-admin add-on from the Code Cookbook) with a very simple interface, lets you set the upload directory outside the document root of your site, not accessible to any outsiders, and then it totally respects your password and beautiful permalinks.

It does much more, as a document workflow solution (sort of an open-source alternative to –ugh– sharepoint, in fact). But just for this little purpose, it’s quite nice.  Highly recommended!

Mainly documenting this just so I will have it somewhere I can find it easily, but maybe it will help others, too.

On the Macaulay Eportfolio system we do not restrict account creation by email domain (since we want our students to use whatever email address they want).  Instead we use a shared codeword which only our students have.  Without that codeword, you can’t create a new account.

This completely shuts down spam blog or account creation (comment spam is a separate issue), but still makes the process easy and open enough for large numbers of students to create (legitimate) accounts whenever they want to from a wide variety of different email addresses and campuses.

But I noticed that every time I upgraded BuddyPress, within 10 or 12 minutes, spam accounts would start flooding in.

The reason is that BuddyPress contains a lurking little file which does NOT respect the codeword restriction.  And spambots seem to be scanning for and targeting that file ALL the time.

In the BuddyPress directory, in bp-templates/bp-legacy/buddypress/members there’s a file register.php .  And that file is a wide-open invitation to splogs and splusers.  Spammers. Bots.  They flock to it.

So every time I update BuddyPress, step number one right after the update is to delete that file.  I write this to myself…to remind myself to do that, and to remind myself where it is.

Thanks, self.

 I had a great time at this year’s WordCamp NYC, hanging out with the other CUNY WordPress folks, and talking WordPress in education to a (larger than expected) and very interested crowd.  We tried to pitch for broad appeal, and I think we hit it, and not have too much inside baseball (not too much) or too much CUNY-carping (not too much).  That was all enjoyable as always.  Even better, though, was a little moment towards the end of the day.

One of the folks in the audience (I didn’t catch where he was from) asked a question about how we explain to students how to use the WordPress media uploader (the many clicks required, the necessity to “insert into post” even after it might seem like they’re done).  We none of us had a great way to provide those instructions. We all agreed that it’s a bit of struggle in a world where we (especially those of us who are used to using Macs), just would like to grab an image from our desktop, drag it into a post, and plop it right in.  True, the media uploader as of 3.3 or so is better than it used to be.  True, it’s one of the oldest parts of WordPress, and not easy to modify, but it just doesn’t feel so smooth.

Well, we complained and agreed that we were right to complain, but then someone else in the audience spoke up and said she thought she remembered a plugin that made this better and she would look through her notes and find it.

Wow! Today I got an email–she didn’t find the plugin, but she did a lot better.  She figured out a relatively easy (relatively) way to make media uploading easier and better, and she wrote up this great, clear, step-by-step instruction set.  A generous, community-minded act.  A tool that we will definitely find useful.  And shared freely, and quickly, too!  Thanks, Margarete Koenen!

This is a fairly technical solution to a fairly limited use-challenge.  But it’s not a scenario that is completely unheard of.  It’s something that we’ve faced here on multiple occasions, so I decided to finally take a swing at a somewhat user-friendly and somewhat elegant solution.

Here’s the challenge.  There are lots of instances–applications for fellowships, submissions for awards, proposals for a conference or journal, things like that, where we have multiple submissions that have to be reviewed by multiple reviewers.  Often the applications include basic contact or demographic data, categories or selections from a limited list, and lines or paragraphs of text, as well as sometimes much longer, formatted, statements or resumés. Then those applications have to be circulated to a full committee, each member of which has to review all the material, assign a numerical rating, and usually have written comments, too.

We used to do all this with stacks of paper, asking candidates to submit five (or more) copies of their whole packages, and then we’d have big fat envelopes and boxes of paper being shlepped around the city (and later shredded).  Those were fairly easy to read and review, but a giant pain to manage and store (or destroy), and hardly environmentally friendly, if that matters.

So a couple of years ago we turned to various online form solutions–drupal webforms, google forms, and so forth.  This was an improvement in some ways–each of them led to a spreadsheet that could be more easily shared (through google docs, usually).  But when the applications to be reviewed were complicated, the spreadsheets were immense and very difficult to navigate (especially in google docs).  And when there were attached PDFs (essays or statements or resumés or whatever), those were included in the spreadsheet as a link, meaning another click, another window, or a download, and some confusion about which went where.

There was also the constant issue (everyone who works with google docs with large numbers of people deals with this, I think) of determining exactly which email address had been invited to view the doc.  Was that your personal gmail address? It was? Which one did you log in with? Are they linked? You can see but not edit? Did you accept the invitation? It went to your college address?  You don’t see it? Google has gotten better with all of this more recently…but it still can be an issue, particularly for technologically unsophisticated folks.

What we wanted (what I wanted, really, but it was based on what others were asking for) was to have a simple system–I log in, and I see the proposals I have to review.  I can go through them one by one, and see all the materials right there, and enter my rating (and comments) right there.  Attractive, easy to navigate, and easy to export the results.

So, call me strange, but this is actually the kind of thing I like to make, and after a longish Saturday afternoon and part of Sunday morning, I think I got a pretty good solution!

A demo version that anyone can see and try is here macaulay.cuny.edu/community/reviewdemo.  Of course any real production version would be private and closed–not viewable by anyone except the committee doing the reviewing.

It does pretty much everything I want it to do, with a couple of caveats (scroll down to the end).

For anyone who wants the details of how it works–it’s fairly easy to replicate, I think, and of course easy to customize and easy to improve. (This is a VERY long description, because I wanted to try to document as fully as possible.  If you want to just skip it and see the result, go right ahead! macaulay.cuny.edu/community/reviewdemo

Here’s the process:

Collecting the Entries

For this I use a WordPress site (can be a site that you reuse for each application process, or a new page on a common site.  Doesn’t really matter).  The site can be attractive, have background information and requirements, and somewhere on there you can have the application that candidates fill out.  An example would be this site macaulay.cuny.edu/eportfolios/itfprogram, except that you can’t see the application form there because the application period is now over for that position.  The magic that makes this all possible (and most of the whole thing) is from the great Gravity Forms plugin.  This is not a free plugin. For one site it’s $39 and it goes up from there. But it’s a plugin that is worth paying for.

Gravity Forms collects all the information, with all kinds of fields that you can completely customize, including the ability to let applicants upload files (limit the filetypes, of course!) or to write long or short open-ended responses.  It then spits all that information out into a csv file (well, you have to tell it to do that, but it’s an easy couple of clicks).

Processing the Entries

This took a little bit of csv magic. The idea is that the data from that csv spit out from Gravity Forms has to be processed a bit to take and make the right format for turning it into WordPress posts.  In this process, Excel’s “concatenate” function is the big secret.  (Of course, Numbers on a Mac, or Open Office Calc on just about any platform would do the same thing.  I used Excel on a Mac, but–more about this below–I would have been better off using Numbers).  The plugin (CSV Importer) we use to turn the csv file into posts wants columns for  the post title, the post body, the post type (a post or a page–for this purpose, we really want page), and excerpt, categories, tags and date.  Any other columns become custom fields.

So if you have a spreadsheet from Gravity Forms with columns for (for example) first name, last name, academic discipline, dissertation title, personal statement, CV, teaching experience, skills (or whatever), you need to concatenate last name with first name, with a comma and a space in between, and make that a new column for post title.  Then (here’s where I got really fancy) concatenate academic discipline, dissertation title, personal statement, CV, teaching experience and skills all into the post body.  But put all your html formatting into here, too.  I inserted h2 tags  with the name of the entry (for example, <h2>Academic Discipline</h2> followed by the cell number for that entry, to make it look nice in the final post.  And…for the personal statement and CV, which were URLs pointing to PDF files, I added the shortcode [gview file=] to make the google doc embedder plugin show those PDFs right there in the page itself.

That all took a while to figure out and set up, but once you get it right once, it does the whole spreadsheet in a couple of seconds.

Importing the Entries

Now that csv is clean and ready to import, it’s very easy.  Just make a new WordPress site and install and activate the plugin CSV Importer. Once that’s activated, you go to its menu item in the dashboard, navigate to your nice clean saved csv, upload it, and bingo. You’ve got a page for each candidate, titled with her name, with all her information, including the linked PDFs, displaying nicely right on that page. (One important caution.  If you use Excel on a Mac, you’re going to find that the csv it produces is not properly formatted–you’ll get “0 Entries” when you try to import.  I’ve run into this problem before in other cases, so I knew about it, but it can drive you crazy if you’re not expecting it.  There’s something wrong–somebody more aware of these things can explain it exactly–with the way that Excel on the Mac saves csv files.  Something with the line breaks, I think.  It’s probably possible to fix it somehow in Excel settings, and that would be smart, but not being smart, I just open the csv in Numbers, and then export from Numbers to a csv again, overwriting the original.  And that’s the file I use.  Wouldn’t it be smarter to just work in Numbers from the beginning, and save that step? Yes.  But as I said, not being smart…)

You can, if you like, fiddle with your CSS to make the display of those pages even nicer and prettier.  I actually ended up using a custom theme (or a customized child of a theme, really), so I could have refinements like a “next” and “previous” link at the bottom of each page, and a dropdown list of all the candidates at the top of each page, and I used colors and font styles that I liked.  Depending on your theme, you could easily do this with custom menus, too.  I leave all that as an exercise for the reader.

For privacy’s sake, you do need to set the site to be viewable only to registered subscribers.  Then you just create accounts for only the members of the committee which will be reviewing.  All kinds of other refinements are possible.  You could use categories to make sub-committees if your reviewers are broken up that way.  You can get as fancy as you need to, since WordPress is so flexible in this kind of thing.

Reviewing the Entries

Now on our new reviewing site, we’re going to be returning to Gravity Forms again (a note about pricing here–Gravity Forms’ single user license means one install, period.  Two WordPress sites in a single multi-site install would count as two sites, not one.  So if you’re trying to go as inexpensive as possible, you’re going to have to get a little creative–in other words, your site for collecting applications will have to be the same site you use for reviewing applications.  You can’t have a new site.  You will then have to work with password protected pages, or changing the site’s privacy settings after the application period and before the review period, or something.  Totally doable.)

We use a new form for collecting the reviews.  I did fields for reviewer’s name (auto-populated from the user’s login), candidate’s name (auto-populated from the page title), comments, and numeric score (you can limit to just 1-5, or 0-10, or whatever.  There isn’t any way I could find to prohibit fractional (decimal) scores.

You can put that form in a sidebar widget (or a footer sidebar, which is what I did), so it’s right there on each page.  Or you could put it on a separate page which reviewers would then need to have open in a separate tab or window.   Gravity Forms provides the widget as part of the install, and that seems like a really efficient solution, so that’s what I did.   Reviewers look at all the candidate’s information, and enter the score and comments right there without even going to another page.  Efficient!

Some reviewers like to be able to see what other reviewers are saying or have said about candidates.  Or in other cases you might not want to allow that, preferring all reviewers to work independently.  It’s really up to you, and I know that I will be doing it each of these different ways in different instances.  If you do want to let reviewers see other reviewers responses, there’s another plugin I used.  This is a (free) plugin for a plugin.  It’s the Gravity Forms Directory add on (and it’s handy for lots of other purposes, too). This lets you take the input from any field in a Gravity Forms form and display it on a WordPress page or post. It updates live and in real time, and you choose which fields you want to be included in the directory, and lots of other options, too.  It’s a very sophisticated and effective add-on for Gravity Forms, and it is free (of course it requires Gravity Forms in order to work), but donation driven.  I recommend you make a donation, if you use it.  I did.  Well-deserved.  You can see this on my demo site macaulay.cuny.edu/community/reviewdemo/results-so-far/ and if you enter a rating on one of those demos, you’ll see your own results show up, too.

Final Steps (reviewing the reviews)

When we’re all done, when all reviewers have completed all reviews, we’ll have another csv file, which we can easily download and sort and manipulate to get the high scorers, review the comments, and so forth.  That csv file may need some more concatenation, or more likely, convert text to columns to un-concatenate (for example, I’ve got names of reviewers entered as just first name and last name in one single field.  I’m going to want to convert that to last name and first name in two separate columns, so I can sort the list alphabetically.  Same for names of candidates–I’ll want to split those up).  But that’s easy csv work, really.

Then we’re ready to start interviews, or select awardees, or whatever the final step is!

Lacks and Caveats

There is a way to let reviewers edit their responses.  I have not yet been able to make that work.  It would be good to have, but until then, I’m just asking people, when they want to make an edit, to just re-review and in the comments make a note like “USE THIS ONE–THE OTHER ONE SHOULD BE DISCARDED.”  Eventually I’ll get it working and then logged in users (the only kind of users we’ll have) will be able to just hit a button marked “edit” if they want to change one of their scores.

I haven’t tried this with more than about 60 entries.  It should still work fine, since WordPress can (usually) handle 100s of pages without an issue.  But that would need to be tested carefully first.

Sometimes the google doc embedder craps out and the nice embedded pdfs (or docs or powerpoints or whatever) don’t show up.  I’ve had especially bad luck with getting it to work for docx or pptx files.  But even if that happens, there’s still a download link so you can fall back on the less convenient downloading the file and reading it.  And you can limit filetypes to just pdfs, which is probably a good thing to do.

The field for paragraph text allows you to limit the length of entries, but only by maximum characters, not by word count.  This is often the way these forms work, and people are pretty used to it, but I wonder why word count is really so hard to do.

Check it out

So that’s about it.  It was really a lot easier to do than this sounds (in fact, describing the whole process was almost harder than doing it, but I thought it might be good to have it documented–for when I forget, as well as for others). I’m sure I’ve forgotten a few points, but nothing too critical, I hope.

That link again, to check out the demo (and I do apologize for the silly fishy content there, but it fills the pages!)

macaulay.cuny.edu/community/reviewdemo

 

 

Some might say it’s not entirely worth it, but Alkivia Chameleon is a very nice and very popular theme, so I wanted it to work!

Unfortunately (as others have complained), since the latest update (was it the WordPress update? or the Chameleon update? I’m not sure), sites using this theme no longer have any posts appearing on the home page. Yuck. It’s like losing your whole homepage. And the workaround (using widgets) just wasn’t very useful.

So I did a little poking around, and until and unless the theme author gets things working again, I have a temporary fix that seems to work just fine. It seems that the file front-page.php was the problem. I went in via FTP, renamed that file (could have deleted it, but thought I’d better not take a risk in case I still needed it. So I just called it “nono.php.” Choose your own clever name).

So anyone else who has alkivia chameleon and WordPress 3.0, and wants to keep using both, just get rid of (or rename) front-page.php and you will once again have posts on your front page. Phew!