I'm trying to add some JavaScript into one of my Wordpress pages. When I change the text area to HTML mode and paste in the JavaScript then save my changes. It does not appear on the page itself. Can someone please help me allow JavaScript in the default Wordpress page text editor?
The JavaScript that I am trying to input is:
<script type="text/javascript">
jQuery(function($){
$.supersized({
random : 1,
slide_interval : 3000,
transition : 3,
transition_speed : 900,
slide_links : 'blank',
});
});
</script>
WordPress is really picky about how you do the newlines and it will sometimes place <p> tags in there which will mess up JavaScript code. I would recommend looking at the source after you make the post and see if any of the <p> tags got incorporated. If so, go back and delete the white-spacing in that area and try again.
In the worst case, you can always use the Raw HTML plugin which will render the raw code for you:
http://wordpress.org/extend/plugins/raw-html/
You, or others viewing this question, might also want to try my plugin which enables support for inline JavaScript and JavaScript code blocks in the HTML editor tab. You don't have to use a shortcode or special markup and you can continue to use the TinyMCE wysiwyg editor without worrying too much about losing the content... If you delete everything in the Visual editor, you'll lose the code block, but edits, additions and targeted deletions of content are fully compatible.
It also preserves whitespace and indentation of HTML code when you switch between the HTML and Visual tabs among a few other minor features.
http://wordpress.org/extend/plugins/preserved-html-editor-markup/
Related
We're developing a plugin for a client on a Wordpress site. And, for some reason, an excerpt of the clientside javascript of the plugin appears as raw text in the body of the page.
Here is an image of the page with its markdown:
Entire shortcode script:
<?php
/*
Plugin Name: Cata Employee
Plugin URI:
description: Employee Viewer
...
https://pastebin.com/iFiJT0rM
strangely enough, even when removing the clientside javascript, the script still appears as text on the page after a couple refreshes. My guess is it's something cached, and my coworker suggested it's being caused by SEO stuff of some sort.
What we've tried:
Changing the plugin from a Cornerstone Element to a Shortcode
Adding a function to the script that hides the text (only some of the lines of the text are in targetable elements, and they share a direct parent with the plugin itself, so we can't just hide the whole tree)
Making the plugin the only element on the page
Might seem redundant, but desired behavior needs to be explicitly stated:
Observed Behavior:
A snip of the clientside javascript appears as text on the page
Desired Behavior:
Not having a snip of the clientside javascript appear as text on the page
Any advice or solutions would be greatly appreciated; we really have no idea what's causing this
I am currently looking for a way to implement prettify into my website to allow for code snippets to be posted within the content of pages.
The Problem:
I am using Redactor WYSIWYG and this is causing some problems within the editor (prettify styles the code block within the editor, adding the styled html to the HTML view as well as the submission of the content to the database)
Is there any way to force redactor to ignore the prettify styling when editing content, and only have the styling applied to the final submitted content (when displayed on a page).
Display Example: Prettify on front end only (no styling submitted with the content).
Editor Example: I don't want the editor to be prettified.
Problem Example: This is why I don't want the editor to apply prettify.
The problem with this is, when you come back to edit the article it applies the prettify styling within the content, and then that styling displays as plain text (as part of the content of the code snippet).
Is there any way to force ignore prettify within Redactor or a work around to my problem?
Prettify source: https://github.com/google/code-prettify
Redactor: http://imperavi.com/redactor/
For anyone else interested in using Prettify in conjunction with Redactor on their website, I resolved my issue with the following javascript:
$(document).ready(function() {
if (!$('#redactor').length){
//Redactor Editor Not Found
var x = document.createElement('script');
x.src = 'js/prettify/run_prettify.js?autoload=true';
document.getElementsByTagName("head")[0].appendChild(x);
}
});
On load, the script will look for anything containining id="redactor" and if it is not found, it then loads the prettify script, otherwise if redactor is found (meaning you have an editor on the page), it is never loaded.
This keeps redactor from inheriting prettify styling within the editor and submitting it within your content.
I'm using the WYSIHTML5 editor: http://xing.github.io/wysihtml5/
This editor adds an iFrame to the page and updates a textarea whenever you make a change to the iFrame's contenteditable body. It's similar to many other WYSIWYG editors, so my issue should apply to other editors.
My issue is I want to be able to edit <html>, <head>, <body> and other important base tags through this editor. You obviously can't edit them in WYSIWYG mode, so raw code mode would be fine.
When I enable these tags, they are stripped out by the browser itself because those tags have already been opened by the page in the iFrame itself. So when I switch between raw code and WYSIWYG modes, they are lost.
I use the default "advanced" parser rules and merge them with these: http://pastebin.com/6QvYkqm4 with jQuery's recursive $.merge().
How can I get around this but still use this plugin? Have I misconfigured the plugin? I'm sure I've enabled the tags in the parser rules.
I highly recommend you use as JQuert TE WYSIHTML textarea editor though even it it is buggy, but compared to many others its alot better.
The JavaScript libraries with which WYSIHTML editors are built with search for those tags and deletes them because it's a security flaw not to, and it will probably warp a site layout if its left in. Imagine if a user changes the page's headers. If you really want to implement those feature I would suggest you find the code that deletes those tags in WYSIHTML5's library and alter it to not recognize the those specific tags. Good luck.
Edit:
Example:
In the folder parser_rules of WYSIHTML5 select advanced.js or basic.js (depends what you are using) find:
"head": {
"remove": 1
},
replace with:
"head": {
"rename_tag": "head"
},
Repeat this process with different rules that until you have a desired rule set. WYSIWYG textarea editors all have different JavaScript librarys but the one your using is simple enough to edit.
A WYSIWYG editor is not the solution you're looking for since you can't "see" (format with styles) the head or markup of a page. You should take a look at http://codemirror.net/
HTML example page
Here's what I have for now :
http://jsfiddle.net/W29Wk/
(I'm using Dreamweaver with the Spry Tabbed panels)
I'd like to make something similar to JSFiddle, when you share the script...
What I need is to be able to write my HTML code in the first tab, CSS in the second and Javascript in the third one. Once I'm done, I go in the "RESULT" tab and it renders my code into HTML.
The RESULT tab does not need to be a TextArea, it can be a DIV or a iFrame, as long as it is the same size of the other TextArea.
Thanks a lot!
The result needs to be an iFrame. Jeffrey Way explained it very good in this screencast on nettuts+: How to Inject Custom HTML and CSS into an iframe
You can make the tabs tabs yourself (or just google it).
But why are you making a second tinkerbin?
I'm writing a plugin for FCKeditor that's meant to insert placeholders for dynamic content into the HTML. The interface look like this:
Currently, the plugin inserts the following HTML:
<div title="Dynamic Element: E-Cards (sidebar)" class="dynamicelement ecards-sidebar"> </div>
The snippet of Javascript in my plugin that accomplishes the actual insertion of these placeholders is this:
function insertNewDiv() {
var divNode = oEditor.FCK.EditorDocument.createElement('div');
oEditor.FCK.InsertElement(divNode);
oEditor.FCK.Focus();
oEditor.FCK.Events.FireEvent('OnSelectionChange');
return divNode;
}
To make it look nice in the FCKeditor window, I'm applying some CSS to the FCKeditor window, including the following, that writes the title in there:
.dynamicelement:before {
content: attr(title);
}
Anyway, other than the styling, FCKeditor treats these div elements no differently than any other div element in its window. This is not good for me.
I need these placeholders to have the following traits:
Insertion of content into the placeholder is not allowed.
Clicking it should select it as a whole.
Tapping the delete key when it's selected should delete it.
The only way to edit it (apart from deleting it) is to select it, then click the toolbar button to open an edit dialog.
It should always be considered a block-level element
It doesn't matter if the HTML output uses a custom tag name or not (<dynamicelement> instead of <div class="dynamicelement">).
Does the FCKeditor API provide a way to give it command like, "Treat every element that matches the selector 'div.dynamicelement' the following way: ..." ?
Also, is there another FCKeditor plugin that does a similar thing that I can refer to that I might have overlooked in my research?
EDIT: By the way, I already know about CKeditor. I'm using FCKeditor for a couple of reasons: it's working for my CMS, the configuration options I'm using are perfect for my clients (except, obviously, for the placeholder thing), etc..
I solved this by duplicating the code that makes the "Page Break" button work.
While wading through the source code, I learned that FCKeditor has a native method for inserting placeholders.
Create a "fake image" and insert it into the editor DOM. You can style the image however you want.
Using Javascript, connect it to the div in question.
Hide the div (it still appears in the source and in your output though).
While in WYSIWYG mode, you're playing with this fake image, and the changes are being carried over to the div.
There a few bits and pieces that need to be in the plugin to make this work. If you grep for FCK__PageBreak, you will find them all in the source, ready to be copied into your plugin. FCK__PageBreak is the class name of the Page Break's fake image.
You might be able to use ProtectedSource to get what you want:
The editor offers a way to "protect" part of the source to remain untouched while editing or changing views. Just use the "FCKConfig.ProtectedSource.Add" function in the configuration file.
But:
Note that there currently isn't any way to "lock" displayed content in the editor. The content protected with ProtectedSource will actually be invisible during editing. It may be used instead, for example, to protect custom non standard tags or server side scripts. By default, FCKeditor uses it to protect <script> tags from activation during editing.
You might be able to use this together with a placeholder image:
Your plugin adds both the "real" protect tags and the placeholder.
The server strips out the placeholder and does things to the real tag; however, if the placeholder isn't there but the "real" stuff is then delete the "real" stuff.
When editing, the server inserts the placeholder image before sending things off to the browser.
All this seems a little convoluted so you might be better off with a simpler kludge:
Plugin just inserts a placeholder image with a specific class or a fake attribute of your choosing.
Tweak the image plugin to ignore your placeholder.
Replace the placeholder image with the real stuff on the server.
Replace the real stuff with a placeholder image when sending it back to the browser when they're editing the content.
Or, you could use your own custom tag (i.e. <dynamicelement>) and then use ProtectedTags:
In many situations, it is important to be able to switch to the source view in FCKeditor and add a few custom tags, needed for custom processing, or whatever. The problem is that browsers don't know how to handle non standard HTML tags, and usually break the DOM tree when finding them (specially IE).
That combined with some CSS to display <dynamicelement> nicely (say some dimensions and a background image) might do the trick without too much dirty kludging.