![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 10 years ago
Last modified 7 years ago
#35545 new defect (bug)
Unexpected behavior of wp.shortcode.regexp
| Reported by: | TobiasHoessl | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Shortcodes | Version: | 4.4.1 |
| Severity: | normal | Keywords: | |
| Cc: | Focuses: |
Description
Using the _.memoize-Function for wp.shortcode.regexp (defined in /wp-includes/js/shortcode.js) leads to somewhat surprising behavior of the returned Regexp-Object:
> wp.shortcode.regexp("foo").exec("[foo]bar[/foo]")
-> ["[foo]bar[/foo]", "", "foo", "", undefined, "bar", "[/foo]", ""]
> wp.shortcode.regexp("foo").exec("[foo]bar[/foo]")
-> null
> wp.shortcode.regexp("foo").exec("[foo]bar[/foo]")
-> ["[foo]bar[/foo]", "", "foo", "", undefined, "bar", "[/foo]", ""]
> wp.shortcode.regexp("foo").exec("[foo]bar[/foo]")
-> null
...
I would expect the call to return the same result every time and not "null" every second time. This happens because the Regexp-Object is recycled and Regexp just seems to behave this way. However when using wp.shortcode.regexp-Function without knowing the internal behavior of the Regexp-Object, this comes rather surprising. Maybe not caching this object might be a better choice here.
For example, the Shortcode-UI-Plugin (https://wordpress.org/plugins/shortcodes-ui/) seems to have a problem because of this.
Note:
See TracTickets
for help on using tickets.
