[Jeremy]

Thanks for the clarification, Rob.. As far as I’m concerned, fix the bug, the functionality makes perfect sense to me! Maybe a note that alerts the user the events are disconnected would help clear up some of the confusion. I’m down with your “make it like google and ical” strategy. Sticking with standards is a good thing!

[Jeremy]

definitely a tricky thing they’re trying to pull off. Good luck!

[Jeremy]

“David, Webotools, Jeremy and anyone else experiencing this: have any of you experienced this same problem in a situation where the Hide from Upcoming Events List feature was not used? If so it would be great to hear about the circumstances so we can build a more complete picture of this.”

(I may be a little late to the party here, but:) We do not use the Hide from Upcoming Events List feature at all, as our upcoming events list in the sidebar widget only shows one particular category.

[Jeremy]

Thanks Jonah I know you’ll work it out. You guys rock.

[Jeremy]

We are on 2.0.9 and are have just identified this bug. Any progress?

Thanks!

[Jeremy]

whoops my meta tag didn’t render.. that should say :

I applied the code posted on gist that adds the tag:
meta name=”robots” content=”noindex”
to my individual pages

[Jeremy]

I’m using version 2.0.7 and am still getting these notices from Google. I applied the code posted on gist that adds the “ to my individual pages. This is indeed showing up in my head but Google is indexing them anyway, because I am still receiving the emails and the Soft 404 errors continue to accrue. Here’s a link to a recently indexed page. http://fromhere.org/events/2012-05-27/ .. I’m wondering if the issue is that the meta tag is showing up at the bottom of the head, instead of near the top? Does anyone know if meta tag placement would cause Google to ignore the tag? Is anyone else who applied this fix still seeing the errors? Maybe changing the priority of the action would help? Any help would be terrific.

Thanks guys, such a great plugin and you have great support..

[Jeremy]

fwiw I am no longer seeing this behavior under 2.0.7 and WP 3.4 – I am not sure exactly where it changed but it is all good now. The events page no longer reports any canonical url, which works just fine. Thanks!

[Jeremy]

Sorry didn’t get a chance to test before, but this is working for me in 2.0.7. Thanks guys!

[Jeremy]

+1 for a fix. Thanks guys!

[Jeremy]

Hi Rob – sorry it took me so long to respond. I updated to 2.0.5 this morning and that reminded me to check on this…

After the update, I deactivated my SEO plugin (where my workaround resides) and resaved the permalinks on my site. I am still seeing a situation where on all of the listings pages, the canonical url reports as the url of the first post on the list, instead of the url of the listings page itself.

Thanks,
Jeremy

[Jeremy]

Hmm, actually, no I have updatd to 2.0.4 and when I deactivate my SEO plugin where I had made the above mods that addressed the canonical bug, I return the former situation where the canonical url is set to the url of the first post in the list. As soon as I turn the SEO plugin back on, the canonical URL switches to the one I had set there.

Maybe the plugin links reported by Will were fixed? From what I see the situation remains the same on my site.

[Jeremy]

I’ve tried this on my site and found the same thing as Seth – the table code works great but the list code removes pagination from the query for some reason. All results instead show on one page. I think for my purposes we’ll be fine without the filter on the list and will only be using it on the table so it’s no issue and I won’t have time to pursue causes but I wanted to throw on some feedback.

Thanks for the code, Jonah!
Jeremy

[Jeremy]

Thanks for the followup, Nick –

I spent a bit of time with this today and have a workaround that involves removing the rel_canonical action from wp_head and replacing it with a custom function that grabs the current url and uses that for the canonical link. Here’s the code:

http://pastebin.com/TTzUue8h

I found that my SEO Plugin ( Infinite SEO by wpmudev ) conflicted with this because it removes the rel_canonical action and replaces it with its own code. So when combined with my code this resulted in two different canonical link tags. This is done in a way without filters or any sort of options, so after fighting with redoing their head function I ended up just adding my code into the plugin file instead of my theme. Obviously this is a bad idea in the long run but it’s got me where I want to be for now. This may or may not be necessary with Yoast’s or another SEO plugin, I only tested with this one.

Interestingly, the current rel_canonical has an return based on an is_singular() test, so apparently your calendar listings pages do not register as archive pages.

Also the rel_canonical function has been reworked by Yoast and others, possibly for inclusion in WP 3.4. The trac thread is here: http://core.trac.wordpress.org/ticket/18660

Thanks,
Jeremy

[Jeremy]

No, I haven’t run Yoast on this site. I am currently running the Infinite SEO plugin. At one point I used All-in-one-SEO.

To isolate I turned off all other plugins besides the two calendar plugins and switched to the default WP theme and still got the same results.

Thanks,
Jeremy

[Author]

Posts