Make Content Copy exports comply with Drupal coding standards (and Coder module) [#555008]

The PHP code exported by the Content Copy module does not follow Drupal coding standards (http://drupal.org/node/318). This causes the Coder module to give hundreds of warnings if this code is put in a file and used to programmatically create content types in a module. There are just three issues as far as I can tell:
1. Uppercase not used for PHP constants (e.g., NULL, TRUE, FALSE)
2. A space separates "array" and "(".
3. Some lines have trailing spaces.

This is just how PHP's var_export() outputs things. I would like to see a brief post-processing step that changes this code to comply with Drupal standards. It should be simple to do with regexes.

Alternatively, the few users who care about this could just perform the post-processing themselves, but this is a hassle to do after every export and I see no drawback to outputting the code directly to a Drupal standard form.

Comments

Comment #1

markus_petrux commented 21 August 2009 at 08:41

I think there should be something external to CCK that CCK can reuse use to beautify the code. Otherwise, this kind of processing would be duplicated somewhere else for sure.

Comment #2

markus_petrux commented 21 August 2009 at 22:30

Status:

Active

» Postponed

Comment #3

threexk commented 22 August 2009 at 02:40

markus_petrux: That seems reasonable. I thought this would just need to be three simple regular expressions, but it's more complicated than that to do it robustly. You have to make sure PHP keywords aren't actually just text within strings, and I think there's also the possibility for PHP code embedded as strings (Computed Field module) that you wouldn't want to touch, etc.

The Coder module has a coder_format.php script to automatically reformat code. It doesn't correct the first two formatting issues I mentioned above, as far as I can tell. If it eventually provided functions to do so, Content Copy could use them--if the Coder module is installed--to reformat its output. (Or, it could just run the whole coder_format.php script on the output.)

Then again that would probably be too much trouble for the small benefit in a narrow use case: using a Content Copy export as code to programmatically create CCK content types in a module.