wysiwyg issue

[bgras]

Hi Guys.

I'm wondering whether You ever had problems with the same problem with
WYSIWYG included in pkcontextcms. I have manualy uploaded file to /web/
image directory and than tried to display it using "source edit" in
WYSIWYG. I used tag <img src='/web/image' />. It's correctly displayed
in preview but after the slot is saved - the whole img tag disappears
- it's stripped.

Could You tell me whether it's fckeditor or pkcontextcms config
problem?

I looked in /plugins/pkToolkitPlugin/web/js/fckeditor/fckeditor/
fckconfig.js and all there seems to be ok.

Thanks,
Bart

[Tom Boutell]

Hi Bart,

You're running into a feature, not a bug. (:

Apostrophe filters out most HTML tags to prevent users from
accidentally trashing their pages (which, without this feature, they
do relentlessly by pasting layout-busting markup from Word etc).

The general idea is that you should be using our media plugin, not raw
img tags, to alternate media slots with rich text slots in an area.
This approach is friendly, convenient and safe.

But if you really want to allow img tags via "edit source," it's
possible to do that. You would need to set app_pkToolkit_allowed_tags
to the list of tags you want to allow. You can do that as a string:

all:
pkToolkit:
allowed_tags:
<h3><h4><h5><h6><blockquote><p><a><ul><ol><nl><li><b><i><strong><em><strike
><code><hr><br><div><table><thead><caption><tbody><tr><th><td><pre>

Or you can use an array of tag names, without the angle brackets.

By default, the HTML filter allows the use of the src attribute if you
have decided to allow the use of the img element.

For more information check out pkHtml::simplify in
pkToolkitPlugin/lib/pkHtml.class.php.

In the current svn trunk version, you can also override the list of
allowed tags for a particular pk_context_cms_area or
pk_context_cms_slot call by passing an allowed_tags option (and
allowed_attributes, and allowed_styles, etc).

> --
>
> You received this message because you are subscribed to the Google Groups "pkcontextcms" group.
> To post to this group, send email to pkcont...@googlegroups.com.
> To unsubscribe from this group, send email to pkcontextcms...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pkcontextcms?hl=en.
>
>
>



--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

[cr0wn3r]

I ran in to this last week Tom with fck's style drop down which can
add span tags with a class around text using the wysiwyg interface.
Seems to me to be a safe way of allowing people controlled access to a
limited set of formatting options.

When I finally worked out why the tags were being stripped I did
wonder then whether its the best idea having this stuff configured in
two places?

All those settings and more are available to be managed within fck's
own config, so without really knowing your reasoning behind it I would
think it better to leave it to the fck config rather than creating a
second layer of config to set up.

> > For more options, visit this group athttp://groups.google.com/group/pkcontextcms?hl=en.

[Tom Boutell]

FCK is not a filter. It can't filter anything, it's at the .js level.
You can give them whatever options you want in the menus, but if
people paste from Word... congratulations, you've got layout-smashing
tag soup on your hands. (:

You can configure the filter to be very tolerant if that's the way you
want it, but be prepared for client complaints about mysteriously
broken pages after they paste from other programs.

Note that you can enable the class attribute via app.yml. But it's
generally simplest and safest to define good css rules for tags h3
through h6, etc. and use those. If you're trying to do heavy block
element styling within a rich text slot you are probably missing an
opportunity to design something once and correctly at the page
template level or use a separate slot that has been styled expressly
for that purpose.

> For more options, visit this group at http://groups.google.com/group/pkcontextcms?hl=en.

[Tom Boutell]

Actually, I'd love to see a snapshot of your style dropdown and a list
of the classes you had in mind, so I can get a sense of whether it's
something that really should be easier to do in the plugin. But you
really do want a filter once this stuff makes contact with clients and
their fascinating ways of editing and pasting text. (:

On Tue, Dec 15, 2009 at 6:28 AM, cr0wn3r <pete...@googlemail.com> wrote:

> For more options, visit this group at http://groups.google.com/group/pkcontextcms?hl=en.

[cr0wn3r]

Theres definately no question that the quality of a site a month after
launch is improved by having given clients as little control as
possible. Very familier with the problems you describe so no argument
there.

I guess the question is, whats the easiest way to spec that control
within the project.

I've always been happy with managing it through FCK's config file.

For the project that I was on last week that I mentioned earlier, I
set up 3 options in the drop down to allow the client to mark up any
part of their text, inline, with one of their three corporate colors.
By design it should just a key word here and there at the begining of
a sentence, and always part of a longer sentence. In the FCK config
that's a very straight forward addition, but as far as I could tell
when I did it last week I had to set it up in the fck config and then
get the pk stuff to allow it as well. Two jobs instead of one :)

[cr0wn3r]

Just to clarify - I was using span tags with a class defined in our
css to both bold the text and change the color to one of the three
predefined ones. Not using the actual color tool.

[Tom Boutell]

On Tue, Dec 15, 2009 at 4:54 PM, cr0wn3r <pete...@googlemail.com> wrote:
> Theres definately no question that the quality of a site a month after
> launch is improved by having given clients as little control as
> possible. Very familier with the problems you describe so no argument
> there.
>
> I guess the question is, whats the easiest way to spec that control
> within the project.
>
> I've always been happy with managing it through FCK's config file.
>
> For the project that I was on last week that I mentioned earlier, I
> set up 3 options in the drop down to allow the client to mark up any
> part of their text, inline, with one of their three corporate colors.
> By design it should just a key word here and there at the begining of
> a sentence, and always part of a longer sentence. In the FCK config
> that's a very straight forward addition, but as far as I could tell
> when I did it last week I had to set it up in the fck config and then
> get the pk stuff to allow it as well. Two jobs instead of one :)

Without the filter, you could do whatever you wanted in the FCK config
file, but users would still override it by pasting from other programs
or mucking around in the source editor. FCK doesn't have any power
over that, our filter does.

But I think you understand that and you're asking why we can't read
the FCK config file to figure out what our filter should allow.

I think the short answer is that it would be a darn nice feature to
have, but since the FCK config file is live javascript code and could
contain arbitrary code, it's not very practical to evaluate it on the
server side.

Perhaps we could build the FCK config file and our filter settings
from the same source file someday. That is certainly an interesting
possibility.

We'll also want to think about ways to allow the class attribute but
limit what classes can be set so that inappropriate block styles don't
wind up in the middle of a rich text area, etc. This is especially
important on sites that allow less trusted users to provide some rich
text content.

[cr0wn3r]

Yeah, I understand. I guess my original thought was that something
that used to be easy has got more complicated to set up, but I can see
now why you've gone down that route and the added benefits it brings.


Could maybe look at taking it
On Dec 15, 10:08 pm, Tom Boutell <t...@punkave.com> wrote: