smd_wrap: conditionally wrap stuff with tags and labels

Bloke · 2011-12-09 23:56:35

jakob wrote:

formatting numbers.

Good call. You can test it out if you like for now using smd_wrap’s custom ‘form’ transform:

<txp:adi_gps />
<txp:smd_wrap transform="form|wraptest">
   <txp:variable name="num" />
</txp:smd_wrap>

and in Form wraptest:

<txp:php>
echo number_format('{smd_wrap_it}', 2);
</txp:php>

Then just add ?num= to your URL and stuff values in to see the plugin render them to two decimal places. If it works to your satisfaction, let me know and I’ll add it as a transform.

alanfluff · 2011-12-10 00:13:21

YEAH! Thanks again Stef, this plugin (which I hadn’t spotted and luckily my friend Google had, I must be more observant¹) has just saved my bacon.

I was using rss_auto_excerpt in an old site to build the meta description and then moved it to a new shiny server and the rss plugin broke :(

So I knee-jerk-switched it for rvm_substr, great but I was getting HTML in my meta description. And lo and behold, <txp:smd_wrap transform="strip_tags"> was there to save my bacon.

Looking forward to playing with more of the obviously powerful options provided by this plugin!

Thanks again! Cheers, -Alan

¹ If you don’t minds me asking, if I want to stay in the loop with the latest new plugins from you and other top TXPers, where do you suggest I subscribe? A mailer somewhere, an RSS feed somewhere? I have a feeling the answer to this is embarrassingly simple…

Bloke · 2011-12-10 00:18:25

alanfluff wrote:

if I want to stay in the loop with the latest new plugins from you and other top TXPers, where do you suggest I subscribe?

Eventually you’ll be able to do it at textpattern.org. You probably can now actually, I’ve never tried using RSS there. But failing that, I’m pretty sure @textpattern gets updates from textpattern.org when new plugins are released there, though not new versions of old ones unless someone manually tweets about it.

alanfluff · 2011-12-10 00:19:37

Thanks Stef!

maniqui · 2011-12-10 00:45:13

<txp:smd_wrap transform="form|wraptest">

Oh, I totally missed this when I asked for form/txp:yield combo support…
Stef, could you foresee any substantial difference between this transform="form|wraptest" and the form/txp:yield combo?

Bloke · 2011-12-10 01:10:08

maniqui wrote:

any substantial difference between this transform="form|wraptest" and the form/txp:yield combo?

Probably some subtle differences. The ‘form’ transforms can be chained so they’re potentially more powerful than <txp:yield /> which only has one ‘level’. But transforms define things you do to your input data, whereas form/yield/container is stuff upon which transforms are applied. Admittedly the line is blurred a little because yield is data inserted at runtime, but the distinction between the two is probably still relevant. It’ll probably come down to whether the other attributes like trim, prefix and suffix are of use on the input data: they work differently to the trim and add transforms so your intended use may dictate which approach to use.

I would expect there are situations where one is more suited over the other so it’s handy having both available. Quite what those situations are I’m not sure, as that’s down to your level of deviousness at pushing and twisting plugins to do things they’re not explicitly designed to do. And I know you have a lot of that commodity in reserve ;-)

Last edited by Bloke (2011-12-10 01:12:41)

Gocom · 2011-12-10 02:48:27

Bloke wrote:

and in Form wraptest: […] echo number_format('{smd_wrap_it}', 2);

That all good, except that number_format expects floats, not strings. It might be good to cast the value before passing it to number_format() to avoid potential future issues.

Btw Stef, do you have any security measurements in place? To make sure that {smd_wrap_it} tag results in a valid string, or can the tags be used to perform remote code execution attacks? In your example the value comes straight from the URL (or POST data) which is very bad if there is no validation.

As security can be a pain, I would suggest also providing real variables and functions (and TXP tags) that can be used to pass the data to other tags or PHP snippets. When a function or a variable is used in the code, there is no direct issue about remote code execution as there is with the search-and-replace tags (in which content is evaluated with rest of the code).

For example this is securer and doesn’t need any extra validation…

<txp:adi_gps />
<txp:output_form form="wraptest"><txp:variable name="num" /></txp:output_form>

<txp:php>
	echo number_format( (float) yield(), 2);
</txp:php>

…as it uses a function, which then returns the content, instead of the content being there when the code is evaluated. If you look at rah_function’s code you will see that I go extra mile (don’t ask me why I use eval() tho) and Instead of evaluating the code with the user provided content, I use variables. You should do something similar. I think.

Last edited by Gocom (2011-12-10 02:58:50)

Bloke · 2011-12-10 03:38:06

Gocom wrote:

In your example the value comes straight from the URL (or POST data) which is very bad if there is no validation.

It was only a test for jakob to see if number_format worked or not before I went ahead and added it, then found it didn’t work for him. I’d never expect anyone to do that in real life! *shudder*

use variables. You should do something similar. I think.

Thanks for the tip. I’ll look into it.

merz1 · 2011-12-10 09:48:06

[OT] As Alan asked for RSS info sources:

Textpattern RSS firehose: Try TXP Info Sources: Textpattern RSS feeds as dynamic OPML if you need one source for pretty much all TXP info available via RSS.

Last edited by merz1 (2011-12-10 09:49:19)

jakob · 2011-12-11 16:24:37

If it works to your satisfaction, let me know and I’ll add it as a transform

In the end I realised that I needed to trap more ‘inventively bad’ user input such as values with currency symbols, with spaces, with incorrectly used separators etc. for example:

198,000.00
240000
$ 123,457
420.000.00 (e.g. the user inputs with a German-formatted number with “.” as a thousands separator and the third-party software automatically appends the missing “.00” resulting in the same separator for decimals and thousands in the saved database value…)
345.678 €

