Re: ImpressCMS 1.3.3: HTMLPurifier off

Well, right now is not possible to create a content without HTMLPurifier. If you have some contents (a non community website), it's better to deactivate the HTMLPurifier.

Maybe since 1.3.x works this not as well and we have to fix it, before we lost more users.

Topic


Re: ImpressCMS 1.3.3: HTMLPurifier off

Is this something that really needs to be added to 1.3? We have already started a release cycle for this and this only extends the final release of 1.3.3.

Topic


Re: ImpressCMS 1.3.3: HTMLPurifier off

Quote:


I hope it's possible to get a solution for ImpressCMS 1.3.x



I've just added the changes i made to ipf_object & ipf_core_object etc to the 1.3 branch in SVN.

If you want to check it out sato & let us know if it works.

I am unsure if those changes will affect the older non wysiwyg editors.

Live as if you were to die tomorrow, Learn as if you were to live forever

The beauty of a living thing is not the atoms that go into it, but the way those atoms are put together!


Re: ImpressCMS 1.3.3: HTMLPurifier off

@QM-B would answering in the future, since my knowledge are not the best to explain the issue. I hope it's possible to get a solution for ImpressCMS 1.3.x

However, thank you again!



Re: ImpressCMS 1.3.3: HTMLPurifier off

Quote:


Unless a class overrides the icms_ipf_Handler::insert() method (or icms_ipf_Object::store()), all the variables are passed through icms_core_Object::cleanVars() before adding to the db.



the only thing i can see happening in cleanVars is censorString() in txtarea dtype.

Can you take a look at my latest commits in trunk?

i have modified icms_ipf_object() & icms_ipf_handler() aswell as icms_core_object()

i also concatenated html content with

<!-- cleaned with htmlpurier -->


when purifier is used to filter, so we can quickly see if the data has been purified on input or not by searching for that line in the content of the db.

Live as if you were to die tomorrow, Learn as if you were to live forever

The beauty of a living thing is not the atoms that go into it, but the way those atoms are put together!


Re: ImpressCMS 1.3.3: HTMLPurifier off

Quote:


Vaughan wrote:
@mcdonald, yes that will work, but it may or may not break other modules/areas that don't use wysiwyg editors.

@QM-B, that's great, should be added in the trunk svn for cms module for next release.

the changes for output shouldn't be required tho if i make those changes to IPF, but i can only do that if all modules/core do that filtering with IPF before using ipf setVar()

it will make no difference using output twice really tho, as the only thing that happens on checkVar html output filter is BBCode conversion to html.



Unless a class overrides the icms_ipf_Handler::insert() method (or icms_ipf_Object::store()), all the variables are passed through icms_core_Object::cleanVars() before adding to the db.

Likewise, the icms_ipf_Object::getVar() filters the variables on return.



Re: ImpressCMS 1.3.3: HTMLPurifier off

@mcdonald, yes that will work, but it may or may not break other modules/areas that don't use wysiwyg editors.

@QM-B, that's great, should be added in the trunk svn for cms module for next release.

the changes for output shouldn't be required tho if i make those changes to IPF, but i can only do that if all modules/core do that filtering with IPF before using ipf setVar()

it will make no difference using output twice really tho, as the only thing that happens on checkVar html output filter is BBCode conversion to html.

Live as if you were to die tomorrow, Learn as if you were to live forever

The beauty of a living thing is not the atoms that go into it, but the way those atoms are put together!


Re: ImpressCMS 1.3.3: HTMLPurifier off

A quick fix to the issue reported by Rene is to find the following line (241) in libraries/icms/core/Textsanitizer.php:

$text = icms_core_DataFilter::nl2Br($text);

and simply replace it with
$text = $text;


This seems to work, but I am not 100% sure....



Re: ImpressCMS 1.3.3: HTMLPurifier off

  • 2012/7/31 6:49:19
  • QM-B

@sato-san: As long as there's no other solution in IPF, you can easily check this yourself in you module. Use the checkVar() before insert your content:

In CMS StartHandler.php:


