Why am I getting \(backward slash) in style of tiny mce? - tinymce

I am getting output like <p>hiii <span style=\"background-color: rgb(224, 62, 45);\">highlighted</span></p>
Don't know why I am getting this slashes in style attribute.
Also when configuring to get underlined text it gives similar o/p(that is backward slashes in style attribute)
I am using it in angular app
"#tinymce/tinymce-angular": "^7.0.0"
"#angular-devkit/build-angular": "^14.2.4"
To tackle underlined issue I configured it to use u tag instead but now need solution for those back slashes

Related

TYPO3 / Fluid: Inline Viewhelper notation in Templates of FluidEmail

I’m using the new TYPO3\CMS\Core\Mail\FluidEmail feature of TYPO3 v10.3 to send HTML system e-mails. Unfortunately, I’m experiencing a weird behavior with Viewhelpers in the e-mail Templates. Calling the regular Viewhelper notation like e.g. <f:uri.resource extensionName="backend" path="Images/typo3_orange.svg"/> works as expected. But inline notations of the same Viewhelper (like {f:uri.resource(extensionName: 'backend', path: 'Images/typo3_orange.svg')}) don’t get processed at all.
Surprisingly, when I call the regular notation first and the inline notation afterwards in the same template, both notations get resolved.
I also experienced that no fluid variables are accessible in the template, e.g. {normalizedParams}, which should be available when you set the request like $message->setRequest($GLOBALS['TYPO3_REQUEST']);
Did anyone experience a similar behavior and has a hint for me?
Here's my implementation in my Controller Action:
$message = GeneralUtility::makeInstance(FluidEmail::class);
$message
->to($email)
->format(FluidEmail::FORMAT_HTML)
->setTemplate('MyTemplate')
->assign('pages', $pages);
if ($GLOBALS['TYPO3_REQUEST'] instanceof ServerRequestInterface) {
$message->setRequest($GLOBALS['TYPO3_REQUEST']);
}
GeneralUtility::makeInstance(Mailer::class)->send($message);
Reference: https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/10.3/Feature-90266-Fluid-basedTemplatedEmails.html
Sounds like a fluid parsing problem. Do you have any { or } flying around in your template that could mess up fluids parsing?
Just run into the same problem with one of my in-house plugins after switching from php7.2 to php7.4 (when switching back to php7.2 the resource path was resolved again correctly).
It turned out that some inline javascript using curly brackets further down the page was to blame (thank you Daniel). Putting it in a separate file solved the issue. It would appear that the use of inline JS is tolerated to different degrees depending on the php version being used.

CQ Dialog: Possible to provide placeholder in text?

We have a requirement wherein a section of a page will be part authorable and part dynamic. What I mean by this is "You have 6 visits left out of 16." The 6 and 16 in the sentence are coming from a REST service call but the text "You have...visits left out of.." has to be authorable through dialog. Also, we are using AEM 6.
Thanks in advance
Maybe this solution will help others looking for simple placeholder text for their dialog textfields (OP not so much). Use an emptyText attribute...
<dialogText fieldLabel="AEM CLassic UI Text" jcr:primaryType="cq:Widget"
name="./nameOfText" emptyText="THIS IS THE PLACEHOLDER" xtype="textfield"/>
Perhaps you can start by extending foundation/components/text, where the user would be expected to enter a valid formatable string (i.e. "You have %d visits left out of %d").
In your component you would be implementing text.jsp therefore overriding the default behavior of foundation/components/text, in which you can do something like
<cq:text property="text" escapeXml="true"
placeholder="<%= Placeholder.getDefaultPlaceholder(slingRequest, component, null)%>"
tagName="span"
tagClass="myformatedmessage" />
You use tagName and tagClass which will wind up putting the formattable text in a <span class="myformatedmessage">...</span>. Then use jQuery to find it and populate the format placeholders after getting the data via ajax. All that jQuery code you can probably put into a clientlib folder within the same component you extended.
Based on your description, I think you are looking for replacement or substitution instead of placeholders.
"placeholder" generally refers to display text inside a form input that is displayed until the user enters data in the field (such as hint data).
You generally have 3 options for replacing parts of the data:
Server-side (prevents page from being cacheable in dispatcher). Requires parsing authored content & replace some kind of tags with desired REST data, such as "You have ${x} visits left out of ${y} total". Other ways of "tagging" substitution data could look like "You have %x% visits left out of %y%"
client-side JavaScript DOM manipulation once REST data returns. ie $el.html(newDomContentString)
client-side JavaScript templates (handlebars, dust, etc). Takes more initial setup in JS, but generally scales better.

Disable escape in Zend Form Element Submit

