Aahan Krish

where did you read about that?

Like I said, “which is what keywords in general are meant for”.

Now, I could argue that terms used by The Guardian (like Liberal Democrats, Politics, UK news, European elections… but I’ve not looked at them all!) are mostly in that same spirit…

W.r.t the emphasized text, yes, you are right. Here, I have a bad example for you:

<news:keywords>
  Dawn of the Planet of the Apes, Andy Serkis, Science fiction and fantasy, Action and adventure, Film, Culture
</news:keywords>

See, I am trying to be realistic about the implementation of this feature. I understand you want to keep it simple. But separating news_keywords meta tag and <news:keywords> sitemap tag by providing two separate meta boxes will only confuse people more.

OTOH, using categories or tags alone to simply things is useless. I’d leave the choice to the users with a note and links to the two docs we’ve constantly been referring each other to; but I’m not the developer. ??

Three checkboxes instead of a dropdown and the choice is left to the user:

- Categories
- Tags
- Author-defined keywords (from Custom Field)

If you still don’t agree with my point, it’s fine by me. I’ll hack through the plugin’s code and implement this for myself (I am not good with code but I can get stuff done ?? ). I just want to know your stand on this.

… and not add too much more options which only confuse and divert. Unless absolutely necessary of course ??

First, please make note of my previous post.

If you ask me, yes, keywords are very important for sites accepted into Google News, and it is a necessary confusion, if at all it’s one.

From what I know and read, the news_keywords meta tag helps Google show your article for relevant searches while the <news:keywords> sitemap tag is meant more for organizing your content among Google News categories AND to aid Google in showing your article for relevant searches (which is what keywords in general are meant for). Which is why I am stressing my point again and again.

Now that we agree about news_keywords meta tag, let me try to convince you about the <news:keywords> tag. ??

(You probably missed my earlier post, so here it goes again, with some minute changes.)

If the <news:keywords> sitemap tag is not meant to be as outright as the news_keywords meta tag in defining keywords relevant to the article, why should they be the same?

Well, because it’d be a lot of work for news organizations to spend time adding two different sets of keywords for each article when they should be spending time on writing quality content.

For examples, you can also take a look at:

– https://mashable.com/sitemap-news.xml
– https://www.theguardian.com/newssitemap.xml

None of these top news sites adhere to your policy of intended usage. They are just keywords, no different.

I think when you are a Google News publisher, you are somewhat better trusted, and those thin lines don’t matter.

(Continued…) Now, you may ask me, if the <news:keywords> sitemap tag is not meant to be as outright as the news_keywords meta tag, why should they be the same?

Well, because it’d be a lot of work for news organizations to spend time adding two different sets of keywords for each article when they should be spending time on writing quality content.

You can also take a look at: https://mashable.com/sitemap-news.xml

I think when you are a Google News publisher, you are somewhat better trusted, and those thin lines don’t matter.

Hi Rolf,

I think you are considering that both <news:keywords> and news_keywords are meant for the same purpose. That’s not true.

The <news:keywords> tag in the news sitemap is actually different from the news_keywords meta tag.

The meta tag is actually meant for keyword induction to help Google classify your content when the keywords within the content of the article can’t do it well enough. I’d like to direct you to this Google News help document: https://support.google.com/news/publisher/answer/68297?hl=en

Also, there’s a limit on the meta tag:

You can add up to ten phrases for a given article, and all keywords are given equal value.

So, what you said is more true for the <news:keywords> sitemap tag, rather than the news_keywords meta tag. BUT…

As said in the document you yourself linked to:

You may use other keywords not listed here; we recommend using English if possible.

Therefore, we can deduce that both news_keywords meta tag and <news:keywords> sitemap tag can be the same given that you are enforcing a combined limit of 10 keywords.

Let me know what you think now.

EDITED: Will create a new topic instead, as this is already marked as resolved.

Arrgh! I didn’t realize that yesterday as I was already logged-in. When I tried to login today, I got this error:

ERROR: Cookies are blocked or not supported by your browser. You must enable cookies to use WordPress.

Once I installed WordPress MU Domain Mapping plugin and set things back up, everything’s back to normal. Puff!

Thank you, Ron. ??

