(OLD 5.7 Discussion FORUM)

 

WebcentricLtd replied on Sep 24, 2014 at 4:47 am Permalink Reply

2nd this.

I found the experience of adding / manipulating tables using redactor to be awful - just impossible to use properly and that's me. If I gave this to some of my clients their heads would explode :)

wvanelten replied on Jun 25, 2015 at 10:13 am Permalink Reply

.

andrew replied on Sep 24, 2014 at 7:59 pm Permalink Reply

The table outline is definitely a bug. We stripped the styles by accident and will fix soon.

We will investigate undo/redo.

MrKDilkington replied on Sep 24, 2014 at 8:21 pm Permalink Reply

Thank you

rosie607 replied on Nov 14, 2014 at 11:50 am Permalink Reply

Really like Redactor but another suggestion that I'd like to make is that I feel that it is really missing the ability to add classes to any tag.
I frequently need to add css styles to h2's p's etc but don't really want spans everywhere. In addition the spans will not have any effect on the parent tag so aren't that useful in styling my typography.

Dushka replied on Feb 24, 2015 at 1:47 am Permalink Reply

Amen to that comment.

wvanelten replied on Jun 26, 2015 at 4:22 am Permalink Reply

True!
I miss this also.

briggers replied on Nov 17, 2014 at 2:53 pm Permalink Reply

Really HATE Redactor.

It may be lean and fast and have a modern looking toolbar but it simply does not have the functionality that should be there for a CMS where editors need to construct pages with anything more complex than a blog. It's not even possible to float an image right or left and wrap text round it or format a table.

Need to be able to add styles to the editor's dropdown lists that are also in the site's theme/styles files.

Redactor is a truly retrograde addition and its inclusion excludes using c57 until a proper WYSIWYG editor is available.

Perhaps someone can build an add-on for TinyMCE or CKEditor - hope, hope!

MrKDilkington replied on Nov 18, 2014 at 3:46 am Permalink Reply

Hi briggers,

You can float images.
- click on an inserted image in Redactor
- click on the "Edit" menu item
- choose a float direction from the Position dropdown

You can add styles to the editor's dropdown list that are in the site's theme/styles files. I wrote a little about adding custom styles in Redactor here -http://www.concrete5.org/community/forums/5-7-discussion/adding-red...

With this said, I am in total agreement that Redactor is painfully bare bones when it comes to styling and formatting options. TinyMCE and CKEditor are both packed with features and have adopted much better looking interfaces.

Here is something to remember though, concrete5 is open source and has a tiny core team. Right now, the core team is working on making 5.7 faster, ironing out bugs, and improving workflow. I am sure they will get to improving Redactor once core development issues calm down. In the meantime it will be frustrating for sure, but not forever.

The good news is that writing plugins for Redactor is easy.
http://imperavi.com/redactor/docs/how-to-create-plugin/...
http://imperavi.com/redactor/docs/api/...

I've tried to make plugins that add features that are currently missing. Integrating them into the core is the hard part. This is where the open source part comes in. If we could get people together to create a master list of required features, create the plugins, and integrate the plugins with the core - we could have these features much sooner.

briggers replied on Nov 18, 2014 at 4:44 pm Permalink Reply

Thanks Mr K,

My mistake about floating images - I've looked at Redactor several times since it was introduced and never found that function. But that doesn't change my view that Redactor is a vastly over-hyped editor when compared with others like Tiny or CKeditor.

One reason for using projects like c5 is to avoid re-inventing the wheel and to make use of work that has already been done so writing plug-ins for something as basic as an editor is just crazy when better tools are available off the shelf. I do however agree with the principle that the user should be discouraged from adding styles which are not consistent with the overall design of the site, so limiting the formatting that he/she can apply is a good thing. However the best way to do that is to provide context sensitive styles in a dropdown and those styles should be the same as provided by a subset of the site styles; this can quite easily be done with other editors - as far as I can see it can't be done with Redactor - tell me I'm wrong again!

Sure a group could get together to build the necessary plug-ins but why reinvent the wheel? One shoudn't need a plugin to apply a class like:

.rtimage{
float:right;
margin: 10px 0px 10px 10px;
}

It should come straight out of the stylesheet for the theme - then if you modify the theme a bit all the right-floated images will get changed automatically.

I also have a concern with Redactor Licencing. It's not clear if the "perpeual OEM" licence that c5 have obtained licences Redactor to be used on a site developed for a client or just allows c5 to distribute c5 including Redactor. In other words do we have to obtain site licences for each site developed for a client? I've asked Redactor that question but not got an answer, and I see that some other CMS, e.g. MODX actually sell an end-user Licence to use Redactor when incorporated in a MODX site albeit at a lower price than the standard licence. Even Laravel does not include it as a standard tool because of licencing issues - unless there is a recent change that I've not found.

So for me there are several objections which mean that for at least the present I'll stick with c56 and not take up c57 for live sites:
- Poor capabilities for styling
- Lack of useful plug-ins
- Questions about licencing

And I think that is a huge shame because c57 does look very interesting

mhawke replied on Nov 18, 2014 at 5:46 pm Permalink Reply

The licensing issue has been discussed and Franz assures us that we can use it without worrying.

http://www.concrete5.org/developers/pro-accounts/community-leaders-...

Did you check the first link in MrKDilkington's post above.

http://www.concrete5.org/community/forums/5-7-discussion/adding-red...

The styles are baked into the theme and will change sitewide if you alter the css in the theme.

It was well known early on that Redactor initially did not have some of the capability of some of the more mature editors you mentioned but that adding these capabilities to Redactor is much easier than modifying the others. I assume that the core team simply hasn't had the hours to dedicate to adding these capabilities. This is an open source project which means that if you have ideas and expertise then by all means pitch in at Github

My clients will be VERY glad to see tinyMCE gone. Very glad.

briggers replied on Nov 18, 2014 at 7:34 pm Permalink Reply

"The licensing issue has been discussed and Franz assures us that we can use it without worrying.

http://www.concrete5.org/developers/pro-accounts/community-leaders-...

A link that is not accessible to us ordinary users - I still make the point that Redactor have not confirmed it one way or another when I asked them directly.

"Did you check the first link in MrKDilkington's post above.

http://www.concrete5.org/community/forums/5-7-discussion/adding-red...

Yes, and it's an useful work around a serious deficiency but it requires defining the classes in the theme css file if they don't already exist then creating another file which links the css classes to the editor as SPANS which means that one ends up with a bit of HTML that looks like this - copied out of the Redactor HTML window:

<p>
   <span class="title-caps-bold"><span style=""><span style=""><span class="title-caps"><span style="">Sed cursus facilisis</span> dignissim. Aliquam rhoncus enim et pellentesque varius. Nulla sodales nibh lorem, sit amet imperdiet arcu commodo sit amet. Mauris sed scelerisque nisl. Ut auctor ipsum tellus, vel viverra massa elementum sit amet.  </span></span></span></span>
</p>

when one selects a style, then tries to remove it then add another style. And if you've got clients who never change their mind about how a bit of content should look they are very different to any of mine. An "erase style" button would be a good idea. And one should not be using <span>s in any case; W3C says "They are the “tag of the last resort” and should only be used where no other HTML element fits the bill, because they have no meaning to assistive techologies, search engines, etc. " (http://www.w3.org/wiki/Generic_containers_-_the_div_and_span_elements)

The bit above should be:

<p class="title-caps">Sed cursus facilisis dignissim. Aliquam rhoncus enim et pellentesque varius. Nulla sodales nibh lorem, sit amet imperdiet arcu commodo sit amet. Mauris sed scelerisque nisl. Ut auctor ipsum tellus, vel viverra massa elementum sit amet.</p>

A little clearer and shorter I think.

And how might we float a little "additional information" box beside the main text - put a div inside a span?

So we have a nice clean CMS producing nice clean HTML with content stuffed full of redundent spans.

I'm sorry but knowing from the early days that an tool is deficient and having an "easy" way of adding the capabilities later does not sound a good reason to avoid using an tool which is already mature and has the capabilities built in and proven over several years. You don't need an easy way to add the capabilities to some editors, they've been there for years

Sure, liking or not liking the look of Redactor, TinyMCE, CKEditor et al is a matter of taste, but lacking functionality is quite different. I've actually never had a client who has expressed a preferrence for any editor; all they want to be able to format the content in the way they like and Redactor is totally deficient in that respect. And I don't like having to plough through their redundent formatting to get back to the basic content every time they mess it all up.

I understand OpenSource and I'm quite pleased the c5 core team haven't wasted hours trying to enhance Redactor but applied their time to a better c5. Its just a shame that now we have a weakness in the core because they made the choice they did. For sure, if I had the expertise I'd be more than happy to code in an alternative editor as a package - I'm just not that good with c5 (yet).

TheRealSean replied on Nov 26, 2014 at 10:41 pm Permalink Reply

I agree.

I also think it would be nice to be able to switch out Redactor with an editor of choice so far it has both impressed me and left me wanting more. The lack of editing functionality has been a big hindrance, I'm currently regretting using 5.7 for this latest site I am working on for that very reason. It was just easier to do in TinyMCE even if a little clunky

MrKDilkington replied on Nov 27, 2014 at 1:17 am Permalink Reply

I imagine that swapping out the editor for something else at this point would be a lot of work.

In comparison, building plugins for Redactor would be less work.

mhawke replied on Nov 27, 2014 at 4:14 am Permalink Reply

The current iteration of Redactor is integrated into concrete5 so that you can add links to internal pages and add images/files from the File Manager. Any 3rd party editor would also have to be modified to provide this important functionality.

alanski replied on Nov 27, 2014 at 7:36 am Permalink Reply

I had a look at the code base for redactor yesterday and the way it is integrated into C5.I was hoping to find a more packaged editor implementation but it seems very embedded.

On the upside i did look at redactors api quickly which suggests that its inline style method can be used to inject inline styles or - more importantly - add a class!
ref:http://imperavi.com/redactor/docs/api/inline/

So all we need to do is figure out how to make a plugin and where to call it in C5 then make it into a package of some sort :)

keeasti replied on Dec 13, 2014 at 7:34 am Permalink Reply

Totally agree with you. I have no idea why any end user would prefer Redactor over TinyMCE or CKEditor... It is just too basic - how would a user even add a special character?

I also don't like the code it produces. There may well be a reason why the team like it better but from an end user point of view, I think it is a retrograde step.

There is this addon in the market place but alas only for 5.5.0 — 5.6.3.2:

https://www.concrete5.org/marketplace/addons/flexible-content/...

which may do the trick if it can be made to work with 5.7

I am not feeling the love for 5.7 yet ... I find all that sliding left and right off-canvass editing irritating, no editable areas indication etc. etc.

