Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#48035 closed enhancement (wontfix)

Extra security against warning error for shortcodes

Reported by: ignatiusjeroe's profile ignatiusjeroe Owned by:
Milestone: Priority: normal
Severity: minor Version: 5.2.3
Component: Shortcodes Keywords:
Focuses: Cc:

Description (last modified by SergeyBiryukov)

Function 'shortcode_regex( $tagnames = null )' expects an array. But if the users enters a string it triggers an php warning error. It's would be better to just type set the parameter to an array. For example:

function get_shortcode_regex( $tagnames = null ) {
	global $shortcode_tags;
	$tagnames = (array) $tagnames; // string typeset to an array. Alternate version: settype( $tagname, 'array' );
	if ( empty( $tagnames ) ) {
//....more core code 

source: includes/shortcodes.php

Change History (2)

#1 in reply to: ↑ description @johnbillion
5 years ago

  • Keywords close added

Thanks for the report @ignatiusjeroe !

Replying to ignatiusjeroe:

if the users enters a string it triggers an php warning error.

I think this is expected behaviour. This function expects this parameter to be an array and anything else is unexpected.

PHP warnings exist for a reason, to inform the user that their code isn't behaving as expected. Warnings shouldn't be avoided just because they can. I think a warning here is appropriate.

#2 @SergeyBiryukov
5 years ago

  • Description modified (diff)
  • Keywords close removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Hi there, welcome to WordPress Trac! Thanks for the ticket.

I agree with the comment above.

This looks similar to the discussions in #17299, #18927, #23767, and #27489 (those tickets are unrelated to this particular function, but they suggest a similar enhancement for other functions). The consensus was that we should not hide warnings caused by developer errors, unless there is a strong reason. It would just make debugging harder.

If a valid parameter generates a warning, we should certainly fix that. However, in case of an invalid parameter, I think the warning is to be expected.

Note: See TracTickets for help on using tickets.