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.
Related
Silverstripe Display Logic works perfectly on forms in the CMS but I cannot get it to work on forms in the front end, specifically Bootstrap forms.
It will hide the element but won't display it when logic is applied.
//If the wetsuit dropdown is equal to custom then show the fins numerical field.
DisplayLogicWrapper::create(NumericField::create("Fins","Fins"))->displayIf("Wetsuit")->isEqualTo('Custom')->end(),
I see it just needs display to change from none to block.
Is there a way to do this so that it will keep the state on page reload as well? The drop down value will be saved as a DB entry.
EDIT: This works in the CMS but doesn't work in the front end - Custom is part of the enum values.
DropdownField::create("Wetsuit","Wetsuit")
->setSource(singleton('DiveEquipment')->dbObject('Wetsuit')->enumValues())
->setEmptyString('Select one'),
NumericField::create('Fins','Fins')
->displayIf('Wetsuit')
->isEqualTo('Custom')
->end(),
EDIT2: Working with SilversTripe 3.5, Bootstrap Forms 1.20 and Display Logic 1.0.8
1.0.8 is very outdated though.
I don't think you need the DisplayLogicWrapper for most fields… It's meant for fields like UploadField.
Have you tried this?
NumericField::create('Fins','Fins')
->displayIf('Wetsuit')
->isEqualTo('Custom')
->end(),
Not the issue here, but it's worth noting that a bug exists in Display Logic 1.3 and lower where the custom templates exist in /templates/ not /templates/forms/, causing precedence issues.
If you're experiencing problems with a FieldGroup not rendering the correct template or whatnot. Upgrading to Display Logic 1.4 will resolve this.
You'll need to include jQuery and jQuery Entwine for this to work on the frontend. This is untested but should resolve your issue.
class Page_Controller extends ContentController {
public function init() {
parent::init();
Requirements::javascript(THIRDPARTY_DIR . '/jquery/jquery.js');
Requirements::javascript(THIRDPARTY_DIR . '/jquery-entwine/dist/jquery.entwine-dist.js');
}
}
I am working on an issue raised by the security team about a possible XSS attack on a few input fields on our form. Our freemarker page has the following code.
<#assign zipcode = someObject.getInfo().getZipCodeFirstFive()>
I read up on HTML encoding and it talks about adding ?html at the end but I couldn't find the freemarker syntax anywhere. So, could I do something like
<#assign zipcode = (someObject.getInfo().getZipCodeFirstFive())?html>
to make it output encoded?
Yes, that would be a possible syntax for this, though I would recommend two things to make it more readable:
You don't need the extra (), you can just write someObject.getInfo().getZipCodeFirstFive()?html
It's unrelated to escaping, but you don't need to write out getters either, so you end up with someObject.info.zipCodeFirstFive?html
On the longer term, I would recommend escaping by default. Before 2.3.24 that's done by surrounding each template by <#escape x as x?html>...</#escape>. Starting from 2.3.24 the recommended methods is auto-escaping set up globally, in the Configuration.
how to change the default SPLIT_PATTERN_SHORTHANDSYNTAX ({value}) by using the StandaloneView?
My Problem:
I have to render several LaTeX pages with different content. So I will use FLUID (Template/Partials). However there is the same Problem as in JS.... Is it possible to change the default "{value}" width ###value###???
The SPLIT_PATTERN_SHORTHANDSYNTAX static variable is defined in the TemplateParser.php but how can I change this dynamically by using a PHPView or StandaloneView?
Best regards Jürgen
This is not possible to do and a feature request to add this capability has been discussed and rejected. Please see https://github.com/TYPO3Fluid/Fluid/issues/106 for more information. Consider using CDATA wrapping to protect (parts of) your template from being processed as Fluid.
I'm building a website using brython and I came by a problem that has nothign to do with it.
My problem is with Mezzanine or TinyMCE editor (I'm not sure which). To make brython work I need the script tag to be "text/python". But the editor filters it automatically to "text/javascript".
I disabled the filtering already, both in the admin panel and in the actual source code, I tried adding "text/python" to the RICHTEXT_ALLOWED defaults in the mezzanine configuration too.
Just to be clear, security is not an issue, this particular feature won't go online in the final version of the website.
Although the HTML specification does allow one to put any value other than "text/javascript" in script's type attribute, few projects do that, and Brython is one of those few. It is likely the "text/javascript" value is simply hardcoded in the editor and it won't allow you to change that.
(There is probably a big chance of having an issue closed as "won't fix/not a bug" or equivalent if you try to report this to the editor's issue tracker).
I think the workaround in this case is to write some javascript to change the text on the attribute on the relevant script tags to "text/python" prior to calling Brython. i.e., instead of triggering Brython on your page with
<body onload="brython()" >
Do something along
<body onload="function (){var x = document.getElementsByName("python"); for(var i=0; i < x.length; x++){x.type="text/python"};brython()}()" >
(and of course, add the attribute name='python' to all your python script tags)
I'm using a transmorgrifier recipe to import some data from drupal into a Plone 4.1 based buildout. The buildout is based on https://github.com/claytron/drupal-plone-transmogrifier, (mostly I updated it to use plone 4.1 instead of 4.0). The import works, I successfully imported data from a drupal site into my plone site. The only issue is that the html tags from the imported html show as the literal tags.
If, after the successful import, I manually go to each item and select 'edit' then click 'save' then the html is interpreted properly, but that would be a lot of editing and saving in order to fix my problem.
see screenshot of freshly imported content with html tags showing.
The blueprint doing the actual import of the field is (I believe) the one shown below:
[text_mimetype]
blueprint = collective.transmogrifier.sections.inserter
key = string:_text_mimetype
value = string:text/html
I experimented with using text/structured instead of text/html in the blueprint but that gave the same result:
What I need is either an additional blueprint that causes the html to be interpreted or a hints on how to ensure that my html gets interpreted at import.
The full list of blueprints used in my pipeline are shown here:
https://github.com/claytron/drupal-plone-transmogrifier/blob/master/src/my.migration/my/migration/config/base.cfg
Ran into the same problem when migrating content using wsapi4plone.core.
Solution: Pin zope.contenttype to version 3.5.5 (the default in the upcoming 4.1.1)
Cause: PLIP #9938 - http://dev.plone.org/plone/ticket/9938 as per esteele.
If it works under Plone 4.0 but not under Plone 4.1, then I'm guessing it has to do with the "factor custom output transformations out of the editors" PLIP that was merged as a part of the Plone 4.1. I would look into the changes from that PLIP and see how the pipeline needs to be adjusted.
Actually that section only insert a value "text/html" in the key "_text_mimetype"
The real encapsulation is done here:
[mimetype_encapsulator]
data-key = text
mimetype = python:item.get('_%s_mimetype' % key)
# replace the data in-place
field = key
condition = mimetype
more info: http://pypi.python.org/pypi/plone.app.transmogrifier#mime-encapsulator-section
Anyway i've experimented that it's not strictly mandatory to encapsulate the html text, it works also with a simple string.
Bye, Giacomo