Skip Navigation

HOWTO: Replace CRED post_content WYSIWYG with textarea

This support ticket is created Il y a 9 années et 3 mois. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

This topic contains 6 réponses, has 5 voix.

Last updated by larryL Il y a 7 années et 9 mois.

Assigned support staff: Nikos.


Sometimes, you want to use a text area for the Post Content field instead of the default WYSIWYG field. Sure you can create a custom textarea instead but more often than not what's inside this won't show up in your search results or be output by default using your theme. There is some good information in the CRED API but it's missing some critical stuff for those new to PHP and the WordPress API. For instance it gives some example code for creating a hook but doesn't tell you where to put it so you can execute it and that's a really important bit of information and so I've created a mini HOWTO that shows all three steps involved for any newbies like me.

Firstly, in your cred form add a generic field titled "post_content_substitute" or whatever you want to call it. Choose "Save to database" in the options and don't forget to click the update form button. The field should like like below in your CRED form.

[cred_generic_field field="post_content_substitute" type="textarea" class="" urlparam=""]

Secondly, we are going to create some code to manipulate our data. In this instance we want to redirect the data entered into the generic textarea field to the post_content field of our post. To do this we create the following code:

add_action('cred_save_data', 'my_save_data_action',10,2);
function my_save_data_action($post_id, $form_data)

// check if CRED form ID 309 is being used and then...

if ($form_data['id']==309) // <------ Put your CRED form ID here.
// scoop up the data from the generic form field and redirect it instead to the post_content field

Thirdly, the important bit. This is how we get our new code executed which is creating our own plugin. You could try to find the relevant functions.php file to put your code into but just one syntax error in there can kill your WP interface and then it's off to VI. Putting the code in a plugin is much safer and there is less risk of your code being replaced during an update. The plugin wrapper is as follows and the PHP tags are the first and last characters in your file.

Plugin Name: Your plugin name goes here
Description: Your description goes here
Version: 1.0
Author: Your name
Author URI: 
Plugin URI:

// Your code goes here


Fill in the required plugin information where required above and add your code to it. Put the file into your plugins directory with the same ownership and rights as your other plugin files and then activate the plugin via the plugins interface in wp-admin.

This HOWTO is a combination of information from the CRED API documentation and various forum posts I found -- none of which unfortunately told the whole story so I
hope this helps someone.



Hi John
and thank you for the helpful post you made.

It was not realized, as it seems, that further details about the WP API
should be included in the documentation.

The plugin idea, instead of using the theme's functions.php is very good and in fact will
work even if the theme is changed or updated.

One question, why do you need to have the generic field saved to DB,
since it is redirected to the post_content field?


Thanks for the feedback Nikos,

Nikos: "One question, why do you need to have the generic field saved to DB, since it is redirected to the post_content field?"

Sorry that's probably badly explained on my part. Effectively, all I am trying to do is replace the standard "post_content" WYSIWYG field on the front end with a generic field because the generic field allows me to use a textarea as my field type. The problem however, is that the data from the generic field is saved to the post_meta table and not the "post_content" field of the wp_posts table as are standard post fields. So, I use the hook to prevent the generic field data from being stored in the post_meta table and store in the the wp_posts table instead.

Hope this makes sense. I did think about doing this with a trigger instead but I thought I'd give the CRED API a go as I'm probably going to have to use it for a few other things such as a Q&A module and Classifieds module for my website.

I bet you're going to tell me how there was a much easier way to do this--right?! 😀



Hi John,

i see the reasoning, but since you save the data from this field as post_content
there is no need to add extra burden to the DB by setting this field to be saved to DB

Maybe using a generic field named "post_content" (maybe saved to DB as well)
could possibly replicate the data to the post_content automatically (havent tested)

In some future release the rich editor for post_content will have 2 changes:

1) TinyMCE will be used (a minimal version) instead of CLEditor
2) It wil be made optional, able to use simple textarea instead

However untill this is done, your current solution seems fine


John, sending many many thanks your way for this awesome and most helping post to me !!

I am also setting the post title through pulling on user entered custom fields from the front-end, I need to have the post-title field shown on the form but as a read-only field.
Otherwise can't save if both post-content and post-title cred fields not shown.

It also a great way for a country selector function I was looking to implement, so now I can use any country selector method and then assign or create a custom taxonomy from it to a custom post type.

Again, many thanks!




Hi guys,

I'm looking for this feature too since Cred post_content field hasn't yet the option to be "un-riched" 😀

Just as @nikos already pointed out I tried to set a generic field with "post_content" field attribute set and effectively the content was saved to the database as the post content!
Thanks again



Has anyone 'else' gotten this to work? I'm having issues. And I don't understand why you need to create a plugin.