eclev91

No no no, though I can see where someone might want sub-categories. That was simply an example of a feature that WordPress taxonomies come with out of the box that your plugin has obscured and made inaccessible by implementing its own interface.

What I required was an entirely separate taxonomy. “Category” being, say, a type of insurance that the job would be in (Property/Casualty versus Health versus Financial, for example) while “Discipline” being what you’d actually be doing (Claims, Accounting, IT, etc).

The greater point being that both child terms and multiple taxonomies are things that WordPress post types support out of the box that your interface has left out. The perfect solution would be dropping your interface for the default WordPress post interface, but that would likely be quite the to-do. In the meantime, I’ve spoofed a solution to my problem using a checkbox custom field. My first note specifically outlines the bug in the handling of checkbox custom fields, as well as a solution (that I’m aware would be overwritten in my code if I were to update the plugin). I’d be happy to open a PR when it hits GitHub.

I’m not sure I understand, what’s a “Job Details posting”? I’m using checkboxes for a secondary taxonomy. I’ll try to explain it as best I can.

Your plugin uses post types and taxonomies and post meta, but totally abandons the WordPress interface for these things, so unless you’ve rebuilt the functionality yourself, it isn’t there.

For example, taxonomies – you’ve created one called “Categories” and built out an interface for it. What if I want child terms? A second taxonomy? You haven’t built out an interface for those, even though the jobs are WordPress posts, which out of the box support as many taxonomies as I assign with terms that may have children.

In this specific case, my client has “Categories” and “Disciplines” as taxonomies for jobs. Your interface only supports one taxonomy for the entire post type, conveniently also named “Categories”, but both of these could be considered taxonomies and also function as so. So I created a checkbox field with several options for “Disciplines” and wrote my own code for the front end to grab the possible values for this field, spit them all out as checkboxes, and then use the input to filter the jobs being displayed.

Yep. So spin up a fresh WordPress. Install your plugin.

1. Under Job Form Settings, create a checkbox field. Create at least two options, separated by newlines.

2. Create a new job. Check one option from the checkbox field that was just created. Save.

3. Edit job. You’ll see the option is selected. Select at least one other option for a total of 2+ selected. Save.

4. Edit job. You’ll see it now shows no options as selected.

Right now, you can order by any of the stuff built into WP_Query using the shortcode:

[staff-directory orderby="title" order="ASC"]

For a totally custom order, Custom Post Types support menu order out of the box if you define it as such.

Since that isn’t already happening when Adam defines the CPT (this is your brainstorming!), you’ll need to add it yourself using add_post_type_support. Drop the following into the functions.php file in your theme (or, if the site has a custom plugin you’re maintaining, it’ll work there, too):

add_action( 'init', 'unique_prefix_add_staff_order' );

function unique_prefix_add_staff_order() {
	add_post_type_support( 'staff', 'page-attributes' );
}

You should now see “Order” in the right column of the edit staff member page.

This will allow you to use the orderby and order parameters that Andy built into the plugin to order by menu order:

[staff-directory orderby="menu_order" order="ASC"]

If you’re not using the shortcode, but rather using the WordPress post type archives, and are therefore using a PHP template (if you have pretty permalinks on, it’ll be https://mysite.com/staff), you’ll need to make sure that the query is being ordered by menu order. You’ll need to force that yourself using another filter called pre_get_posts:

add_filter('pre_get_posts', 'unique_prefix_order_by_menu_order');

function unique_prefix_order_by_menu_order($query) {
	$post_types = array('staff');
	if($query->is_main_query() && in_array($query->get('post_type'), $post_types)) {
		$query->set('orderby', 'menu_order');
		$query->set('order', 'ASC');
	}
}

And those will work as well. Drop that wherever you dropped the add_post_type_support(), but again – only if you aren’t using the shortcode.

I’ll follow up on this guys behalf:

Not getting an error, it simply says there are no spam comments, but I’ve got > 4,000. WordPress 4.4, latest version of the plugin.

Thanks!

Which plugin? I may have time to do a PR

I seem to be having the identical issue. Let me know of any details that would be helpful.

Declaring image size:

add_image_size('slider', 1900, 500, array('center', 'center'));

Already did that via the instructions here, so get_option('siteurl') results in https://example/wp, but this is not where wp_content is located. wp-content is located at get_option('home') – https://example. It could potentially make sense for the original WP_CONTENT_URL definition to use home instead of siteurl, since this is the same in most cases, but I would wager there are alternative use cases where this would break other things.

I haven’t edited any core code – I used their functions to grab the global Twig Environment from the site’s core plugin, then use new Twig_SimpleFunction() and so on. I hate to edit core files.

Neither of those solutions worked, unfortunately, but it did occur to me that echoing the object resulted in a string, so there must be a method doing it somewhere. That led me to the __toString() method in the Ai1EC_Date_Time class, which got me what I needed, so I ended up with

strtotime($date->__toString())

It did exactly what I wanted. Thanks for taking the time to address my question.

I can do them right next to each other, like so:

<div class="col-md-12">
			{{ event.get('start') }}
			{% if expired( event.get('start') ) %}
				<span class="register-for-event expired">Registration Closed</span>
			{% else %}
				<a class="register-for-event replace-me" data-event-id="{{ event.get( 'post_id' ) }}" href="">Register</a>
			{% endif %}
		</div>

And I still get two different things. I’m calling the same function on the same object in the same context it seems.