Sean Leavey

Thanks. Do you know then the difference between this setting and the other one in the blog settings, “Discourage search engines from indexing this site”?

Seems like showing all available roles makes the most sense. It’s up to site admins to ensure they add users to the intended group when they add a directory user.

It only contains the new ones:

print_r(array_keys(get_option('wp_22_user_roles')));

gives

Array ( [0] => administrator [1] => subscriber [2] => researcher [3] => intern [4] => excluded )

Some plugins remove the default roles and replace them with their own. WordPress does not enforce that the default ones are kept; indeed it looks up the database to get the current roles and the default since they can change.

Hmm, but isn’t that function just listing the roles available on the primary site, not the site being listed? Don’t you have to call e.g. set_current_blog before each call to wp_dropdown_roles?

Yes I’m using a plugin which has modified roles on one blog on my network. This network does not have the default “Admin”, “Editor”, “Author”, etc., yet these are still shown in the dropdown box for that blog.

Oops, that code snipped should be $coauthors->add_coauthors( $post_id, $array_of_coauthors );, i.e. the second parameter is not the class instance, but actually an array of WP_Author objects.

It might be easier to use the existing functions in Co-Authors Plus to do this. It looks like the coauthor term is created when the post is saved by the coauthors_update_post function that is hooked onto save_post. Looking at that, it seems the actual function that creates the terms for the post is $coauthors->add_coauthors( $post_id, $coauthors ); (where $coauthors is the name of an instance of the CoAuthors_Plus class). If you run that function for each post id in your database that doesn’t already have a coauthor, with $coauthors set to an array containing the user login names of the coauthors you want to assign, that should work.

• This reply was modified 6 years, 8 months ago by Sean Leavey.

Easiest way to check is to load a different theme temporarily and see if it’s still broken.

There may be other queries that have changed in WordPress core since this plugin was written, preventing the extra join from the coauthor terms being searched against. One such instance of a query changing in WordPress already caused the issue I fixed above – maybe there are more.

How confident are you about hacking around the code? If you can get your installation to spit out the content of the queries being modified by Co-Authors Plus, that would be useful to help debug your problem. The error_log function is useful to print stuff to the log file in /wp-content/debug.log. The first places to look would be the values of $where in posts_where_filter, $groupby in posts_groupby_filter and $join in posts_join_filter, immediately before they return their value.

To co-authors-plus.php in the plugin’s directory.

Hi G P,

Append ?author=x to your home page URL, where x is the author ID. Note that this is buggy in the current version of Co-Authors Plus – see my bug report (and solutions).

For reference, this codex page describes the query variables supported by WordPress to retrieve pages regarding different types of post-like objects.

Great – thanks a lot for doing this!

Hi Paul, I just tested your code and it works nicely. Thanks a lot! Your reasoning for wanting to keep the cookie expiry setting is sound and makes sense. We don’t have a policy on session times and nothing on the site is particularly sensitive, so I’ll just set the expiry to a large number of hours.

Do you have an ETA on the next version that will include this capability? Thanks again!

Thanks for looking into this – I’ll test it out tomorrow and let you know how I get on. However, you should know that my intention was not to disable the cookie expiry totally, but rather to avoid modifying what the WordPress default is. On my installation it defaults to 2 weeks, so by disabling the cookie override in the way I implemented it, it really just stops the default 2 week period from being overridden.

Great! I’ve uploaded my version of wpDirAuth.php here: https://gist.github.com/SeanDS/f4fcd57b2719bae9097d5941e8c58d72

All I did was add an additional boolean setting that allows the admin to stop the cookie expiry that the auth_cookie_expiration hook sends to wpDirAuth_cookieExpire from being overriden to 1 hour. I thought about adding an extra setting to allow the admin to set a custom expiry time, but that’s probably beyond the intended scope of this plugin.

I hope this is useful, and makes it into the next version! Cheers.