Dare I say <cough> Windows 8 <cough> moment?
Just bring back the start button already ;)

mesuva replied on Dec 17, 2014 at 9:24 pm Permalink Reply 3 Attachments

This morning I had a proper go at creating a plugin for Redactor, to handle the insertion of special characters.

It took me about 2 hours to write - it might need a bit of tidy up (and I'm not sure what to do with translating the text), but gee, it was really nice to write.

THIS is why I think Redactor is a great inclusion. It might not at this point have quite as many features are TinyMCE, but because it's API is clean and modern, we'll have a much better time expanding it to meet concrete5's specific needs.

I wrote it for version 10 of redactor, so this isn't immediately able to be included, but when the redactor version is updated to version 10 it should be pretty easy to include.

Here it is on github.
https://github.com/Mesuva/specialcharacters_redactor_plugin...

Screenshots attached.

-Ryan

WebcentricLtd replied on Dec 18, 2014 at 3:08 am Permalink Reply

that's really good - and really encouraging (nice to hear something positive about redactor for a change). Is the code that comes out of Redactor 10 any cleaner?

MrKDilkington replied on Dec 18, 2014 at 7:45 am Permalink Reply

@mesuva

Very nice job on the plugin.

This might encourage others to make Redactor 10.x plugins too. Which in turn might make updating Redactor in concrete5 5.7 a priority for the core team.

Getting Redactor features fleshed out will cross off a major user experience complaint.

briggers replied on Dec 18, 2014 at 7:58 am Permalink Reply

Very good - that makes 15 redactor plugins available! In another couple of years it might have the same capability as Tiny.

Now we need only another 250 plugins to give redactor a similar versitility and flexibility as, for example, CKEditor.
500+ man hours, £30,000 development cost to get equivelence to something that's already available and free of charge (although some of the 260+ plugins do have a charge)

And I'd really like to understand why mhawke's clients would be glad -
Quote"My clients will be VERY glad to see tinyMCE gone. Very glad."

Do they all work for redactor?

I'd prefer the core team to work on an alternative - almost any alternative.

mhawke replied on Dec 18, 2014 at 8:50 am Permalink Reply

I welcome Redactor because a lot of my non-techie customers have to put TinyMCE into HTML mode to fix something that cannot be fixed otherwise and then I get a support call to fix the mess they made. At the moment, Redactor has the same problem but I have faith in it's future. As far back as 2005, I built FCKEditor (predecessor of CKEditor) into websites so this is not my first rodeo when it comes to online editors. If you follow the forums for the past many years, you will find lots of people who have been frustrated with trying to customize the behavior of TinyMCE.

The core team made a decision based on Redactor's ease of extendability and I personally believe it is the correct long term choice. I also believe that it's unfair to suggest that it is not a priority for the core team. I think they simply have bigger fires to put out at the moment. If you want some features that aren't availabe, dig in and built it. That's why it's a free, open source project. My clients will never need 250 plugins and I don't want to load my systems with all that bloat so I much prefer the 'a la carte' model.

MrKDilkington replied on Dec 18, 2014 at 9:18 am Permalink Reply

@briggers

After looking at the Redactor API, I understood why Redactor was chosen for 5.7. They wanted something easily customizable and extensible.

I can understand being frustrated with the lack of features though. This is where the open source part comes in. People can adopt a feature to develop and if enough people take part, we could knock this out pretty fast.

We can all succeed by working together.

alanski replied on Dec 18, 2014 at 10:06 am Permalink Reply

Interesting that Perch CMS has OEM licence similar to Concrete5 and similar issues. Problem is there is no support model/process that is clear to answer questions.

Biggest bane is the spans inserted. How to get rid of these? It seems crazy by default but to get a questions answered officially from Imperavi (Redactor) is awkward to say the least so its left to developers with biggest itch to dive in? Id say Concrete 5 core team should be easing this itch with us as fast as possible. PLease....it is xmas season :)

MrKDilkington replied on Dec 18, 2014 at 10:43 am Permalink Reply

"Biggest bane is the spans inserted. How to get rid of these?"

That was going to be the first plugin I intend on making. It also seemed like a good starter task to learn how to make plugins.

A bar of soap for an icon, maybe a brush, with a drop down that has formatting reset/format scrubbing options (for everything and individual selections).

Example plugin idea: select all and strip formatting
Use selectAll and stripTags to remove the span tags and leave stuff like a, h1-h6, p, br, etc.
http://imperavi.com/redactor/docs/api/selection/#api-selectAll...
http://imperavi.com/redactor/docs/api/clean/#api-stripTags...

Example plugin idea: remove spans with an empty style attribute <span style="">

This is the current behavior of Remove Style
Before:

<p style="text-align: center">
   <span class="title-caps-bold">Presenting your Business has never been so easy</span>
</p>
<p style="text-align: center;">
   Pellentesque ultricies ligula vel neque dictum, eu mollis tortor adipiscing.
</p>
<p style="text-align: center;">
   Etiam congue, est vel tincidunt vestibulum, nunc nunc porta nulla, at adipiscing neque tellus quis urna. 
</p>

After: select all the text and use Remove Style under Custom Styles

<p>
   <span><span style="">Presenting your Business has never been so easy</span></span>
</p>
<p>
   <span style="">Pellentesque ultricies ligula vel neque dictum, eu mollis tortor adipiscing.</span>
</p>
<p>
   <span style="">Etiam congue, est vel tincidunt vestibulum, nunc nunc porta nulla, at adipiscing neque tellus quis urna. </span>
</p>

alanski replied on Dec 18, 2014 at 12:53 pm Permalink Reply

@Karl,
Re-reading i just wonder if the effort for Redactor is worth it.
If another editor can be integrated it seems a lot of pain might be reduced by taking this route rather than writing plugins for commerical software bundled in.

I had a quick look at the code but couldn't really tell if plugging in another editor was feasible as Redactor seemed quite embedded. AT least it looked like the task might be overriding core quite heavily. Doe anyone have a line on this route?

JohntheFish replied on Dec 18, 2014 at 1:14 pm Permalink Reply

Funny thing is, there used to be several very similar threads about tinyMCE and the quality of html it generated.

briggers replied on Dec 18, 2014 at 10:39 am Permalink Reply

@mhawke

It's a blight for all of us to have to sort out the clients' HTML produced by an editor whether it be redactor or tinymce. I invariably end up copying out into a desktop text editor with syntax highlighting, cleaning it up and copying it back. It's just that redactor with so little formating control is worse than anything else I've used going back even before and including FCKeditor. And none of my clients are computer techies even when they are techies in other subjects.

Perhaps you can tell me how, using redactor in c57, one can set table and column widths without switching into html mode, because I can't find it but then I've only been working with computer programming since 1971 and the first website I built with FCKeditor was in 2000 so maybe I've still got some way to go. That's just a basic feature that's missing as far as I can see.

You are certainly right about not wanting to bloat an editor with 250+ plugins, and to use your analogy an 'a la carte' approach is certainly best, but when there are only 14 items on the menu, and some of those are no more than half cooked, redactor is more like a 'pasta sauce' jar - just add meat and spaghetti and cook it yourself. Adding a plugin for tinymce or ckeditor take a few seconds. Adding a plugin for redactor involves writing it first - wow, now that's what I call frustrating.

And filling up a page with <span class="xxx">yyyy</span> ain't going to make sorting out the html any easier.

I did not say or imply " .. that it is not a priority for the core team." I'd agree with your comment "I think they simply have bigger fires to put out at the moment." I did say/imply I thought their time could be put to better use than improving redactor by dumping it and incorporating something else with a better feature set.

@MrKDilkington

The redactor api is no easier for customisating and extending (they just claim that as a sales feature) than the ckeditor api so why chose the editor that will need more customisation and extension than everything else. And redactor is not open source, it's tied up in a commercial licence.

Redactor claims 10,000 clients/developers and 50 million users (5,000 sites per developer???? or does each content editor count as a user) ckeditor claims 715,000 registered developers - I wonder where the real add-on development effort is going to be focussed.

mhawke replied on Dec 18, 2014 at 11:02 am Permalink Reply

According to their Wikipedia page, the FCKEditor was first published in March, 2003 so I'm not sure how you were building with it in 2000.

Look, this is starting to resemble a Linux vs Microsoft fanboy thread so I will not wasting my time on it anymore. The decision has been made. If you don't like Redactor the way it is now then pitch in and help make it better. If you've been programming since 1971 then you should have quite a bit to offer.

https://github.com/concrete5/concrete5-5.7.0/issues?q=is%3Aissue+is%...

Or build a c5 package that incorporates CKEditor.

keeasti replied on Dec 18, 2014 at 11:29 am Permalink Reply

Not sure about fanboy-ism ... at the moment Redactor is poorly featured. It may be great one day when it is fully fleshed out but for now it is not very usable. I actually don't give a hoot which text editor is used so long as it is easy to work with, has the necessary features and produces good code.

briggers replied on Dec 18, 2014 at 11:56 am Permalink Reply

Actually in 2000 I used a content editor called ACE, written in visual basic and ran on IIS and, if I remember correctly, called and use editor functions built into Internet Explorer 5 or 5.5 but wouldn't work in any other browser at the time.

I'll skip over the "fanboy" bit. I just think it's a real shame that a brilliant system like c5 is hobbled by a poor editor when there are functional alternatives. And I'll restate @MrKDilkington comments at the start of the thread "The issue I see is the move to Redactor takes the user editing experience a step back. In a push towards being as simple and clean as possible, important features aren't being included. This makes the editing experience very bare bones."

One of the things I did learn in my 40 years is that if you have a piece of software that just does not do what is needed you can spend an infinite amount of time and money trying to correct it and so is usually quicker, easier and cheaper to rewrite it.

What I am advocating here is for Redactor to be dropped until it is a mature and fully functional editor which produces clean and w3c standard code and replaced with an editor which is fully functional - I don't care which but suggest that TinyMce and CKEditor seem to fit the requirement and I know both but there may be others which are better.

I also know that for a couple of clients for whom I want to build sites using c57 I can't because the current editor simply is not up to the type of content they would create - c56 with TinyMCE works fine and I'll stick with that. I won't write add-ins for a commercial product like Redactor - if its producers (who charge for it) can't be bothered to make it work properly then I can't either. OK, they have found a market to serve and can make money from it - good, that's commerce but I'll not put my time or money into their profit, I'd rather make a donation to a genuine opensource developer - like c5 to incorporate an opensource editor.

... And if you can tell me how to format a table in Redactor without reverting to the html editor I'd even send you the price of a beer.

mhawke replied on Dec 18, 2014 at 12:06 pm Permalink Reply

One thing that does concern me about Redactor is the fact that plugins for version 9 are incompatible with version 10. The c5 community is having a fit because all add-ons need to be re-written for 5.7 so are we walking into a similar situation with Redactor? What is their philosophy regarding backward compaitility for the plug-ins we write?

keeasti replied on Dec 18, 2014 at 11:31 am Permalink Reply

@mesuva
Well done, Sir!

virtualgt replied on Jan 15, 2015 at 8:39 pm Permalink Reply

I chose Concrete5 as my CMS system of choice for my company Intranet based on one simple test... copy text from other HTML sources and paste into the content block. Then see what it looks like when you Save. Tables present the toughest challenge. Try copying tables from websites or from Google sheets.

Redactor is the BIG loser!

TinyMCE is light-years ahead of Redactor but CKEditor is the very best. Is there some reason why C5 v5.7 isn't using CKEditor?

I cannot consider upgrading to version 5.7 until I can properly copy, paste and format tables in my content blocks.

Hopefully, with all the comments posted here, we will see some changes in the near future.

mesuva replied on Jan 16, 2015 at 2:01 am Permalink Reply

This might come down to your expectation of what a content editor does when you paste content from somewhere.

Do you expect it to retain all of its visual formatting or do you want it to just strip it down to the basics like paragraphs and headings?

Personally I want the editor to help me keep content and styling as separate as possible. When content is pasted in, I want it to match the site's formatting, not look like the source.

My experience so far with the editor has been pretty good. It does what I need it to do and I really love the fact that the styling of the content as you are writing it matches what it will look like. That's true inline editing. From a development point of view I'm now also not having to think about a typography.css file, that's a bonus.

There are certainly a few things missing from the editor at the moment, but most of these things can/will be solved by the inclusion of some plugins (special characters, sub/superscript, etc). Table editing is lacking, but to be honest I try and avoid tables in a content block anyway, I don't think it's a particularly nice way to handle such content.

On sites where we've needed tables a lot, we've either used a table attribute or special block to output tables - our clients just paste their data and they're done. (yes I'm aware that these aren't out of the box, we've built custom things for these purposes). Tables should be for tabular data and therefore I think the often warrant their own block.

To answer your question directly though, I'd suggest the main reason Redactor has been selected is that it is much easier to embed it into concrete5 and extend it with custom features than other editors. Going into the future, as Redactor continues to be developed, concrete5 will be able to simply update the Redactor script as opposed to maintain it's own custom version of the editor (i.e. lots more work/pain).

So it could be just a matter of letting it mature a bit more and sticking to 5.6 for a bit longer (as it would better meet your needs right now), or considering a different way to pasting in and handling things like tables.

virtualgt replied on Jan 16, 2015 at 3:45 am Permalink Reply

Thanks for your insights. I can certainly understand from a web developer's
perspective how Redactor works for you. But my only interest in Concrete5
is to create Intranets and so need to transfer existing data from wikis
like Confluence, data from websites and spreadsheets from Excel and Google
to make this existing data available in an organized, readable and
accessible way.

Currently, CKEditor is the only HTML text editor that I can paste a Google
sheet with merged rows or columns, background colors, text color, and text
effects and have it look ANYTHING like the original Google sheet.

When pasting into Redactor, not only is all this formatting lost but there
is no way to reestablish it. At least with TinyMCE, I can touch up a few of
the issues and get it looking pretty close to the same. I've also tried
pasting tables from websites and Redactor is the only text editor of the
three I've mentioned that actually loses data on paste! This is
unacceptable for my needs.

I do love v5.7 so hope you are right that eventually there will be
solutions for tables. I presume your solutions are not available as Add-Ons
yet and I don't have the coding savvy to roll my own.

*UPDATE*: I actually just blew myself away! I forgot about a solution that
I had come up with after doing a bit of research on this subject. I found
that by pasting tables into the "Design" window of Kompozer, a great open
source HTML authoring app, and then copying the HTML from Kompozer's Source
window, I can paste the HTML into Concrete5's Content Editor as HTML code
and it looks exactly like the original. This works for both 5.6 and 5.7, so
there's the solution!

This even resolved the problem with a website table that when copied from
the website and then pasted into Redactor, lost the first column. Now has
all the data AND looks identical.

mesuva replied on Jan 16, 2015 at 4:42 am Permalink Reply

That's fantastic to hear that you've come up with an effective workaround.

My main point really was that it sounded like your usage scenario was a bit outside of the main purpose of the content editor, so that it's not that the new editor is not up to scratch as such, more that perhaps your needs are simply different to what Redactor provides.

It sort of sounds like you'd do well with a custom block for your site that utilises CKEditor. I reckon that it wouldn't be that hard to package up by itself. The hard bit is integrating the c5 specific stuff like linking in pages and files, which maybe could be skipped in your case - you'd really just need the basic editor and that's it. You could then use that for cutting and pasting complex tables, etc, while using the normal 5.7 content block for everything else.

In essence I'm saying that it's a case of finding the right block for the job!

I've never actually used CKEditor before, I might take a quick look myself.

mesuva replied on Jan 17, 2015 at 2:57 am Permalink Reply 1 Attachment

Just an update to this - I had a look at CKEditor and put together block using it. I've used the editor's inline editing mode, so it behaves very similar to Redactor.
I've pushed this up to github here:https://github.com/Mesuva/ckeditor_content...
(Screenshot of it in action attached to this post)

It actually didn't take very long to get working, but all this really does is enable the editor - it DOES NOT include integration with c5's file manager and sitemap. That integration is a lot more work and not something I'm not really intending to do, but if someone is keen to do this they're welcome to use the package as a base.

CKEditor is pretty nice, there's a crazy number of plugins and configuration options. The package is set up so that you can just drop in your own configuration of ckeditor into the vendors folder. I used the 'Standard' config of the editor with the Bootstrap theme and added a few extra little features, but that config is all self contained in the ckeditor folder.

So this might be handy for those that have some particular need to copy and paste lots of unusual content (as per what @virtualgt described for example), but I'm NOT suggesting it should replace Redactor, I'm only putting this out there as an auxiliary option.

It is also kind of nice to know though that if for whatever reason Redactor does need to be replaced (i.e. the Redactor guys abandon their project), we do have alternatives like CKEditor.

danielgwood replied on Jan 16, 2015 at 4:04 am Permalink Reply

Quick note: I've hacked together a simple plugin based on AndyJ's work which adds underline, undo, redo, sub and superscript to the editor, if anyone wants that I'll post the code.

It's for (and has only been tested on) 5.7.2.1, but I'm hoping to upgrade to 5.7.3 next week.

Probably not going to go any further with it right now, because although I want many of the features in your list, if C5 upgrades to Redactor 10 a good number of my concerns will go away.

MrKDilkington replied on Jan 16, 2015 at 4:22 am Permalink Reply

That is excellent, danielgwood.

Redactor is due to be updated to version 10 in the next 5.7.4 release.
https://github.com/concrete5/concrete5-5.7.0/issues/1434...

Andrew: "When we start on this in earnest we will make a feature branch for it and
integrate redactor 10 as quickly as possible, so other people can help add
features to it."

http://www.concrete5.org/community/forums/customizing_c5/5.7.3.1-is...

Andrew: "5.7.4 will feature a number of improvements to Redactor, some new features we'll talk about soon, some support for content export and import from 5.6 to 5.7, and more."


One thing I was thinking about was preventing duplicated efforts at making plugins. It might be useful if people declare their intentions for what features they are working on. This way all the most pressing feature requests could be spread out and done fairly quickly. If someone doesn't get a feature plugin done in time, then someone else could pick it up.

danielgwood replied on Jan 16, 2015 at 5:10 am Permalink Reply

Heh yeah I saw that - that's why I'm stopping. I suppose it's more a case of "when" Redactor 10 comes rather than "if".

Once Redactor 10 is in I'll revisit this I think, and will be posting code/plans openly on GitHub.

briggers replied on Jan 16, 2015 at 5:17 am Permalink Reply

@virtualgt's solution to pasting preformatted content is certainly workable but the suggestion that we get content editors to develop their pages in some other WYSIWYG editor then copy and past into C5 rather defeats the objectives of having an on-line, in-context CMS. The simple fact is that we have a lawn mower engine (Redactor) powering a Formula 1 car (C5). It ain't going to win many races even with the best chassis!

Fundamentally redactor has several problems:
1. Lack of facilities for real world content editing of anything beyond simple blog type pages.
2. C57 currently has an old version of Redactor (9) and any plug-ins written to overcome its deficiencies are not necessarily compatible with the current version (10). So developing plugins now is a waste for the time when C5 updates to Redactor 10
3. Licencing - incompatability between C5's MIT licence and Redactor's commercial licence.

This latter point was explained to me by two clients, one in a semi-government organisation and the other in a large corporation. Both have organisational policies to ensure that ALL copies of software used in their organisations have been correctly obtained and traceable licences are held on their software registers. All FOSS licences are acceptable so C5 with its MIT licence is fine, but:

1. since it contains propriety, non-open source components - Redactor, they need to obtain the correct licence for that.

2. there is a conflict between the licences - MIT says:
"Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software."

Redactor licence says:
"The OEM License: Holders of the OEM License may use the Software as if they had the Professional license. In addition, OEM License holders are allowed to sell or otherwise distribute the Software to the developers and not only to the end users. The OEM license allows license holder’s clients to develop their own products based on or containing Software. The OEM License holder’s clients do not have to obtain their own Professional or OEM license. The OEM License holders are allowed to integrate the Software with open source products. However, neither license holder nor license holder’s clients can sell Redactor as a sole product (with or without modification); License holder and license holder’s clients should use it fairly; Imperavi LLC still holds all the copyrights for Software code, Software code does not become open source, and we solely determine "fair use" of the Software."

Under the MIT licence anyone can "deal in the Software without restriction" which means they could extract, package up, modify and sell or distribute a version of Redactor as long as it includes the C5 licence. I don't think anyone would want to do that, the effort required would outweigh any advantage since there are more capable editors easily available but that doesn't satisfy the corporate lawyers.

I also thought of developing a specialist block containing an alternative editor but it's rather complex to link it with other core functions of C5 and it would then be rather silly to tell users that they use content block A (with Redactor) for simple stuff and content block B for everything else.

So for me, there is one section of the market that can't use C57 even if it wants to.

This issue with licencing is recognised by other companies releasing open source software such as Canonical Ltd with Ubuntu Linux and Red Hat with Fedora Linux. The way they deal with the issue is to provide the core system as one download with its open source licence and offer the non open source software as a subsequent download, each propriety package under its own licence. So C5 could be offered as a package without an Editor under MIT and the editor (Redactor) as a separate package under its licence, then have a routine as part of the installer which merges the editor into the main package.

