Output filter to get only last two characters

General
1

I am working on a chunk for use by snippets and am wondering if I can use filters rather than the snippet to get only the last two characters of the value sent to the chunk.

The top one is the desired output, the bottom one the fantasy idea. The tabyear value is currently generated by the snippet and could be just 2027 or a longer 2026 - 2027. The single version is easy enough to do using strtotime filter [[+tabyear:strtotime:date=`%y`]]. The double year is the challenge.

<input type="radio" name="tabs" id="tab27">
  <label for="tab27" class="yearlabel">2026-2027</label>
  <table id="yr27" class="departures tbl">


<input type="radio" name="tabs" id="tab[[+tabyear:lasttwodigits]]">
  <label for="tab[[+tabyear:lasttwodigits]]" class="yearlabel">[[+tabyear]]</label>
  <table id="yr[[+tabyear:lasttwodigits]]" class="departures tbl">

I know I can just add a bit more coding to the snippet and send an additional value. But I am wondering if MODX had an auto-magical way to do this with filters at the chunk.

2

Maybe this helps?

[[+tabyear:reverse:limit=`2`:reverse]]
3

Or you could just create your own custom output modifier:

Also, the built-in reverse modifier behaves quite weird, if there are digits in the string:

1 Like
4

Sounds like it will be easier to modify the main snippet to produce that value, since there doesn’t seem to be a quick and easier filter.

Thanks for the suggestions.

5

I could have sworn that there was an output modifier for substr but it looks like there’s not. Seems like a useful one to add.

6

Actually it turns out PHP’s built in substr choked on our 2026–2027 case, due to the en dash used. So any MODX filter would likely have choked in similar fashion. We ended up getting the last two digits before combining the years into the final string.

7

There exist Multibyte String Functions (with the prefix mb_ → mb_substr in this case), that you can use (and are indeed used in MODX if the setting use_multibyte is set to Yes).

8

I tried the mb_substr, which also seemed to have issues, again I assume likely due the en dash, and ended up grabbing the last two before we combined the dates for display on the webpage.