It removes CODE when chaning from TEXT to VISUAL editor.

Hi cascompany, this is an issue I’ve run into regularly over the years. The plugin uses the TinyMCE editor for WYSIWYG editing as do many other plugins. I’ve developed a tendency to never switch to the Visual tab. Instead, I have the site I’m working on open in another tab in the browser, and constantly keep the Text tab open in the editor. Once I update something, I then refresh the site in the other tab in the browser to see how things are looking. Kinda clunky, I know, but it’s the only method I’ve been able to trust. I’ll be looking into some things I’ve found in an attempt to fix this in the plugin. But since it’s such an ongoing issue, I’m not so sure of how this will turn out.

Yes, I see its a problem of TinyMCE in the editor, as It does exactly the same on the Pages editor in wordpress itself …
I have found some to put on functions.php of the template used, to modify some of the behaviour of the TinyMCE is this :

function override_mce_options($initArray) {
    $opts = '*[*]';
    $initArray['valid_elements'] = $opts;
    $initArray['extended_valid_elements'] = $opts;
    return $initArray;
    }
add_filter('tiny_mce_before_init', 'override_mce_options');

With this code, the above example becames a little better, like this :

<page size="A4" class="some_page_class"></page>
<div class="some_div_class">

Some Text

</div>

It still removes the “link” line, but keeps the “page” one…. BUT… it closes all things (the page and the div) … so well, not really working (i.e to make a “header block” or things like.

BUT…. is a starting point, for someone with better knowledge …. It would be really good if the damn Tiny does not close the tags, and also, if not remove the link line as well… I really cant find what to change.

//// Talking about the plugin….
A great function that the plugin needs… is a way to detect what blocks have “%%variables%%”, and ask you to fill the variables when you are inserting the “shortcode” from the visual editor. You know… I do not need this… I need this, to make my clients can do some things with the blocks I can prepare for them.
Basically because of this TinyMCE I suppose…. you cant also use the “insert full content (not the shortcode)”, basically… because the code that gets inserted, is missing the same tags or have the same auto-close errors, that you have with the editor when making the block as we talked above.
So… the other option is to insert the shortcode… wich is okey… exept if you have variables… because it dont insert the code with the variables, and makes the user in the need to go to the Text Mode, to manually add the name=”values” for each one. And believe me, most “normal” people, will not really do this.

I basically use the blocks to do some “pre-built” reports, I use around 10 blocks, including different headers, and footers for different pages types, in some of the blocks, they need to put some variables … like: title, subtitle, url, colorcode, etc. some is just text, some is color numbers, or a url of a image.
So they insert the [HEADER] tag
go to the visual composer and do some stuff there (tables, text, put images, etc.)
and then they insert the [FOOTER] tag
and voilà… they do some content, using my predefined format.
So the problem is that … I cant make them do this, because they need to manually put the variables (as the insert tag, does not contemplate them) and you know… “visual composer” people, usually have a special touch to screw up the code with a single touch.

Believe me, I would even purchase something that really do what I need to do…

Hi cascompany … In looking into this issue over the past week I’ve included code similar to your override_mce_options example, which now retains most if not all HTML code as written. However, the Link tag is an issue unto itself. TinyMCE is removing this to stay compliant with HTML5, which doesn’t allow the Link tag in the Body of a page. That’s not something I want to orverride whatsoever.

Having said that though, it looks as though you need to be able to use a custom CSS. That’s not only something I want to include, it’s also needed for a fork project I’m about to start. I was going to include a Textarea field on a Settings page to keep the custom CSS in the database, but I think it’d be better if users such as yourself could instead add their own file, I’ll call it customstyles.css, to the CSS folder. I’ll then include code to load it in the header of the page, with a selection on the Settings page to load it either before or after the plugin’s own CSS, your choice. I won’t include a customstyles.css file with the plugin, ensuring I don’t override during updates.

//// Your other request for a %%variable%% dialog … I’m considering it, but that’s not something everyone would want to see. I could probably include a way to Opt-In if you want that function turned on, but I’d question how many other users need that functionality.

I’m going to mark this as Resolved since the first issue is taken care of. If you’d like people to get in on the conversation on the %%variable%% issue, which I wouldn’t object to, please feel free to start a separate thread.

Dave