keeasti replied on Jan 16, 2015 at 12:56 pm Permalink Reply

Does anybody know why TinyMCE was ditched?

Hypocrite replied on Jan 17, 2015 at 3:09 am Permalink Reply

I think the main reason was that concrete5 was moving towards inline editing and at the time tinyMCE was in version 3.x which did not really support this.

The funny thing is that not long after it was announced that concrete5 was replacing it with Redactor, tinyMCE 4 came out and that version does support inline editing.

I think it would be really cool if concrete5 would offer options for different editors like they do for grid frameworks.

Of course integrating different editors is more work than grid frameworks but to be honest, I don't think there really are more than three competitors in the market; tinyMCE, Redactor and CKeditor.

mckoenig replied on Feb 2, 2015 at 10:53 am Permalink Reply

Sorry if this has been already said in this discussion but the urge to post it is just overwhelming:

I just cannot wrap my head around the decision to switch from TinyMCE to Redactor. I'm getting hammered by customers who have next to no control about how their content looks like. And there is no easy way to add absolutely basic features such as a real color chooser and font sizes. Come on! This might be a devs dream but it's a nightmare to any customer who just wants to change his content around.
Redactor (at least the version that ships with C5.7) is lacking so many standard features it's absolutely mind boggeling how anyone could have thought it's a bright idea to switch to it. For now I'll be using 5.6. Redactor makes 5.7 useless to me.

Sorry for the rant. But I needed to say it ;)

keeasti replied on Feb 3, 2015 at 8:09 am Permalink Reply

Hear hear!

MrKDilkington replied on Feb 24, 2015 at 10:22 pm Permalink Reply

This link was posted in another thread.
http://premium.wpmudev.org/blog/introducing-upfront/...

It's a front end editing tool for WordPress. I am posting it here because it is made with Redactor (not exclusively Redactor though).

This is a clear example that we aren't coming close to the potential of what Redactor can do. There are all sorts of neat things we can make, the only limitation is our imagination.

Have good user interface and workflow ideas, but don't know how to program? That isn't a problem, you can still participate and contribute by sharing your ideas. Others who can program can implement those good ideas.

growlrooed replied on May 9, 2015 at 5:23 pm Permalink Reply

I am totally in agreement. This editor is ridiculously basic. I have to build custom blocks with the HTML baked in just so my clients don't beat themselves (or me) over the head when they try to post content.

Plus there's features that should be standard like allowing divs, tables, custom styles, etc. Seriously?

What would be useful is a post on how we can go in and add all the plugins that are available for Redactor which seemingly are missing from the version put into CC5.7.

Furthermore, I'm noticing an inconsistency with the redactor plugins within the site. In the content block, you call up the redactor and you get a version where you can't change font colors. But in a custom designed block you call up a version of redactor that has it!

I tried installing the latest version of redactor in application/js/ and that just causes havoc with the editor.

oy.

MrKDilkington replied on May 10, 2015 at 5:40 am Permalink Reply

@growlrooed

I agree that features are very basic right now. There is good news in this area, with the release of 5.7.4, Redactor has been updated to version 10 and there is a new plugin registration method.

With 5.7.4 plugins can be made to add additional features. Once a plugin is made, it can be installed as a package. Users will be able to download Redactor plugins from the marketplace like other add-ons. This will allow for picking and choosing of plugins based on project needs.

In 5.7.4, plugins are enabled individually in a new dashboard page "Rich Text Editor". From this menu you can enable font color, font family, font size, underline and packaged plugins.
Dashboard > System & Settings > Basics > Rich Text Editor

There is a new method for adding Redactor to blocks. By default, it will make all enabled plugins available for use. Plugins can also be enabled or disabled on a block by block basis.
https://www.concrete5.org/documentation/developers/5.7/interface-cus...

Packaging Redactor plugins
https://www.concrete5.org/documentation/developers/5.7/interface-cus...

Redactor by default replaces <div> tags. In 5.7.4 this can be turned off with "replaceDivs: false". Changing this setting requires overriding Redactor, so I think there might be a better way of handling this.
https://www.concrete5.org/community/forums/5-7-discussion/div-replac...

The version of Redactor that comes with concrete5 is customized with concrete5 specific settings. Attempting to override it with a "vanilla" version of Redactor will cause problems or not work at all.

Dushka replied on Feb 24, 2015 at 1:16 am Permalink Reply

A feature that would be very handy would be the ability to add a caption to inserted images. However, a workaround solution is not that difficult. All one need do is insert a table then insert the image in one cell and write the caption in the cell below.
Another urgently-needed feature for myself is the creation of anchor tags and links to them. I plan to post articles with a considerable number of footnotes that I can link to from superscripted numbers in the body of the text. Help!

csebe replied on Apr 30, 2015 at 10:53 am Permalink Reply

Hi Dushka & others,

Have a look here:http://www.concrete5.org/index.php?cID=729897... and let me know if of interest in the current format.

EDIT (2015-05-10): I have finished up a second version of the "Anchors" plugin:
https://github.com/csebe/anchors_redactor_plugin...
For me, it does what I needed/intended:
- create anchors with name entered manually
- create anchors from selected text (name "calculated" automatically)
- create anchors automatically for every H1...H6 found in the content
- create a table of content from all found anchors

The main issues with it are:
- Concrete5 installation is really manual...
- TOC look is ugly and needs customizing in the code.

Cheers,
Lian

alanski replied on Apr 30, 2015 at 12:19 pm Permalink Reply

that links to anhcor discussion is a bit squiffy
http://www.concrete5.org/index.php?cID=729897...

tduncandesign replied on Jul 10, 2015 at 12:10 pm Permalink Reply

Also came looking for image captions in Redactor this morning, and I got along OK with http://captionjs.com. This way my client won't have to mess with tables, just enter the "title" attribute on image edit in Redactor -- configs allow you to inherit styles (such as float right, margin, etc) from the initial image before it is put into the figure/figure caption format by caption.js.

bosko1982 replied on May 12, 2015 at 1:38 pm Permalink Reply

Hi,

I want to use

$thumbnail

or picturefill for images that were added thru Redactor, is this possible?

Thank you.

MrKDilkington replied on May 13, 2015 at 2:26 am Permalink Reply

@bosko1982

That is an interesting question. I don't know if <picture> can be used for images.

bosko1982 replied on May 13, 2015 at 9:32 am Permalink Reply

Thank you, i donk know it too, but meybe will someone get it working and C5 will be more of features :)

goodnightfirefly replied on May 13, 2015 at 3:42 am Permalink Reply

http://www.concrete5.org/documentation/developers/5.7/designing-for-concrete5/supporting-responsive-images-in-your-concrete5-theme/

Read the "Map Screen Widths to Thumbnail Types" bit halfway down.

Basically, your theme page_theme.php needs to have a getThemeResponsiveImageMap() method, and Redactor will output responsive images.

bosko1982 replied on May 13, 2015 at 9:29 am Permalink Reply

@goodnightfirefly,

Yes, i have all done what is written in tutorial and its working fine on all blocks (Image, Pagelist, Slider). Picturefill is loaded wity my theme.
But its not working in Redactor, picturefill need tag "<picture>" to get working, what i read.

here is example of image on Image block and in Redactor: (its 4k image 1,5mb, my internet speed its not wery good)
http://hozo.sytes.net/concrete5.7.4RC2_clean/blog/test-4k...

try to resize browser and see its working fine with Image block.

Or i am doing something wrong..., please teach me to get working if not its a feauture request. :)

my english bad, but i hope you understand :)

Thank you

MrKDilkington replied on May 13, 2015 at 11:24 pm Permalink Reply

@bosko

The picture element is supported in Redactor, but the feature was broken when Redactor was updated to version 10.

This will be fixed in 5.7.4.2.

This is why there was confusion about using <picture> in Redactor.

bosko1982 replied on May 14, 2015 at 10:07 am Permalink Reply

Avesome, great to hear that.
Thank you.

1976Ltd replied on May 13, 2015 at 6:15 am Permalink Reply

Not sure if this is the best thread to be putting this in but it would be amazing to see Monotype's Web Font platform integrated with Redactor.

http://www.monotype.com/services/font-design/web-fonts/web-font-pla...

MrKDilkington replied on Jun 2, 2015 at 5:51 am Permalink Reply

I added a new plugin.

Anchor Tag Link and Target
https://www.concrete5.org/download_file/-/79617/...

What it does:
- add anchor links using the concrete5 page selector
- add anchor link targets
- show and hide anchor links
- show and hide anchor link targets
- remove anchor links
- remove anchor link targets

csebe replied on Jun 4, 2015 at 11:52 am Permalink Reply

Hi all,

As one of the (really minimal) contributors to Redactor (through the Anchors plugin that might be very well forgotten soon, as some other people integrated anchors much better with C5) I must say I kind of hate Redactor too.

Is not that it is not extensible and I understand certain people might like its apparent simplicity. It is just completely blur for me why the whole community should work now like hell to re-invent another wheel, whilst we had one working very well before.
Any arguments like: "people complained the same about TinyMCE" don't stand, as we're supposed to learn from mistakes and hold on to the things we have already working.
This unilateral decision of changing the default editor (and the only one accepted) in 5.7 generated a lot of extra working hours for many of us, partly to investigate really strange issues that finally led to Redactor as the culprit, and partly to find workarounds/create plugins for simple features that should have been there, working perfectly already.

No disrespect to the C5 team, I think it is a great product but this Redactor is $#"$**"$^^...
Now that I got this off my chest, please allow me to introduce you to my latest wall I hit with Redactor, nothing a plugin may fix I reckon (the bug was tested in 5.7.4.1. and 5.7.4.2):

Please try to use <pre>...</pre> tags in a content block.
Option 1: Do it visually (WYSIWYG)
- Click inside the empty content block.
- Click on "Code" under the Formatting (reversed P) button
- Add there few lines, like:

line 1
    line 2
line 3

- click the "Save" blue button, and you'll see instantly how the line breaking are not preserved. So much with respecting the <pre> html tag purpose.
- for even more fun, click "Edit" on the newly added block, to edit the 3 lines. You'll see this instead (on 5.7.4.2 only):

line 1  <span class="redactor-invisible-space">line 2  line 3</span>

and it is not possible to get out of the what looks like the "pre" area anymore.

Option 2: switch to HTML mode and then add the 3 lines like:

<pre>
line 1
   line 2
line 3
</pre>

You'll see that switching repeatedly wysiwyg <-> html is not breaking it. However, when you save, it behaves as in Option 1.

