Hack: allow relative filepath for custom scripts

[maniqui]

Hi. I've already published this at TXP forum: http://forum.textpattern.com/viewtopic.php?pid=243670#p243670

// evals a PHP script and displays output right under the custom field label
function glz_custom_script($script, $custom, $custom_id, $custom_value) {
// hack starts
 global $prefs;
  // test if $script is an absolute path (i.e. /home/path/to/script/).
  $abs_path = strcmp(substr($script, 0, 1),'/') === 0 ? true : false;
  // if it's not an absolute path, then it's a relative path (i.e. just the script name, 
  if (!$abs_path) {
    // then, recreate the full path by appending the value of custom_scripts_path (i.e. /
    $script = rtrim($prefs['custom_scripts_path'],'/') . '/' . $script;
  }
// hack ends
  if ( is_file($script) ) {
    include_once($script);
    $custom_function = basename($script, ".php");
 ...

Look for the correct line (the one defining glz_custom_script function) and edit the first line so the code lookslike the above snippet.

This mod will let you use both relative or full path when specifyng the filesystem path to a glz_custom_field custom script. So you could put just the custom script name, like “my_image.php” instead of the full path (”/home/path/to/my_image.php”), making it easier to deploy or share a DB with other dev.

Gerhard, do you think it could be possible to pass the custom field’s name to the custom script function? I mean, as now, that you pass the $custom_id and/or $custom_value. Having the custom field name would open the possibility to write more reusable custom scripts .

[gerhard]

Thanks for this Maniqui, I'll be including this in v1.2.5. This very patch prompted a new release, I was convinced that there will be no more v1.x releases. Thanks!

[maniqui]

You are welcome, Gerhard. Please, double check the hack, as I'm not a PHP expert (not even a noob!) and who knows if I didn't introduce any bug or security issue :) The hack is pretty simple, so I doubt I have gone too wrong with the code.

BTW, it takes advantage of the already existing custom_scripts_path preference, which is defined by your plugin, but afaik, it wasn't ever implemented anywhere for real usage.

[gerhard]

Of course I'm going to double-check everything : ).

If only more people had your attitude, it would be bliss. Even if you you're not a PHP expert (your words), you took a stab at it, and I think that's just amazing.

[gerhard]

Sorry for the super long absence, I'm endlessly caught in other things as I'm sure you could already tell.

I'm slowly getting back into glz_custom_fields, this issue is top of my priorities.

On the passing the custom field's name to the custom function issue, I'm already passing the custom_1, custom_2 etc. Is that not enough to get the custom field name? I could add a helper to do the mapping, it would be trivial.

I want to pass as few values as possible into the functions, most of them look super ugly as it is, anything over 3 values just doesn't feel right.

[maniqui]

Hi gerhard.

As you suggest, having the custom_n may be enough to get the corresponding custom field name. I can't recall exactly on which context/idea/mood/time I asked for this feature. I think my idea was something along this lines: to let end user create some "rich" custom fields on the fly, by following some naming conventions (decided by the developer). For example, if the user created a custom field named "cat_music" and specified an hypothetical "category_listing.php" custom field script, it would automagically create a dropdown (or whatever) with all the subcategories on "Music" category. Or some other crazy thing. In other words, 'clever' (ie. pre-defined, pre-agreed) naming of custom fields will let the developer "parse" the custom field name, and do something with that info, allowing the user to create new "scripted" custom fields that will list stuff on TXP database (like categories, or list of articles from a particular category, or who knows what else).

Sorry for the late reply.