I don't mind this optimisation, although I wonder if this is the most common case. It will probably worsen performance in most cases.

A little off-topic, but are you sure that you want to use strip_slashes? It's a pretty strange function to use in production code.

A little off-topic, but are you sure that you want to use strip_slashes? It's a pretty strange function to use in production code.

You mean stripslashes?

Here is strip_tags which commonly used to check and shortcircuit in anythin HTML parsing related.

I meant strip_tags. It's not wrong to use it, but it is a pretty naive solution. This function doesn't understand HTML and is just a very specific form of a regex. As we all know, HTML cannot be parsed with regex. It works for 99% of what people want it for, but in a product like WordPress, I am not sure if it's the best choice.

After having read the original bug report, I think it may actually work fine for what you want it to do, but whenever I see people use this function, it raises a red flag for me that there probably exists a better solution. What if a plugin adds this HTML formatting to an empty title:

<b>Title: </b>

where the actual title would go after the colon. What if the title is a topic about PHP:

<?php //Blog about writing PHP code

I meant strip_tags. It's not wrong to use it, but it is a pretty naive solution. This function doesn't understand HTML and is just a very specific form of a regex. As we all know, HTML cannot be parsed with regex. It works for 99% of what people want it for, but in a product like WordPress, I am not sure if it's the best choice.

where the actual title would go after the colon. What if the title is a topic about PHP:

Nice catch. I will report it as it definitely should be considered.

Anyway, even if it was a valid use case or legit scenario where tags should be removed, the empty string is certainly the base scenario, so I think that early returning here is a little win, especially for how much allocation is required even for this base case scenario.