Support for the PHP syntax in patterns! Patch. Also some UI doc, a fix for DB prefix, and the user permissions pattern

I'm guessing it should go something like this:

///////////////////////////////////////
// Create a dummy page
///////////////////////////////////////

$pattern = array(
 'info' => array(
    'title'   => 'Set up template contact page',
    'description' => 'Set up template contact page',
    'author'  => 'dman',
    'author_email' => 'dan@coders.co.nz',
    'version'  => '0.1',
    'category' => 'Examples',
    'core'     => '6.x',

  ),
  'modules' => array(
    'node',
  ),
  'actions' => array(
    // Actions is an array of smaller acts
    array(
      'tag'     => 'node', // 'tag'?
      'type'    => 'page',
      'title'   => 'Contact Us',
      'body'    => 'Put your contact details here',
    ),
  ),
);

.. and a bit of psychic coding gave me:

/**
 * Read and evaluate a php file to return a 'pattern'
 */
function patterns_load_php($path, $local = TRUE) {
  if ($local && !file_exists($path)) {
    return FALSE;
  }
  $pattern = array();

  if (!$php = file_get_contents($path)) {
    trigger_error("Failed to read PHP pattern file $path", E_USER_WARNING);
    return FALSE;
  }

  eval($php);
  // That should have declared a 'pattern' into current scope.

  if (!patterns_validate_pattern($pattern)) {
    trigger_error("Failed to evaluate a useful pattern from the input file $path. Pattern did not validate. May have been invalid syntax. ", E_USER_WARNING);
    return FALSE;
  }
  return $pattern;
}

Am I right?

Sorry for putting three things in one patch, but I didn't get any response to the first one, so needed to keep things moving forward.

OK.

1. Support for PHP patterns! Works well for me. You can convert from either scripts recorded by macro.module, or by inspection of $_POST pretty easy. I've attached a sample from my experimental suite of setup actions.
   This involved touching a few places to ensure that *.php files could be used the same as *.xml files. Does not yet save in php, but does read it.
2. Also, some UI help to make patterns more intuative to first-timers. On the patterns screen, I've used hook_help to tell me the search paths eg:
   

   Patterns will be looked for in files under the following locations:
   * sites/prototype.kiwischools_2009.gadget/files/patterns
   * sites/prototype.kiwischools_2009.gadget/patterns
   * profiles/kiwischools/patterns
   * sites/all/patterns
   * sites/all/modules/kiwischools-admin/patterns/patterns

   (This involved a tiny refactoring of patterns_get_patterns() to abstract the search algorithm into a smaller function)

3. Patterns was currently NOT DATABASE-PREFIX safe, in the place where it did db_query('SHOW TABLES LIKE "cache_%"'); and it threw errors when I tried on a prefixed site that had a different set of tables than the 'default' site.
   A small fix for this is attached.

   function patterns_execute_action($form_id, &$form_state, $params) {
     // Make sure we always have a clear cache for everything
     // Beware - this direct database access needs to be db-prefix-safe!
     global $db_prefix;
     $result = db_query('SHOW TABLES LIKE "{cache}_%"');
   
     while ($table = db_fetch_array($result)) {
       // Remove the db prefix if any. cache_clear_all() will put it back again.
       $table = substr(current($table), strlen($db_prefix));
       cache_clear_all(null, $table);
     }
   ...
   

4. I got PHP warnings from user_patterns()

               $data[$data['rid']] = array_merge($perms, $data[$data['rid']]);
   

   when 'rid' was not an array. The code indicates that 'rid' is never expected to be an array, so I cast it into one to suppress the error. You'd only see it if running PHP_STRICT warnings - which I do.

Cool, thanks.
I'm doing a bit of intensive cookie-cutter-site install-profile wizarding this week, so more tweaks may be forthcoming. I may even experiment with 'publishing' patterns...
The next one I need to do is one that auto-configures FCK Editor the way I want it ...
... after the one that creates a handful of boilerplate pages and content types...

Good fun, but slow going for me.

Well, there certainly is a potential security issue with PHP evaluation anywhere.
I once cracked a system that had inadvertently left cck import open :-)

OTOH, I am really not in favor of Yet Another configuration language, when clearly a PHP array is as obvious, flexible, dynamic, portable and powerful enough for any set of configs I need.

So yeah, the thing to do is tie the ability to use eval() to the php filter permission, or something like that.
I guess you can embed ?php? tags directly into XML ... and have the processor eval them on the fly? ... Nah, I want to be able to use the full power, maybe a foreach. "A pattern that creates a node for each registered user". I'm treating patterns as bundled PHP 'snippets' that perform admin actions I guess...

Ah.
I've not worked with shared tables and prefix arrays yet. Must remember to consider those.
I don't know if there is a quick fix, could be tricky.