For this I made an smd_macro entitled scrub_number with the following attributes and defaults:

value
decimals (default = 0)
format (default = 0)
dec_point (default = .)
thousands_sep (default = ,)

Code:

<txp:php>
// vars
$n = '{value}';
$format = '{format}';
$decimals = intval('{decimals}');
$dec_point = '{dec_point}';
$thousands_sep = '{thousands_sep}';
if ($n != '') {
  // remove all chars except numbers but leave commas and dots for the time being
  $n = preg_replace('/[^0-9.,]+/','',$n);
  // strip off any 2-digit decimal point data (comma or dot-separated)
  if ( in_array ( substr($n,-3,1), array (',','.') ) ) { 
    $n = substr($n,0,-3); 
  }
  // strip out any remaining non-digits
  $n = preg_replace('/[^0-9]+/','',$n); 
  if ($format == '1' ) {
   // output a formatted number
    echo number_format ($n, $decimals, $dec_point, $thousands_sep);
  } else {
   // output simple number with decimal places if required 
    echo sprintf('%01.'.$decimals.'f', $n);
  }
}
</txp:php>

I can then use this with <txp:scrub_number value='<txp:variable name="myvar" />' format="1" thousands_sep="." /> to get consistently formatted German-style numbers that are of the form ###.###. I can then use smd_wrap to add currency symbols, square metres or other info as required.

Notes/Questions:

I expect with some regex-ninja one could simplify my code significantly. All recommendations welcome.
smd_macro: Is there a better practice for dealing with curly-brace denoted variables in php code that needs curly-braces in if-statements? php threw errors until I did it this way.
smd_macro: Is there a risk of variable clashes how I’ve done that and if so, what might be a better way of namespacing the variables?
Limitations: I’ve introduced an artificial limitation by stripping off 2-digit decimals. Also it doesn’t currently handle swiss-style number formats with minute/second apostrophes.
smd_wrap: Is it feasible to integrating this kind of more comprehensive number scrubbing and formatting into smd_wrap?

Gocom · 2011-12-11 17:13:23

jakob wrote:

smd_macro: Is there a better practice for dealing with curly-brace denoted variables in php code that needs curly-braces in if-statements? php threw errors until I did it this way.

There really should. It throws out errors as the curly tags are replaced before the code is evaluated. PHP doesn’t see tags, but just some code (the resulting value) it needs to process.

That also means that the snippet is extremely vulnerable to remote code execution attacks. Anyone that can pass a value to <txp:variable name="myvar" /> can execute any PHP code they want, whether it be an intentional attack or an accident. Even just using slashes in the value throws out errors.

smd_macro: Is there a risk of variable clashes how I’ve done that and if so, what might be a better way of namespacing the variables?

If you mean variables in the PHP code, no. All code wrapped with <txp:php> tags is in its own scope (context). <txp:php> is a function that evaluates the code contained inside the tags, and so the code is wrapped inside a function and only affects its own scope. Outside doesn’t care what is inside the tags, and inside doesn’t care what is outside.

If you refer to smd_macros curly tags, those are just search-and-replace tags and can not cause any conflicts.

Last edited by Gocom (2011-12-11 17:21:34)

Bloke · 2011-12-11 17:36:29

jakob wrote:

smd_macro: Is there a better practice for dealing with curly-brace denoted variables in php code that needs curly-braces in if-statements?

Not yet. 98% of the use cases I assumed would be to plug the variables into existing plugins or tags: that is, combining tags into a super-tag. Thus most of the time the destination plugin or tag would handle validation, error conditions and sanitization on your behalf.

If you’re wrinting PHP in a macro then Gocom is right: validation is your responsibility. I should probably mention that in the docs! In this case you could probably get away with:

$format = doSlash('{format}');

for a bit more safety. Not really thought it through.

smd_macro: Is there a risk of variable clashes

As Gocom says, if you’re not defining ot using global variables then you’re safe as everything executes in local scope.

smd_wrap: Is it feasible to integrating this kind of more comprehensive number scrubbing and formatting into smd_wrap?

I don’t think so at the moment because it doesn’t support arbitrary variable insertion/replacement into functions. You might be able to do it by chaining forms and using <txp:yield />, nesting smd_wrap to split + sanitize multi-variables injected into yield from the container, but by the time you’ve figured that out you might as well have used smd_macro, some rah_functions or just plain PHP!

Last edited by Bloke (2011-12-11 17:37:14)

Textpattern CMS

Textpattern CMS support forum

#25 2011-12-09 23:56:35

Re: smd_wrap: conditionally wrap stuff with tags and labels

#26 2011-12-10 00:13:21

Re: smd_wrap: conditionally wrap stuff with tags and labels

#27 2011-12-10 00:18:25

Re: smd_wrap: conditionally wrap stuff with tags and labels

#28 2011-12-10 00:19:37

Re: smd_wrap: conditionally wrap stuff with tags and labels

#29 2011-12-10 00:45:13

Re: smd_wrap: conditionally wrap stuff with tags and labels

#30 2011-12-10 01:10:08

Re: smd_wrap: conditionally wrap stuff with tags and labels

#31 2011-12-10 02:48:27

Re: smd_wrap: conditionally wrap stuff with tags and labels

#32 2011-12-10 03:38:06

Re: smd_wrap: conditionally wrap stuff with tags and labels

#33 2011-12-10 09:48:06

Re: smd_wrap: conditionally wrap stuff with tags and labels

#34 2011-12-11 16:24:37

Re: smd_wrap: conditionally wrap stuff with tags and labels

#35 2011-12-11 17:13:23

Re: smd_wrap: conditionally wrap stuff with tags and labels

#36 2011-12-11 17:36:29

Re: smd_wrap: conditionally wrap stuff with tags and labels

Board footer