One of the differences is that WP.com Markdown is per-site rather than per-post, which in that case should eliminate the bug you’re describing.

Actually the issue persists on WordPress.com, which is why I was kinda worried.

If you have any other bugs where the Markdown content is deleted, please describe in detail.

I thought you were aware of this, which is why the lack of much detail.

Anyway, I noticed that the markdown content stored in post_content_filtered gets deleted (i.e. when you edit a post you see HTML instead of Markdown) when:

• you make changes to a post (title, tags, categories, etc.) using the ‘Quick Edit’ option in the All Posts listing screen (edit.php?)
• you do bulk edits to posts
• you switch between revisions of a post
• a scheduled post is (automatically) published
• a post is saved from an external editor (i.e. not the WordPress post editor)

These are the cases I noticed, and there may be more, which is why I think post_content_filtered is a bad place to store Markdown content which we want to be available at all times.

I can’t guarantee that I’ll fix anything, since this plugin will be deprecated in favour of Jetpack Markdown.

Will be waiting, thank you! ??

Related: https://wordpress.stackexchange.com/q/113387/10691

No. That’s not a typo.

$get_cat_dynamically = 'random';

// Now this:
$query->set( 'category_name', $get_cat_dynamically.', featured' );
// OR this:
$query->set( "category_name", "{$get_cat_dynamically}, featured" );

// Is equivalent to:
$query->set( 'category_name', 'random'.', featured' );

// Which in turn is equivalent to:
$query->set( 'category_name', 'random, featured' );

The period is being used to concatenate the strings.

So for your first example, basically I was doing ‘cat1’, ‘cat2’, where as I needed one string that would be parsed, such as ‘cat1, cat2’. Did I get that right?

Yes. You need to have multiple category slugs in one string, and not each in their own.

As for the second dynamic example, the syntax is confusing to me…

A small correction, and a better example:

// Say... (just to show how a variable can be used; you might know this already)
$get_cat_dynamically = 'random';

$query->set( 'category_name', $get_cat_dynamically.', featured' );

Is this better?

Hey, just a heads up. Answer here: https://www.ads-software.com/support/topic/show-posts-from-multiple-categories-1?replies=3#post-4910968

Had the same issue today, and here’s how it should be done:

$query->set( 'category_name', 'random, featured' );

That’s right. As you can see here, the category parameter category_name, takes only a string. So you need to put the category slugs in one string.

And if you are using a variable, here’s how it’d be done:

$query->set( "category_name", "{$get_cat_dynamically}, featured" );

NOTE: The double quotes are important in the second case.

Well, do you know any work around Matt? I tried in vain.

Short answer, Yes, the comments are recognized by both Google and Bing.

1. As the plugin’s description says, the “Initial development of this plugin was commissioned by Google”.

2. Read this post about the plugin by Mark Jaquith:

The comments on this post are loaded asynchronously with an XHR (known to laymen as “AJAX”) from the server. This makes the initial HTTP GET for the page much faster, and delivers a better user experience for pages with large numbers of comments.

If you use a newer browser (like Safari, Chrome, or Firefox 4), when you click on the previous/next comment navigation links those comments will also be fetched using an XHR. The rest of the page, which doesn’t change, doesn’t have to be downloaded again. Look at the URL as you change pages — it updates to reflect the page you’re viewing! After navigating through comments pages asynchronously, try using the “Back” button on your browser. You will have distinct history states for each comments page, using new HTML 5 window.history.pushState(), window.history.replaceState() and window.onpopstate functionality.

No changes have been made to this theme or to the WordPress core. This plugin functions entirely by using the WordPress hooks system, and it should work with any theme that uses the standard comments template functions.

Without this plugin active, this page’s HTTP GET (uncompressed) is approximately 186.3 KB. With the plugin active, it is approximately 10.8 KB.

The onload event for this page fires 2x faster. The HTML is generated by the server 6x faster. The HTML downloads 3x faster.

– Also, I see that the timestamps in Google’s own sitemaps use their timezone i.e not UTC. Is there any reason why WP SEO sitemaps doesn’t respect my WordPress site’s timezone settings?

Hope this gets Joost’s attention — I see that he’s active right now ??