I've updated i18n from version 1.3 to 1.4.

If I want to translate a block, I get

The submitted string contains disallowed HTML:

error message. In 1.3 this worked without any problems. I've done it a few hours before updating the module.

I've found a similar issue: #1298440: Translate block with full html input type ERROR (The submitted string contains disallowed HTML).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

scito’s picture

It seems that the img tag is causing problems.

The submitted string contains disallowed HTML: <p style="margin-bottom: 1em;"><img src="/sites/cabane-diablerets.ch/files/images/alternatives-wandern.ch/369473_Cabanediablerets_ext_front1.jpg" alt="Cabanes des Diablerets" class="img-center" height="413" width="800"></p>

img is not allowed in locale_string_is_safe.

scito’s picture

A block translation with a text like <p>Hello world.</p> is working with i18n version 1.4.

I'm using the block with images on my front page of the MAYO theme. I translated the text below the image.

I've reverted i18n to version 1.3. The translation of the block with the image works now again.

willkaxu’s picture

Priority: Normal » Major

The block translation with a text like <h1>Hello world.</h1> is working with i18n version 1.4. But when I want to add some style like <h1><span style="color: #A40000;">Hello</span> world.</h1>, i18n version 1.4 doesn't work, it only tells " The submitted string contains disallowed HTML". It seems "color: #A40000" is not supported in i18n version 1.4.

koffer’s picture

Same problem with <img> ! any advance?

quimic’s picture

Same here.
I am using wysiwyg/CKEditor with specific profiles for filter HTML, plain HTML and plain text. When translating a block, I noticed that though the indicated text format matches the translated text format, the interface is the "Plain text" interface instead of being the specific editing profile. Just a simple plain text editing field.

Sifro’s picture

Same here: inserting a swf video causes this error too.

Possible workaround:

1. open file includes/locale.inc
2. find function locale_string_is_safe($string)
3. replace current code function with "return 1;"
4. edit your block translation
5. immideatly revert the change to prevent easy attacks from untrusted users

Jose Reyero’s picture

Category: bug » support
Priority: Major » Normal
Status: Active » Closed (works as designed)

I don't think we've changed anything about that in this (1.4) release, though maybe the validating function (in core) has changed, I don't know.

This shouldn't be a problem for block body as it has 'text format' but for block title we are just using this string for validating.

In your examples, it is not about the tags but the attributes (class, style). See http://api.drupal.org/api/drupal/includes!locale.inc/function/locale_str...

So I think this is just worked as expected (maybe it was not before).

mmncs’s picture

Priority: Normal » Critical
Status: Closed (works as designed) » Active

I'm having the same error after updating to 1.4 and I have allowed translation of all text formats. But Jose you say that it works as designed does that mean that one only can translate plain text and not html?

mmncs’s picture

Category: support » feature
Priority: Critical » Normal

Being a bit to quick I can see that Jose is right, since the tags img and div has been omitted. But wouldn't it be nice if these where allowed?

abdelatifs’s picture

So were do you guys think we should put a request?

I even tried to use filter html text format and in the Limit allowed HTML tags tab I put every possible html tags in there and it still didn't work.

Seems like using img tag is messing things up.

And don't want to either hack core or use a custom module, this should be fixed in core.

Patribus’s picture

Hello, having same problem:

the moment I use attributes, the error comes.

<table> is ok, <table class="extra-table" style="vertical-align: top; width: 240px; "> for instances, gives error

waiting for solution or new update

Cheers

kristofferwiklund’s picture

I found a workaround. As describe in this
https://drupal.org/node/1298440

Go to Administration » Configuration » Regional and language » Translate interface.
Search for the block, translate and save.

If I went to the block and translate it I got the error above.

pfrenssen’s picture

davemybes’s picture

This doesn't just apply to blocks: I'm getting the same error with translating a Views header through the Translate Interface page. I've enabled translations on the required Text formats already. I have a DIV with a class that is causing the problem. If I change it to a P with the same class, it works fine. This is also on 1.4.

dragonwize’s picture

