Thread

Hi Supply,

I think we may need to take a look for ourselves.

Please be on the lookout for an email from EllisLab.

Cheers,

Supply,

One more thing!

Can you show the the template code where you are calling this text area?

Cheers,

Sweet as.

I’ve since discovered after looking in the database, that the output is what is being saved. Which is weird because the input is restored when I go to edit the entry.

here is the template({page_copy} is the RTE field):

{exp:channel:entries channel="pages" disable="categories|category_fields|member_data|pagination"}
{if no_result}{redirect="404"}{/if}

{embed="includes/header" title="{title}"}

 <section id="window">

  {embed="includes/navigation"}
  
  <aside>
   <a href="{homepage}" class="logo"><img src="/static/images/logo.png" alt="{site_name}"></a>
   <div>{exp:ce_img:single src="{page_tile}" width="200" height="200"}</div>
  </aside>

  <article>
   {page_copy}
  </article>
  
 </section>

{embed="includes/footer"}
{/exp:channel:entries}

Hi, everybody!

I compared the code of textarea and RTE fieldtypes.

In case textarea is set to XHTML or Auto <br />, the content of the field is parsed by $this->EE->typography on templates.

system/expressionengine/fieldtypes/textarea/ft.textarea.php:

return $this->EE->typography->parse_type(
   $this->EE->functions->encode_ee_tags($data),
   array(
    'text_format' => $this->row['field_ft_'.$this->field_id],
    'html_format' => $this->row['channel_html_formatting'],
    'auto_links' => $this->row['channel_auto_link_urls'],
    'allow_img_url' => $this->row['channel_allow_img_urls']
   )
  );

RTE returns the data as it is in the database.

sytem/expressionengine/modules/rte/ft.rte.php:

function replace_tag($data, $params = '', $tagdata = '')
 {
  return $data;
 }

There’s a function to check for a converted fieldtype, but just on edition:

if ($field_ft == 'xhtml')
  {
   $data = trim($data);

   // Undo any existing newline formatting. Typography will change
   // it anyways and the rtf will add its own. Having this here
   // prevents growing-newline syndrome in the rtf and lets us switch
   // between rtf and non-rtf.

   $data = preg_replace("/<\/p>\n*/is", "\n\n", $data);
   $data = preg_replace("/<br( \/)?>\n/is", "\n", $data);
  }

So, I replaced the function replace_tag of rte by:

function replace_tag($data, $params = '', $tagdata = '')
 {
  return $this->EE->typography->parse_type(
   $this->EE->functions->encode_ee_tags($data),
   array(
    'text_format' => $this->row['field_ft_'.$this->field_id],
    'html_format' => $this->row['channel_html_formatting'],
    'auto_links' => $this->row['channel_auto_link_urls'],
    'allow_img_url' => $this->row['channel_allow_img_urls']
   )
  );
 }

This way, everything works as expected. The old textarea fieldtypes are parsed correctly without need of edition.

Could some developer of EllisLab check if I’m right?

Thanks, guys!

One more thing!

I believe RTE shouldn’t save paragraph tags. For better the editor could be, is virtually impossible to avoid to edit the code sometimes. Even an user who doesn’t know HTML, some day could have to edit some lines.

By this perspective, less tags is better. If I can eliminate the need to edit some tags, we should do.

I know that is better to performance to save the data ready for output, but if we need the $this->EE->typography for backward compatibility to the old textarea fieldtypes anyway, keep the paragraph and break line tags out of the field data looks a better option.

Well, Robin and Mathias are the better voices to hear in this matter than me, I guess.

Thanks!

——————————————————————————————-

P.S.: This will prevent this bugs, too: https://support.ellislab.com/bugs/detail/17931 , https://support.ellislab.com/bugs/detail/17907

Good work Robson. I’m looking forward to verification on this as well. This is a very important thread for me.

Ditto mmcgeeCC, nice work tracking it down, Robson.  I’ve bumped it up to the devs as a bug- Pascal was thinking that xhtml switch should maybe happen on the switch, rather than edit.  But they haven’t gone in and fixed/tested a final solution yet.  Just wanted to note it’s currently on their radar.

Hi, Robin!

Please, forgive me to insist on this, but I’m curious about.

Why does not to add the paragraph and breakline tags on template parsing, as already happens with textarea fields? Besides the point I mentioned before, looks a little dangerous to convert all data on switch. Even with backups, on large sites some bugs could just be found after the publishing of new data.

Thank you so much for your attention!

Hi, Shane.

I’m not sure, but I believe

validates on both doctypes. So, looks a better choice.

Tags ending with [space]> are indeed valid in HTML 5.

I prefer them. It looks like a number of markup decisions were made in the RTE (using <b> and <i>, etc.) that really should be left to the developer. Isn’t EE supposed to be the CMS that lets us control our markup? That’s why I chose it in the first place.

I agree, Dylan. I chose EE by the same reason.

Talking about standards, STRONG and EM still are the tags for emphasis, while B and I is used for “typographic reasons”. So, most of time, STRONG and EM are tags more for use of authors, while B and I is for developers.

Because of this, I believe RTE should use STRONG and EM.

I agree with both Dylan & Robson’s comments. self closing tags are valid and should be allowed (I prefer them too), and strong & em should be used by default over b & i.

Hey Robson,

Robin is away this week at EECI in Europe. I am sure she will respond.

I would ask that any comments further on the topic be put into a new thread that references this one. This thread is becoming quite the beast. We appreciate your feedback, but ultimately the Devs went with what they thought was the best. Feature Request are welcomed!

Thanks,

Going back to the original topic, what was the decision about the P and BR tags? Some news?

Please, don’t tell you are going to convert all old fields on the switch of the field type. On big sites, is impossible to check if the conversion worked fine.

Since a user found the not obfuscated file of the RTE, I’m tempted to fix this by myself.

Thanks, guys.

If Ellislab aren’t going to fix it, I’d sure appreciate if you did and shared it around.
The RTE in its current state is not usable.

Hi Robson,

Since a user found the not obfuscated file of the RTE, I’m tempted to fix this by myself.

We don’t obfuscate any of our code in ExpressionEngine. We do compress most of the JavaScript, but that is easily undone.

As Shane noted above, I’ll ask that any new issues with the RTE be noted in a new thread and that and ideas for improvements be made in the Feature Request Forum. Keep in mind, the RTE is only one Feature Release old and there is lots of room for improvement 😊

I’m going to move this over to Community Help to preserve the conversation and let the discussion continue!

Thanks all for your input and feedback, we really do appreciate it.

Cheers!