Moodle

Bill,

I tested adding first
<font face="impact">test1<span style="font-family: tahoma,arial,helvetica,sans-serif">test some text</span> test2</font>

and then

<span style="font-family: impact">test1<span style="font-family: tahoma,arial,helvetica,sans-serif">test some text</span> test2</span>

to htmlarea (the latest weekly 1.9.2+ with IE7 and FF3 ) and could not reproduce this. Both seem to work ok...font is changed inside span tags.

Maybe some filter is causing your problem?

Sorry - I did not notice that this happened in Database activity. Database does seem to strip tags...

Is this something that can be fixed soon, or do I need to maker other plans? I need the information up pretty quickly because classes are starting.

Thanks.

Bill

Bill,

i have nothing to do with Database activity (wrote previous comment only for editor) but after a quick check it looks like file mod/data/field/textarea/field.class.php and function update_content

else { $content->content = clean_param($value, PARAM_CLEAN); }

cleans span tags. Another thing is that even if you delete those tags (then it will stay as you wrote it , uncleaned in database and in editor when you edit content) moodle filters the visible content when you view database in view.php - this may be some security issue (I really don't know the reason)

I hope Eloy, Peter, Martin or some other core developer can give you better explanation.

Well, there are two problems here (after talking with Petr about this):

1) The most obvious is that the clean is cleaning too much (it's cleaning the font-family selector and it shouldn't). it's easy to fix. Will be in CVS in some minutes (I'll post here once committed).

2) The second problem is WHEN that cleaning is happening. I really thing that we don't have to clean before insert or update DB, mainly because we always clean on display (format_text(), format_string()). So I'd suggest database module to don't perform that clean when inserting/updating those "textarea" fields.

In fact, doing that causes wrongly-cleaned contents to be sent to DB, so they cannot be recovered. In the other side, cleaning on display... guaranties that contents in DB are the ones entered by user, i.e. the cleaning doesn't destroy anything.

Adding to Robert and Martin here... ciao

1) has been fixed in CVS (for 18_STABLE, 19_STABLE and HEAD). Will be available in next weekly build (or by direct CVS access). That will allow you to save new contents having that css selector.

2) waiting for answer about to avoid that cleaning before insert/update in database module.

Ciao

Is this related to my earlier report (http://tracker.moodle.org/browse/MDL-15925) that disallows the administrator to use EMBED and OBJECT tags? It would be great, while you are cleaning up the CLEAN routine, to make it so that admin can use these.

Ah, Bill, this isn't related to MDL-15925 AFAIK.

Reading it I don't think that "allowing to bypass the setting to admins" is completely correct. Because then, other users can arrive. Perhpas a new capability (edit:useembedandobject or so) could be added to the system to allow selectively permissions about who can use those tags? (just thinking as I type, not really sure if that's possible). I'd suggest you to comment there, to leave both bugs separated.

Ciao

this embedding should be imo solved the same way as trusttext in forum and glossary, but first step would be to rewrite it there

I just downloaded the new 1.9.2 weekly stable (August 13) and updated my site. The problem with <span="textGreek"> (or any other span) is still there. Moodle leaves the </span> but still strips out the leading <span>. Is it possible for you to tell me where I can manually enter the fix? I have lots of data to input and can't until this is fixed. Thanks.

Weird. It is the next day, and the <span> tags are being left alone. I did uncheck Enable Trusted Content, so maybe that is the difference, and with it checked the <span> is still being removed. Don't know.

Backported the addition of 'text-decoration' and 'font-family' to MOODLE_17_STABLE and MOODLE_16_STABLE while working on MDL-16293

-eric

Thanks for reporting this issue.

We have detected that this issue has been inactive for over a year has been recorded as affecting versions that are no longer supported.

If you believe that this issue is still relevant to current versions (2.1 and beyond), please comment on the issue. Issues left inactive for a further month will be closed.

Michael d;

lqjjLKA0p6

I'm closing this issue as it appears to have become inactive and is probably not relevant to a current supported version. If you are encountering this problem or one similar, please launch a new issue.