sunamumaya

Cheers, thanks for fixing it!

give me an admin account on your site for further checking

No, can’t do.

I posted right after Otto, so I guess the relevancy of my previous post is now less.

I think Otto has made the right call.

It’s more than that. Users have a specific problem or task, and they search for a plugin to solve that problem or perform that task, and since we’re all busy, we rely on others reviews and author’s good faith.

To me, this is not good faith. Your plugin should have in bold, in Installation instructions, “IMPORTANT: This plugin requires you to download an additional, non-open source software, under a different license.” What about commercial use in heavy-traffic, high income sites that come to be dependent on code they do not own or control, for example? There are bothersome legal implications that could arise.

In addition to no being fair to the users, it’s also not fair to the other plugin authors. I skipped a few plugins and downloaded yours because it seemed the best for my needs, completely unaware of these issues. Had I known, I could have simply tried out other plugins instead (which I ultimately did).

Nothing against making a buck, you could simply create a premium plugin and say so, and sell that library or whatever. But the current situation remains dubious, I’m afraid, and it needs to be remedied. Fortunately, it would appear that the solution is as simple as forewarning users very strongly and clearly about what’s going on, before they download your plugin, so that they do so in fully aware of the implications.

The more I work with the plugin, the more I realize the necessity of having some sort of meta field for references, commentary, explanations, for each individual answer. The “Hint” field is not enough.

Working with the example above, we could have a brief explanation of why the question was formulated as it was, and why each answer is correct or incorrect, along with the references.

If this is not too much please implement it, it would be very, very useful.

Rachel,

that is checked, but still not enabling Co-Authors Plus (CAP). It does ensure the Author drop-down appears in the back-end, but CAP isn’t enabled.

Let me take this opportunity to thank you for your brilliant work with CPT-onomies, though! One of the best plugins out there.

Please let me know if you have any other ideas, although I think this is a CAP issue, not a CPT-onomies thing.

Cheers!

I don’t know how to do that…

I’m using the CPT-onomies plugin, and I do have the “Guest Authors” in the “Attach to Post Types” configuration settings, but it does not do it.

Any other ideas?

Anyone?

This is pretty important, since not excluding the co-authored posts from author archive pages may result in a lot of duplication (same post shows in main archive, and in all co-authors’ author archives; if you have three co-authors for an article, that’s four places where that article shows up).

I have managed to use a pre_get_posts filter used exclusively on the author archive pages, using a taxonomy query like this:

`$tax_query = array(
array(
‘taxonomy’ => ‘author’,
‘field’ => ‘name’,
‘terms’ => $query->query_vars[‘author_name’] ,
‘operator’ => ‘NOT IN’
)
);`

This trick basically makes sure the current author is not among the co-authors of their own articles, which should be true for all articles that are not co-authored, if the ‘author’ taxonomy is not set AT ALL for those articles.

Trouble is, the plugin seems to set the ‘author’ taxonomy for all new single-author articles anyway, even if they are not co-authored. This renders the above solution useless.

Any other ideas?

Can you tell me how?

I have created a custom post type, and when I edit it, the Co-Authors interface does not show up, there’s only the normal author select list.

Thank you, I’ll be watching this thread intently.

Also, it would really help to be able to do this check in queries, e.g. to exclude co-authored posts from author template pages.

It’s not your fault, it’s this rather poorly written plugin.

Your issue can be solved like this (assumes you can edit PHP, and you have the latest version of the plugin):

1. Open wp-content/plugins/wordpress-seo/frontent/class-frontend.php

2. Go to line 582, it should look like this:

( is_home() && get_query_var( 'paged' ) > 1 )

3. Select the entire line 582, and replace it with

( is_home() && get_query_var( 'paged' ) > 1 && ( isset( $this->options['noindex-subpages'] ) && $this->options['noindex-subpages'] ))

EXACTLY as it I put it here.

This will fix your problem. I basically added the check for the noindex-subpages option (the “No index subpages of archives” tick box in your screenshot). Without this check, the plugin treats your “home” archive outside the normal rule for archives controlled by that tickbox.

IMO this is a very, very serious bug, as it literally hides your main post archive from search engines, behind your back, and this is done by a SEO optimization plugin…

Good luck, let us know.

You mean 5.0.35.0, I think ??

I upgraded, then tested it, and it works well now, no AEC links in feed.

Thanks for the fix!

I’ll rate and review now.

Errata: links appear not only for editors, but for all visitors, IP-based, just as they would on the site itself, but without a time limit.

Please see this screenshot illustrating the issue:

https://i.imgur.com/OzJ0utQ.png

Thanks for looking into this!