So, after about 2 month working on automating the importing of an old website with ~5000 articles/pages into concrete 5.7 (and succeeding!) how am I supposed to tell the client, a professional editor, they cannot create pages like thishttps://www.virusbtn.com/virusbulletin/archive/2010/10/vb201010-just... anymore?
I have found a stupid way to fool the system and import the articles with the needed formatting, however, the moment a page is put in edit mode and then saved, everything is lost as described above and looks really ugly.

Regards,
Lian

mhawke replied on Jun 4, 2015 at 4:59 pm Permalink Reply

It might be fixed in an update that's just been released today:

http://imperavi.com/redactor/log/...

csebe replied on Jun 5, 2015 at 5:39 am Permalink Reply

Excellent timing from them and good eyes in your case :)
However, how can I update to latest version to see if fixed, if the "thing" is not free? I guess I need to wait for C5 team to integrate the new Redactor version in C5, right?

(On a side note, I like the comment in their log: "Minor glitch with <code> formatting adding extra code on Return". Messing up the whole page by using one of - not so many - built-in buttons, doesn't look minor to me.)

mhawke replied on Jun 5, 2015 at 7:17 am Permalink Reply

Yes, we will have to wait for the core to start using the most recent version. I have found that if you add the desired 'pre' content to the editor and then highlight it and chooser the 'pre' formatting on the toolbar then it works. If you choose the 'pre' formatting first and then fill it up then the problem arises.

As Maino points out, his CKEditor solution is not ideal because you can't choose images or files or pages from the concrete5 infrastructure so that's not really a solution for my clients yet. If someone (smarter than me) could have a look at how the core team has added hooks into the c5 File Manager and Sitemap into Redator's native 'link' dialog then perhaps it's possible to add these two buttons to any content editor.

mesuva replied on Jun 5, 2015 at 8:49 pm Permalink Reply

Yes, I'll stress the point that the package I whipped up is really just a proof of concept that another editor could be pulled in and used with inline editing. It might be handy for someone to wrangle some custom bits of content, tables, etc, but it lacks the file manager and sitemap integration that would be needed to use it in place of the existing Content block.

I didn't have the time (or business case) to invest in working out how to do this integration, but I put it on github in case someone else does.

I'm a big believer that complex HTML shouldn't be placed in Content blocks, that's what custom block types are for, but I appreciate that there are some scenarios where it's necessary.

Mainio replied on Jun 4, 2015 at 5:13 pm Permalink Reply

Although I can see your level of frustration in your post, very well said there. Especially the part about re-inveting the wheel.

In my latest project, redactor has served well as a plain HTML editor for me. It creates very messy HTML with all its added span elements to the source and it doesn't support simple things like adding a class directly into the list element or the paragraph element. It just has to create an extra <span> every time. Even making proper <blockquotes> turns out to be a horrifying experience with Redactor.

There are already alternatives out there for the frontend:
https://github.com/Mesuva/ckeditor_content...

But it doesn't currently probably help much as we still have Redactor in all the other editing views which provide rich text editing.

csebe replied on Jun 5, 2015 at 5:49 am Permalink Reply

Thanks for sharing this!

I was literally just starting to investigate how hard it would be to create a custom block that simply integrates another well known editor in it! I mean, I guess TinyMCE is delivered as just one .js file (and maybe on .css) that has its functions "listening" to a predefined textarea element events.

Anyway, I am glad that Mesuva thought of this and already did it (at least partly), 'cause my JS/Jquery/PHP skills are quite limited.

I'll give it a try!

MrKDilkington replied on Jun 4, 2015 at 10:44 pm Permalink Reply

@csebe

I can confirm that using <pre> tags in the HTML view or code formatting doesn't respect line breaks. When saved, the contents of the <pre> tags are all jumbled together.

@Mainio
I made a plugin for applying classes and ID's on elements.

Add and Remove Classes and ID's
- add and remove classes and ID's on block elements
- add and remove classes and ID's on links
- add and remove classes and ID's on images (images must be drag selected/highlighted)
http://www.concrete5.org/download_file/-/79131/...

Right now the custom styles are applied by wrapping the selected text in a <span> and then applying the custom style class to the span. I believe I can make a plugin that applies the custom style directly on the element. Based on the selection/cursor position, the closest block level element will get the custom style.

You still need to be able to apply custom styles to inline text, so there could be two custom style options - inline and block.

inline
- wraps inline text in spans to apply the custom style

block
- apply the custom style directly on the block element

MrKDilkington replied on Jun 6, 2015 at 1:37 am Permalink Reply

For those who are unhappy with Redactor, there might be additional options.

This is a forum reply from Andrew on June 5, 2015:

"The editor_config.php element was removed in favor of a better way of providing rich text editor support in 5.7.4. This way allows developers to specify which plugins they want to use, etc... and potentially even support multiple editors at some point in the future"
https://www.concrete5.org/community/forums/5-7-discussion/editor_con...

The other main editor options are TinyMCE and CKEditor. Both have their pros and cons. No single editor is going to satisfy all the needs of every user.

TinyMCE
http://ckeditor.com/demo#full
http://ckeditor.com/demo#inline...

CKEditor
http://www.tinymce.com/tryit/full.php...
http://www.tinymce.com/tryit/inline.php...

If the core team is asked to include additional editors (or replace Redactor), there needs to be substantial effort in investigating other options. Individuals need to take the initiative to look for alternatives and test them. No progress will be made by requests for something else without supplying alternatives.

growlrooed replied on Jun 8, 2015 at 4:01 pm Permalink Reply

I'm pretty much at wits end with Redactor. I'll take the challenge with trying to go back to TinyMCE or CKeditor.

What do I need to keep in mind when trying to install one these back into CC5.7.4? It's probably way over my head but it has to be a better solution than this just awful Redactor.

briggers replied on Jun 8, 2015 at 6:11 pm Permalink Reply

Here here.
I'm really trying to like 5.7 but 9 months and 12 version releases we still have a totally inadequate rich text editor (RTE).
I can't help but feel that the sterling effort being made by a few community developers to create Redactor add-ins is just spitting into the wind. Currently there are just half a dozen add-ins which are far from bringing its functionality up to even the most basic TinyMce or CKeditor level and they have hundreds of add-ins going much further than that.
I think a radical approach is needed. How many of us, who would like to use 5.7, would be needed to "Crowd Fund" a developer to work along side the core team to replace Redactor - or at least create an alternative RTE version using a fully featured editor like Tiny or CKEd? That would surely be a more effective utilisation of resource than a piecemeal development of add-ins.
The wider, non-concrete5, community is never going to develop many add-ins - after all if you are spending $40 to buy a product you are clearly happy with what it offers and don't want or need any add-ins. If one did, one would select an alternative with the functionality already to spend money on.

growlrooed replied on Jun 8, 2015 at 6:46 pm Permalink Reply

I couldn't agree more. I would happily pay into a fund for a developer (MrKDilkington, there's your cue.) to kick out a decent rich text editor.

mhawke replied on Jun 8, 2015 at 7:07 pm Permalink Reply

Perhaps I'm confused. There's a marketplace for add-ons like this so why pay in advance? It's no mystery that a content editor that uses a different RTE and has access to c5's sitemap and file manager would sell quite well but I don't think that solves the real problem. What is really needed is an architectural change that permits us to swap in whatever editor we want across the entire system so that users don't have to learn several different RTEs as they edit different blocks throughout the site.

Mainio replied on Jun 8, 2015 at 7:23 pm Permalink Reply

@mhawke:

I think we already have such "architectural change" in place:
https://github.com/concrete5/concrete5/blob/develop/web/concrete/src...

Although, I'm not aware of anyone who would've given it a shot and tested whether it has any shortcomings for editor X.

Theoretically it should be possible through that but the sad news is that even the core doesn't apply that method everywhere where redactor is displayed. So it might take some time to get this fully working without running over the redactor jQuery plugin that is used to initialize each and every instance of Redactor in the core.

mesuva replied on Jun 8, 2015 at 7:05 pm Permalink Reply

Can I ask, what tasks are you trying to do with Redactor that are causing your frustration?
What kind of content are you trying to wrangle?

growlrooed replied on Jun 8, 2015 at 11:18 pm Permalink Reply

OK let me run down the list:

Apply a div...and not have it be stripped out on saves.
Bold type...no matter what the element is.
Apply a class...and not have it stripped out on saves.
Apply a style ...and not have it junk up the code by wrapping everything in a <span>.
Switch between html and rich text view...and not have the html stripped out on save.
Easily embed media without having to use "embedly".
Make better use of, and have easier installs of, the redactor plugins that are out there.

I know it's a tall order, but if you guys can do this feat, you'll make a lot of people happy and put CC5 back up to the esteem it deserves.

mesuva replied on Jun 9, 2015 at 1:33 am Permalink Reply

