I have TinyMCE in my Wordpress plugin, and have been having a super irritating problem with TinyMCE. It will save edits made in plaintext mode but won't save edit made in Visual mode (and throws an error).
This is the code I use to create the TinyMCE textarea. I name the field correctly to save and load from options.php (which works when it's just a plain textarea).
$x_options = get_option('editbox');
/*HTML form fields*/
$rc_initial_data = ( isset( $x_options['fluid_body'] ) ) ?$x_options['fluid_body']:'';
$settings = array( 'wpautop' => true, 'textarea_name' => 'editbox[fluid_body]', 'quicktags' => true, 'tinymce' => true, 'quicktags' => array('buttons' => 'em,strong,link,block,ul,ol,li,p,close,spell,img') );
wp_editor( $rc_initial_data, 'fluid_body', $settings );
The error I get is this:
Can't create duplicate variable: 'typeMap'
The error is in wp-tinymce.php (which loads a .js file). I use multiple TinyMCE-enabled fields, but they are all named uniquely so the "duplicate" thing shouldn't be a problem (and isn't, if it's plaintext).
Any ideas why the Visual editor isn't working? Everything is the current version, Wordpress, jQuery, etc.
Related
I'm trying to find a solution for this for weeks and I'm finding answers all
over the internet but I do not know where and how to add this very short script.
I want to have plain text paste enabled on my frontend wordpress tinymce.
So people say use this
tinymce.init({
plugins: "paste",
paste_as_text: true
});
But I don't know where to put this script in.
The class-wp-editor.php does not have any tinymce.init config that I can find.
Would be great if I can solve this.
Thanks
I would use
wp_editor()
with a shortcode.
tinymce is part of settings.
$settings = array( 'tinymce' => array('your_options') );
wp_editor($content, $editor_id, $settings);
Thank you for your respond.
Still I don't know how where to add this.
Do I need to add this to my function.php or a new .php file.
If so how can I make tinymce see this file?
This is the script I use to display the tinymce at the frontend.
With searching over the internet I added the 'paste as text' => true in,
but this does not help as the editor still paste in styled format.
Did I do this correct, if not, how to enable 'paste as text'?
<?php $cont = isset($post) ? $post->post_content : '';
wp_editor(wpautop(stripslashes($cont)),'post_content', array(
'paste_as_text' => true,
'textarea_name' => 'pack[post_content]',
'teeny' => 1, 'media_buttons' => 0,
'tinymce' => array('toolbar1' => 'bold,italic,underline,blockquote,strikethrough,bullist,link,unlink,media,mybutton'),
'quicktags' => false, 'textarea_rows' => 15)); ?>
I am using the Carbon Fields plugin (not composer). I am building a large site and will have many functions to add fields to lots of different pages. I don't like to have extremely long files that make it harder to find the code for each page. If everything is in the main plugin file, it works fine. But if I try to require_once() or include() another file that contains Carbon Fields classes, I get the error: "class Container not found".
Is there a way to get the classes to be available in included files instead of everything having to be in the main file? I have searched the documentation and can find nothing on this.
Finally figured this out for anyone else running into an issue. Each included file that requires Carbon Fields classes must have the following at the beginning of the file:
require_once(WP_PLUGIN_DIR . '/carbon-fields/carbon-fields-plugin.php');
use Carbon_Fields\Container;
use Carbon_Fields\Field;
After this, you can start your functions and such. I am adding some additional coding on the extension plugin file to ensure the Carbon Fields plugin is activated to keep things from breaking.
You can include your file directly in functions.php like this (after installing the plugin):
require_once get_template_directory() . '/assets/inc/your-file.php';
Just replace /assets/inc/ with your folder structure.
I'm guessing your real issue is not invoking a Container::make before calling Field::make and the reason you received the class error.
In other words, something like this would go in your included file:
use Carbon_Fields\Container;
use Carbon_Fields\Field;
Container::make( 'post_meta', __( 'Page Options', 'crb' ) )
->where( 'post_type', '=', 'page' ) // only show our new fields on pages
->add_fields( array(
Field::make( 'complex', 'slider', 'Slides' )
->set_layout( 'tabbed-horizontal' )
->add_fields( array(
Field::make( 'text', 'slider_title', __( 'Slide Title' ) ),
Field::make( 'image', 'slider_media', __( 'Slide Media' ) )
->set_type( array( 'image', 'video' ) )
) ),
) );
The Container class must be called before the Field class or you will get the error you mentioned.
I want to add WP editor with TinyMCE to my custom text widget, but it won't show TinyMCE buttons it just shows textarea. When I test my code on page.php it works perfectly - editor shows with all the buttons and metabox. Can You please tell me what I'm doing wrong?EDITWidgets screenshot.Same code used in page.php screenshot
The code I use :
$settings = array(
'wpautop' => true,
'media_buttons' => false,
'textarea_name' => 'test-editor',
'textarea_rows' => get_option('default_post_edit_rows', 10),
'tabindex' => '',
'editor_css' => '',
'editor_class' => '',
'teeny' => true,
'dfw' => true,
'tinymce' => array(
'theme_advanced_buttons1' => 'bold,italic,underline'
),
'quicktags' => false
);
wp_editor( 'Text in editor', 'test-editor', $settings );
Looks like you need to find another WYSIWYG editor. Reading the Codex, there are two issues with your code:
The $editor_id
can only be composed of lower-case letters. No underscores, no hyphens. Anything else will cause the WYSIWYG editor to malfunction.
And this one that prevents the editor from working in a meta box
Once instantiated, the WYSIWYG editor cannot be moved around in the DOM. What this means in practical terms, is that you cannot put it in meta-boxes that can be dragged and placed elsewhere on the page.
Custom wordpress form, using wp_editor, I create a Tinymce instance on the textarea.
Editor defaults to HTML but if I click into the editing area the contents disappear.
However if I switch to Visual mode, all works as expected, then switch back to HTML mode all works there too, maybe the click is being intercepted by TinyMCE?
Any clues please....
Thanks
Martin
PS initializations are:
$settings = array(
'wpautop' => true,
'media_buttons' => false,
'tinymce' => array(
'theme_advanced_buttons1' => 'bold,italic,underline,blockquote,|,undo,redo,|,fullscreen',
'theme_advanced_buttons2' => '',
'theme_advanced_buttons3' => '',
'theme_advanced_buttons4' => '',
'theme_advanced_resizing' => true,
'width' => '600px'
)
);
Such problems (besides others) may arise when a hidden textarea (or other html element) is used to init a tinymce editor. Best way to avoid this is to make it visible just before you init the editor.
I've taken a different approach and re-init the tinyMCE when switching between them. Attach it to an even handler:
var postContent = "Take Content from some hidden field, AJAX call, etc.";
if ( tinyMCE
&& tinyMCE.activeEditor
&& tinyMCE.activeEditor.id )
{
tinyMCE.activeEditor.setContent( postContent, {} );
tinymce.execCommand( 'mceRemoveControl', true, tinyMCE.activeEditor.id );
}
I'm trying to diligently follow what the codex says about modifying the appearance of the comments form (located here) but I can't get it to work. The default comments form appears despite my array of arguments that should change it.
In the template I have: comments_template('mycomments.php');
Then...
<?php
//inside my mycomments.php file
$comment_args = array (
'fields' => array('author', 'email'),
'must_log_in' => true,
'title_reply' => 'Review this product',
'label_submit' => 'Submit',
);
comment_form($comment_args, $post->ID); ?>
Am I doing something wrong?
I figured it out. There was nothing wrong with my arguments. Instead... I needed a / infront of the relative link to my customized comments template:
comments_template('/mycomments.php');
Moral of the story: If you're having trouble getting the template to work (at all), make sure you're actually loading the right template file!