protected function beforeInsert(&$obj) {
$dsc = $obj->getVar("description", "s");
$dsc = icms_core_DataFilter::checkVar($dsc, "html", "input");
$obj->setVar("description", $dsc);

$body = $obj->getVar("extended_text", "s");
$body = icms_core_DataFilter::checkVar($body , "html", "input");
$obj->setVar("description", $dsc);
return TRUE;
}


in Start.php you need to check both for output:

public function getDescription(){
$dsc = $this->getVar("description", "s");
$dsc = icms_core_DataFilter::checkVar($dsc, "html", "output");
return $dsc;
}

public function getExtendedText(){
$body = $this->getVar("extended_text", "s");
$body = icms_core_DataFilter::checkVar($body , "html", "output");
return $body
}


And don't forget to use the function to get the output:
Add to your toArray() function:

$ret['dsc'] = $this->getDescription();
$ret['body'] = $this->getExtendedText();

That's it.. more details for checkVar() you can find here



Re: ImpressCMS 1.3.3: HTMLPurifier off

ok, looking into this in more detail, this seems to be an issue with IPF.

specifically with IPF object

in function getValueFor()

if (method_exists($myts, 'formatForML')) { return $myts->displayTarea($ret, $html, $smiley, $xcode, $image, $br, $formatML); } else { if ($html) { return $myts->displayTarea($ret, $html, $smiley, $xcode, $image, $br); } else { return icms_core_DataFilter::checkVar($ret, 'text', 'output'); } }


and in

function getVar()
case XOBJ_DTYPE_TXTAREA: switch (strtolower($format)) { case 's': case 'show': $ts = icms_core_Textsanitizer::getInstance(); $html = !empty($this->vars['dohtml']['value']) ? 1 : 0; $xcode = (!isset($this->vars['doxcode']['value']) || $this->vars['doxcode']['value'] == 1) ? 1 : 0; $smiley = (!isset($this->vars['dosmiley']['value']) || $this->vars['dosmiley']['value'] == 1) ? 1 : 0; $image = (!isset($this->vars['doimage']['value']) || $this->vars['doimage']['value'] == 1) ? 1 : 0; $br = (!isset($this->vars['dobr']['value']) || $this->vars['dobr']['value'] == 1) ? 1 : 0; if (defined('XOOPS_EDITOR_IS_HTML')) { $br = false; } if ($html) { return $ts->displayTarea($ret, $html, $smiley, $xcode, $image, $br); } else { return icms_core_DataFilter::checkVar($ret, 'text', 'output'); } break 1; case 'e': case 'edit': return htmlspecialchars($ret, ENT_QUOTES); break 1; case 'p': case 'preview': $ts = icms_core_Textsanitizer::getInstance(); $html = !empty($this->vars['dohtml']['value']) ? 1 : 0; $xcode = (!isset($this->vars['doxcode']['value']) || $this->vars['doxcode']['value'] == 1) ? 1 : 0; $smiley = (!isset($this->vars['dosmiley']['value']) || $this->vars['dosmiley']['value'] == 1) ? 1 : 0; $image = (!isset($this->vars['doimage']['value']) || $this->vars['doimage']['value'] == 1) ? 1 : 0; $br = (!isset($this->vars['dobr']['value']) || $this->vars['dobr']['value'] == 1) ? 1 : 0; if ($html) { return $ts->previewTarea($ret, $html, $smiley, $xcode, $image, $br); } else { return icms_core_DataFilter::checkVar($ret, 'text', 'output'); } break 1; case 'f': case 'formpreview': return htmlspecialchars(icms_core_DataFilter::stripSlashesGPC($ret), ENT_QUOTES); break 1; case 'n': case 'none': default: break 1; } break;


as you can see, if ($html) then displayTarea() is used and not checkVar()

I can fix that easily, but my experience in IPF isn't great at mo.
to fix the above, we need to be 100% sure that when an object is stored in the DB using IPF that it has been filtered with checkVar() using the correct methods for input filtering.

However I am unsure whether that is actually happening. I don't see that in the content module which uses IPF.

& I don't see it in the IPF Handler insert/update functions.

it could be added i think, but I am not sure that we would also need to add a type parameter to the object to state whether it's an integer, float, url, text, html etc.

in doing that, any modules using IPF & the core areas that use IPF would need to have this type parameter defined also so that we know which filter types to use with each object.

