I've created a Confluence blueprint plugin as per the basic/intermediate/advanced tutorials available from Atlassian. I now want to update the page template to include a {HTML} macro with embedded CDATA, where a URL in that CDATA contains a portion to be substituted with user-entered data.
What I'd ideally like to do, with the <at:var...> being substituted with locationid:
<ac:structured-macro ac:name="html">
<ac:plain-text-body>
<![CDATA[<iframe src="http://...?locationid=<at:var at:name="locationid"/>"></iframe>]]>
</ac:plain-text-body>
</ac:structured-macro>
Unfortunately this does not work; the <at:var at:name="..."> inside CDATA can't be substituted.
I've tried various formats of this, for example substituting in the entire CDATA string itself, even going as far as substituting in the entire <ac:structured-macro> block in a single string. None work.
A Google search brought up two very similar questions on the Atlassian community wiki, this and this. Furthermore I found a Confluence Server JIRA to fix this problem, but it's been rejected and closed.
Despite the evidence against a solution I'm hoping that someone creative has an idea of how I can achieve this?
Atlassian SDK: 6.2.14
I'm not exactly sure what you're asking ;) but could it be the same as this discussion in our doc space?
Confluence 4.3-RC1 Release Notes
After years of experience with custom made CMS systems, I come to this conclusion:
Clients really want to copy and paste information from word processors into their website CMS. They don't like to create large texts in a website box, and prefer to do so from their good old word processor. Or they simply have their text already prepared for other purposes, and therefore want to copy and paste.
Clients do not like to lose their format. They've spent time on their boldface text, headings, etc, and they do not like to do this all over again.
Rich Text Format fields (TinyMCE, CKEditor, etc) are not yet able to properly convert all formatted text into the right HTML. I do not blame them; this has to be very difficult given the odd 'source code' that word processors put in the clipboard. But reading all SO topics about richttext related issues, I feel this is a known limitation.
What do you do in such cases? I've tried the following:
Explain the client beforehand that this is not a word processor we are implementing, and it has limitations. They can understand, but still want to copy and paste.
Only show very few buttons for formatting (bold, italic, links). That way, we can strip the tags and clean this up quite well, and this limits issues. Works better, but clients keep asking for font options, more colors, headers, etc.
So not a really good solution in sight. Are there others who have tackled this issue successfully?
One solution (and probably the best I've come up with) is to post-process the pasted content. So, catch the publish event and correct all the crappy HTML -- catch all the "mso-normal" styles, for instance, and remove them. You'd have a set of rules which clean stuff coming out of, say, MS Word.
Though, this is not just a word processing problem. You're pasting from one rich text editor to another, and styles just don't transfer between rich editing environments. This is not so much a technical problem as it is a logical problems.
Update: Someone pointed me to this: Copy-Pasting Word to your Web CMS. No real solutions, but just confirmation that it's a sticky problem.
I totally agree with you:
Last week I did a very interesting test with a customer for which I had to prepare some demo's of .NET based CMS systems (Umbraco, Sitefinity, DNN, Composite C1 ect). The customer himself had a Drupal based site and I was ashamed none of my CMS demo's did a 100% job with a complicated Word table (Ceteris paribus: I did not do some CMS fine-tuning, used every CMS out of the box). The worst part was his Drupal CMS did a 100% good job! It was exactly the same as it was in Word. For a client working a lot with Word my CMS-ses were a showstopper. Of course there are a lot of discussions on the web about 'you should not copy from Word' or 'do NOT use Word for CMS things'. Fact is: clients work with Word so we should deal with it.
I am thinking of converting my forum input textarea exclusively to TinyMCE HTML editor. I already have both options but it is a pain maintaining both and inserting images in textarea needs preview etc...
This is more of a general question. Do you think it is safe to include HTML editor (with all the safety measures like paste only text, filter for html not allowed etc...) as the only kind of editor on a forum? It's 2011 and machines are generally fast, connection are better.
What are the downsides of using HTMl editor instead of text field? I can not imagine a blog CMS to have "normal" textarea for input.
But for some reason on forums I do not see many html editors... Even the TinyMCE site has a textarea for their editor. So is there really something to watch out for and a no go...?
I know it is more of a phylosophical question, but I guess you have experience with forums, blogs, etc...
My site is about cooking and beeing able to insert pictures (and upload them) the easy way seems to be a big plus for our home cooks ;-)
If you don't consider security (you'll need to filter the HTML input on the server side so it won't contain anything dangerous), there's only the user experience left for consideration. On a forum you write text most of the time. There's seldom any use for more functionality than bold, italics and images. The solution used here on Stack Overflow addresses this by having a very limited set of functions, and applying it in the textarea with a sane markup language.
Other forums either use old software or didn't think the improved user experience was worth the effort. The textarea-only solution fits most forums well enough since most of the input is text-only anyway.
I do think you would benefit from HTML input. Make sure that only allowed HTML can be sent though, since the user can circumvent everything on the client side.
TinyMCE uses Javascript to add functionality to an existing textarea. If Javascript is disabled, then the user will be presented with a normal textarea anyway.
I would say it's relatively safe, as long as all input from the user is validated on the server before it's used for anything.
I run a blog where the blog title is either an external link or an internal link to a longer piece similar to what you’ve seen on similar blogs. For some reason, ExpressionEngine (1.6.x) does nothing to sanitize such things as ampersands in the URLs provided.
I use Markdown in the body text, which seems to do a great job of sanitizing all URLs. Yet, ExpressionEngine’s own handling of the titles doesn’t cut it. I have tried formatting the “title URLs” in Markdown and failed miserable, and damn if I know what the hell it is in ExpressionEngine that prevents me from using it.
So the question boils down to what other ExpressionEngine 1.6.x users do and have done, or whether someone can come up with a MacGyver-esque solution. Because I’ve been stumped upwards of half a year.
The XML Encode Plugin for EE1 from Rick Ellis of EllisLab will convert your special characters to HTML entities.
The plugin was originally designed to convert reserved XML characters to HTML entities in the ExpressionEngine RSS templates, but should work for what you need.
To use the plugin, wrap your {title_link} custom field in between its tag pairs:
{exp:xml_encode}
{title_link}
{/exp:xml_encode}
This would result in:
http://www.google.com/search?q=nytimes&btnG=Google+Search
Being converting into:
http://www.google.com/search?q=nytimes&btnG=Google+Search
Other EE1 Plugins which offer more similar but advanced features are Cleaner by utilitEEs (Oliver Heine) or Low Replace by Lodewijk Schutte.
How does the Reader function of Mobile Safari in iOS 5 work? How do I enable it on my site. How do I tell it what content on my page is an article to trigger this function?
A lot of the answers posted here contain false information. Here are some corrections/clarifications:
The <article> element works fine as a wrapper; Safari Reader recognizes it. My site is an example. It doesn’t matter which wrapper element you choose, as long as there is one, other than <body> or <p>. You can use <article>, <div>, <section>; or elements that are semantically incorrect for this purpose, like <nav>, <aside>, <footer>, <header>; or even inline elements like <span> (!).
No headings are required for Reader to work. Here’s an example of a document without any <h*> elements on which Reader works fine: http://mathiasbynens.be/demo/safari-reader-test-3
I posted some more details regarding my findings here: http://mathiasbynens.be/notes/safari-reader
I've tested 100 or so variations of this on my iPhone in order to figure out what triggers this elusive Reader state. My conclusions are as follows:
Here is what I found had an impact:
Having around 200 or more words (or 1000 characters including whitespace) in the article you want to trigger the "Reader" seems necessary
The reader was NEVER triggered when I had less than 170 words; although it was sometimes triggered when I had 180 or 190 words.
Text inside certain elements such as <ol> or <ul> (that are not typically used to contain a story) will not count towards the 200 words (they will however be displayed in the reader if the reader is triggered for other reasons)
Wrapping the 200 words in a block element such as a <div> or <article> seems necessary (that said, I'd be surprised if there were any websites where that was not already the case)
For full disclosure, here is what I found did NOT have an impact:
Whether using a header or not
Whether wrapping the text in a <p> or letting it flow freely
Punctuations (ie removing all periods, commas, etc, did not have an impact)
It seems the algorithm it is based on is looking for p-Tags and it counts delimiters like "." in the innerText. The section (div) with the most points gets the focus.
see:
http://lab.arc90.com/experiments/readability/
Seems to be the base for the Reader-mode, at least Safari attributes it in the Acknowledgements, see:
file:///C:/Program%20Files/Safari/Safari.resources/Help/Acknowledgments.html
Arc90 ( Readability )
Copyright © Arc90 Inc.
Readability is licensed under the Apache License, Version 2.0.
This question (How to disable Safari Reader in a web page) has more details. Copied here:
I'm curious to know more about what triggers the Reader option in Safari and what does not. I wouldn't plan to implement anything that would disable it, but curious as a technical exercise.
Here is what I've learned so far with some basic playing around:
You need at least one H tag
It does not go by character count alone but by the number of P tags and length
Probably looks for sentence breaks '.' and other criteria
Safari will provide the 'Reader' if, with a H tag, and the following:
1 P tag, 2417 chars
4 P tags, 1527 chars
5 P tags, 1150 chars
6 P tags, 862 chars
If you subtract 1 character from any of the above, the 'Reader' option is not available.
I should note that the character count of the H tag plays a part but sadly did not realize this when I determined the results above. Assume 20+ characters for H tag and fixed throughout the results above.
Some other interesting things:
Setting for P tags removes them from the count
Setting display to none, and then showing them 230ms later with Javascript avoided the Reader option too
I'd be interested if anyone can determine this in full.
Both Firefox and Chrome have the similar plugin named iReader. Here is its project with source code.
http://code.google.com/p/ireader-extension/
Read the code to get more.
I was struggling with this. I finally took out the <ul> markings in my story, and viola! it started working.
I didn't put any wrapper around the body, but may have done it by accident.
HTML5 article tag doesn't trigger it on my tests. It also doesn't seem to work on offline content (i.e. pages saved on your local machine).
What does seem to trigger it is a div block with a lot of p's with a lot of text.
The p tag theory sounds good. I think it also detects other elements as well. One of our pages with 6 paragraphs didn't trigger the Reader, but one with 4 paragraphs and an img tag did.
It's also smart enough to detect multi-page articles. Try it out on a multi-page article on nytimes.com or nymag.com. Would be interested to know how it detects that as well.
Surprising though it may be, it indeed does not pay any attention to the HTML5 article tag, particularly disappointing given that Safari 5 has complete support for article, section, nav, etc in CSS--they can be styled just like a div now, and behave the same as any block level element.
I had specifically set up a site with an article tag and several inner section tags, in prep for semantic HTML5 labeling for exactly such a purpose, so I was really hoping that Safari 5 would use that for Reader. No such luck--probably should file a bug on this, as it would make a great deal of sense. It in fact completely ignores most of the h2 level subheads on the page, each marked as a section, only displaying the single div that adheres to the criteria mentioned previously.
Ironically, the old version of the same site, which has neither article, section, nor separating div tags, recognizes the whole body for display in Reader.
See Article Publishing Guidelines.
Here are APIs about how to read and parse: Readability Developer APIs. There's already a project you can refer: ruby-readability.
A brief history:
The Safari Reader feature since Apple's Safari 5 browser embeded a codebase named Readability, and Readability started off as a simple, Javascript-based reading tool that turned any web page into a customizable reading view. It was released by Arc90 (as an Arc90 Lab experiment), a New York City-based design and technology shop, back in early 2009. It's also embeded in Amazon Kindle and popular iPad applications like Flipboard and Reeder.
I am working on algorithms for cleaning web-sites from information "waste" similar to Safari Reader feature. It's not so good as readability but has some cool stuff.
You can learn more at smartbrowser.codeplex.com project page.