I think this list sort of comes down to your impression of what a Content block should _do_. My view (and I've put this elsewhere on the forums) is that the Content block should really just be for simpler content, not richly marked up content. So it should handle headings, paragraphs, links, lists and inline images... beyond this I believe that more specific blocks should be used, or at least custom block templates.

So when I look at your list of issues, this is how I see things:

> Apply a div...and not have it be stripped out on saves.
My question here is why are you adding what is a structural element to your content here? If you adding a div to separate something out, perhaps that _thing_ should be added using a simple custom block, where the structural elements/div are already going to be output and you just put in your content. If it's for something like a captioned image, you could instead use the layout tool to create a simple column to place your image and caption instead - the bonus being that things will flow nicely when on mobiles

> Bold type...no matter what the element is.
A strong tag is an inline tag, so it should only be able to be applied to text, not to any element. TinyMCE does allow you to bold something like a heading, but I would argue it doesn't make sense to actually put strong inside or around a heading tag. It's already a heading, so adding strong for semantic emphasis isn't really the way to go. If you are doing this for visual reasons, I'd be saying you need to change your styles, not mark up your headings with strong tags. If you need to visually differentiate between headings of the same kind for some reason, I'd use a class.

> Apply a class...and not have it stripped out on saves.
I just manually added a class to a paragraph and a h2 tag and it stuck when I saved. Are you adding this to div tags that then get replaced?

> Apply a style ...and not have it junk up the code by wrapping everything in a <span>.
I agree that this isn't good behaviour, but I believe there is a plugin in the works that differentiates between block level styles/classes and inline styles/classes. Sometimes you do actually want a span to be applied, but we do need to be able to apply classes to block elements.

> Switch between html and rich text view...and not have the html stripped out on save.
Is this again a case of divs being stripped out? From my perspective if I client pastes in random content from some location, I want it to strip out extra stuff like divs and crud that isn't in my list of 'content' elements I've mentioned above. For example, when you copy and paste from something like a PDF, it often copies in a <div class="column"> - I've had those break some layouts. I'd rather it strip it back to 'safe' content.

> Easily embed media without having to use "embedly".
I don't think the content block is a suitable block for embedding media. That's what blocks like Youtube and the Video block are for, or even just the HTML block. Adding media directly in a content block sort of goes against the whole concrete5 block concept in the first place. Doing it this way also makes it hard to modify with custom block templates too.

> Make better use of, and have easier installs of, the redactor plugins that are out there.
I think this has been resolved in recent versions, plugins can be packaged up and installed like normal, then the plugin can simply enabled with a checkbox in a Dashboard page (the same one where you can turn on colors, etc). I tried one of MrK's packages like that the other day and it was installed in seconds.

I certainly agree with you that there are still lots of improvements that can be made as to how Redactor is used in concrete5, but I'm just saying that maybe it's a case of expecting things to work like they used in with TinyMCE when perhaps it wasn't the best/correct way to do things in the first place.

briggers replied on Jun 9, 2015 at 2:34 am Permalink Reply

To that list I'd add the list from MrKDilkington that opened this thread.

But I think you are totally missing the point. A content block is a free-format block, i.e. it's there for the website owner/administrator to put in whatever they like in whatever format they need. If they feel that their information can best be presented by say, creating a table that is floated to the right of some text wrapped round it or sticking a video in the middle of some explanatory text then that's their choice. It might not be best practice - whatever that is - but it is what they want to do. And it's simply not practical to create custom block templates in advance to cover every possible way of presenting information. Nor is it practical to expect a user to create custom blocks every time he wants a new page format.

Redactor does not provide enough flexibility and without the development of dozens and probably hundreds of add-ins will never do. They may not fit your definition of best practice but Tiny and CK both provide most of what is wanted in their core versions and offer (in the case of CK) 340 add-ins to cover special needs. Of course not everyone needs all 340 add-ins so one can just include those that one does need, and do so without having to write code. Redactor currently has about 20 plugins most of which just improve its core to a feature set somewhat smaller than the alternatives' cores.

My proposal would give you the option, stick with Redactor for simple blogging type sites or use an alternative when something more sophisticated is needed.

mesuva replied on Jun 9, 2015 at 3:49 am Permalink Reply

> A content block is a free-format block, i.e. it's there for the website owner/administrator to put in whatever they like in whatever format they need.

I simply don't agree with this, I don't believe it's _intended_ to be an all-purpose HTML block.

I think your needs are different from ours. We're able to built sophisticated layouts and formatting using Redactor as the editor in 5.7, as we specifically DON'T try to use it do the heavy-lifting. We use layouts, the built in blocks and occasionally (but not that often) custom blocks to ensure consistent formatting and ease of data-entry. We also use the composer and custom page templates, which works great for broader structured data - our clients just use the right process for the right kind of content and they don't have to think about formatting.

mesuva replied on Jun 9, 2015 at 3:49 am Permalink Reply

(removed as it's a double post for some reason!)

¯\(°_o)/¯

briggers replied on Jun 9, 2015 at 4:49 am Permalink Reply

You are absolutely right - our needs are different.

We have a range of clients; at one end of the scale who sells a large range (100s) of industrial equipment and materials who uses his website as a set of specification sheets pre-sale and user guides post sale. He has progresses from a totally static HTML site 15+ years ago through several incarnations of sites using a database and 30-40 page templates to describe the products to a c5.6 site which he has total control over. His pages include diagrams, graphs and tables all of which need to be closely aligned to the related text. Plus footnotes and end notes and cross references to other sections of other pages. At the other end of the scale we have a client who barely needs a RTE at all since almost everything they add goes into forms as plain text and is displayed through templates which format every thing.

The key point is that with c5.6 and Tiny we have a choice, with 5.7 and Redactor we don't. We can accommodate the second example above but not the first. We simply cannot convert the first client to 5.7 because Redactor is so limiting.

In the end, if your clients have simple needs for content then you can accommodate them if they have more complex needs then Redactor cannot do the job. A better RTE would let us meet the needs of both types of client - and everyone in between and we'd all be happy!

mesuva replied on Jun 9, 2015 at 6:08 am Permalink Reply

The example you've described is certainly convincing - I can see why Redactor wouldn't have the features you need to handle that scenario. I'm seeing your point. I've perhaps had the luxery of having 5.7 projects so far where it's been new/simpler content, instead of complex 'legacy' content.

I still think for the _average_ needs of editors, it's still better to have a cleaner/leaner editor for the default content block, but I think your specific example highlights the need for _other_ editors to be available.
On the one hand you're held back from 5.7 adoption because of your complex projects, whilst I'd be unhappy ripping out Redactor and putting TinyMCE back in!

So what we really need is an 'Advanced Content' block, something that could be used for more complex editing tasks, while leaving Redactor for sites/cases where a more complex editor would just cause more headaches than value. I think this has basically been said earlier in the thread.

I'd really love someone to run with the CKEditor 'proof of concept' block I whipped up and investigate what is required to hook into the file system and sitemap... I don't really have much time at the moment, but I reckon if that could get 'finished' as such we'd have the best of both worlds. Redactor for more common tasks (and for inbuilt editing on things like blocks), but CKEditor for handling the advanced scenarios you've described.
(unless you think TinyMCE is still the way to go?)

briggers replied on Jun 9, 2015 at 8:42 am Permalink Reply

Great, we seem to have some common ground.

As a start though, I'd rate redactor as 1/10, TinyMCE as 6/10 and CKEditor as 8.5/10, so your proof of concept is going in the right direction.

However I see your proposal for an Advanced Content block as having a couple of downsides. the first is that the editor would have to be able to access all the core functionality that redactor currently does. Secondly, it would have to be easily configurable through the Dashboard so that some specialised add-ins could be added/removed as specifically required. This would then effectively make the standard content block redundant.

But CKEditor in its standard shape is so easy to configure with buttons (add or delete the name from the toolbar list) and plugins (drop the js file into the correct directory) that giving the user total control of his editing UI even at page level should not be a problem - one could have a "Editor Config" page property with Simple (few formatting options), Intermediate, Complex (many formatting options), Custom (just the ones one needs for the application) - haven't we seen something like that before?

I don't care especially for TinyMCE but it is better in all respects than redactor so I'd really like Andrew or Franz to tell us what would be involved (time & cost) in replacing redactor with CKEditor. We know from your PoC that it's possible. Then we could look for some funding to get it done. :-)

You could then use the Simple config for your clients and I could use the Complex or Custom config for some of mine and everyone else could use the in-between version that suited their clients.

mhawke replied on Jun 9, 2015 at 9:04 am Permalink Reply

How about a page attribute that chooses which RTE to use on that page.

briggers replied on Jun 9, 2015 at 10:21 am Permalink Reply

I don't have a problem with that but I do see some medium to long term maintenance issues with having 2 very different RTEs in the same site.

That would affect both the system core and potentially an editor's content. What would happen if a page constructed using the elementary RTE evolved into something that needed to be edited with the advanced RTE?

So I still favour the argument for a single RTE that can be set to (very) basic for some purposes and varying degrees of advanced for others.

mhawke replied on Jun 9, 2015 at 10:25 am Permalink Reply

Is the HTML output of TinyMCE incompatible with the HTML CKEditor wants to see? Once the HTML is saved, it's just standard HTML right? The October CMS allows you to swap different editors in at a later date without compatibility issues.

JohntheFish replied on Jun 9, 2015 at 10:39 am Permalink Reply

Such a capability would be ideal.

In practice I doubt if any but trivial formatting would run a full circle through 2 or 3 different text editors and end up the same as when it started. Playing Chinese whispers with text editors could provide endless hours of amusement.

More realistically, I doubt if anyone moving text editors would care if they were happy with the editor they moved to.

briggers replied on Jun 9, 2015 at 10:47 am Permalink Reply

"Is the HTML output of TinyMCE incompatible with the HTML CKEditor wants to see? Once the HTML is saved, it's just standard HTML right?"

It may work fine, but redactor does insert some rather peculiar attributes e.g.

<p data-redactor-inserted-image="true"><img src="...

which are rightly ignored by the browser but I don't know what effect they might have on other RTEs

But it still means maintaining the integration code for 2 or even more RTEs

mhawke replied on Jun 9, 2015 at 11:56 am Permalink Reply

You can turn that behaviour off:

http://imperavi.com/redactor/docs/settings/clean/#setting-removeDat...

but then you have issues with pull requests like this:

https://gist.github.com/16nsk/18f97b8d60e9595e1017...

keeasti replied on Jun 10, 2015 at 9:56 am Permalink Reply

Redactor may be OK for very simple sites/edits but not for anything 'serious'. Especially when trying to manually import many pages from an existing site.

Also, in my experience, *clients* like to have control even though as designers/developers we may frown upon this.

I really like TinyMCE and it can be anything you want it to be ... from very basic to advanced. It can easily be tailored to fit the given situation. I am sure CKEditor is very similar in this aspect but only have limited experience with it.

I think the decision to go with Redactor has done more to alienate me than any of the other questionable decisions.

Never did like the trend for 'dumbing down'.

exchangecore replied on Oct 19, 2015 at 4:07 pm Permalink Reply

Just gonna toss in my $0.02 here (and sorry to MrKDilkington if I’m thread jacking here but it feels like we might be a tad late for that ;)).

I think asking the core team to change because 2% (or whatever number) of people don't get the things they need out of the default WYSIWYG editor might be a bit extreme. There's clearly a lot of work that's gone into getting Redactor working with the core and there's no small number of other things that I'm sure need to be taking priority over building another editing interface. I think most of us use concrete5 for far more than it's wysiwyg editor, it's only one piece, and that piece can be swapped out to do just about whatever you want. Not to mention you can build a block to do just about anything.

That said, because of the seemingly popular demand, I've started down a path of building a "community_ckeditor" package. At this point there is a decent portion of missing functionality and probably no small number of bugs so don't go installing this on your production environments, it's not done yet.

I'm hoping to get it functional here over the next couple weeks if time allows (this is strictly a spare time project). I ask that you don't go creating issues for it on github just yet, but if you want to contribute to getting it up and running I will acknowledge pull requests and you are certainly more than welcome to participate in any issues marked with the "discussion" label. If/when this gets to a stable point I'll get it on the marketplace.

https://github.com/ExchangeCore/Concrete5-CKEditor...

Hopefully this can serve as an example of how to swap out the core editor so that if someone wants to implement an even different editor (say TinyMCE) they could work at it.

mhawke replied on Oct 19, 2015 at 7:34 pm Permalink Reply

If anyone wants to add ckEditor as a block instead of swapping out Redactor entirely can have a look at this project.

https://github.com/Mesuva/ckeditor_content...

keeasti replied on Nov 9, 2015 at 5:12 am Permalink Reply

You are right of course that the editor is not everything but from the clients point of view, it is what they interact with the most. This is why a good experience there is, in my opinion, very important.

I'll be sure to check out your plug-in ... thanks for making the effort!

MrKDilkington replied on Jun 6, 2015 at 5:03 am Permalink Reply 7 Attachments

I added a new plugin.

Block Custom Styles
http://www.concrete5.org/download_file/-/80402/...

What it does:
- apply custom styles directly to block level elements (without using span tags)

I attached screenshots of how it compares with the regular custom styles feature.

Now there are two options for custom styles.
1. "Custom Styles" for applying a custom style to inline text (wrapping the text in a <span> tag). Used for adding styles to text within a larger block of text.
2 ."Block Custom Styles" for applying a custom style directly to the block level element. Used on an h1-h6, p, etc.

If people test it and it continues to work reliably, we could change the current Redactor button title from "Custom Styles" to "Inline Custom Styles". This is how some other editors handle it - with separate inline and block styling. I have attached a screenshot of CKEditor and how it marks styling as inline or block.

WebcentricLtd replied on Jun 6, 2015 at 6:21 am Permalink Reply

excellent work MrK. I've installed this and have only tested minimally but it looks good so far.
I don't suppose you've thought about building a redactor plugin to add page attributes :) ?