this boils down to the core needing this input filtering sorting out as a top priority.

I can fix the above temporarily by using checkVar in the above functions defined as input instead of output, but that means filtering will be explicitly done on output when using IPF.

Live as if you were to die tomorrow, Learn as if you were to live forever

The beauty of a living thing is not the atoms that go into it, but the way those atoms are put together!


Re: ImpressCMS 1.3.3: HTMLPurifier off

Madfish wrote:
Quote:


When content, created with the Content module, is saved it stores it correctly in the database. No br-tags, only p-tags.
Upon turning off HTMLpurifier br-tags are inserted when the content is displayed on the frontpage.

The issue is related to the Content module and HTMLpurifier, with Impression this issue doesn't exist.



ok so we're getting somewhere, because the data is stored in the DB without the br tags. we have 2 likely issues.

1. the filtering is being done on input, but when the content is output, it is using either textSanitizer displayTarea() or it is using checkVar() defined as text not html.

2. the filtering is being done on output only instead of on input & is using text not HTML filtering when purifier is disabled.

either way, i'm thinking this is the content module at fault, but i'm not sure. I will take a look at it though.

Sato-san wrote:
Quote:


Right know we have 3 editors, therefore I added the "dobr" function. I don't know what the user like to use, therfore I added this line. Does I don't need it in any case for ImpressCMS 1.3.x right now?

And you are right, only the editors (5 people) can create and edit the content, therefore I dissabled the HTMLPurifier. But as I toled, if I dissable the HTMLPurifier, I get BR tag in my content.
I can solve this, if I write the HTML code in one line. But if I edit the content again, the code is not in one line and I have to fight with it again. However, it's very strange.



I would say this is the same issue related to above with the content module.
either the cms module is using old displayTarea in textSanitizer or it is using checkVar incorrectly as text not html when purifier is disabled. or filtering on output instead of input.

I'll take a look at the cms module also.

dobr is used when textSanitizer displayTarea() was used instead of the newer checkVar() function in DataFilter. it was primarily for use with the old dhtml & xoops editors which utilise the nl2br() function (newline to break)

Live as if you were to die tomorrow, Learn as if you were to live forever

The beauty of a living thing is not the atoms that go into it, but the way those atoms are put together!


Re: ImpressCMS 1.3.3: HTMLPurifier off

Thank you for your fast reply, because I'm almost on despair about the BR tag. In my case, I use the "cms" module, like this:

http://impresscmsdev.assembla.com/code/impresscmsaddons/subversion/nodes/modules/cms

Right know we have 3 editors, therefore I added the "dobr" function. I don't know what the user like to use, therfore I added this line. Does I don't need it in any case for ImpressCMS 1.3.x right now?

And you are right, only the editors (5 people) can create and edit the content, therefore I dissabled the HTMLPurifier. But as I toled, if I dissable the HTMLPurifier, I get BR tag in my content.
I can solve this, if I write the HTML code in one line. But if I edit the content again, the code is not in one line and I have to fight with it again. However, it's very strange.

If you like to reproduce, take the latest ImpressCMS 1.3.2 or 1.3.3, install the sprockets module and the cms module.
Set the TinyMCE in the Generell Preferences as default. Allow the admin to use the TinyMCE for the cms module and create a content with a table tag. After them you can see the line break issue.



Re: ImpressCMS 1.3.3: HTMLPurifier off

Quote:


Vaughan wrote:

but i've noticed with the tinyConfig module, if it's enabled then force_br = false is no longer present in tinymce.php but it is if tinyconfig is disabled.



The issue has nothing to do with TinyConfig. force_br_newlines exists in TinyConfig 1.1, but not in TinyConfig 2.0 because force_br_newlines is redundant in TinyMCE 3.5 branch.

The issue is not related to TinyMCE, because it happens with FCKeditor too.

When content, created with the Content module, is saved it stores it correctly in the database. No br-tags, only p-tags.
Upon turning off HTMLpurifier br-tags are inserted when the content is displayed on the frontpage.

The issue is related to the Content module and HTMLpurifier, with Impression this issue doesn't exist.



Re: ImpressCMS 1.3.3: HTMLPurifier off

