Gary Pendergast

Really? An F grade, because I didn’t put classes on <form> tags, which are technical tags, not semantic or layout tags?

There are classes you can use, instead of clobbering every form on the site:

.jobman_app_form form, .jobman_app_form label {clear: both;}

I’m going to be looking at re-writing a bunch of this code in the next major release – it’s kind of ugly.

In the mean time, you can manually delete old results by running the following queries on your database:

DELETE pm FROM wp_postmeta pm LEFT JOIN wp_posts p ON p.ID=pm.post_ID WHERE p.post_type='jobman_app' AND p.post_date<'2011-01-01';
DELETE FROM wp_posts WHERE post_type='jobman_app' AND post_date<'2011-01-01';

Adjust the date in each query for the oldest application you want to delete.

Thanks for the bug report! A fix for this will be in the next release.

In wp-admin, go to Job Manager -> Settings -> Display Settings -> Job Templates.

Change the “Apply Now” text inside the [job_apply_link] shortcode to be the appropriate img tag, instead.

I discussed this over email, but for anyone playing along at home:

Job Manager stores all of its data as Post metadata in the wp_postmeta table. Because it also has the customisable fields, the meta_key names aren’t based on what the data being stored is.

The long and short of it is, I’m not aware of any search plugins that would play nicely with this format. It’s possible to do a bit of a hack job that just works with your particular job fields, but having a search that works with any format will take some more effort.

Which multilingual plugin? Job Manager doesn’t play particularly nicely with this type of plugin, it seems, as it does some stuff in a non-standard way that it really shouldn’t. (Hangover from older versions of WordPress.)

I can hopefully write a quick hack to get them to work together, and I can look at improving Job Manager further down the track.

The issue here is that Job Manager uses WordPress’ built in media system, which has no concept of private/public files. (This is being discussed here: http://core.trac.wordpress.org/ticket/17255 )

The problem with implementing a fix for this is that there is no lightweight way to authenticate a user.

While I understand the concern, I think this can be considered a low risk for the time being. Guessing the filename of a specific CV (as opposed to a random CV) would be quite tricky, and would only yield information that is already usually publicly available. (Ie, through LinkedIn.)