Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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).
Comment | File | Size | Author |
---|---|---|---|
#41 | page-view-test.txt | 5.5 KB | trigdog |
#41 | result.png | 21.08 KB | trigdog |
#35 | i18n_relax_translation_validation-05.patch | 46.69 KB | Jose Reyero |
#33 | i18n_relax_translation_validation-04.patch | 42.13 KB | Jose Reyero |
#28 | i18n_relax_translation_validation-02.patch | 41.33 KB | Jose Reyero |
Comments
Comment #1
scitoIt seems that the
img
tag is causing problems.img
is not allowed inlocale_string_is_safe
.Comment #2
scitoA 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.
Comment #3
willkaxu CreditAttribution: willkaxu commentedThe 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.Comment #4
koffer CreditAttribution: koffer commentedSame problem with
<img>
! any advance?Comment #5
quimicSame 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.
Comment #6
Sifro CreditAttribution: Sifro commentedSame 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
Comment #7
Jose Reyero CreditAttribution: Jose Reyero commentedI 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).
Comment #8
mmncs CreditAttribution: mmncs commentedI'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?
Comment #9
mmncs CreditAttribution: mmncs commentedBeing 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?
Comment #10
abdelatifs CreditAttribution: abdelatifs commentedSo 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.
Comment #11
Patribus CreditAttribution: Patribus commentedHello, 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 errorwaiting for solution or new update
Cheers
Comment #12
kristofferwiklund CreditAttribution: kristofferwiklund commentedI 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.
Comment #13
pfrenssen#1298440: Translate block with full html input type ERROR (The submitted string contains disallowed HTML) has been marked as a duplicate of this.
Comment #14
davemybes CreditAttribution: davemybes commentedThis 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.
Comment #15
dragonwize CreditAttribution: dragonwize commentedStill 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:
To:
Patch to come.
Comment #16
Jose Reyero CreditAttribution: Jose Reyero commentedThis 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.
Comment #17
dragonwize CreditAttribution: dragonwize commentedI 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?
Comment #18
Jose Reyero CreditAttribution: Jose Reyero commentedTranslators 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
Comment #19
Jose Reyero CreditAttribution: Jose Reyero commentedThis 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.
Comment #21
pfrenssen#19: i18n_relax_translation_validation.patch queued for re-testing.
Comment #22
uno CreditAttribution: uno commentedIn order to allow img you need to:
Save and translate your block(s).
If you are concerned about the security, revert to original locale.inc, once you're done with translation.
Comment #23
dimitriseng CreditAttribution: dimitriseng commented@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.
Comment #24
Jose Reyero CreditAttribution: Jose Reyero commented@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.
Comment #25
dimitriseng CreditAttribution: dimitriseng commented@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!
Comment #26
goldenboy CreditAttribution: goldenboy commented#19: i18n_relax_translation_validation.patch queued for re-testing.
Comment #27
paulrooney CreditAttribution: paulrooney commentedPatch 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.
Comment #28
Jose Reyero CreditAttribution: Jose Reyero commentedThis 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.
Comment #30
Jose Reyero CreditAttribution: Jose Reyero commentedComment #31
Jose Reyero CreditAttribution: Jose Reyero commented#28: i18n_relax_translation_validation-02.patch queued for re-testing.
Comment #33
Jose Reyero CreditAttribution: Jose Reyero commentedSimplified previous patch and updated tests.
One permission should be enough (translate user-defined strings).
Comment #35
Jose Reyero CreditAttribution: Jose Reyero commentedSome tests were failing because of the new permissions.
Comment #36
Jose Reyero CreditAttribution: Jose Reyero commentedWe 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.
Comment #37
dimitriseng CreditAttribution: dimitriseng commented@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! :)
Comment #38
trigdog CreditAttribution: trigdog commentedI 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.
Comment #39
Jose Reyero CreditAttribution: Jose Reyero commented@trigdog,
Could you post some more details, please? Which strings? Post an example?
Comment #40
Jose Reyero CreditAttribution: Jose Reyero commentedFixed some related issues:
- Unsupported operand types in i18n_string.pages.inc when translating string groups.
- Disabled strings being updated (wrong count of updated strings).
Comment #41
trigdog CreditAttribution: trigdog commented@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> </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!
Comment #42
mgifford@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).
Comment #43
Jose Reyero CreditAttribution: Jose Reyero commented@trigdog,
So the problem is with Views (i18nviews) ?
Are all the strings translated only with i18n modules (blocks, fields, etc..) working?
Comment #44
Jose Reyero CreditAttribution: Jose Reyero commented@mgifford,
Which are these strings? (i.e. block body, ... ?)
Comment #45
Jose Reyero CreditAttribution: Jose Reyero commentedWe need to take care of this and also produce a new release ASAP so marking as 'critical',
Comment #46
Jose Reyero CreditAttribution: Jose Reyero commentedIt 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
Comment #47
Jose Reyero CreditAttribution: Jose Reyero commentedThis change is already in latest stable release.
Comment #48
timmetj CreditAttribution: timmetj commentedI 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.
Comment #49
timmetj CreditAttribution: timmetj commentedNobody 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.
Comment #50
kerios83 CreditAttribution: kerios83 commentedme - http://drupal.org/node/1534454#comment-5917262
Comment #51
timmetj CreditAttribution: timmetj commentedAnd 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..)
Comment #52
haclong99 CreditAttribution: haclong99 commentedAs 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.
Comment #53
Jose Reyero CreditAttribution: Jose Reyero commentedFixed filtering issues with taxonomy terms and block titles.
(Remember latest i18n-dev needs variable 2.x branch)
Comment #54
mordonez CreditAttribution: mordonez commentedit's possible this issue has generated another bug? see #1604760: i18n_taxonomy_term_name() duplicate ampersand
Comment #55
Jose Reyero CreditAttribution: Jose Reyero commentedPlease check out latest dev version before re-opening bugs.
Comment #57
Maksym Kozub CreditAttribution: Maksym Kozub commentedWhile 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.
Comment #58
pfrenssen@Maksym, FYI you can make dynamic references to modules by placing the issue number between square brackets, preceded with a hash sign (eg.
). 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: