WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 9 months ago

#20077 closed defect (bug) (wontfix)

shortcode_parse_atts should not force arguments to be lowercase

Reported by: fireproofsocks Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Shortcodes Keywords: close
Focuses: Cc:

Description

Inside wp-includes/shortcodes.php, the shortcode_parse_atts() function forces shortcode arguments to be lowercase. So if your shotcode had something like [my_shortcode MyVar=123], then your code that uses something like "print $MyVar;" fails... you have to use "$myvar" instead. This is counter-intuitive. I understand that there needs to be some restrictions on what is a valid parameter name (see http://core.trac.wordpress.org/ticket/9405), but I think it makes the most sense that the parameter names can correspond to any valid PHP variable name; PHP variables ARE case-sensitive, so this arbitrary restriction of forcing lower-case parameters seems like the incorrect approach.

Change History (9)

comment:1 in reply to: ↑ description ; follow-ups: azaozz2 years ago

  • Keywords close added

Replying to fireproofsocks:

... PHP variables ARE case-sensitive, so this arbitrary restriction of forcing lower-case parameters seems like the incorrect approach.

Right, however shortcodes do resemble HTML tags and are used inside the HTML. All tag properties/attributes in WordPress are lower case.

This is rather a coding standards question. Been thinking we should define a "WP variable" standard and use and enforce it whenever possible. Things like CPT names, CSS class names (when handled by an API), and any other variable string that is passed to an API should conform to some basic rules. That would make all of them much easier to escape, clean, sanitize, etc.

comment:2 in reply to: ↑ 1 mikeschinkel2 years ago

  • Cc mikeschinkel@… added

Replying to azaozz:

This is rather a coding standards question. Been thinking we should define a "WP variable" standard and use and enforce it whenever possible. Things like CPT names, CSS class names (when handled by an API), and any other variable string that is passed to an API should conform to some basic rules. That would make all of them much easier to escape, clean, sanitize, etc.

+1 to that.

comment:3 in reply to: ↑ 1 GaryJ2 years ago

Replying to azaozz:

This is rather a coding standards question. Been thinking we should define a "WP variable" standard and use and enforce it whenever possible.

http://codex.wordpress.org/WordPress_Coding_Standards#Naming_Conventions

comment:4 follow-up: fireproofsocks2 years ago

Re coding standards, fair enough... consider the following: should standards be strictly or loosely enforced? post-type names often correspond to filenames and URLs, which MAY be case-sensitive depending on the server. Variable names and their limitations is a PHP convention, however.

comment:5 in reply to: ↑ 4 azaozz2 years ago

Replying to GaryJ:

http://codex.wordpress.org/WordPress_Coding_Standards#Naming_Conventions

Right, something like that but for variable strings used as names or IDs in the different APIs.

Replying to fireproofsocks:

...should standards be strictly or loosely enforced?

Don't think we can enforce anything for the currently used names/IDs. Many already have some sort of sanitization or restrictions anyways.

It's probably better to discuss this on wpdevel. Thinking we could go with something like [a-z0-9_-]+ that would keep everything nicely readable and very easy to sanitize for inclusion in HTML, etc.

comment:6 fireproofsocks2 years ago

My recommendation here is to allow parameter names to use anything that's a viable PHP variable name. That just makes sense in this case, similar to using extract(). From the PHP docs:

"A valid variable name starts with a letter or underscore, followed by any number of letters, numbers, or underscores. As a regular expression, it would be expressed thus: '[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*'"

http://php.net/manual/en/language.variables.basics.php

comment:7 DrewAPicture9 months ago

  • Cc xoodrew@… added

comment:8 SergeyBiryukov9 months ago

  • Component changed from General to Shortcodes

comment:9 nacin9 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

A viable PHP variable name is basically *anything*, including emoji. So, no. I absolutely think that HTML is what shortcodes should follow (they are, after all, modeled a bit after it and are part of the content), not PHP.

Also, this change could potentially break a ton of content that accidentally uses uppercase letters (but the code works fine).

Note: See TracTickets for help on using tickets.