MrKDilkington replied on Aug 19, 2015 at 10:03 pm Permalink Reply

@AndyJ

Displaying attributes in Redactor was recently added to concrete5 with the new Snippet class.
https://github.com/concrete5/concrete5/blob/develop/web/concrete/src...

Community developer hissy just released a new marketplace package that extends this class to add additional attributes to the custom styles dropdown.

Added attributes:
Page Author Name
Parent Page Name
Page Type Name

More attributes can be easily added with this package.

http://www.concrete5.org/marketplace/addons/basic-snippets-pack/...
https://github.com/hissy/addon_basic_snippets_pack...

derykmarl replied on Jun 18, 2015 at 4:03 am Permalink Reply

(redacted)

mhawke replied on Jun 18, 2015 at 8:20 am Permalink Reply

I'm pleading with everyone... Could we please post these new issues with Redactor to separate threads. This thread is becoming all but useless because it covers about 40 different topics. The beauty in a forum is that a thread covers a single topic that can be folllowed from question to solution. In other communities, this thread would have been stopped a long time ago for being off topic. This is turning into an IRC chat.

derykmarl replied on Jun 22, 2015 at 3:28 am Permalink Reply

(redacted)

mhawke replied on Jun 22, 2015 at 9:29 am Permalink Reply

Could you point me to the other forum discussions where folks are suggesting we consolidate all the Redactor questions under this thread?

derykmarl replied on Jun 22, 2015 at 9:48 am Permalink Reply

(withdrawn)

mhawke replied on Jun 22, 2015 at 11:48 am Permalink Reply

I understand your point and I completely agree that if the post is about 'feature requests' then it belongs here but a lot of the questions posted here are really bug reports or work-arounds and so it makes it very difficult in the future to find a coherent, concise thread that addresses a specific problem if every issue is thrown into this bucket. In my 10 minute search of the Redactor questions posted so far on these forums, I couldn't find anyone who was suggesting we stuff everything in here. There are very few threads like this one in the support forums so this is not really 'the way we do things around here'.

wvanelten replied on Jun 26, 2015 at 4:10 am Permalink Reply

Please add the ability to add the different Bootstrap table styles and Bootstrap horizontal description.
(to be honest, all Bootstrap styles should be selectable from the editor)

Thanks in advance.

MrKDilkington replied on Jul 2, 2015 at 2:46 am Permalink Reply

There is new Redactor news.

The upcoming version 5.7.5 will include inline and block custom style options along with an update to the current version of Redactor.

The current version of Redactor will bring welcome bug fixes.
http://imperavi.com/redactor/log/...

"Add 'method' to getThemeEditorClasses, for 'inline' or 'block', make the styles plugin apply the style appropriately. #2649"
https://github.com/concrete5/concrete5/issues/2649...

"Update redactor to latest stable #2648"
https://github.com/concrete5/concrete5/issues/2648...

MrKDilkington replied on Jul 30, 2015 at 6:01 am Permalink Reply

New in concrete5 5.7.5+

When defining custom styles, there is now the option to make them inline or block. An inline style will wrap the selected text in a span tag and then apply the the custom style to the span. A block style will apply the custom style directly on the block level element tag of the selected text (examples of block level elements are p, h1-h6, etc.).

What makes a custom style inline or block is determined by a new getThemeEditorClasses() array key called "forceBlock". A 'forceBlock' value of -1 will make the style inline and a value of 1 will make the style block.

Example: the Elemental theme default styles

public function getThemeEditorClasses()
{
    return array(
        array('title' => t('Title Thin'), 'menuClass' => 'title-thin', 'spanClass' => 'title-thin', 'forceBlock' => 1),
        array('title' => t('Title Caps Bold'), 'menuClass' => 'title-caps-bold', 'spanClass' => 'title-caps-bold', 'forceBlock' => 1),
        array('title' => t('Title Caps'), 'menuClass' => 'title-caps', 'spanClass' => 'title-caps', 'forceBlock' => 1),
        array('title' => t('Image Caption'), 'menuClass' => 'image-caption', 'spanClass' => 'image-caption', 'forceBlock' => '-1'),
        array('title' => t('Standard Button'), 'menuClass' => '', 'spanClass' => 'btn btn-default', 'forceBlock' => '-1'),
        array('title' => t('Success Button'), 'menuClass' => '', 'spanClass' => 'btn btn-success', 'forceBlock' => '-1'),
        array('title' => t('Primary Button'), 'menuClass' => '', 'spanClass' => 'btn btn-primary', 'forceBlock' => '-1'),
    );
}

If you create a custom style that you want to use both as an inline style and a block style, then you can define the custom style twice. One approach is to add a "- Inline" or "- Block" suffix to the custom style title.

Example: a custom style used both as inline and block

public function getThemeEditorClasses()
{
    return array(
        array('title' => t('Title Thin - Block'), 'menuClass' => 'title-thin', 'spanClass' => 'title-thin', 'forceBlock' => 1),
        array('title' => t('Title Thin - Inline'), 'menuClass' => 'title-thin', 'spanClass' => 'title-thin', 'forceBlock' => '-1'),
    );
}

Kiesel replied on Nov 5, 2015 at 8:06 am Permalink Reply

Very simple thing:
How do I make an <a href...> tag and choose a style for it from the custom styles dropdown?

Is that in the current version still not possible?

Mainio replied on Nov 5, 2015 at 8:32 am Permalink Reply

Redactor always wraps custom styles within <span> elements, so that's not basically possible out of the box.

It has been suggested to the core team about a year ago that it should work differently as currently redactor makes a lot of mess in the HTML:
https://github.com/concrete5/concrete5/issues/1610...

This actually makes the redactor custom styles (or the whole editor) quite useless in our projects.

Maybe some noise into this issue at github might get it noticed at some point...

MrKDilkington replied on Nov 5, 2015 at 9:02 am Permalink Reply

@Mainio

You can make custom styles apply to block elements using "forceBlock".

There is more information on using forceBlock in this How-To in the "New in concrete5 5.7.5+" section.
https://www.concrete5.org/documentation/how-tos/designers/adding-red...

Kiesel replied on Nov 5, 2015 at 9:09 am Permalink Reply

Yes, but <a> isn't a block...

Mainio replied on Nov 5, 2015 at 9:09 am Permalink Reply

@MrKDilkington Thanks for the info, did not know that!

But yeah, I think this still does not fix all the issues with Redactor...

Mainio replied on Nov 5, 2015 at 9:10 am Permalink Reply

And also yeah, if it does not apply to inline-level elements, we're back to square one.

Kiesel replied on Nov 5, 2015 at 9:08 am Permalink Reply

Thanks for the info.

Puh...Redactor sucks so bad. We had high hopes that it either gets better or changed, but it's still here and still can't do the most basic things it seems.

Wish we could use tinyMCE.

Mainio replied on Nov 5, 2015 at 9:28 am Permalink Reply

@Kiesel There is actually CKEditor alternative:
https://github.com/ExchangeCore/Concrete5-CKEditor...

But I thin it still has some issues. I haven't personally tried it but it might be worth to try.

I personally think CKEditor should be what core ships with and if someone wants to use the closed source redactor alternative, they can create hook into the content editor abstraction layer (as this add-on does, I think).

exchangecore replied on Nov 5, 2015 at 9:48 am Permalink Reply

Still a work in progress. It works, but we're still working out some kinks and implementing features.

Right now it's at a point where:
- You can probably break it if you try
- We do have at least 1 known intermittent bug https://github.com/ExchangeCore/Concrete5-CKEditor/issues...
- We are still building some integrations with concrete5 features (sitemap / file manager)
- This is only available from github (We'll be taking it to the marketplace as soon as we feel confident that we've implemented the necessary features and have made it as bug free as possible)

All that said... You can download it from github, install it, use it, submit bug reports to github, and if it breaks something you just uninstall the package and revert your page version.

Kiesel replied on Nov 6, 2015 at 4:16 am Permalink Reply

Thanks for that alternative. I'm not that keen on tryouts right now, but I'll keep an eye on that. If it gets nicely stable I'm gladly give it a go.

MrKDilkington replied on Nov 5, 2015 at 9:55 am Permalink Reply

@Kiesel

You are right, it doesn't address your problem. I have an add-on you can use in the meantime though. It is currently under PRB review, but I might remove it.

Redactor II was announced recently and at the same time they removed all the Redactor I documentation, API info, examples, and plugins. Which means I have to use the Wayback Machine to look at archive pages to see what methods I can use to finish my plugins.

MrKDilkington replied on Nov 5, 2015 at 10:18 am Permalink Reply 1 Attachment

@Kiesel

I have attached a Redactor plugin that allows for adding classes and IDs to current tags, spans, blocks, links, tables, and images.

Just place the cursor in the tag you want to change, then select the tag from the dropdown.

Images are selected by clicking on them. When they are selected, they have a light blue border. Clicking them a second time removes the selection.

I have a more flexible and intuitive version that uses DOM nodes, but I am not sure if I am going to finish it.

derykmarl replied on Nov 5, 2015 at 10:49 am Permalink Reply

Ooh. This wasn't aimed at me but I think you must be a genie as I was wishing for exactly this yesterday. Thanks!

Dushka replied on Nov 5, 2015 at 10:48 pm Permalink Reply

@MrKDilkington
I hate to be a pest, but could you please elaborate here. I have installed your add-on (many thanks), but am having no luck at all. For instance, when I click on an image, it merely responds in the familiar way by placing a broken line around it and offering the Edit option.
And when I go into HTML mode and click in a tag, all the icons are grayed out — how does one access the drop down?

