2 added 565 characters in body
source | link

I don't see any reason whatsoever to use eval() in this circumstance.

I need to execute this code as php and have a custom hook for add_before_content() which runs just before content and sidebars.

So, you've provided the user a text input, or textarea, and need to output that content in the template. And you want to do so at a custom hook. All good so far. Here's where you go awry:

In my layouts class, I have a method that checks the user input and then uses this to add the includes using eval()

function add_before_content() {
    global $options;
    $string = "get_template_part('content/block', 'branding');";
    return eval($string);
}

add_action('before_content', 'add_before_content');

What's the point of this?

First: why would you be writing user input to a PHP file, instead of storing it in the database, as would be appropriate?

Second: You're already inside of a custom hook callback; why not simply output the user input directly from your callback?

Let's say you've called this option content_branding. Try something like this:

function add_before_content() {
    global $options;
    // Sanitize, for safety
    $content_branding = wp_kses_post( $options['content_branding'] );
    // Echo (or return) the result
    echo $content_branding;
}

add_action('before_content', 'add_before_content');

What am I missing?

EDIT

The reason I say the contents are not important is because it can be anything and they all differ. Some are just outputting a widget positions, others featured posts. But the same scenario would be true if the file just had Whatever the php is inside the included file is, it should just run as if its included normally.

Based on this clarification, I am going to reiterate (and up-vote) Eric Mann's suggestion that, rather than use your current approach, you instead use dynamic sidebars, and custom Widgets.

I don't see any reason whatsoever to use eval() in this circumstance.

I need to execute this code as php and have a custom hook for add_before_content() which runs just before content and sidebars.

So, you've provided the user a text input, or textarea, and need to output that content in the template. And you want to do so at a custom hook. All good so far. Here's where you go awry:

In my layouts class, I have a method that checks the user input and then uses this to add the includes using eval()

function add_before_content() {
    global $options;
    $string = "get_template_part('content/block', 'branding');";
    return eval($string);
}

add_action('before_content', 'add_before_content');

What's the point of this?

First: why would you be writing user input to a PHP file, instead of storing it in the database, as would be appropriate?

Second: You're already inside of a custom hook callback; why not simply output the user input directly from your callback?

Let's say you've called this option content_branding. Try something like this:

function add_before_content() {
    global $options;
    // Sanitize, for safety
    $content_branding = wp_kses_post( $options['content_branding'] );
    // Echo (or return) the result
    echo $content_branding;
}

add_action('before_content', 'add_before_content');

What am I missing?

I don't see any reason whatsoever to use eval() in this circumstance.

I need to execute this code as php and have a custom hook for add_before_content() which runs just before content and sidebars.

So, you've provided the user a text input, or textarea, and need to output that content in the template. And you want to do so at a custom hook. All good so far. Here's where you go awry:

In my layouts class, I have a method that checks the user input and then uses this to add the includes using eval()

function add_before_content() {
    global $options;
    $string = "get_template_part('content/block', 'branding');";
    return eval($string);
}

add_action('before_content', 'add_before_content');

What's the point of this?

First: why would you be writing user input to a PHP file, instead of storing it in the database, as would be appropriate?

Second: You're already inside of a custom hook callback; why not simply output the user input directly from your callback?

Let's say you've called this option content_branding. Try something like this:

function add_before_content() {
    global $options;
    // Sanitize, for safety
    $content_branding = wp_kses_post( $options['content_branding'] );
    // Echo (or return) the result
    echo $content_branding;
}

add_action('before_content', 'add_before_content');

What am I missing?

EDIT

The reason I say the contents are not important is because it can be anything and they all differ. Some are just outputting a widget positions, others featured posts. But the same scenario would be true if the file just had Whatever the php is inside the included file is, it should just run as if its included normally.

Based on this clarification, I am going to reiterate (and up-vote) Eric Mann's suggestion that, rather than use your current approach, you instead use dynamic sidebars, and custom Widgets.

1
source | link

I don't see any reason whatsoever to use eval() in this circumstance.

I need to execute this code as php and have a custom hook for add_before_content() which runs just before content and sidebars.

So, you've provided the user a text input, or textarea, and need to output that content in the template. And you want to do so at a custom hook. All good so far. Here's where you go awry:

In my layouts class, I have a method that checks the user input and then uses this to add the includes using eval()

function add_before_content() {
    global $options;
    $string = "get_template_part('content/block', 'branding');";
    return eval($string);
}

add_action('before_content', 'add_before_content');

What's the point of this?

First: why would you be writing user input to a PHP file, instead of storing it in the database, as would be appropriate?

Second: You're already inside of a custom hook callback; why not simply output the user input directly from your callback?

Let's say you've called this option content_branding. Try something like this:

function add_before_content() {
    global $options;
    // Sanitize, for safety
    $content_branding = wp_kses_post( $options['content_branding'] );
    // Echo (or return) the result
    echo $content_branding;
}

add_action('before_content', 'add_before_content');

What am I missing?