PHP or Tokens in markup field?

Thanks! This is a really useful feature. You just save me the trouble to figure it out myself.

I wish this to be in the next module release!

Miguel

It worked like a charm! Thanks!

Is placing this code into the markup field adequate?

<div><?php 

print drupal_render($form['nid']);

?></div>

This does not seem to print out anything.

Thanks,
Rob

Here's the right implementation (can some plz create a patch? My Mac is having CVS issues at the moment):

/**
 * Implementation of hook_field_settings().
 */
function markup_field_settings($op, $field) {
  switch ($op) {
    case 'form':
      $form = array();
      $form['markup'] = array(
        '#type' => 'textarea',
        '#title' => t('Markup'),
        '#default_value' => isset($field['markup']) ? $field['markup'] : '',
        '#required' => TRUE,
        '#rows' => 15,
        '#description' => t('The markup to be displayed. Any HTML is legal here, so be careful not to break your page layout.'),
      );
      $form['instructions'] = array(
        '#type' => 'markup',
        '#value' => htmlentities(t('This is a special field. It will output the markup below, unfiltered by the system, on the node/edit form for this content type. Consider wrapping any visible output in <div class="form-item"></div> to follow form standards.')),
        '#weight' => -1,
      );
      $form['format'] = filter_form($field['format'] ? $field['format'] : FILTER_FORMAT_DEFAULT);
      return $form;

    case 'validate':
      break;

    case 'save':
      return array('markup', 'format');
    case 'database columns':
      return array();
  }
}

/**
 * Implementation of hook_widget().
 */
function markup_widget(&$form, &$form_state, $field, $items, $delta = 0) {
  $element = array(
    '#type' => 'markup',
    '#title' => '',
    '#value' => check_markup($field['markup'], $field['format'], FALSE),
  );
  return $element;
}

OK, here's the patch.

I will be adding this functionality to the module shortly, currently i'm not looking to go the input filter route though, and instead plan to take care of the php evaluation internally as other cck fields tend to do.

I have just committed php functionality into the module. It should appear in the next Dev release, most likely dated the 16th December.

There will now be an 'Allow PHP Code' checkbox under the markup field in the field settings. Currently you can access the current node through the $node object. If any other objects or variables should be accessed in the code, please request here.

Nice work @smoothify!
Thanks!

If you want to evaluate PHP Code for a field, shouldn't you use Computed Field instead? Allowing PHP Code in Markup module suddenly makes this module very dangerous and will force me to re-evaluate who has permissions to edit content types and fields.

cYu, i sincerely dont see how it is dangerous.

If a user has permission to edit Content Types and fields, he can already break your whole site. So i don't see the point...

Computed field does have a different use case, as it only displays on the node view and not the node edit form. This module of course is to display markup to site contributors as they edit nodes and doesn't save anything to the db.

Many other CCK fields such as text fields allow php code for things such as allowed values and default value - i don't believe they are protected by permissions or isolated in any way?

If they have permission to edit content types and fields, wouldn't that mean that they can add a text field or similar and execute php code in that way?

Personally I can't imagine a situation where I give permission to edit types / fields without trusting them not to run something dangerous - but if this is considered a valid concern, there are ways around it such as

- Put the php aspect in a separate module so if you don't enable it, you can't run it.
- Add a user permission for executing php code.

I'd be interested to hear the general consensus on this, or perhaps find out what approaches other field modules (that allow php) take.

@Fidelix - there is a large security difference between allowing someone to administer content types and arbitrarily execute PHP code on your server.

@smoothify -
From the Best Practices section at: http://drupal.org/handbook/modules/filter

The PHP Filter is especially dangerous, because it allows, among other things, code-driven queries to be run on your site's database. Grant this input format to users who are not only trusted but really know what they are doing with PHP and Drupal. A one-character typo could end up with horrifying consequences.

From a Lullabot article on input filters: http://www.lullabot.com/articles/drupal-input-formats-and-filters

The PHP Evaluator is the most radical of all Drupal's core filters. It looks for text enclosed in ... and evaluates it as PHP code. This effectively allows you to program and extend Drupal just by submitting content to the site! In 99% of cases, this is a bad idea, and the initial attraction of harnessing such power should be weighed by a healthy sense of fear. If you really need to write PHP code to accomplish what you're trying to do, writing a module is usually a better idea (and not that hard in most cases). Furthermore, in the wrong hands, the PHP Evaluator is an enormous security risk. A malicious attacker, with the PHP Evaluator at their disposal, could wipe out your database and take control of your web server.

At the very least, a separate permission to enable this feature or re-use of the "Use PHP input for field settings (dangerous - grant with care)" (which is what you'd need to add PHP to text fields as you mentioned above) permission would make me feel a little better about it.

My biggest concern is for the people who already have the module and do somewhat of a blind upgrade from the dev version to the first stable not realizing what power they are giving to their existing users that already have permission to edit this field. Outside of that, I still have a "healthy sense of fear" about the functionality in general but do see the use case for it.

@cYu

Point taken, I will definitely wrap some access control around it.

What would your vote be for?

1 - reusing content.module's "Use PHP input for field settings (dangerous - grant with care)",

2 - a markup field specific permission such as: "Use PHP input for markup field (dangerous - grant with care)"

@cYu, i understood your concern, and i acknowledge it as truthful.

@smoothify, for the sake of simplicity, 1 would be better.

I cant see why would someone be alowed to use php for general inputs but not for markup fields.

I have now added access control to the php code, reusing the one from content.module.

I had to change the way it works slightly, instead of having the markup field with an 'Allow PHP Code' checkbox underneath there is a separate text area field inside a PHP Code fieldset.

The reason for this is, with the checkbox it would be possible for an administrator to allow php code for a specific field, but then leave the markup (therefore the php code itself) editable by those with edit content type permissions.

Instead, now an administrator can add php code for a field, and those with the edit content type permissions can see the code but can't edit or override it.

http://drupal.org/cvs?commit=466668

Nice idea smoothify. This approach was interesting...

#17 works well, providing that there is some kind of text (like 'Placeholder for PHP code below') in the html field - it won't get displayed with the php, but without it the php won't get displayed.

is this already intregated in the dev version?
my client wants to see the article node nid when editing and i am not finding a solution in any module.

if not, can anybody please tell to me how do you do it?
thanks

@candelas

Yes, this is in the dev version, and there is access to the node object.

so i go to try it.
thanks a lot lot for sharing your code with us :)