Kiesel replied on Nov 6, 2015 at 4:07 am Permalink Reply

You have to activate it first in the rich text editor settings:

/dashboard/system/basics/editor

MrKDilkington replied on Nov 6, 2015 at 6:58 am Permalink Reply

@Dushka

Using Redactor plugin packages:
1. extract the plugin zip file into your concrete5 packages directory
2. install the package
Dashboard > Extend concrete5 > Add Functionality
3. enable the Redactor plugin
Dashboard > System & Settings > Basics > Rich Text Editor > check Add and Remove Classes and IDs

The plugin doesn't work using HTML mode. You place the cursor inside the text/tag you want to change and then click the "+" plus sign icon to access the dropdown.

tag
- based on position of the cursor, finds the nearest parent tag of any kind
span
- based on position of the cursor, finds the nearest span tag
link
- based on position of the cursor, finds the nearest link tag
table
- based on position of the cursor, finds the nearest table tag
image
- works with images that are selected "have a light blue border"

Dushka replied on Nov 11, 2015 at 6:21 pm Permalink Reply

@MrKDilkington
Excellent. Thanks for that explanation. I had missed the bit about activating in the dashboard. I really appreciate your commitment to the community.

Kiesel replied on Nov 6, 2015 at 4:14 am Permalink Reply

Awesome! You made my day! That works. Still not a one-hit wonder, but with this the clients can do. Thanks a lot!

Hope Redactor gets soon out of the Alpha and becomes somewhat usable from scratch.

pvernaglia replied on Nov 14, 2015 at 1:37 pm Permalink Reply

I'm building a site right now with 5.6 so we could use Core Commerce, it's the first time in about a year I have built something with 5.6. It has been such a pleasure using TinyMCE again, I never thought I would say that!

I thought Redactor was going to be a great addition to C5, but it has been a huge dissapointment.

I think under the hood 5.7 is great, but working with 5.6 this past week, I still think the overall editing experience is much better in 5.6 than 5.7.

alanski replied on Nov 14, 2015 at 4:36 pm Permalink Reply

I am inclined to agree with you on the editing experience - not just tinymce but overall.

MrKDilkington replied on Nov 14, 2015 at 4:53 pm Permalink Best Answer Reply

The ExchangeCore guys have put a lot of work into getting CKEditor ready for concrete5. It is very close to being ready. Despite it being unfinished it is working very well and will be a huge asset to the community.
https://github.com/ExchangeCore/Concrete5-CKEditor...

Please "watch" and "star" the GitHub project and comment here to show them that their hard work is appreciated.

If you are a developer, please see how you can contribute.

anete replied on Nov 14, 2015 at 5:34 pm Permalink Reply

This is great news, thanks for the info @MrKDilkington. Have watched and starred the project and will look forward to it being ready. Thanks for your input into it. I think this will make a big difference to 5.7 as it seems to be the area where there is the most frustration.

pvernaglia replied on Nov 15, 2015 at 11:47 am Permalink Reply

Thanks for sharing this. I just installed it and it works very well. I'm excited to see this in the works and that it's being done by some good C5 developers.

It is testament to the dissatisfaction people have with Redactor!

MrKDilkington replied on Nov 15, 2015 at 8:31 pm Permalink Reply

@anete
@pvernaglia

That you for starring and watching the project.

When it is finished, I will being writing tutorials on how to create the different style types.

arlenesey replied on Nov 22, 2015 at 3:52 pm Permalink Reply

Have "watched" and "starred" this Github project.
Text editing is such an important part of a CMS, and Redactor is surprisingly sparse.
Despite it's drawbacks (I never saw any) Tiny MCE worked very well for me.
Looking forward to CKEditor. Thank you to everyone involved and you MrDilkington for your continued dedication and help within the community. We really do appreciate it.

growlrooed replied on Jan 27, 2016 at 11:48 am Permalink Reply

I really look forward to getting back to using a real editor like CKEditor. Redactor is just a floundering disaster that just brings CC5 down IMHO. Good riddance.
A big thank you to the developers and you MrDilkington!

Here's a $64K question: When we install the new editor how will it effect Problog posts, blocks posts and others that were created in Redactor?

leinteractive replied on Dec 21, 2015 at 12:47 pm Permalink Reply

I've browsed through much of the Redactor discussions on this page and other linked on it.

For me, the biggest issue I have is being able to insert a Title Tag for a Link and Alt Text for Images. Both for SEO purposes.

TinyMC had those features, and I miss them greatly.

Right now, I have to go into the source code to find the link tag and add the title to it. Not something I'll be showing clients how to do.

Is there already plugin that adds this functionality to Redactor?

MrKDilkington replied on Dec 22, 2015 at 2:55 am Permalink Reply

@leinteractive

Redactor allows for alt attributes to be set on images, but the way to do it is currently mislabelled. When you click on an image in Redactor, an "Edit" button appears on the image. Clicking on the Edit button pops up a form. In the form, the "Title" input is actually the way to add the alt attribute. This needs to be fixed.

Regarding title attributes for links, I have found no current information showing that their use improves SEO or is considered in search engine rankings.

An example SEO article describing their use.
http://www.searchenginejournal.com/how-to-use-link-title-attribute-...

A plugin can be made if this feature is still required.

MrKDilkington replied on Dec 24, 2015 at 2:51 am Permalink Reply

The mislabelled TItle field has been corrected.

"change input label from Title to Alt #3242"
https://github.com/concrete5/concrete5/pull/3242...

GBNT replied on Jan 27, 2016 at 11:04 am Permalink Reply

Hi MrKDilkington,

i'm using the Super/Sub Script plugin but it only works on <paragraphs>. Is there a way to make it work on <headings>?

Cheers

MrKDilkington replied on Jan 27, 2016 at 6:38 pm Permalink Reply

@GBNT,

The Subscript and Superscript Buttons plugin adds buttons to a default Redactor feature. This feature does not appear to work on headings.

It is not ideal, but if you have a limited number of items to change, you can edit the HTML manually. This would be done after setting the heading (applying the heading will clear the sub/sup tags).
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/sub...
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/sup...

keeasti replied on Jan 28, 2016 at 9:59 am Permalink Reply

First off, great job on your herculean effort to improve Redactor!
My question is whether anybody knows the reason or has an opinion on why C5 switched to Redactor and didn't stick with TinyMCE (or even change to CKE) when they were obviously far superior? Is there a reason which is not readily apparent?
Why re-invent the wheel?!

exchangecore replied on Jan 28, 2016 at 10:11 am Permalink Reply

CKEditor Update:

In the next major release of Concrete5 (version 8), redactor will be no more. CKEditor will be the new editor throughout the core (https://github.com/concrete5/concrete5/issues/3293). As such, the work on the CKEditor package that was under development will be put on hold and efforts will be diverted towards improving the core editor implementation. Hopefully it will be at least as full featured as the package that was under development with some other great improvements. Everyone who contributed ideas, code, and took the time to test and report issues to the CKEditor package should know that you were an important part in bringing a new, full featured editor to concrete5 version 8.

I won't try to speculate as to why the core team decided on redactor in the first place (and quite frankly I don't think it matters much at this point), but I know that they are also frustrated with the path Redactor has taken in their latest version, hence the change.

keeasti replied on Jan 28, 2016 at 10:15 am Permalink Reply

How exciting!
Thanks for the info.
RIP Redactor and good riddance :)

tduncandesign replied on Jan 28, 2016 at 10:27 am Permalink Reply

Is the package version (https://docs.exchangecore.com/community_ckeditor/develop/) viable for 5.7 sites now in production? What if it is installed on existing sites, do you have to have it in from the start, or can it be installed on live sites? Would that destroy instances of Redactor content? What if it is installed then un-installed, does the C5 install revert seamlessly to Redactor? What would happen if we start using the package CKEditor now, but later upgrade the site to C5 v8 with CK as core?

Sorry for the noob questions, but great work on improving the editing. I confess I have not been following this closely, so am not up to date on it.

exchangecore replied on Jan 28, 2016 at 10:37 am Permalink Reply

@tduncandesign

When it was mentioned that there was going to be a move to CKEditor in the core we were just doing some final testing before it was goign to go to the PRB for review. So in answer to the viability question, I would say that you could use it in production. When you install it, it automatically acivates the editor, all existing content remains in place, and when you edit it you are just editing using CKEditor instead of redactor. If you uninstall the package, it is reverted to whatever the core editor is (so if you install it and decide it's not working all you need to do is uninstall it and you're back to where you were). If you have the CKEditor package installed, and then upgrade to v8 later on, it woudl continue to run off the package, you simply need to uninstall the package at that point in time to get the core editor back.

I would say that CKeditor package is safe to use and should cause no data loss. Worst case scenario is if you have a redactor plugin already installed that supports something CKEditor doesn't, then you would simply be missing out on that functionality. Also, if you edit content and it doesn't come out quite the way you want it, you can always revert your page version and uninstall the package.

That said, I'm personally not putting any effort into supporting bug fixes for the package at this point, so if you come across them, feel free to report them but don't expect any immediate fixes (coming from me at least). Hope this helps.

tduncandesign replied on Jan 28, 2016 at 10:44 am Permalink Reply

@exchangecore

Thanks so much, that is great news! Since the current build is just getting under way and will need a good editor for blogs and whatnot, I am going to give your package a go. It's got to be better than Redactor!

WebcentricLtd replied on Jan 28, 2016 at 12:26 pm Permalink Reply

@tduncan, I've been using the ckeditor package on a production site for a few weeks now. There has been a lof of heavy editing and I haven't had any issues with data loss - or any other issues. In fact it helped speed up addition of content immensely over using redactor.

edited - the only minor issue is that depending on how the editor is implemented some add-ons will still use redactor as their editor. But, the content block etc will use ckeditor .

tduncandesign replied on Jan 28, 2016 at 12:36 pm Permalink Reply

Good to hear!

That is interesting about some add ons using redactor. I wonder if that would be the case with custom blocks built with Ramon's Block Designer Pro that use wysiwyg text areas. Will find out soon enough...

WebcentricLtd replied on Jan 28, 2016 at 12:41 pm Permalink Reply

block designer / pro wysiwyg implements redactor (Unless it has been updated). I didn't find that to be too much of an issue though

tduncandesign replied on Jan 28, 2016 at 12:46 pm Permalink Reply

Thanks for the heads up on that. Shouldn't be too much issue, most times I use a wysiwyg (STILL have a hard time typing that acronym) in custom block fields is a CYA moment, in case ensuing text needs to gain italics or a link in something like a description field.