javiertoledos

That’s the thing I don’t think that the user should be able write php code directly in terms of security, despite of adding a lot of flexibility, someone who gains access to the backend would able to write arbitrary code to escalate privileges. The idea is to limit the user to use exclusively shortcodes (no more php) in the repeater templates to implement a kind of sandboxing. Anyways it’s just a suggestion, you always sacrifice something when improving security.

I know I’m discouraging storing or letting the user write custom php code, but, if you’re going to execute the php code in the repeater templates and they cannot be written in files, you may be able to execute the repeater template code from database by doing an eval ( '?> ' . $repeater_template ); the eval function can run an arbitrary (and malicious) code but it’s what the plugin is doing already by including custom repeater templates from files.

Maybe something like this

$repeater_template_file =  alm_get_current_repeater ($repeater, $type);
/* If file doesn't exists that means that the ALM template folder
 * is not writable, then use the database
 */
if ( !file_exists ( $repeater_include_file) ):
  $repeater_template = alm_get_current_repeater_from_db ( $repeater, $type );
  eval ('?> ' . $repeater_template );
else:
  include ( $repeater_template_file );
endif;