Fix non-existent snippet tags being broken up by an @ tag #16322
Conversation
… adding tests for property set tags
| ], | ||
| [ | ||
| 'This is a [[snippetName@propSetName:default=`default value`]]', | ||
| 'This is a default value', |
There was a problem hiding this comment.
This is the test that's failing. The snippet returns the value of the prop property, which doesn't exist in this scenario, so the snippet returns an empty value. That should make it return the default filter, but instead it returns nothing at all (This is a ).
Can reproduce the same behavior when creating things manually on a template/resource, so that suggests something is broken?
There was a problem hiding this comment.
There is a chance this may've been related to #16337, so will need to test again.
|
@Mark-H is this still in a draft state? |
|
Yes, I was hoping for some help trying to figure out the failing test but didn't get any. |
Fixes issue with default value not working when prop set is specified in an Element call
| if (strpos($tagName, '@') !== false) { | ||
| $split = xPDO:: escSplit('@', $tagName); | ||
| $psName = $split[1]; | ||
| $this->set('name', $split[0] . $remainingTag); |
There was a problem hiding this comment.
Note that this is where the issue lies (same goes in the modTag file L520). Here, when modifiers are present, you end up with snippetNamedefault=`default val` instead of snippetName:default=`default val` (note the colon missing in the former) when setting the name on the Element.
There was a problem hiding this comment.
A couple other things:
- I made my own submission for this (Follow up to 16322: Fix non-existent snippet tags being broken up by an @ tag #16682) only because it was easier to do, particularly because I wanted to make sure whatever I came up with passed on the latest 3.1 dev branch and I've been having issues getting the unit tests to run on my local dev install.
- I refactored how the two parts of the tag are broken up (using substr approach instead of explode/implode), as it seemed easier to see what was happening.
What does it do?
Described in #16318, if a non-existent snippet tag is found within an output filter, an @ tag inside the filter can cause the output to break.
The provided example where
xxxdoesn't exist:is getting broken up by modTag/modElement::getPropertySet on the
@, treating the part in front of it as the name of the tag/element, including half the snippet tag.This fix makes sure that it only considers the bit up to the first
:.To ensure property sets continue to work, I wanted to add some property set tests but I can't get this structure:
to return anything when the snippet returns an empty value. If someone can figure out why that's not working (in either the test or real world cases!) that would be great.
Why is it needed?
Make parser more resilient.
How to test
Unit tests or create your own similar test cases with snippets on a resource.
Related issue(s)/PR(s)
Fixes #16318