I can't disable escaping in a Zend_Form_Element_Submit, so when the label has special characters it won't display it's value..
This is my actual Zend Form piece of code:
$this->submit = new Zend_Form_Element_Submit('submit');
$this->submit->setLabel('Iniciar Sesión');
$this->submit->setIgnore(true);
$this->addElement($this->submit);
I've tried $this->submit->getDecorator('Label')->setOption('escape', false); but I obtain an "non-object" error (maybe submit isn't using the "Label" Decorator)..
I've also tried as suggested $this->submit->setAttrib('escape', false); but no text will be shown either.. Any idea? Thanks
Should be as simple as doing this:
$element->addDecorator('Label', аrray('escape'=>false));
Or see setEscape(). http://framework.zend.com/manual/1.12/en/zend.form.standardDecorators.html
Regarding failure to retrieve named decorator... Try getDecorators() Do you see 'label' in the results?
There is no Label decorator for submit form element by default (this is why you get the error).
The $this->submit->setLabel('Iniciar Sesión'); value goes to Zend_View_Helper_FormSubmit, which always does escaping and uses the label as a value.
The helper used by the Submit element escapes by default. Unlike with the label decorator, submit labels are included in a HTML attribute so they need to be escaped.
Your label - Iniciar Sesión - is a perfectly valid UTF-8 string, so the escaped version of it will be the same. If your label is not appearing then something else is going wrong. I'd guess that your page is being served using a charset that doesn't match what Zend View is using (UTF-8 by default).
View the page source to see what actually gets output - that might give you some more clues. Alternatively if the page this form is on is public, if you can provide a URL we might be able to spot the issue.
I ran into a similar issue. In my instance, I added both a label and a description to a text field element. This line of code allowed me to turn off the html escaping for the description attached to that field element:
$form->getElement('txtUPC')->getDecorator('description')->setOption('escape', false);
In my testing, the setEscape() was not recognized by the form elements or their decorators.

Convert links in blockquotes to plain text

So, I've been asking a lot of Xpath questions recently.
Sorry, but I've only just started using it, and I'm working on a kind of hard project.
You see, at the moment I'm parsing HTML like this (not a copy and paste, just an example):
<span id="no153434"></span>
<blockquote>Text here.<br/>More text.<br/>Some more text.</blockquote>
And I'm using
//span[starts-with(#id, 'no')]/following::*[1][name()='blockquote']//node()
To get the text inside.
It's working fine, although it's very frustrating. I need to manually check for then manually combine the strings before and after the br, add a newline, and so on. But it stills works. Until there is a link in the text, that is. Then the code is like this:
<span id="no153434"></span>
<blockquote>Text here.<br/>Text.<br/><font class = "unkfunc">linkhere</font></blockquote>
I have absolutely NO idea where to go from here, as the link is included as a completely seperate item (twice) in the array. Atleast with the br I knew where it had to be moved to. Really contemplating giving up in this project after all this effort.
You can use this XPath to obtain text inside element: //span[starts-with(#id, 'no')]/following::*[1][name()='blockquote']//text()
So you receive following result:
Text here.
Text.
linkhere
If you want only text nodes and br:
//span
[starts-with(#id, 'no')]/
following::*[1][name()='blockquote']
//node()
[ count(.|..//text()) = count(..//text())
or
name()='br'
]
returns
Text here.
<br />
Text.
<br />
linkhere
The answer is to not use XPath for this kind of work.
Got it working 1,000,000x easier with Objective-C-HTML-Parser.

encode url not encoding

I am working in a template in Moveable Type and would like to do the following:
Twitter
It all works but I'm worried that the current link or at some point even if I use a title mt tag that it might not be right for the browser address bar. I thought you could use encode_url="1" but it doesn't appear to encode my titles or links. For example: I have a title with spaces in it and the resulting code still has the spaces in it. Also for the example above shouldn't the http:// be encoded in a special way? Because it doesn't do it.
Am I doing something wrong here?
I just checked this code and it is outputting properly for me. I am using MT 4.34. I used the following template code in an index templated:
<mt:Var name="url" value="http://google.com/hello I have spaces">
<mt:Entries lastn="1">
Permalink: <mt:EntryPermalink encode_url="1"><br />
Fake URL: <mt:Var name="url" encode_url="1">
</mt:Entries>
And I got the following output:
Permalink: http%3A%2F%2Fwww.capndesign.com%2Farchives%2F2010%2F09%2Fthe_big_picture_scenes_from_china.php
Fake URL: http%3A%2F%2Fgoogle.com%2Fhello%20I%20have%20spaces
So I would confirm that you're using a current version of MT (4.34 or 5.x) that supports this modifier, because the spaces and special characters should definitely be getting replaced with HTML entities. I'd also try the code I provided above to see if you get the same output (except your permalink will obviously be different).