smoothify i am trying to use it but i have a luck in understanding.
if i put a text in the markup field, everything works but if i write in the php field, it doesn't work.
my code is very simple

<?php 
print $node->nid ;
?> 

i am looking on the issues but i dont find howto do it.
can you give to me a tip, please? :)

i also tried to write it as in default value with php on other cck fields but also, it doesnt work...

<?php
$value =  $node->nid ;
return array(0 => array('value' => $value));
?>

also, if i write in both fields (markup and php) it gives to me this error (i write it just in case it would be useful to you)

warning: explode() expects parameter 2 to be string, array given in xxxx/modules/menu/menu.module on line 429.

thanks for your time :)

Have your tried simply returning the $values:

$value =  $node->nid ;
return $value;

This does need some more documentation though :)

i just tried but the markup doesnt show.
i am trying in a form on a story tipe of content with the only field added is your markup.
and yes :) i have to learn much php.
gracie mile

i have tried also

<?php
$value =  "2" ;
return $value;
?>

but the markup (nor field wrapper, nor label) will show in the edit node form.
if i write markup and not in the php field, it shows.

I just installed devel module to see if i found something to help :)

me again :)

in a new installation with only view and cck, if i dont put php and write in the normal markup field i get

<div id="edit-field-indicador-element-wrapper" class="form-item">
 <label for="edit-field-indicador-element">indicador: </label>
 2
</div>

but if i write in the php, i dont get anything in the html.
?¿?

good morning :)
one more thing that i forgot is i am working with drupal 6.20

@candela

You are right, there was a bug in this functionality.

I have now committed a fix to the git repository here:

http://drupalcode.org/project/markup.git/commitdiff/e73695d

This won't be in the next automated dev release until midnight GMT, but you can retrieve a patch from the above link, or get the new module file here

Let me know how you get on :)

I forgot to add, the intended behaviour is to use print or echo to output any text, but return does seem to work too.

thanks thanks!!!!
it works as i needed!
i put my code here just in case someone needs it :)

<?php
if (!$node->nid) {
print "Articulo nuevo";
}
else{
print $node->nid;
}
?>

i dont change the issue fixed because maybe you want to make something else ;)

:)
another little bug... i report here because i think it is not that important...
since i dont do webs often, i do a trick to conserve especial fields that i create.
so when i try to add the field to this new content type using the the possibility of "select an existing field" and save it, i get this error in the page where i am redireted to modify it (admin/content/node-type/story/fields/field_identificador)

user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') SELECT vid, nid, FROM content_type_story' at line 1 query: INSERT INTO content_field_identificador (vid, nid, ) SELECT vid, nid, FROM content_type_story in xxxx/sites/all/modules/cck/includes/content.admin.inc on line 1553.

then i give the order to save and it is ok.
if i try to edit the field, no more warnings...

i have disable all the modules but cck and views and i get the same error with a fresh db.
i mean, first time when i create the markup, all it is ok but, when i add the field to another type of content, i get the error.

i am on ubuntu 10.04 and mysql server and client 5.1

i pleasure to contribute on this little debugging.
and now i keep with my work that i am late!!! o.o

hello again :))

one thing that i dont know if has to be with your module or it is a conflict with hierarchy select

now i started to rebuild the site with pieces that i have construct. so i made active the hierarchie select module an when a content has your field, when i go to add that type of content, i get this error:

warning: explode() expects parameter 2 to be string, array given in xxxx/modules/menu/menu.module on line 429.

I looked into issues on hierarchy select and nobody talks about this.
I also made searches through internet and nothing that i could find.

now to eat and sleep and tomorrow afternoon, more :)

i have tried your module without hierarchy select and other kinds of fields and no problem (number, text, select) and nomal taxonomy fields (default from drupal).
i dont undertand the problem (i have used hours to do it but drupal is too big for me in the amount of time that i have to finish this project).
so i find a "while solution": it works and roles dont see the problem... (dirty one)... i dont like to work like that but... while we find the solution (i will ask a friend that is a excellent programmer for tips) i can keep working because.. :( i need to finish... or i will do it throught theme (also no as good solution as your module for updates).
thanks a lot, your module is a big help :)
i will have an eye for updates on it!

more :))

the workflow module field lets you put permssions on the workflow for the different cck fields.
you can check a field as editable and viewable.
the rest of the cck fields work ok with this but, the makup has to be editable for it to be seen.
AND has to have editable permissions in the modules permissions for that field in the drupal core permissions.
it made me crazy!!
i almost stopped using markup.
so, i think it would be a nice idea to put this on the documentation :)

by other side, when i preview a node, the error line about 429 that i mention before appears twice.

i will tell here all the things i go seen, just in case they help to you to debug :)