Thread

Alright, I am looking into this further and will get back to you once I have further information.  Thank you, ron00nor.

Sorry for the confusion on this one, ron00nor.  I’ve updated the kblog entry to note that br and p tags cannot be overridden simply by adding them to the array.  In truth, I would choose ‘Allow all’ if compatibility with a WYSIWYG editor is mission critical.

However, if using ‘Safe html’ and consequently hacking the core.typography.php file is necessary, you can try adding br and p to the ‘safe’ lists as per the kblog- and then edit around line 629.  You would need to move the conversion of the safe_encode snippet above the br/p replacement, a la:

// Convert allowed HTML to pMcode
        
        foreach($this->safe_encode as $val)
        {
            $str = preg_replace("#<".$val.">(.+?)</".$val.">#si", "[$val]\\1[/$val]", $str);
        }

       // Turn 
 tags into newlines
        
    $str = preg_replace("#
|
#i", "\n", $str);
        
    //Strip paragraph tags
        
    $str = preg_replace("#|]*   >|#i", "",  preg_replace("#<\/p>]*   >#i", "\n", $str));

Again- I wouldn’t recommend hacking and believe ‘Allow all’ would be preferable.  Hacks aren’t officially supported.  But if it’s mission critical, give the above a try.

Make sense?

Thanks,
I will give this a try. Saves my a lot of messing with supplementary fields.

Hi,

This last suggestion works perfect! Thanks.

However after having solved this issue the next one arises. I have been testing a bit around and here are my results:

The weblog is set to ‘Allow only safe HTML’. Am I right that only the HTML as listed earlier is allowed and all other is stripped out?
Entering is done in two ways: one through the CP and the other through a SAEF.

Here is what I can do:
....
and

*****

Nothing is stripped. Both HTML tags are accepted on making the entry and displaying the entry. It also makes no difference if the Field Type is set to WYSIWYG or Textarea.
This tags are not listed as ‘Safe’.

Am I missing something?

Hrm- the h tags are listed under safe in the docs- and if you take a look, it’s adding them to the array separately:

if ($allow_headings == TRUE)
        {
            foreach (array('h2', 'h3', 'h4', 'h5', 'h6') as $val)
            {
                $this->safe_encode[] = $val;
                $this->safe_decode[$val] = $val;
            }
        }

The anchors aren’t in the docs list, but it’s expected behavior as well.  They’re basically converted to pm code links and processed as such, which is intended.  There’s quite a bit going on in the typography class, so it can be a bit difficult to track it.  Let me do a little confering on tweaking the docs for re: links.  But it is intended behavior.

Hi Robin,Lisa,Greg,Ingmar,

I overlooked the <h> code in the docs. It’s indeed also safe. The <a > I can live with. Checking with a piece of embedded code the weblog behaves like expected: the embedded code is shown as text. All safe HTML is processed well.

All in all, with the little hack in the typography class, I’m quiet satisfied!

Thank you all for enduring my persistence but the result is that I now fully understand this part of ExpressionEngine.

A very warm new year wish from here to the EE team.
Hopefully we will get an ‘exciting’ 2.0 09

Glad you were able to achieve a successful resolution, ron00nor!