what module are you using?

$this->initCommonVar("dobr");


seems to be quite old, dobr is used in the non TinyMCE editors. or if the module is using old textSanitizer displayTarea() instead of DataFilter::checkVar()

but i've noticed with the tinyConfig module, if it's enabled then force_br = false is no longer present in tinymce.php but it is if tinyconfig is disabled.

also if it's a site where there is no user integration. ie. users do not login & post content at all, then there is no need for htmlpurifier to be enabled.
so if the only people that login to your site are content creators who you implicitly trust, then disable purifier.
The thing is Xoops & ICMS are a CMS system, they are supposed to be there to help you build sites with content WITHOUT the need to be creating HTML or code yourself, but from what I'm reading, it seems that some people are wanting to write full blown HTML pages. bit of a cliche there.

so what we need to know is EXACTLY what modules you are using for the content areas where you are seeing these problems. is it the content module? news module, or whatever.

I can't fix something that I can't physically see myself. so I would need to install those modules & actually use them in order to see what's going on & find out where & why it's occuring there. Until I know that, i can't just change the core as it will likely break things for users who aren't seeing those problems.

Live as if you were to die tomorrow, Learn as if you were to live forever

The beauty of a living thing is not the atoms that go into it, but the way those atoms are put together!


Re: ImpressCMS 1.3.3: HTMLPurifier off

This has been a significant problem for me too, as I have a large number of static pages.



Re: ImpressCMS 1.3.3: HTMLPurifier off

If I understand right, than this problem is still since 1.3.x? In fact is, right now it's not possible to create any free content in a module, since the TinyMCE and HTMLPurifier not working well together.

ImpressCMS is a very nice system and has a very nice framework, but I'm not able to create a free content. From a viewpoint of a web designer, it's a absolutely no go (from my personal point of view).

Is there a chance to fix it within 1.3.3?

Example:
I like to create a community portal. The function of HTMLPurifier could be useful and helpful for security.
But if I like to create a business website with more than 2000 pages of content, it's not possible to create flexible and complicated content.


"ImpressCMS brings a lot of third party libraries, but I could not use in a content? What's that then?"

These words are a quotation from 12 ImpressCMS users, not from me


Edit: In my module is a option to handle the BR tag, but it's would not solve the issue.

$this->initCommonVar("dobr");



Re: ImpressCMS 1.3.3: HTMLPurifier off

You haven't really identified the source of the extra line breaks.

Only using the core (no TinyConfig) - and with the version of TinyMCE distributed in the core (3.4.9)

Turn HTML Purifier off, then create some content with TinyMCE. View the source after you save it.

Create the same content with FCKeditor and view it after saving.

Paste the source into the DHTML editor and view it after saving.

Then turn HTML Purifier on and create some content with TinyMCE. View that source after you save it. View the source of the first post now.

Create the new content with FCKeditor and view it after saving.

Paste the source for the new contennt into the DHTML editor and view it after saving.

Vaughan's right - we haven't added a new version of HTML Purifier or TinyMCE to the 1.3.3 branch that is any different than the 1.3.2 branch.



Re: ImpressCMS 1.3.3: HTMLPurifier off

are you using tinyconfig module by any chance?

Live as if you were to die tomorrow, Learn as if you were to live forever

The beauty of a living thing is not the atoms that go into it, but the way those atoms are put together!


Re: ImpressCMS 1.3.3: HTMLPurifier off

in libraries/icms/core/DataFilter.php

find

static public function filterTextareaDisplay($text, $smiley = 1, $icode = 1, $image = 1, $br = 1)


and change the $br = 1 to $br = 0

static public function filterTextareaDisplay($text, $smiley = 1, $icode = 1, $image = 1, $br = 0)


that should fix it. but it's likely to break text entered without using tinymce. ie. the normal xoopseditor. but that all depends on if the content entered is supposed to be text or html. if it's html (even with purifier disabled) it should still use the html display. if it's plaintext then it will use the above function. does this happen with all content, or certain modules etc?

this is 1 of the main reasons we wanted to get rid of all the editors and just use tinymce for everything.

EDIT: just thinking, that can't be the issue, otherwise we would see this problem in previous versions.

Live as if you were to die tomorrow, Learn as if you were to live forever

The beauty of a living thing is not the atoms that go into it, but the way those atoms are put together!


Re: ImpressCMS 1.3.3: HTMLPurifier off

Yes, I can confirm this.

When the the HTMLpurifier is turned off extra br-tags are added between the closing and opening p-tags.

HTMLpurifier ON:

<p>Lorem ipsum dolor sit amet, quando munere corrumpit per et, mea alii choro nostro id. No ubique facilisi ius. Te facete mandamus est. Lorem noster te sed. Pri propriae percipitur an. Admodum evertitur quaerendum eu eam.</p>
<p>Consul iriure eripuit ne eos, quo nonumes civibus et, mea an graecis alienum temporibus. Oratio similique vix in, integre omittam eam te. Augue principes ius id, nonumes fierent volutpat ei vis. Ei clita integre suscipit duo, falli causae minimum eos no. Dicta discere ea eam. Amet ceteros petentium per ad, facer nostrud accumsan has eu, no prompta eruditi nec.</p>
<p>An inermis phaedrum quo, nec eu case scaevola adipiscing. Sea invidunt vituperata interpretaris at, vel te vidisse deleniti, albucius intellegat disputationi ea sea. Sed in perpetua oportere, wisi cotidieque at sea, minim reprimique ex pro. Nibh explicari sed no, graece nonumes cu sea, senserit suavitate ad duo. Nibh deserunt ei mel, enim delicata repudiandae per an. Et qui oratio dignissim persequeris, albucius efficiendi ei nec, te est posse consul temporibus.</p>
<p>Eu pri possim eleifend ocurreret. Te sit decore omittam. Ei ipsum legimus perfecto quo, wisi novum molestiae sea at. Fuisset voluptatibus delicatissimi cu pri, ne duo quem habeo. Cum id erant primis omittam, cu odio tale pertinacia mel.</p>
<p>Sint melius iracundia his eu, no qui veniam nominati aliquando. Pro decore interesset ei, an mel adhuc iriure, sea ne temporibus delicatissimi. Usu et decore insolens periculis. Primis postulant repudiare an duo. Vix brute dolorem et, in per atomorum maluisset concludaturque, probatus argumentum no eam.</p>


HTMLpurifier OFF:
<p>Lorem ipsum dolor sit amet, quando munere corrumpit per et, mea alii choro nostro id. No ubique facilisi ius. Te facete mandamus est. Lorem noster te sed. Pri propriae percipitur an. Admodum evertitur quaerendum eu eam.</p>
<br />
<p>Consul iriure eripuit ne eos, quo nonumes civibus et, mea an graecis alienum temporibus. Oratio similique vix in, integre omittam eam te. Augue principes ius id, nonumes fierent volutpat ei vis. Ei clita integre suscipit duo, falli causae minimum eos no. Dicta discere ea eam. Amet ceteros petentium per ad, facer nostrud accumsan has eu, no prompta eruditi nec.</p>
<br />
<p>An inermis phaedrum quo, nec eu case scaevola adipiscing. Sea invidunt vituperata interpretaris at, vel te vidisse deleniti, albucius intellegat disputationi ea sea. Sed in perpetua oportere, wisi cotidieque at sea, minim reprimique ex pro. Nibh explicari sed no, graece nonumes cu sea, senserit suavitate ad duo. Nibh deserunt ei mel, enim delicata repudiandae per an. Et qui oratio dignissim persequeris, albucius efficiendi ei nec, te est posse consul temporibus.</p>
<br />
<p>Eu pri possim eleifend ocurreret. Te sit decore omittam. Ei ipsum legimus perfecto quo, wisi novum molestiae sea at. Fuisset voluptatibus delicatissimi cu pri, ne duo quem habeo. Cum id erant primis omittam, cu odio tale pertinacia mel.</p>
<br />
<p>Sint melius iracundia his eu, no qui veniam nominati aliquando. Pro decore interesset ei, an mel adhuc iriure, sea ne temporibus delicatissimi. Usu et decore insolens periculis. Primis postulant repudiare an duo. Vix brute dolorem et, in per atomorum maluisset concludaturque, probatus argumentum no eam.</p>




 Top