Component: Blocks » Strings
Category: feature » bug

Still looking for where the actual change was made but I can confirm this issue.

The problem exists in i18n_string.pages.inc in function i18n_string_validate_submission().

This function calls locale_string_is_safe() without any condition except for checking for empty form fields in the calling function i18n_string_translate_page_form_validate().

As shown in locale.admin.inc in locale_translate_edit_form_validate() and #352121: locale_string_is_safe() is not suitable for user provided text in non-default textgroups, locale_string_is_safe() should only be ran on strings in the "default" textgroup.

The fix is changing i18n_string_validate_submission() in i18n_string.pages.inc

From:

function i18n_string_validate_submission($formkey, $value) {
  // Validation based on locale_translate_edit_form_validate.
  if (!locale_string_is_safe($value)) {

To:

function i18n_string_validate_submission($formkey, $value) {
  // Validation based on locale_translate_edit_form_validate.
  if (strpos($formkey, 'default') === 0 && !locale_string_is_safe($value)) {

Patch to come.

Jose Reyero’s picture

Status: Active » Closed (works as designed)

This is not a bug. We need some validation for strings and the best one we have atm is locale_string_is_safe().

Maybe if you want strings to be run through some other filter you should work on #1238642: Strings should be able to be runned through filter_xss(_admin)

And anyway I don't really understand your issue because block title is run through check_plain() always.

So definitely no, we are not contributing to hacks that may open up security holes. Maybe what you need here is a module that allows adding some html, with proper text format to blocks.

dragonwize’s picture

Status: Closed (works as designed) » Active

I disagree. This is in core and is not considered a security issue so why is it a security issue for i18n?

Can you support your position with actual use cases that this creates a security hole that has not been discussed and agreed upon in #352121: locale_string_is_safe() is not suitable for user provided text in non-default textgroups?

Please also address why i18n is trying to enforce HTML related security on text that is ran through Drupal's text filters that are there to handle security as decided upon by the site admin?

Jose Reyero’s picture

Translators are not site administrators.

Anyway, after reading this carefully, it seems maybe they are so, well... we should ease these restrictions, https://drupal.org/node/1471870

Jose Reyero’s picture

Status: Active » Needs review
FileSize
13.86 KB

This patch should fix two issues:

- Strings with format not being properly checked on form submission, thus going through locale_string_is_safe()

- Relaxing validation for strings without text format. Now they bypass locale_string_is_safe() is the source string doesn't validate either.

I hope this makes everybody happy. Let me know whether it works.

Status: Needs review » Needs work

The last submitted patch, i18n_relax_translation_validation.patch, failed testing.

pfrenssen’s picture

Status: Needs work » Needs review
uno’s picture

In order to allow img you need to:

  1. open file includes/locale.inc
  2. Go to line 500 - function locale_string_is_safe($string) which contains the list of safe strings
  3. Add string 'img',

Save and translate your block(s).

If you are concerned about the security, revert to original locale.inc, once you're done with translation.

dimitriseng’s picture

Status: Needs review » Needs work

@Jose Reyro - Thanks for agreeing to put this in. When applying the patch #19, blocks can now be translated ok. The "The submitted string contains disallowed HTML:..." error does not occur anymore and the translated content is displayed properly, which is great!

However, now there is a problem with the display of the block in the original language. In my case, I can save the block in its original language correctly, but when I view it then the HTML is displayed instead of displaying the content properly. Can you please check?

Steps to reproduce:
- Create block, add content and save. The block is saved ok.
- Translate the block and add some tags such as for a table. The translated block is saved ok (enabled by this patch).
- View the block in the translated language. The block contents are displayed properly.
- View the block in the original language. The block contents are not displayed properly but instead the full HTML is shown.
- Revert the patch and the original block is displayed properly.

Jose Reyero’s picture

@dimitriseng,

Do you mean the proper text format is not applied to block body?
Or that it is run through check_plain so you can actually 'see' html tags?

Thanks for trying the patch.

dimitriseng’s picture

@Jose - The text format I use actually does not limit the allowed HTML tags so when the block is displayed the formatting should be shown properly and not the tags I am not sure why this is happening, it might be that the text format is not applied to the body of the block. Is this working for you? Happy to test another patch, I think this is very close to being resolved!

Once this is resolved, we can also test the patches at #1252144: Support Wysiwyg editors for string translations (Wysiwyg Javascripts don't get loaded for block translations) and we will then have fully functional block translation functionality using WYSIWYG editors! :)

Thanks for your great work on this module, it is appreciated!

goldenboy’s picture

Status: Needs work » Needs review
paulrooney’s picture

Patch from http://drupal.org/node/1437146#comment-5745060 works. I am now able to save a block translation with HTML including inline styles without receiving the "The submitted string contains disallowed HTML:" error I experienced prior to applying the patch.

Jose Reyero’s picture

Title: After 1.4 update, block translation disallowed HTML error » Rework string translation access. (After 1.4 update, block translation disallowed HTML error)
FileSize
41.33 KB

This patch fixes the issue in #25 (default string not being filtered properly) but also it goes a little further.

It is a complete rework of string/translation validation:
- Introduces new permission to translate user-defined strings (translate user-defined strings) so it can be granted on top of 'translate interface'.
- Introduces new permission to allow translating anything to trusted users: translate unsafe strings.
- Replaces locale_string is safe by our own validation function.
- Centralizes format & permission checking so it can be applied equally to all translation forms.
- Handles special formats like FILTER_XSS_ADMIN and adds a permission to translate it.

Status: Needs review » Needs work

The last submitted patch, i18n_relax_translation_validation-02.patch, failed testing.

Jose Reyero’s picture

Version: 7.x-1.4 » 7.x-1.x-dev
Jose Reyero’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, i18n_relax_translation_validation-02.patch, failed testing.

Jose Reyero’s picture

Status: Needs work » Needs review
FileSize
42.13 KB

Simplified previous patch and updated tests.

One permission should be enough (translate user-defined strings).

Status: Needs review » Needs work

The last submitted patch, i18n_relax_translation_validation-04.patch, failed testing.

Jose Reyero’s picture

Status: Needs work » Needs review
FileSize
46.69 KB

Some tests were failing because of the new permissions.

Jose Reyero’s picture

Status: Needs review » Fixed
Issue tags: +Needs change record

We need to move on with this. So I've committed the patch.

Now it's time to test before a new release, which I'd like to do soon.

dimitriseng’s picture

@Jose Reyro - I have tested the dev version and this seems to be working ok now! Great work, many thanks!

As per my comments in #25, now that we have this working, if possible it would also be great to get #1252144: Support Wysiwyg editors for string translations (Wysiwyg Javascripts don't get loaded for block translations) working before the next version of i18n is released. We will then have fully functional block translation functionality using WYSIWYG editors! :)

trigdog’s picture

I am building a Spanish install of Drupal and it also has an English translation. I was having the disallowed HTML issue with my div tags in views translations so I installed the latest 7.x-1.4-dev (2012-Apr-03) and I was able to save my html tags in the translations with no errors but when I went to view the page the html tags were display as text and not rendered as html. I went back to my previous version of i18n 7.x-1.4-dev (2012-Feb-23) and all of my html elements were rendered properly again but again I can not save them without the disallowed HTML error.

Jose Reyero’s picture

@trigdog,

Could you post some more details, please? Which strings? Post an example?

Jose Reyero’s picture

Fixed some related issues:
- Unsupported operand types in i18n_string.pages.inc when translating string groups.
- Disabled strings being updated (wrong count of updated strings).

trigdog’s picture

FileSize
21.08 KB
5.5 KB

@Jose Reyero,

Sorry for the delayed response but I wanted to test it on a fresh install of Drupal just to make sure it wasn't something wrong with just my site. I was able to reproduce the same problem with just the following installed:

Drupal 7.12
Chaos tool suite (ctools) 7.x-1.0
Internationalization 7.x-1.4+35-dev (2012-Apr-11)
Internationalization Views 7.x-3.x-dev (2012-Jan-08)
Localization update 7.x-1.0-beta3
Variable 7.x-1.1+19-dev (2012-Mar-22)
Views 7.x-3.3

I then created two language neutral test pages (Basic Pages) and created the attached view with two fields: the title and a Global: Custom text field. In the Global: Custom text field I just put the following for the text:

<div>&nbsp;</div>

This works fine in the original view but when I go to "translate view" and translate it for Spanish and save the html is just displayed as text. See result image to see the result. Thanks!

mgifford’s picture

@Jose - Do you need more tests on this?

It's a bit rewrite of the functionality. We've got some HTML strings that we need translated (that were working fine in 1.3).

Jose Reyero’s picture

Status: Fixed » Postponed (maintainer needs more info)

@trigdog,

So the problem is with Views (i18nviews) ?

Are all the strings translated only with i18n modules (blocks, fields, etc..) working?

Jose Reyero’s picture

@mgifford,

Which are these strings? (i.e. block body, ... ?)

Jose Reyero’s picture

Priority: Normal » Critical

We need to take care of this and also produce a new release ASAP so marking as 'critical',

Jose Reyero’s picture

It looks like the problems are coming from i18nviews implementation of i18n_string so please give a try to #1534454: Update text handling and filtering using latest i18n features (permissions, filter_xss_admin)

And, unless someone tells me this affects i18n modules (not other plug-ins), we should be closing this issue.

Full documentation for this (change record) here, https://drupal.org/node/1534468

Jose Reyero’s picture

Status: Postponed (maintainer needs more info) » Closed (fixed)

This change is already in latest stable release.

timmetj’s picture

I have updated to 1.5 (came from 1.4) and now am facing a special character issue..
menus and taxonomies containig chars like '&' are now shown as '& amp;'

Can somebody please help me? in 1.4 everything was working fine.

timmetj’s picture

Version: 7.x-1.x-dev » 7.x-1.5
Status: Closed (fixed) » Needs work

Nobody is facing this issue? Since the update to 1.5 my whole site is showing '& amp;' everywhere instead of just '&'
Looks like a critical one for me, but tell me if the solution is right here.. I found the issue http://drupal.org/node/1526000 but directs it to this one.

kerios83’s picture

timmetj’s picture

And have you solved it? cause i can't understand the changes mentioned in all topics. Sincs 1.5 they made 2 filtering methods and default everything is now filtered as plain text? This is a hard change not? Everybody updating now will see all plain text instead of html?
Sorry that i can't understand it yet what to do.. for me at first sight it only looks like only the '&' is changed into '& amp;' for me. other html and caracters seem to be normal (since i'm running a dutch and french website..)

haclong99’s picture

As for timmetj and kerios83, when i have a single quote (or an ampersand) in block title, it shows ' for the single quote or & for the ampersand.

I don't have internationalization views installed so i don't think it concerns only internationalization views.
I've got this issue in translated block title and translated vocabulary terms but not in original language.

thank you for your help.

Jose Reyero’s picture

Status: Needs work » Fixed

Fixed filtering issues with taxonomy terms and block titles.

(Remember latest i18n-dev needs variable 2.x branch)

mordonez’s picture

Status: Fixed » Active

it's possible this issue has generated another bug? see #1604760: i18n_taxonomy_term_name() duplicate ampersand

Jose Reyero’s picture

Status: Active » Fixed

Please check out latest dev version before re-opening bugs.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Maksym Kozub’s picture

While this is a different module etc., the whole issue has somehow reminded me of http://drupal.org/node/1458574 and http://drupal.org/node/1282018. On the fundamental side, this issue is yet another example of a mindset based on the idea of asymmetrical translation workflow, rather than a symetrical/truly multilingual one.

pfrenssen’s picture

@Maksym, FYI you can make dynamic references to modules by placing the issue number between square brackets, preceded with a hash sign (eg.

[#123456]

). This will show all the important information at a glance: the issue number, title and current state of the issue.

For convenience, these are the issues that were referenced in the previous post: